[cabfpub] Ballot 208 - dnQualifiers

[Peter Bowen]

> On Oct 20, 2017, at 2:15 PM, Geoff Keating via Public <public at cabforum.org> wrote:
>> 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.

Sorry for the lack of rationale in the ballot.  Ben was super helpful and drafted the ballot itself after a couple of rounds of discussion because I ran out of time.  So I take the blame for not including the prior discussion in the ballot.

The reason for choosing the dnQualifier attribute is that 5280 has a list of attribute types which are mandatory to support and dnQualifier is in that list.  I also looked at all the certs in CT logs and found no conflicting use of dnQualifier.  The core definition of dnQualifier in X.520 aligns with the intent here: "The DN Qualifier attribute type specifies disambiguating information to add to the relative distinguished name of an entry. “  The usage in this ballot is to provide disambiguating information when the subject would otherwise be the same (notably be empty).

We could move to serialNumber or assign new object identifier which can be used for this purpose, but is would have no more meaning than dnQualifier for all known implementations.  I did not find any place where dnQualifier had any semantics in applications when I looked.

Thanks,
Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20171020/de6df46f/attachment.html>