Subject: QC container ID support

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 10 Nov 1999 21:16:15 -0000

Stefan, 
What happened to the smart-card serial number/container ID? 

My request got support both from ID2 and TrustCenter. 

When we are talking legally binding signatures it is nice to know from what (possibly 
stolen) container they emanated from. 

Both SEIS and German signature law defines this.

And most QCs will be smart-card-based. Otherwise they simply don't make sense. 

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Nov 1999 17:54:23 -0500

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

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 10 Nov 1999 20:39:34 -0500

As I said before it would be appropriate to define a qcStatement providing
essential information about the signature device associated with the
certificate. This may also carry an identifier of the actual container.

/Stefan

---

From: Marc Branchaud <[email-masked]>
Date: Thu, 11 Nov 1999 14:16:05 -0800 (PST)

On Wed, 10 Nov 1999, Stefan Santesson wrote:
> 
> The problem with subjectAltName extension though is that included names
> have to be unique.

Just so I'm sure, this is a QC-specific requirement, right?  I don't
recall anything about subjectAltName per se that mandates unique altNames.

		Marc