Subject: "Subject Alternative Name" v/s "Subject/Serial Number"

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Sat, 26 Jan 2002 18:31:48 -0300

Hi, my name is Roberto Opazo, this is my first mail sent to the group.

In Chile we have finished approving the law of electronic signature and we
are initiating conversations to define the regulation that must complement
this law. A central subject of the discussion is how information of the
national unique roll, called RUN (Rol Unico Nacional) should be included in
certificates. That is a number only associate to each citizen in all the
country. It is a comparable identifier to the social security number
insurance in the U.S.A. but its use is but spread, since most of the
Chileans they obtain his RUN when being born and practically all the
computer science applications of the country use it to identify the users.
An important precedent in our country about the form to include this
identifier in a certificate is a resolution of the Service of Internal Taxes
that it establishes that the extension "Subject Alternative Name " is due to
use. The organization who I represent (Acepta.com) is promotional of this
form of codification. Nevertheless, a local CA, who uses technology of RSA
Labs argues that this is difficult to codify and difficult to read. They are
in favor to use the field "Subject" on some form. I would like to request
help with the following doubts:

* It seems to be reasonable to place a RUN in the "Subject"?

* In individual, could be used the attribute "Serial Number" of the field
"Subject" for this?

* Where I can find examples of certificates which they use the extension
"Subject Alternative Name"?

* Where I can find normative what exist of other countries that have solved
east kind of problem?

Thank you very much by its aid.

As it is my first mail to the group, them control a small presentation...

I am founding and Acepta.com’s CEO, a CA developed in Chile using OpenSSL.
We were first in obtaining the accreditation on the part of the Service of
Internal Taxes of the Country on March 2001 (only 2 CAs are on this position
at this time). We have actively collaborated in the development of an
operational model to use electronic invoice that soon will begin to work and
I believe that it will leave more to Chile like one of the advanced
countries in the use of PKI, as much by the penetration in the Internet
users, like by the real value contributed by the technology.

Greetings,

Opazo, Roberto
CEO – www.acepta.com
Certification Authority for Chile

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 27 Jan 2002 09:49:10 +0100

Hi Roberto,

I can give you some information on how some other CAs have handled
this.  In the Nordics (Sweden + Finland) we have a unique code called
person-number that we indeed put into certificates.  According the
Qualified Certificate (RFC3039) profile you can use serialNumber
for holding such identifiers which is the case of the Swedish and Finnish
certificates.  To use SubjectAltName is also possible but less
often featured.  VeriSign use a private such extension for keeping
DUNS (Duns & Bradstreet) numbers in Web-server certificates
which is the same thing as person-numbers but for companies.
But no web-browsers etc. understand this extension, so it will
be listed in hex-code, and since it is not standard either,
few even know that this information is there!

PKIX has a now expired effort addressing the s.c. "permanent identifier"
problem, but right now serialNumber looks like the right solution.

An interesting side discussion: The person-numbers in
SE+FI contains information like date of birth and gender which
is fine when used together with authorities as they already have
this information.  However, this makes the certificates less
"popular" within organizations where you may not want to
expose date of birth all the time.  Therefore Finland created
a "proxy" number that of course still is unique but contains
no information.  Although none of these PKIs have gotten
very far, I believe the Finish solution is recommendable.

Regards
Anders Rundgren
X-OBI

----- Original Message ----- 
From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "PKIX (Grupo de la IETF)" <[email-masked]>
Sent: Saturday, January 26, 2002 22:31
Subject: "Subject Alternative Name" v/s "Subject/Serial Number"

I am founding and Acepta.com's CEO, a CA developed in Chile using OpenSSL.

Greetings,

Opazo, Roberto
CEO - www.acepta.com

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Jan 2002 14:09:31 +0100

> * It seems to be reasonable to place a RUN in the "Subject"?

Today, there is no attribute in the "subject" that has a semantics that, by
itself, tells that this attribute is unique. The only meaning is that the
*set of* attributes shall be unique. 

RFC 3039 states the following:

   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.

So if you place the "National Unique Roll" (NUR) in the subject field 
it will certainly allow you to make a difference between two persons 
that have the same family and first name, but you cannot take 
advantage of the fact that this attribute is indeed unique.

