[Servercert-wg] Browser Alignment Ballot - Name Chaining

[Corey Bonnell]

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

 

> That's not really supported for the reasons I gave in the previous mail. That interpretation disconnects all context, and there's real danger in doing so, which is exactly why it's important to make it precise.

 

RFC 3280 did not mandate for client implementations to perform RFC 4518 comparisons for UTF8Strings; binary comparison was sufficient. However, RFC 5280 mandated that client implementations implement RFC 4518 matching for UTF8Strings. If the goal was to move away from more complex comparison algorithms for DN matching in favor of binary comparison -- thereby tightening up the issuance/encoding profile as a result of non-support by client implementations, then RFC 5280 was a step backwards by mandating RFC 4518 comparisons for UTF8String attribute values, as there was no such previous requirement. Additionally, the language in Mozilla’s Potentially Problematic Practice mentioned in my previous email (“The specs (RFC 2459 <https://www.ietf.org/rfc/rfc2459.txt> , RFC 3280 <https://www.ietf.org/rfc/rfc3280.txt> , RFC 5280 <https://tools.ietf.org/html/rfc5280#section-7> ) permit them to mismatch") is a nod to non-binary equal DNs being allowed by RFC 5280.

 

Practically speaking, it’s obvious that if a CA doesn’t encode binary-equal DNs for name-chaining, then there’s going to be a whole host of breakage on most clients. However, I’m somewhat surprised to learn that not doing so is considered a RFC 5280/policy violation by Root Programs as opposed to a potential interoperability issue.

 

> I appreciate the concern, and while I believe it's unfounded on principle, I also am not sure I understand the practical concern. It 

> seems like the position you're taking is "This ballot can't contain anything that I can't link to", but that's an unreasonable barrier for 

> ballots. The purpose of the ballot is to capture "Here's what root programs have required, in word or in practice, and treated as an

> issue otherwise".

 

I think the distinction is valuable to understand, because it meaningfully changes how someone would review the draft ballot. Additionally, understanding whether or not a particular item is an existing, well-stated requirement helps to inform effective dates for changes. My intent wasn’t to gate-keep what can or can’t go into your draft ballots.

 

I am concerned by this proposed language:

“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 this is currently a Root Program requirement, then it is afoul of policy if a CA issues two end-entity certificates, one with a CN of WWW.EXAMPLE.COM and another end-entity certificate with a CN of www.example.com.  I’m thinking the intent here is that for a given CA Public Key, the subjectDN must be byte-to-byte equal for all Certificates that contain the CA Public Key in the SubjectPublicKeyInfo. Is that an accurate assessment of the intent?

 

Thanks,

Corey

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Monday, May 4, 2020 5:37 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 Mon, May 4, 2020 at 4:06 PM Corey Bonnell <CBonnell at securetrust.com <mailto:CBonnell at securetrust.com> > wrote:

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

 

Right, this confusion is exactly what we're trying to address. You're not the first to make this argument, and that's what this is attempting to clarify - again, existing policies that Root Programs have dealt with individual CAs on.

 

That might argue it's for the "Cleanups and Clarifications" ballot, except that Root Programs have treated this as both policy violations and RFC 5280 violations. The perception you have - that this is a new normative requirement - is exactly why it's lumped into here, to make it clear it's a new requirement and discuss if any considerations are needed. As mentioned in the commit, this is already intended as an existing requirement (of both the BRs and RFC 5280), but that it's not obvious to some, despite it being treated as such, is important to address.

 

The problem with the text you're quoting here is that you're trying to use client processing behaviour (implementations) to describe issuance requirements. The two are separate, and that's important to realize, since the goal is to profile issuance so that clients can reduce/remove special cases.

 

 

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.

 

That's not really supported for the reasons I gave in the previous mail. That interpretation disconnects all context, and there's real danger in doing so, which is exactly why it's important to make it precise.

 

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.

 

I appreciate the concern, and while I believe it's unfounded on principle, I also am not sure I understand the practical concern. It seems like the position you're taking is "This ballot can't contain anything that I can't link to", but that's an unreasonable barrier for ballots. The purpose of the ballot is to capture "Here's what root programs have required, in word or in practice, and treated as an issue otherwise".

 

To be fair, for a number of the proposed changes, these are new requirements, but for other Root Programs. This is because these are issues only dealt with in individual Root Programs' policies, and thus if a policy doesn't contain it, it's a new requirement to them. I think, if I understand your objection, you believe that this is a new requirement for CAs. But it isn't, in practice and how it's been treated in the past. And that's why it's part of this, to capture all of those for further discussion.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200507/4d3c4c0e/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/20200507/4d3c4c0e/attachment-0001.p7s>