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

[Russ Housley <[e-mail]>]

DKG:

Please see below.

> On Jun 15, 2022, at 5:13 PM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> On Wed 2022-06-15 14:39:49 -0400, Russ Housley wrote:
>>>>>> 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.
> 
> Sorry for the confusion, let me retry my explanation.
> 
> The text says "or any type of automated processing".  That is, it is
> apparently talking about something else *in addition to* certificate
> path construction and validation.
> 
> It says this in the context of a sentence that talks specifically about
> "the certificate issuer" -- which is not the relying party.
> 
> The implication seems to be that the certificate issuer (and perhaps
> other parties, though again it is unclear) should avoid using these
> extensions in any sort of automated processing.  I don't think that's
> reasonable, or what anyone intends.  But it's what the document appears
> to say.

Let's look at the whole paragraph.  I think I now understand your concern, and I suggest:

OLD:

   Logotypes MAY be included in public key certificates and attribute
   certificates at the discretion of the certificate issuer; however,
   logotypes MUST NOT be part of certification path validation or any
   type of automated processing.  The sole purpose of logotypes is to
   enhance the display of a particular certificate, regardless of its
   position in a certification path.

NEW;

   Logotypes MAY be included in public key certificates and attribute
   certificates at the discretion of the certificate issuer; however, the
   relying party MUST NOT use the logotypes as part of certification
   path validation or any type of automated processing.  The sole
   purpose of logotypes is to enhance the display of a particular
   certificate, regardless of its position in a certification path.

Russ