> * In individual, could be used the attribute "Serial Number" of the field

As indicated above, the serialNumber atribute does not have the property of
uniqueness by itself. So it can help you to establish the global uniqueness
of the name, as long as no application uses the serialNumber attibute alone.
This means that, e.g. it is not allowed to use ACL entries that contains the
serialNumber attribute alone, instead ACL entries must contain all the
attributes contained in the DN from the certificate to which an access is to
be granted.

> "Subject Alternative Name"?

Such extensions are used as soon as Distinguished Names are not being used.
I let tother people from the mailing list to provide examples.

> * Where I can find normative what exist of other countries that have solved

There exists a draft document that addresses this issue. Although expired,
it is yet available on the IETF web server. Take a look at:
http://www.imc.org/draft-ietf-pkix-pi

It defines a specific extension in the Subject Alternative Name to support
Permnanent Identifiers. Since certificates can have an empty subject name,
it is necessary to allow the support of the concept of permanent identifier
as part of the subject Alternative Name. 

However, at the light of different conversations that took place, I would
think that it might be appropriate at this time to define new attributes
that could be included in the subject DN to support the notion of Permanent
identifier.

The next two questions are for you: 

1) if two certificates *from two different CAs* contain the same RUN 
   (Rol Unico Nacional) is your intention to be able to say that it is 
   the same person ?

2) after having taken a look at http://www.imc.org/draft-ietf-pkix-pi, 
   would you think more appropriate in your case to support the notion 
   of permanent identifier in the DN or in the Subject Alternative Name ?

Denis

---

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Tue, 29 Jan 2002 00:15:34 -0300

Thanks a lot, I respond between lines...

>    (Rol Unico Nacional) is your intention to be able to say that it is

Yes, any CA accredited in Chile MUST follow certification practices in order
to validate de Chilean Unique Identifier (RUN) of each individual certified.

>    of permanent identifier in the DN or in the Subject Alternative Name ?

I continue thinking It is better to use Subject Alternative Name. After
reading frc 2459 it was very clear for as that Chile was going to need an
OID for the RUN. We registered 1.3.6.1.4.1.8321 as an OID for Chile and
reserve 1.3.6.1.4.1.8321.1  to be used for RUN. Now, any CA to be accredited
for de government taxes department MUST use it. Here is my certificate as
example:

http://varios.acepta.com/ietf/roberto.opazo.cer

It seems very close with de Unique Identifier recommendations.

Now some comments for the future RFC...

I like the argument “you can not take any advantage about one unique
identifier in the DN”. I think this could be mentioned in “Introduction”.

Other situation that could be mentioned is “Individuals can have many
Permanent Identifier and many RP can work with one of then, but others RP
could be interested in others. For example, the national security code v/s
the passport number. If people have to administrate more than one
certificate, usability problems start. So we need to use User Alternative
Names”.

In the definition part, I think the rfc should start at the General Names
syntax of the User Alternative Name, other case it is not clear the manner
for certificate codification. And also, I do not understand why not to use
the choice “other name” for Permanent Identifier.

> Denis

Best regards,

Roberto

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 29 Jan 2002 09:41:49 +0100

To the list and the co-chairs,

From the discussion on the list, due to the lack of a standard, some CAs
have defined private extensions to support the concept of a permanent
identifier.

The two cases advertised to the list are the following:

1) The Australian Government wanted to put the ABN (Australian Business
   Number) (a social security type number for companies) into certificates. 
   They looked into it and decided the best place for it was in a private
   extension. It has its own OID: 1.2.36.1.333.1 and what follows this 
   OID is the 11 or 12 digits ABN number,

2) It was very clear for as that Chile was going to need an OID for the RUN. 
   We registered 1.3.6.1.4.1.8321 as an OID for Chile and reserved 
   1.3.6.1.4.1.8321.1 to be used for RUN. 

