> On Oct 20, 2017, at 2:15 PM, Geoff Keating via Public <[email protected]>
> 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
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
