dnQualifier topic - not solved yet.

[Stefan Santesson <stefan@xxxxxxxxxxx>]

All,

My last trial to settle the dnQualifier topic drowned in the NR-bit struggle.

So I take the chance, during this apparent rest in the traffic, to bring
this up again for settlement.


What we need:
-------------
We need an attribute that we can use to store an identifier of a
certificate subject. This may be a unique identifier (sufficient to
identify the subject) or may act as a name distinguisher (sufficient to
identify the subject if combined with other names of the subject)

What do we have:
----------------
We have five candidate solutions, all with troubles. they are -

1) X.520 dnQualifier - the only attribute from rfc2459 with an intention
close to what we need. The problem is that using this attribute will break
the INTENT of this attribute according to X.520. This is also a solution
implemented by some vendors today.

2) X.520 serialNumber - Having the problem that it is defined for a device.
It is also only used with the object class device in X.501. It has however
been considered by X.500 standardization to change this to include support
for use with any type of "object". This is however not done yet and not
formally approved. It should also be noted that this is the current
solution of Finland, Sweden, Germany and probably more national electronic
ID-projects.

3) X.520 uniqueIdentifier - Having the problem that it is defined as a bit
string. This makes it impossible to display in any standardized way except
as a hex dump. Not a very useful format.

4) RFC 1274 uniqueIdentifier - Having the problem that is has an illegal
OID, together with all attributes defined under the PilotAttributeType
branch. This is in fact the same problem with the attribute domainComponent
also used in RFC2459 and the QC-profile, so using this attribute does not
introduce a new problem, but it makes the existing problem worse and more
critical.

5) To define a completely new attribute - Having the problem that we may
have a longer road to travel before this gets recognized and implemented in
proucts.


We need a solution that can be used consistently in the subject field in
son of RFC 2459 as well as in the QC profile.


So Please fellows.

This must be an important problem to solve for many of you out there,
affecting your products and implementations. So be active and propose
actions. Don't wait for others to solve this for you. Make your voice heard.

I hope we can solve this within a couple of weeks and perhaps make a straw
poll if consensus is hard to reach.


/Stefan 


-------------------------------------------------------------------
Stefan Santesson                <stefan@accurata.se>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. +46-40 108588              
211 20  Malmö                   Fax. +46-40 150790              
Sweden                        Mobile +46-70 5247799

PGP fingerprint: 89BC 6C79 5B3D 591B 8547  1512 7D11 DBF4 528F 29A0
-------------------------------------------------------------------