[cabfpub] Ballot 208 - dnQualifiers

[Ryan Sleevi]

On Fri, Oct 20, 2017 at 3:14 PM, Geoff Keating <geoffk at apple.com> wrote:

>
>
> On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public <
> public at cabforum.org> wrote:
>
>>
> - How this matches with the X.520 definition of dnQualifier, in particular
>> the second sentence:
>>
>> The DN Qualifier attribute type specifies disambiguating information to
>> add to the relative distinguished name of an entry. It is intended to
>> be used for entries held in multiple DSAs which would otherwise have the
>> same name, and that its value be the same in a given DSA for all entries
>> to which this information has been added.
>>
>
> This matches 1:1. Is there a concern that it doesn't match, or that more
> rules are necessary?
>
>
> What I quoted above is X.520.  It doesn't seem to me to be describing the
> same thing as the ballot.  In particular, normally you would consider a
> CA’s issuing infrastructure to be one single DSA, which produces a
> contradiction between the ballot text "The CA MAY set the dnQualifer value
> to the base64 encoding of the SHA1 hash of the subjectAlternativeName” and
> X.520’s text “its value be the same in a given DSA”.
>
> - How this is actually intended to be used in the web PKI?
>>
>>
> As raised on our most recent call, one notable thing is that this allows
> CAs to issue single certificates for domain names greater than 64
> characters, at a DV level, while interoperably working with the Web PKI.
> This flows as follows:
>
> - The X.509/RFC 5280 definition for commonName is limited to 64 characters.
> - If you have a certificate with a domain name greater than 64 characters,
> you cannot place it in the common name of the subject.
> - The common name of the subject may only contain domain names and IP
> addresses.
> - All other specified fields of the Subject must be validated to OV level.
>
> As a consequence, the only way with DV today to represent these
> certificates is with an empty sequence for the subject name and a critical
> subjectAltName, pursuant with RFC5280. You can see this at
> https://no-subject.badssl.com
>
> If you tried to load that on Apple iOS, it would load.
> If you tried to load that on Apple macOS earlier than 10.10, it would load.
> If you tried to load that on Apple macOS since 10.10, it will fail, as
> empty subjects are no longer supported.
>
>
> It works for me in 10.11—so does that mean this ballot is no longer needed?
>

Just tested 10.12 and 10.13 and it's still failing - perhaps it was a point
release of 10.11?

Yes, it's still needed. While I highlighted Apple products specifically
(given the affiliation), the problem actually affects a number of clients -
hence why badssl has that site.


> This provides a way for a CA to ensure that a DV certificate with a domain
> name of more than 64 characters can be issued, by using the dnQualifier
> field (which is CA-controlled, as noted in the relevant X.520 text you
> cited) to serve as a disambiguator between certificates the CA has issued.
>
> Does that help capture it?
>
>
> I see the problem but I’m very hesitant to standardise something in
> CABforum which contradicts X.520.
>
> Have we really explored other alternatives?
>

I think we have. What would help you get that confidence?


>  For example, truncate the commonName to 60 characters and append an
> ellipsis in Unicode (“…”) so that it can’t be confused with a domain name.
>

That seems significantly more dangerous - for example, there's no guarantee
that the ellipsis avoids confusion, particularly in the conversion routine.
I'm also not sure I understand the concern regarding X.520 - which the
Forum has otherwise ignored in other specification of Subject naming
attributes when establishing rules.

Is the substance the concern about X.520 - that is, if there is a solution
to address your concern, then there's no need to get creative here?

For example, you can find decades-old discussion in the IETF making the
same arguments you're making here, and similar disagreement about the
conclusions you're reaching (e.x.
https://www.ietf.org/mail-archive/web/pkix/current/msg23992.html )

Solutions in this space include:
- Fixing all products that fail to adhere to this aspect of RFC 5280 (In
general, penalize DV site holders due to the ecosystem) before allowing it
to be used
- Forcing the interoperability pain on Subscribers by allowing them to get
such certificates, despite knowing they won't work (even in particularly
popular products)
- Attempting to use an existing unbounded directory name type from RFC
5280, thus avoiding potential compatibility issues (which potentially runs
into your concerns regarding X.520 even more substantially)
- Introducing a new attribute type and value with the arbitrary syntax we
describe, much like was done for EV - still a risk of compatibility
- Defining our own annotation scheme for such long names (as you propose) -
introduces security risk into the ecosystem, given how many systems perform
matches and the risk of unicode folding (case in point: Consider null
terminators in the commonName, as pointed out by Moxie Marlinspike, and the
issues they caused)

Of these, it seems both aligned with X.520, past IETF discussions, and the
purpose itself of dnQualifier to help provide this disambiguator. Should
such an approach fail in the Forum due to a substantial number of members
sharing a concern about diverging from the intent of the global Directory
Information Tree, then the next possible approach would arguably be the
introduction of a new attribute, compared to the other solutions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171020/071c30db/attachment-0003.html>