[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Ryan Sleevi]

On Mon, May 4, 2020 at 2:57 PM Corey Bonnell via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Hello,
>
> Having reviewed the Browser Alignment Ballot [1], I have concerns about
> the new requirements in section 7.1.4.1 concerning Name Chaining.
>
>
>
> The previous language is as follows:
>
> The content of the Certificate Issuer Distinguished Name field MUST match
> the Subject DN of the Issuing CA to support Name chaining as specified in
> RFC 5280, section 4.1.2.4.
>
>
>
> The proposed language is:
>
> The encoded content of the Issuer Distinguished Name field of a
> Certificate SHALL be byte-for-byte identical with the encoded form of the
> Subject Distinguished Name field of the Issuing CA certificate.
>
>
>
> 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.
>
>
>
> Section 4.1.2.4 of RFC 5280 does not mandate binary equality for DNs to
> support name chaining but instead defers to section 7.1, so I don’t believe
> this is an existing Root Program requirement. The closest thing to such a
> requirement that I’m aware of is Mozilla’s Potentially Problematic Practice
> of “Issuer Encoding in CRL” [2] (with associated discussion here on MDSP
> [3]), but despite being frowned upon, it is currently not a policy
> violation to not use binary-equal DNs (although understandably certificates
> may not work otherwise depending on the UA implementation).
>

Hi Corey,

Thanks for raising it. I'm afraid there's some confusion, both in terms of
RFC 5280 and in terms of Root Program expectations, so I thought it'd be
useful to capture. This actually came up as three different root programs,
either through interpretation or treatment, treated it as violation, based
on the RFC.

First, it's relevant to also read Section 4.1.2.6, since we have to take
both sets of requirements (requirements on encoding Issuers, requirements
on encoding Subjects), which is where part of the confusion came from (at
least, in past CA incidents)

   When encoding attribute values of type DirectoryString, conforming
>    CAs MUST use PrintableString or UTF8String encoding, with the
>    following exceptions:
>       (a)  When the subject of the certificate is a CA, the subject
>            field MUST be encoded in the same way as it is encoded in the
>            issuer field (Section 4.1.2.4) in all certificates issued by
>            the subject CA.  Thus, if the subject CA encodes attributes
>            in the issuer fields of certificates that it issues using the
>            TeletexString, BMPString, or UniversalString encodings, then
>            the subject field of certificates issued to that CA MUST use
>            the same encoding.


Now, this is a requirement on the Subject of a CA certificate, but places a
binding between it and the subject certificates Issuer field, so it's also,
in effect, a requirement on End-Entity Certificates (and Sub-CAs). The
requirement is on the *encoding*, not merely loose (LDAP StringPrep)
equivalence.

This requirement matches the Mozilla
<https://bugzilla.mozilla.org/show_bug.cgi?id=1625527#c15>, Apple, and
Google implementations, and has been treated as invalid certificates by
these clients. This is an area where RFC 5280 is profiling (restricting)
the issuance, while Section 7.1 describes how to handle legacy/backwards
compatibility. If you'll note, the language in 4.1.2.6 directly precludes
the application of the 7.1 mapping, because it MUST-levels the name
matching between subject certs and their issuer.

The existing language in the BRs is meant to capture that level of
expectation of UAs; unfortunately, because it did not say "encoded
identically", folks seemed to rely on the 7.1 behaviour, which was only
intended for compatibility with pre-RFC3280 certificates. The "problem"
arose because RFC 2459 tried to set a flag day ( see
https://tools.ietf.org/html/rfc2459#section-4.1.2.4 , Dec 31, 2003). RFC
3280 removed that (largely ignored) transition date, and replaced it with
language saying "the same contents" (
https://tools.ietf.org/html/rfc3280#section-4.1.2.6 ), but this caused some
ambiguity about the applicability on Section 7.1, and so RFC 5280 made this
explicit here that "contents" referred to the encoded value, not the myriad
possible values. This ensures that, going forward, eventually the Section
7.1 StringPrep profiles resulting from lack of specificity in 2459 and
ambiguity in 3280 will eventually be able to be removed in a future
5280-bis.

Of course, 5280 itself doesn't require *only* 5280 certificates, that's
more for UAs, and UAs that require all CAs/certificates comply with 5280
can fully ignore Section 7.1 because they should never encounter
certificates that need Section 7.1's backwards compatibility hooks / how to
handle non-5280 compliant certificates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200504/9b5f44a5/attachment.html>