[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Corey Bonnell]

Hi Ryan,

I interpreted section 4.1.2.6 differently, as it states: 

    “Implementations of this

   specification MAY use the comparison rules in Section 7.1 to process

   unfamiliar attribute types (i.e., for name chaining) whose attribute

   values use one of the encoding options from DirectoryString.  Binary

   comparison should be used when unfamiliar attribute types include

   attribute values with encoding options other than those found in

   DirectoryString.”

 

In other words, CAs should be using PrintableString and UTF8String types, and when they do, the mapping in section 7.1 can be used, as it is the “modern” Name comparison mechanism. Indeed, section 7.1 states:

   “Standard naming attributes, such as common name, employ the

   DirectoryString type, which supports internationalized names through

   a variety of language encodings.  Conforming implementations MUST

   support UTF8String and PrintableString.  RFC 3280 required only

   binary comparison of attribute values encoded in UTF8String, however,

   this specification requires a more comprehensive handling of

   comparison.”

 

And as far as “When encoding attribute values of type DirectoryString, conforming CAs MUST use PrintableString or UTF8String encoding, with the following exceptions: …” is concerned, I believe that is a fallback mechanism for for CAs that still embed BMPString values, etc. in Names so UAs don’t need to parse TeletexStrings (yikes) and can revert to binary comparison. In other words, it’s not prescribing binary equivalence when PrintableStrings and UTF8Strings are employed.

 

Now, all that being said, I don’t think mandating binary-equal DNs is a bad thing and can definitely ease UA implementation, which in turn would increase security.

But I don’t believe this is an existing Root Program requirement as non-binary equivalent DNs are allowed by RFC 5280 for name-chaining (assuming PrintableStrings and UTF8Strings are used), which is why I raised my original concern about introducing new requirements in the alignment ballot.

 

Thanks,

Corey

 

 

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

 

 

 

On Mon, May 4, 2020 at 2:57 PM Corey Bonnell via Servercert-wg <servercert-wg at cabforum.org <mailto: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://scanmail.trustwave.com/?c=4062&d=jOqw3qd2Y7S0zMNhD7UiVE8ZlQViH1lQXi5fUZQrBg&s=5&u=https%3a%2f%2fbugzilla%2emozilla%2eorg%2fshow%5fbug%2ecgi%3fid%3d1625527%23c15> , 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 <https://scanmail.trustwave.com/?c=4062&d=jOqw3qd2Y7S0zMNhD7UiVE8ZlQViH1lQXi9fV5d4Ug&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc2459%23section-4%2e1%2e2%2e4>  , 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 <https://scanmail.trustwave.com/?c=4062&d=jOqw3qd2Y7S0zMNhD7UiVE8ZlQViH1lQXnwKDJN4Bg&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2frfc3280%23section-4%2e1%2e2%2e6>  ), 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/0b390ae3/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/20200504/0b390ae3/attachment-0001.p7s>