Re: Pseudonym in Subject DN (in QC certificates)

[Stefan Santesson <[e-mail]>]

Regarding new attributes in the subject field in Qualified Certificates.

I've had several off list discussions regarding the pseudonym attribute in
the subject field of QC.

Everybody except one has been in favour of adding this attribute in the
subject field.

Pros are:
- Makes it easier to meet the EU directive directly by using just the
subject field without bending current X.509 definitions.
- Clearly defines when a name is based on a pseudonym
- RSA has offered to include this (and other PersonalData) attributes in PKCS#9

Cons are:
- Will require definition of new object classes for directory systems when
this attribute is used.

The cons are more and more fading away. Magnus Nyström at RSA wrote to me:

"Well, yes, one have to include this new attribute in the definition of a 
 new object class, or extend the definition of an existing class if one
 would like this to work well. But that was also my original intention - to
 include them in the 'pkcsEntity' auxiliary object class that is being
 defined in PKCS #9. Further, most directory products does support changes
 to the schema, and there are already several proposals being made in
 this area, e.g.:

 -Netscape's draft about "inetOrgPerson", published as
  'draft-smith-ldap-inetorgperson-03.txt'; and
 -Chadwick's draft regarding ldapv3 and PKIX
  (draft-ietf-pkix-ldap-v3-01.txt) which incorporates the 'pmiUser' object
  class which I doubt many directory products have built-in support for
  today.
 -RSA Laboratories "pkcsEntity" auxiliary object class, being defined in
  PKCS #9 v.2."

Taking this into consideration I think that we should go forward and
include the pseudonym attribute.
This will force us to expand the set of supported attributes compared to
RFC 2459 and also to add matching rules for this attribute. we will also
have to remove the option to allow a pseudonym to be stored in the
commonName attribute and instead say that this attribute SHALL be used to
store the subjects registered name in a preferred presentation format.
Nicknames and spelling other than the registered names are allowed as long
as they are related to the persons registered name.

Another consideration is to add the title attribute as a role attribute
since role has repeatedly become an issue within these types of
certificates. The text should declare that when this attribute is present
it SHALL define a role of the subject. I believe that this is consistent
with the attribute definition in X.520. This attribute is further already
on the list of supported attributes in RFC 2459.

Finally we should assign an OID to be optionally included in the
qcStatements extension, which declare that a certificate is compliant with
syntax and semantics definitions of this specification. Otherwise there
will be no way for a relying party to tell whether the certificate is
compliant with these definitions other than by understanding present policy
OID:s.

So if no serious objections are raised, I would like to go forward and
update the specification according to this proposal.

/Stefan



-------------------------------------------------------------------
Stefan Santesson                <[e-mail]>
Accurata AB                     http://www.accurata.se
Slagthuset                      Tel. [phone]              
211 20  Malmö                   Fax. [phone]              
Sweden                        Mobile [phone]

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