[Servercert-wg] Browser Alignment Ballot - Name Chaining

Ryan Sleevi sleevi at google.com
Mon May 4 14:36:58 MST 2020


On Mon, May 4, 2020 at 4:06 PM Corey Bonnell <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/20200504/2ee6e9c7/attachment-0001.html>


More information about the Servercert-wg mailing list