Subject: Update of the QC personalData issue (errata)

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Nov 1999 18:08:21 -0500

Ooups, 

Two small errors in my previous mail.

1) countryName was missing in the list of attributes for the subject field,
and;
2) the attributes stored in the subject field are only required to form a
DN. To obtain an unmistakable identity, according to the QC profile
definition, it may also require examination of the
subjectDirectoryAttributes extension.

/Stefan

All,

Here is an update of the QC personalData issue after further considerations
and discussions during the Washington meeting.

To make a good solution here we have to go back to the original ideas
behind this structure.

The personalData structure was added in order to allow specification of
specific identity information without populating the subject field with odd
non-standardized attributes.

subjectAltName was a natural choice since we needed not only attributes but
also other information like attribute semantics and registration authority
info to be present.

The problem with subjectAltName extension though is that included names
have to be unique. This means that a complete unmistakable identity have to
be stored. Not only non-unique attributes, adding extra information to the
subject field.

Now this impose 2 problems:
1) Attributes like countryOfResidence can't be used unless a complete
identity is stored in the personalData.
2) Name/identity information must be duplicated with risk of ambiguity and
confusion between the subject field and the personalData structure.

Two major changes have made prerequisites different now compared to when
personalData was originally formed:
 1) The update of RFC 2459 will open up for use of
SubjectDirectoryAttributes in accordance with the proposal below.
2) The new qcStatements extension has a predefined statement declaring
conformance with syntax and semantics of the QC profile. This can include
qualifying data such as definition of attribute semantics and a list of
associated registration authorities.

The proposed solution is to take advantage of this and:

Allow storage of the following attributes in SubjectDirectoryAttributes:
   postalAddress
   gender
   placeOfBirth
   dateOfBirth
   countryOfCitizenship
   countryOfResidence

Further allow all RFC 2459 attributes to be present in the subject field
but require that a complete DN (in the form of an unmistakable identity) of
the subject shall be defined using an appropriate subset of the following
attributes: 

  commonName
  pseudonym
  surname
  givenName
  dnQualifier
  stateOrProvinceName
  localityName
  organizationName
  organizationalUnitName
  title

(Note that the pseudonym attribute will be included also in the next RFC
2459 update so all attribute will be supported by RFC 2459)

Finally we define (as said above) that an attribute semantics OID, and a
sequence of associated name registration authorities may be specified in
the qcStataments extension as a statement info carried with the predefined
statement declaring conformance with syntax and semantics defined in the QC
profile.

Preliminary ASN.1 definition: 

statementInfo QC-STATEMENT ::= {
    attributeSemanticsSyntax IDENTIFIED BY id-qcs-pkixQCSyntax-v1

attributeSemanticsSyntax   ::=  SEQUENCE       {
    attributeSemantics      OBJECT IDENTIFIER    OPTIONAL,
    registrationAuthorities RegistrationAuthorities OPTIONAL }

RegistrationAuthorities    ::=  SEQUENCE       {
    registrationAuthority   GeneralName }

So finally, after these changes, we can totally delete the personalData
structure which nobodey so far has shown a desire to implement anyway.

We can do this without loosing any of the functionality that we originally
needed the structure for and we end up with a much more consistent
specification with only one common place to store the identity attributes.

Another issue here has been static identifiers. 

One way to go here is that an appropriate attributeSemantics OID may
provide the definition that the dnQualifier attribute is populated with a
value that have this property, i.e. to be a unique static identifier of the
certified subject.

An alternative could be to define that dnQualifier in QC always MUST
contain a unique value for the subject (within the set of all certificates
issued by a CA)

I'm currently open for suggestions here.

Any comments are welcome.

If there seems to be consensus around this then it will be included in a
new draft in a few weeks (hopefully) and then go for a new WG last call.

/Stefan