Re: Pseudonym in Subject DN (in QC certificates)

[Stefan Santesson <stefan@xxxxxxxxxxx>]

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