[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Ryan Sleevi]

On Tue, May 12, 2020 at 1:11 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> > Yes to the point about applying to CAs, although no to the point about
> aligning across all certificates associated with a CA Public Key. There are
> CAs that use the same SPKI but with different CA Subject Names, and that's
> valid and allowed (from a UA perspective and from a 5280 perspective)
>
>
>
> 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 think what you're trying to say is:
- If this is an existing requirement, there are some CAs in violation of
this existing requirement (Answer: Yes)
- If this is a new requirement, there are some CAs who would be in
violation *if they issued new certificates exhibiting the same
problem* (Answer:
Yes)

However, it's framed (incorrectly) as if:
- If this is a new requirement, this retroactively places some CAs in
violation (Answer: No)

You're correct that there is extant badness, but if you believe this is a
new requirement, then this language doesn't address extant badness.
However, if you accept that it's an existing requirement, then this
language doesn't change extant badness, which is already bad.


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

The goal is to ensure there's exactly one canonical encoding among the set
of those described under Section 7.1 for each DN associated with an SPKI.
If the names would not compare as equivalent via the StringPrep form, then
it's fine to have many, provided of course that each DN meets all the other
requirements (uniqueness, attribute type, etc).

This is explicitly about reducing ambiguity between the Subject/Issuer,
both for certificates and in the related revocation artifacts (e.g. OCSP
and CRLs), so that users consistently can ensure they get the 'correct'
artifact.

The complexity is easy and obvious with respect to CRLs. If we accept that
A and A' (e.g. two DNs with equivalent encoding under 7.1 but are not
byte-for-byte equivalent) represent the same CA, which in RFC 5280 terms
they do, then you have complexity with respect to the CRL encoding,
particularly when the client implements RFC 3280 or 2459, which more
members in the Forum do than 5280-as-described. If you have a certificate
B, issued by A (or more aptly, the set of A | A', but encoded as A), and
you have a CRL for that, encoded as A', then beyond path building issues,
you also end up with revocation issues. Trying to provide separate CRLs for
A and A' based on how it was encoded in the certificate then opens it own
can of complexity (with respect to do you use cRLIssuer in the CDP, or do
you use different URLs with critical IDPs, or ...)? The same complexity can
be applied to OCSP, particularly with respect to issuerNameHash
complexities but also to the validation of the OCSP response itself. Or
applied to CT, with respect that every log inspecting client would have to
support full LDAP StringPrep implementations, beyond memcmp, when
determining whether to alert on a cert.

Just as RFC 5280 profiles down X.509, so to do the Root Programs and the
BRs further profile that down into a more restrictive set suitable for the
specific needs of these clients. The flexibility, in extensions and
representations and encoding, leads to client complexity, which can and has
lead to security issues (e.g. CVE-2020-0601), and so profiling down that
complexity into consistency helps everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200512/27835f6c/attachment-0001.html>