[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Ryan Sleevi]

On Wed, May 13, 2020 at 4:14 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> >> It appears there are some still-valid intermediates listed in CCADB
> whose subjectDN would match per RFC 5280 section 7.1 (RFC 4518) but are not
> byte-for-byte equal due to differences in encoding using PrintableString
> vs. UTF8String in different certificates. These would run afoul of the new
> requirement.
>
> > I think the framing you've chosen does more harm than help, so I'm
> hoping it was accidental. That is, you're continuing to state it as a new
> requirement, despite our previous discussion, but then conflating that with
> retroactive concern as if it was an existing requirement. That only serves
> to muddy the water.
>
>
>
> I agree that I could have chosen better phrasing. My point was that the
> practice of issuing multiple intermediate certificates whose subject DN
> differ only by PrintableString/UTF8String would run afoul of the
> requirement introduced in the draft ballot if continued after passage of
> said ballot. It’s still a new requirement in terms of the Baseline
> Requirements, however.
>

Again, we disagree on whether it's a new requirement :) But let's work on
the more fundamental bit below before we circle back here :)


>
>
> >>> The encoded content of the Subject Distinguished Name field of a
> Certificate SHALL be byte-for-byte identical among all Certificates whose
> Subject Distinguished Name can be compared as equal according to RFC 5280,
> Section 7.1, if at least one Certificate is a CA Certificate.
>
> >> Can you expand a bit on the goal of this requirement? I originally
> thought it was to force a 1:1 mapping of CA Public Key to subjectDN
> encoding for all CA Certificates, but as you noted that’s not the case.
>
>
>
> > I'm not sure how you would reach that conclusion with the existing
> language.
>
>
>
> I don’t see how the proposed language accomplishes the goals that you
> outlined. As we have discussed earlier, non-binary equal DNs are allowed by
> RFC 5280 for mapping the subject DN of the CA certificate to the issuer DN
> of CRLs, so this proposed text does not constrain the profile for CRL
> issuer DN encoding.
>

I'm wanting to make sure I follow your logic here. If we assume that A (in
all its variants) use byte-for-byte identical A, that a CA can and should
be permitted to use encoding A', which does not appear in any such
certificate, as the basis for the CRL and/or OCSP response?

I think we'd take an even dimmer view at that, because that's a clear and
unnecessarily deliberate attempt to break revocation by a CA.


> Additionally, this new requirement introduces significant complexity and
> potential for confusion by relying on RFC 4518 for DN comparison, which
> supports only the repertoire of characters available in Unicode 3.2 as
> specified in section 2.4 (IDNA 2003 has this same issue). A DN that has an
> attribute value that contains a code point not assigned in Unicode 3.2 will
> not match any other DN, even itself.
>

I'm having difficulty following. By the logic you're using above, any CA
which uses such an attribute cannot actually issue any certificates that
conforming clients accept, because by the problem you've stated, all
clients will reject the certificates because they're unable to locate the
issuer based on the subject, based on the Section 7.1 description. At the
same time, non-conforming clients (e.g. using RFC 3280), *would* accept
such certificates, because by a simple byte-for-byte equivalence test, they
would be equivalent. How is this a problem with the proposal, as opposed to
an illustration of the fundamental problem it's trying to fix?


> Given this, I think would be valuable if we could explore an alternate
> requirement that doesn’t rely on potentially messy comparison logic while
> accomplishing the goal of mandating binary-equal name chains for issued
> certificates and CRL artifacts, etc.
>

I'm open to suggestions you feel would be useful here to clarify. I
disagree that it's possible to escape the potentially messy comparison
logic because the only way you can be sure that a CA is not using said
logic is to, well, depend on said logic to say for what you MUST NOT do.
The problem you've described with respect to Unicode 3.2 seems to be easily
addressable by saying that all CAs that have either byte for byte subjects
or which compare equal using the 'potentially messy comparison logic' must
be byte for byte identical, and that's a fairly trivial change, although
I'm sure it'll read a bit awkward (to say things 'byte for byte identical'
MUST be 'byte for byte identical').
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200513/a663ed02/attachment-0001.html>