Subject: Re: Why don't using Permanent Identifier on QC certificates?

From: Stefan Santesson <[email-masked]>
Date: Wed, 03 Jan 2001 10:01:40 +0100

Juan Carlos,

After reading the trailing answers to your mail I choose to answer yours 
directly since I don't want to get involved in the best identifier system 
for US.

The QC standard (approved 5 Nov 2000) gives you a set of attributes to 
express an identity in the form of a DN.
You can choose to include another attribute at your selection but then this 
attribute must NOT be necessary to identify the person.

So if you choose to follow the QC RFC, you should definitely use the SN 
attribute to store a national registration code (such as SSN), IF you have 
made the decision that you want to include this code at all.

The PI draft defines another attribute/mechanism to create a complete new 
way of assigning a unique identifier for a person. I.e. to my knowledge you 
can't use it to store an existing code (such as SSN).

So if you have an existing code structure, use SN and if you want to use 
the PI concept then use that but only as a complement to a complete DN.

I would though be careful before I start using PI in a wide scale because I 
fear that it may not scale as well as we would like. In Sweden you have to 
go to the national standards body to get an OID. Since OID is only designed 
to define objects in standards, the current schema in Sweden are to my 
knowledge just dimensioned to register more than just above 16000 
organizations under the Swedish root. They have just used up about 500 + so 
that is not a problem right now. But imagine what would happen if every 
organization asks for its own OID structure to register peoples/employees, 
then the standards body would have to create a new sub structure for this.

I have not made my homework to well so I can be wrong here but I think this 
should be overlooked more carefully before we jump to fast into approving 
the PI concept.

/Stefan

At 16:25 2000-12-19 -0400, Juan Carlos Pérez Aguayo wrote:
>In the QC draft is stated:
>
>"...The serialNumber attribute type SHALL, when present, be used to
>    differentiate between names where the subject field would otherwise
>    be identical.  This attribute has no defined semantics beyond
>    ensuring uniqueness of subject names.  It MAY contain a number or
>    code assigned by the CA or an identifier assigned by a government or
>    civil authority.  It is the CA's responsibility to ensure that the
>    serialNumber is sufficient to resolve any subject name collisions..."
>
>and on the Permanet Identifier drfat;
>Sorry if this discussion has happened before, but I don't know if there are
>some final statement:
>
>"... A serialNumber attribute may be used for two
>    different purposes in the DN of a person:
>
>    1) In a DN or a SubjectAltName to differentiate between
>       two names (for two different individuals) that otherwise
>       would not be different.
>
>    2) In the identifier field from a permanent identifier.
>       This is the recommended use for national ID's and
>       employee ID's, for example. ..."
>
>Now, consider this:
>
>a person has a unique identifier, assigned by a goverment authority, wich is
>guaranteed to be unique on a national scope (country domain)
>
>How to incorporate this identifier into a certificate?.
>
>SerialNumber or SubjevctAltname field? When I read the QC profile
>"..identifier assigned by a goverment o civil authority...", and then the PI
>draft say "... This is recommended use for national ID's...", I am confused.
>
>Why the QC does not use Permanent Identifier?
>
>Thera are some application wich need incorporate this class of personal
>identifier. By example, in my country (CHILE) each people ha an unique ID
>stamped in a card (this card has the photography and handwritting too), and
>this is broadly recognized for identification. One can to do many
>transactions wich need this ID for proceed.
>
>Thanks in advance
>
>Juan Carlos Pérez A.
>Acepta.com

---

From: "Anders Rundgren" <[email-masked]>
Date: Wed, 3 Jan 2001 10:42:08 +0100

Stefan,

> can't use it to store an existing code (such as SSN).

The PI draft does as you say introduce a a completely new way of assigning
a unique identifier to an entity (although the current draft mention individuals, I consider that
just a typo...), but does not prohibit (or recommend) this identifier in any way.  I.e. PI 
should work with any existing UID scheme.

> then the standards body would have to create a new sub structure for this.

I think this is slightly wrong.  The OID you mention refer to a registered naming authority
which is essentially only applicable to a few useful external schemes that exists
today.  Like DUNS, the Swedish citizen registry etc.  Organizations acting as CAs
would typically not specify this optional element as their naming domain = CA.

> should be overlooked more carefully before we jump to fast into approving 

I believe that the PI concept has some problems like competing with DN and
maybe worse: If the PI-thing is going to automate the mapping processes
we use today I have some serious doubts on the current semantics like:

- Is a single CA (cert) supposed to support an arbitrary set of naming domains?

- What happens if a CA generates some certs with and some without PI?  Syntax error?

IMO it had been better if PI had supported DN mapping and was a part of a CA cert only.
That would restrict PI naming domains to one / CA but that is IMO a much more
practical solution. 

/anders