Subject: Re: Pseudonym in Subject DN (in QC certificates)

From: Stefan Santesson <[email-masked]>
Date: Tue, 24 Aug 1999 11:24:57 +0200

Tom, David Magnus and Hans,

What are discussed here is problems in directories if we add a new
attribute for pseudonyms in the subject field and also the possibility to
use an "informational policy OID" to explain just the fact if the
commonName attribute contains a pseudonym.

Regarding the directory problem I would like to have your comments David to
what Tom writes below. Will we brake common object classes in directories
if we use pseudonym instead of commonName in the subject field. We have to
make sure that we don't introduce a new problem if we add this attribute. 

<snip>
>>[Tom Gindin]   I believe that defining a separate pseudonym attribute, and a
>>separate nickname attribute since nicknames are a subclass of pseudonyms
which
>>are much less misleading, would require the division of several existing
>object
>>classes into three, or a sizable change to their definitions.  Among the ones
>>getting this treatment would be person and its subclass organizationalPerson,
>>which are among the most widely deployed of all directory object classes.
>
>[Stefan Santesson] I interpret this as that your advise is to NOT
introduce these attributes
>in the subject field. Correct ?
>
>[Tom Gindin]   Correct.

Secondly I would like to comment on the policy OID issue.

<snip>
>[Tom Gindin]   While certification path processing ignores and is not
disturbed
>by informational policy OID's of the sort I suggested, the subject directory
>attributes approach might be less debatable.
>

Yes, you are right in theory. But I still interpret that you are braking
the implicit semantics of policy OID:s. What if an implementor tries to
detect this policy OID by including this OID in the list of accepted
policies. This will cause the user so accept all certificates which
contains this policy OID. So your way of handling this will introduce a new
detection mechanism where implementation errors are likely to occur. I
would never like to propose such overloading mechanism unless I'm 100% sure
that this will not cause conflicts, and I'm not.

In this case I would rather introduce this information in the qcStatements
extension where such informational policy OID:s can be placed without
trouble. It would be OK to put an OID here saying that this certificate
contains a pseudonym name of the subject. 

/Stefan 
-------------------------------------------------------------------
Stefan Santesson                <[email-masked]>
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
-------------------------------------------------------------------

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 26 Aug 1999 15:41:27 +0200

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

---

From: "David Chadwick" <[email-masked]>
Date: Fri, 27 Aug 1999 20:11:45 +0100

Stefan wrote

> RFC 2459 and also to add matching rules for this attribute.

You do not need to define any new matching rules if you make the 
syntax of pseudonyms the same as commonName, and use the 
same matching rules as for commonName. Then all you are doing is 
attaching a new meaning to the value that was previously called a 
commonName but was really a pseudonym in disguise.

David
***************************************************

David Chadwick
IS Institute, University of Salford, Salford M5 4WT
Tel +44 161 295 5351  Fax +44 161 745 8169
Mobile +44 790 167 0359
*NEW* Email [email-masked] *NEW*
Home Page  http://www.salford.ac.uk/its024/chadwick.htm
Understanding X.500  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string MLJ9-DU5T-HV8J

***************************************************

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 28 Aug 1999 00:45:42 +0200

Yes David, That's actually what i meant but maybe didn't express very clearly.

/Stefan