[Servercert-wg] Browser Alignment Ballot - Name Chaining

Corey Bonnell CBonnell at securetrust.com
Wed May 13 13:14:48 MST 2020


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

 

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

 

Thanks,

Corey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200513/acd1094f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4947 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200513/acd1094f/attachment.p7s>


More information about the Servercert-wg mailing list