[Servercert-wg] Browser Alignment Ballot - Name Chaining

Thu May 14 09:20:57 MST 2020

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

To be clear, I am most certainly not saying CAs should be doing this and it is obviously undesirable for the webPKI, but a CA participant in a RFC 5280 PKI are permitted to do it absent requirements that further profile. As I have mentioned several times previously, Mozilla currently has a Potentially Problematic Practice (but not a concrete prohibition) concerning this exact issue, and it’s clear that you want to prohibit this in the Baseline Requirements but the current draft ballot language does not prohibit it. This is why I raised it as a potential issue that may be worth clarifying.

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

I wouldn’t be so quick to ascribe malice to any binary mismatches in the DN between an Issuing CA Certificate and the associated CRLs despite issued certificates’ issuer DN being binary equivalent. I’d think such a mismatch could reasonably be the result of a software bug or misconfiguration, especially given that it is plausible for the logic and configuration for revocation artifact generation and certificate issuance to be separate in a given PKI system. Having a well-defined, concrete prohibition in the Baseline Requirements would draw attention to this as a potential issue so it is explicitly accounted for in system design, testing, etc.

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

In a world where software faithfully implements the relevant RFCs, you’d be correct. However, there is at least 1 UA that performs RFC 4518-style name comparisons while simultaneously allowing for code points assigned after Unicode 3.2 to be present in DN attribute values while verifying certificate chains, which runs counter to RFC 4518 (and thus RFC 5280).

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

I think a requirement that mandates that the Issuer Name for all associated artifacts (certificates, CRLs, and OCSP) be byte-to-byte identical with the subject DN in the CA Certificate without referencing RFC 5280 section 7.1 -- which does not provide the desired result due to deviations in RFC 4518 compliance by UAs and carries with it significant complexity -- would largely accomplish the goals that you outlined.

Thanks,

Corey

From: Ryan Sleevi <sleevi at google.com> 
Sent: Wednesday, May 13, 2020 4:57 PM
To: Corey Bonnell <CBonnell at securetrust.com>
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Browser Alignment Ballot - Name Chaining

On Wed, May 13, 2020 at 4:14 PM Corey Bonnell <CBonnell at securetrust.com <mailto: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/20200514/79791c65/attachment-0001.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/20200514/79791c65/attachment-0001.p7s>