Re: Pseudonym in Subject DN (in QC certificates)

[[e-mail]]

Stefan,

I haven't commented on the proposed pseudonym attribute, having 
been busy trying to wrestle the "NR" alligator.

But I believe that defining a single attribute for pseudonym would be 
WRONG. Instead, I believe that we need a continuum of certificate 
classes that range from a complete pseudonym (the subscriber was 
wearing gloves when he pulled the handle on the certificate vending 
machine, to avoid leaving fingerprints), all the way up to a certificate 
that is issued as an act of state by a sovereign government, plus
everything in between.

Once you define an attribute for a pseudonym, then when someone 
comes along and needs to identify an individual whose identity is 
known by the CA but not disclosed in the certificate, or by a 
publicly-held and audited corporation, or a Licensed CA, or 
a State or Province, etc., etc., then the temptation will be to 
define yet another attribute.  This way lies madness, not to mention
a complete lack of interoperability.

I really believe that a somewhat sparsely populated list of certificate 
classes that identify the amount of due diligence that is invested into
the identity of the subscriber is a better way to go. Please see Appendix 
D, page 57, of our Novell Security Attributes document, available
at http://developer.novell.com/repository/attributes/certattrs_)v10.htm 
for more details and a reasonably well worked out list of such classes.
I would, of course, be happy to entertain suggestions for revisions and 
additions to that list.

Bob


>>> Stefan Santesson <[e-mail]> 08/26/99 07:41AM >>>
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
-------------------------------------------------------------------