[cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating]

> On Oct 20, 2017, at 12:34 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Fri, Oct 20, 2017 at 3:14 PM, Geoff Keating <geoffk at apple.com <mailto:geoffk at apple.com>> wrote:
> 
> 
>> On Oct 20, 2017, at 11:30 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com>> wrote:
>> 
>> 
>> 
>> On Fri, Oct 20, 2017 at 2:20 PM, Geoff Keating via Public <public at cabforum.org <mailto: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 <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?

*sigh* too many version numbers, all in the 10-13 range!  I meant macOS High Sierra 10.13, build 17A405.  That works for me when I use Safari to browse to https://no-subject.badssl.com <https://no-subject.badssl.com/>.

> 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 <https://www.ietf.org/mail-archive/web/pkix/current/msg23992.html> )

I don’t think there was, ultimately, disagreement.  That discussion appears to terminate with this message:

https://www.ietf.org/mail-archive/web/pkix/current/msg23960.html <https://www.ietf.org/mail-archive/web/pkix/current/msg23960.html>

and the outcome was the creation of the uniqueIdentifier attribute (described in X.520 immediately before the section which describes dnQualifier).  So now there are clearly two fields, one of which is used to distinguish between the same DN in a DSA and the other distinguishes between different DSAs.  The uniqueIdentifier description even says

> It may be, for example, an encoded object identifier, certificate, date, timestamp, or some other form of certification on the validity of the distinguished name.

which sounds like the perfect field to store a hash of the subjectAltName, or a UUID.  (The field is a bit string, which means you don’t have to base64 encode anything.)

So, did we consider uniqueIdentifier?  If so, what were the problems?

While I’m asking questions, if there were problems related to it being a bitstring, did we consider serialNumber?  If so, what were the problems?

I’m sorry to be asking so many questions, but I can’t find any record in the forum archives on this topic, and the author of the ballot didn’t include a rationale.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171020/4cacacbd/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3321 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171020/4cacacbd/attachment-0003.p7s>