[cabfpub] Ballot 208 - dnQualifiers

[Geoff Keating]

> On 22 Oct 2017, at 11:05 am, Peter Bowen <pzb at amzn.com> wrote:
> 
> The dnQualifier is designed to add “disambiguating information” to Distinguished Names.  This ballot uses it for that purpose.  Notably I expect CAs to use it to disambiguate certificates where there is no distinguished name or where the CA has information that two certificates with identical subjects were issued to different entities.

Isn’t it the case that every attribute adds “disambiguating information” to a name?  For example, countryName distinguishes between identically-named entities in different countries.  You have to read the entire description in order to find out how a particular attribute is used, and in this case, it’s to be used to distinguish between the same entity as seen by different systems.

> The issue that both Li-Chun and Geoff raise appears to be whether we should use a different attribute type instead of dnQualifier.  The most obvious suggestion would be to define a new attribute type, under an Object Identifier arc that is managed by the Forum or a member.  However this results in real-world compatibility issues.  There are numerous products which error if a certificate DN contains attributes not on a whitelist.

I think you’ve undercut this ballot a bit by pointing out that:

> A bit of searching on “oid.map”, I did find the source, which is a PKIX library from Certicom.  The part of oid.map that seems relevant is below.  I note dnQualifier is not there, so maybe we should choose one of the attributes below:

but if you still want to use dnQualifier, the obvious way to do it is to follow X.520 by having it be the same for a single CA, you could say something like

	• Optional. Contents: This field distinguishes between the same entity in different Directory System Agents.  If present, the field MUST contain the commonName of one of the CA’s root or subordinate CA certificates (not necessarily one which issued this certificate).


I would suggest that there is a simpler workaround for individual cases, which is to give the host in question a shorter name (in addition to the long name) which can then be in the commonName field.  Most subscribers won’t encounter problems with an empty subject name, or will be able to update software to fix them, so this will not be something that needs to be done often.

Another workaround for individual cases is to identify the subscriber!  If you just supply the countryName field, that will do.  It can be determined and verified automatically in most cases.
-------------- 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/20171022/36c917aa/attachment-0003.p7s>