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

[Russ Housley <[e-mail]>]

DKG:

> 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.

Correct.  I have -03 in an edit buffer, but I was hoping to hear back from you before posting it.

> 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?

I do not agree.  I'd like to hear from my co-authors.

The biggest changes are the result of merging RFC 3709 and RFC 6170.  In fact, I looked at a diff, and there are very modest changes before Section 4.2, which is where the material from RFC 6170 begins.

> 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.

The fact that there are few changes in the prior to Section 4.2 helps someone that has already implemented RFC 3709 understand what changed.

> 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.

Yes, we want a quality specification.  I am starting with the assumption that there was consensus for RFC 3709.

> 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.

The point that this document has few changes since RFC 3709 prior to Section 4.2 is proof that is not the case.

>>>> [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.

I've already said why I do not think that is the right approach.  That said, if others support this position, then I will bend to the consensus. (The consensus call will be made by Tim.)

>>> 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.

I think that CAs will decide which of the approaches will be deployed in the certificates that they issue.  The much strengthed privacy considerations is giving them a lot more information to make this decision.

>>>> 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?

At the top:

   LogotypeExtn ::= SEQUENCE {
      communityLogos  [0] EXPLICIT SEQUENCE OF LogotypeInfo OPTIONAL,
      issuerLogo      [1] EXPLICIT LogotypeInfo OPTIONAL,
      subjectLogo     [2] EXPLICIT LogotypeInfo OPTIONAL,
      otherLogos      [3] EXPLICIT SEQUENCE OF OtherLogotypeInfo
                             OPTIONAL }

All of them are available for display.  Ii is all oc the communities that are associated with this certificate, the issuer, the subject, and all of the other logos that are associated with the certificate.

I have not seen an actual certificate that uses all of this capability, but more of this capability could be used as logos become more prevalent.


Deeper in the structure:

   LogotypeData ::= SEQUENCE {
      image           SEQUENCE OF LogotypeImage OPTIONAL,
      audio           [1] SEQUENCE OF LogotypeAudio OPTIONAL }

Choose one image and one audio.

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

I think I can do that.  I'll try to find the time.

Will an example that has two community logos (both to be displayed) and two subject logos (one to be displayed) be good enough to make this point?  Of course, they will all be bogus URLs under example.com <http://example.com/>, example.net <http://example.net/>, and example.org <http://example.org/>.

>> 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.

Of course TLS 1.3 is used many places beyond the Web.

I am not opposed to logotypes being used in the Web, but it has not happened so far.

>>> 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?

There are implementations.  I took this posting to be a public indication of an implementation:

https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=spasm&q=from%3A%28Corey%29&as=1 <https://mailarchive.ietf.org/arch/search/?qdr=a&start_date=&end_date=&email_list=spasm&q=from:(Corey)&as=1>

>>>> 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.

I am very confused by this comment.  Only relying parties perform certificate path construction and validation.

>> 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.

As I already said at the top of this message, it helps with the diff.  The simple diff helps people that already implemented RFC 3709.

Russ