In order to avoid/limit the proliferation of such private extensions, or
avoid the use of the serialNumber attribute in a way that is not conformant
to the standards, I believe that it is time to progess the Permanent
Identifier draft (http://www.imc.org/draft-ietf-pkix-pi) that has been
dormant for nearly two years.

The single question is whether this document should be progressed on the
standard track or issued as an informational RFC. I would like to hear the
opinion of the co-chairs of this topic, then I will re-issue the document. 
I think that the standard track would be more appropriate.

Denis

---

From: Massimiliano Pala <[email-masked]>
Date: Tue, 29 Jan 2002 16:40:34 +0100

> have defined private extensions to support the concept of a permanent

I agree with Denis that a solution have to be found. As we have verified
many countries have the need to identify, using a permanent identifier,
the user: this is highlighted when dealing with public administrations
(at least according to my experiences).

I am in favor to review (I have to read it more carefully and a new
version is needed as it is outdated, isn't it ?) and progress the 
http://www.imc.org/draft-ietf-pkix-pi as pointed out by Denis.

I suggest it to be pushed on the standard track instead of publishing
it as an informational RFC, but I am not against any solution that will
be proposed, I am interested in having a clear resolution of the issue
ASAP.

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
                                                       madwolf at openca.org
http://www.openca.org                             madwolf at hackmasters.net
http://openca.sourceforge.net                    Mobile: +39 (0)347 7222 365

---

From: Massimiliano Pala <[email-masked]>
Date: Thu, 31 Jan 2002 11:56:53 +0100

Hi all,

I have some points I'd like to highlight about the PI. Current comments are
made against the http://www.imc.org/draft-ietf-pkix-pi.

First of all some general considerations. My personal point on the PI is
that this should be used only within the subjectAltName ext. and this to
prevent the Subject DN from ever growing and keep as human readable as
possible. I know that there could be established policies following the
Subject DN's but I support this option.

Let's get through the draft in order.

I would change the paragraph:

<< A permanent identifier is a name assigned by an organization, 
   unique within that organization, that singles out a particular 
   individual from all other individuals.  A CA which includes such 
   an identifier in a certificate is certifying that any different 
   public key certificate containing that identifier refers to the 
   same individual. >>

Adding a phrase to clearly state that the "public key certificate..."
is from the CA in subject, something like:

<< A permanent identifier is a name assigned by an organization, 
   unique within that organization, that singles out a particular 
   individual from all other individuals.  A CA which includes such 
   an identifier in a certificate is certifying that any different 
   public key certificate issued by that CA and containing that
   identifier refers to the same individual. >>

I would like to extend the structure of the PersonalIdentifier to
something like this:

   PermanentIdentifier ::=     SEQUENCE {
           assignerAuthority        GeneralName OPTIONAL,
           identifierDesc           Name,
           identifierValue          IdentifierValue }

   IdentifierValue ::= CHOICE {
           permanentId		[1]	    Name,
	   permanentIdHash	[2]	    IDHash }

   PermanentIdHash ::= SEQUENCE {
           identifierHash	    OCTET STRING,  --- original identifier's Hash
	   identifierHashAlgorithm  AlgorithmIdentifier }
           
(there can be errors as I am not a master in structure definition :-D )

This structure (if correct) could solve problems tied to different current
situations, indeed there is the possibility to hide the "real" assigned ID
using the hash value instead. Usage of the Hash instead of the "real" ID
is therefore clearly stated when used. (this could be required if the original
value carries sensible data like date of birth, etc... ).

The identifierDesc field is used to give a text identifier of the id used,
i.e. "RUN" or "ABN", depending on the description adopted by the
assignerAuthority
(I am not sure if this could be coded using different techniques, if so, please,
point it out - thanks). 

I'd also change the word "responsible" when talking about the
assignerAuthority some paragraph behind: this to state that this field
carries an indication not directly stated by the assignerAuthority's
subject (it is no liable for the contents of the field).

It could also be simply stripped off, something like:

<< The assignerAuthority field of this attribute, when present, 
   identifies the organization assigning the content of the identifier
   field. When the assignerAuthority field is missing, the assignee
   Authority is the CA itself and it is assumed  to be the issuer
   name of the certificate. >>

Some comments ? Denis ?

-- 

C'you,

	Massimiliano Pala