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

Hi Daniel,

I'm going to adress your concern on an even higher level and not go into 
any specific details.

First my great thanks to you for your effort and time to review this work.

However, this update was initiated to adress a few minor issues with the 
updated documents. On this path, we have attempted to fix some other 
obvious things as well. But, and this is important, we never intended to 
do a complete rewrite and to fix any wording that possibly could be 
improved.

There is also a value to preserve as much as possible of the original 
documents, unless there is a very clear and distinct reason to change 
them. The reason is that the more you change a document, the harder it 
is for both reviewers and implementers to understand what the 
differences are. This was the reason why we once in PKIX dropped an 
effort to make a complete rewrite of OCSP in favour of just updating 
what was broken, even if the old document was not perfect and could have 
a much better structure.

There is a limit to the effort that is reasonable to put into this 
update. I'd say that we have done more than enough unless there is a 
clear and sufficient problem that needs to be resolved to avoid a 
serious interoperability issue or security threat.

Daniel, do you have any showstopper that absolutely must be fixed?

/Stefan

On 2022-06-15 18:59, Daniel Kahn Gillmor wrote:
> 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
>
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm