Re: [lamps] draft-ietf-lamps-rfc3709bis-01 security, reliability, and privacy considerations

[Daniel Kahn Gillmor <[e-mail]>]

Hi Russ--

Thanks for the more in-depth review, and for the concrete feedback and
offered improvements on several different points.  It looks like many of
the details i raised are now going to be addressed, although i don't
know where to look for specific improvements to the draft.  i don't
think an -03 has been released, and i don't know of any public revision
control that i can use to confirm how specific text has been updated.

This message comments on a few of the higher-level concerns, rather than
going into the details:

On Wed 2022-06-01 17:38:06 -0400, Russ Housley wrote:
> I'm trying to achieve a balance in the changes.  I'd really like to
> preserve as much of the original text in RFC 3709 as possible.  I'm
> not trying to avoid clarity, but I am trying to avoid changes that are
> purely editorial.

I think this high-level decision is a mistake.  This document
substantively changes RFC 3709 in some fairly significant ways,
including the merging of RFC 6170's Certificate Image "Logotype", which
is one of the primary ways that these embedded media are *not* logotypes
at all.  Who benefits from its text being similar to RFC 3709?  Who
would benefit from the standard being written to be read alone?

When this document is released, RFC 3709 (and 6170) will move to
"obsolete" status, and this will be the canonical reference for any
X.509 certificate with embedded media.  Please consider making the new
canonical reference (this document) something that makes sense and
stands on its own, without requiring the reader to already know the
backstory behind how we got here.

I'm not suggesting here that you change any technical wire format
details, i'm suggesting that framing this document clearly ("purely
editorial" changes) has a significant impact on its utility.

The RFC development process is not about trying to produce minimal
diffs.  It's about trying to produce a useful canonical resource.

If your goal for minimal diffs is about how someone needs to modify an
RFC 3709 implementation to cover material in this draft, then the
appropriate way to solve that problem is to ensure that the "Changes
Since…" subsection is adequate for the task.  New implementers shouldn't
have to read or understand RFC 3709 to make sense of what's happening
here.

