Re: Pseudonym in Subject DN (in QC certificates)

[Stefan Santesson <[e-mail]>]

Bob,

Inclusion of new attributes are always a delicate matter that needs to be
handled with care. But I believe that in this case we have crossed the line
where it can be a legitimate step.

The fact is that in order to meet the EU-directive, we have to deal with
inclusion of pseudonym in the subject field.

Using the commonName attribute imposes weakness in the structure by
stretching current definitions. With the support from RSA and many
representative vendors in Europe I think we should do the step and include
the pseudonym attribute. I think we have the backup to get necessary
support for this move.

Of course this will effect implementations, but implementers of this
specification must be aware of this and act accordingly when they are
working with pseudonym names.

/Stefan

At 07:00 PM 8/26/99 -0600, [e-mail] wrote:
>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
>-------------------------------------------------------------------
>

-------------------------------------------------------------------
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
-------------------------------------------------------------------