>>> [re: "logotype data" vs. LogotypeData"]

I think this is a major source of unnecessary confusion in the draft,
and if the draft was re-titled/re-framed as something like "Multimedia
in X.509 Certificates (historically called 'Logotypes')" then it would
be relatively simple to change from "logotype data" to something like "a
multimedia resource", thereby eliminating this source of confusion.

>> On Tue 2022-03-29 18:17:02 -0400, Daniel Kahn Gillmor wrote:
>>> Furthermore, the draft doesn't do much to try to alleviate size concerns
>>> at all -- it almost looks like an afterthought.  For example, if the
>>> draft really wanted to prioritize minimizing certificate size, then it
>>> would offer an ASN.1 native OCTET STRING representation for the embedded
>>> objects, rather than stuffing another layer of base64-encoding with the
>>> data: URL.
>> 
>> I have seen no attempt to address this tradeoff.  The draft could
>> mitigate at least some of the size concern by specifying a compact way
>> to encode in-band data.  It does not do so, and it does not even try to
>> justify why it does not do so.
>
> I do not think we should address this one.  Doing so would be a move
> away from the syntax in RFC 3709.  At least that was the outcome from
> my perspective from the exchange between you and Stefan on the LAMPS
> WG mail list a few weeks ago.

I agree that making such a change would introduce a new wire format, one
not already currently supported by existing implementations.  I don't
think it would invalidate existing certificates that use the
base64-encoded data: URL format, but it would offer a way to reduce the
incentive to make privacy-leaking network-based media retrieval a part
of new certificates.

If trying to improve privacy is not the goal of this draft, i can
understand that, even though i think it is a disappointing missed
opportunity.

>>> what i still don't understand, after several re-reads of the draft, is
>>> why the LogotypeData can have more than one image and more than one
>>> audio element.  Or maybe LogotypeData offers multiple distinct digital
>>> representations of the same object by enclosing a sequence of
>>> LogotypeImage objects?  but then i don't understand why there are
>>> multiple LogotypeDetails objects within a LogotypeImage object.
>>> 
>>> Maybe the draft itself could offer a succinct explanation of why each of
>>> these layers is present?
>> 
>> The rationale for every layer remains unclear to me after several
>> re-reads of the draft and having this e-mail exchange.
>
> Again, changes to this are not on the table.  We are preserving compatibility with the syntax in RFC 3709.

I don't think you're understanding me here.  I'm not asking for changes
in the structure of the wire format.

I have read (and re-read) the draft, and RFC 3709, and i am *still* not
confident that I understand the rationale for every layer of SEQUENCE OF
or SEQUENCE SIZE that appears in the ASN.1 structure.  It's possible
that i'm particularly dense, but i doubt i'll be the only person in this
situation.

I'm not saying that this draft should change the wire format.  I'm
saying that the draft could be much clearer about the rationale for each
layer of arbitrary SEQUENCE.  Some of them are for different semantics
of multimedia (the "SEQUENCE OF" in communityLogos or otherLogos); some
of them are for differently-formatted variants of the same underlying
visual or acoustic pattern (the "SEQUENCE OF" in LogotypeData); some of
them are for different places to try fetching the same underlying octet
stream (the "SEQUENCE SIZE"s in LogotypeReference or LogotypeDetails).
Is that it?

If so, a clear summary or a set of examples that exercise each sequence
would be a useful thing in the document.

> While the privacy improvements in TLS 1.3 are important, the Web PKI
> has seen no adoption of RFC 3709.

If you don't expect this to be in the WebPKI, then i think it might be
useful for the document to observe some specific contexts where this
mechanism is concretely useful.

I also note that TLS 1.3 is not exclusively used by the Web.

>> draft-ietf-lamps-samples is now RFC 9216.  Please include some full
>> X.509 test vectors.
>
> Some implementers that have found these examples sufficient.  I'd like
> to hear from an implementer that the additional work would really be
> helpful before putting in the effort.

I don't think i've heard from any implementers at all, at least in
on-list discussion, though i might have missed it.  Can you help me
understand what effort is involved in including test vectors?  I would
assume that any implementer -- of tooling for a CA, relying party, or
subscriber -- has test vectors of their own for their own internal
testing.  And presumably an easy way to generate such a thing as well.
Can we not just reuse one of those?  Is there any reason to think that a
sample certificate itself would be proprietary?

>>> v) "5. Type of Certificates" says:
>>> 
>>>     logotypes MUST NOT be part of certification path validation or any
>>>     type of automated processing.
>>> 
>>>   but this seems to be in conflict with requirements like "The
>>>   background image MUST allow black text to be clearly read when placed
>>>   on top of the background image." which would presumably be enforced
>>>   by the certificate issuer via automated processing.
>>> 
>>>   Perhaps this is supposed to mean "any type of automated processing by
>>>   the relying party" or "any type of automated processing during
>>>   certificate validation"?
>> 
>> This item (v) is also still not addressed.  Are we really saying that an
>> issuer MUST NOT attempt to confirm (for example) that two formats of
>> visual representation are actually roughly visually similar, using (for
>> example) a conversion to raw pixels and then some sort of distance metric?
>
> I think you are misreading this one.  Path validation is specified in
> Section 6 or RFC 5280.  I'll add an explicit reference.  This is not
> saying anything whatsoever about the vetting that a CA might perform
> prior to including the logotype data in the certificate.

The text just says "or any type of automated processing", in addition to
certification path validation.  This is one of several examples in the
document where the document appears to implicitly refer to one
particular party involved with a certificate (in this case, the relying
party) but not considering how the text reads in the context of one of
the other parties involved (e.g. the subscriber, the issuing authority,
the resource host, an implementer, etc).

That potential confusion makes it difficult to apply the document.
Being explicit would be make it easier to use safely.

> There already are subsections for each of the otherType OIDs.
>
> There is really one paragraph that for each of the the "three standard
> logotype types". I cannot see how making those subsections would be
> helpful.

Having an explicit subsection (even if it contains only a single
paragraph) per logotype context makes it easier for people to refer to
them in discussions, or in comments in an implementation.

It also makes a glance at the table of contents more informative, as the
most prominent contextual uses are more visible, which in turn makes the
document easier to follow.

I can't see the downside to a clearer document structure.

Regards,

  --dkg