Subject: I-D ACTION:draft-ietf-pkix-pi-03.txt

From: [email-masked]
Date: Thu, 14 Feb 2002 07:05:18 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Permanent 
                          Identifier
	Author(s)	: D. Pinkas, T. Gindin
	Filename	: draft-ietf-pkix-pi-03.txt
	Pages		: 9
	Date		: 13-Feb-02
	
This document define a new form of name, called permanent 
identifier, that may be included in the subjectAltName extension 
of a public key certificate issued to a physical person.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pi-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pi-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pi-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 14 Feb 2002 15:09:32 +0100

>of a public key certificate issued to a physical person.

I cannot from the draft deduct that this is only about physical persons.
Actually it talkes about "entities" which IMO is anything worthy of an ID.

To do a separete PI effort for organizations as been suggested seems like
complicating things and deviates from DN attributes which are universal.

Anders

---

From: "Roberto Opazo" <[email-masked]>
Date: Thu, 14 Feb 2002 17:01:50 -0400

Congratulations, I think it is very good and necessary.

I agree with the syntax proposed, but I think the text is not completely
coherent with the syntax…

I do not understand why the text has a scope so restricted. The term
 “Person” in the e-mail abstract is obviously a typing error since it is
right in the draft using the term “entity”. But there is another scope
restriction, “…may be included in the subjectAltName extension…”. Why only
subjectAltName? The new syntax applies to OtherName type, so in fact it
applies to every extension witch use a General Name (GN) type, like
issuerAltName for example. The text is saying “may be”, so it is not
restricting the possibility of using it in another extension, but I think
there is a space for interpretation, that implies confusion.

Based on previous conversation with Denis Pinkas, I think this is not a
typing error, so I would like to post my point…

Usually we do not have collision problems with CA names, so PIs are less
necessary for issuers than for subjects, but there are other reasons to use
a PI, at least consistency and comfort.

I think consistency is very important, if PI are going to be used, then
there will be many routines to extract that identifier from one certificate
and there will be DBs witch use this identifier as record key. So, it will
be very comfortable and consistent to use the same method to treat entities
and CAs in DB. Actually, there are many Systems that are not PKI based and
this systems are using some identifier that will be good candidates to be
PI. Many of these systems are going to be migrated to use PKI. The
developers involved has no idea about what DNs are. I think PI will
facilitate the construction of tools for that people and they will want to
have a routine to manipulate identifiers, not necessary DN.

One example: Last year, when we wore discussing the Service of Internal
Taxes (SII) regulation in Chile to use public key certificates, they said
they want the certificates to have the Run (Rol único nacional) of the
subject and the Rut (Rol único tributario) of the issuer. My opinion was not
in favor of putting de Rut of the CA in certificates because that
information can be obtained very easily from CPS, CA Web site and Service of
Internal Taxes resolutions, between others. Other reason to not want to put
the Rut there was to increase the certificate size, that is not very good
when you are putting it in a smart card. But people prefer to administrate
the Run and the Rut in the same way.

Lets think in an access control database, there you have entities authorized
identifies by PI, and there you have a list of CAs in which the System
trust, do you want to identify this CAs by DN or you prefer to use the same
method used for entities?

In many cases this CAs are going to be regulated, so there is no risk of not
finding the CA PI in the certificate if the organization using the DB want
to use a CA PI.

Does it sound reasonable to you?

If not, the syntax proposed in the draft allows it, but the text do not.

Best regards,

Roberto Opazo – [email-masked]
CEO – www.acepta.com
Certification Authority for Chile

> -----Mensaje original-----
> De: [email-masked] [mailto:[email-masked]]En
> nombre de [email-masked]
> Enviado el: Jueves 14 de Febrero de 2002 08:05 AM
> Para: IETF-Announce:
> CC: [email-masked]
> Asunto: I-D ACTION:draft-ietf-pkix-pi-03.txt
>
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Thu, 14 Feb 2002 23:06:54 +0100

Roberto,
I support issuer PIs as well.

I have an objection to this xxxxAltName thing for PIs that you may comment on.
The majority of pre-PI schemes use serialNumber for keeping this infomation.
The really huge programs going on in Norway and Sweden where the banks
build national PKIs is a prime example.

These certficates contain a minimal DN (country, name, number).  The latest version
of the Post Offices' profile even excluded country!  Nice and clean IMO.

So how do you fulfil 3039's DN uniqness requirement using the PI draft?
Probably by *duplicating* the RUN, citizen number etc. in the DN, or
creating nonsense disamabiguers.  Although its not a crime to duplicate
data, I feel some resistance to creating a scheme based on that.

If the PI draft is no longer limited to individuls, should there not be any
kind of identifier telling what it denotes?

Anders

----- Original Message -----
From: "Roberto Opazo" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 14, 2002 22:01
Subject: RE: I-D ACTION:draft-ietf-pkix-pi-03.txt

I agree with the syntax proposed, but I think the text is not completely
coherent with the syntax.

I do not understand why the text has a scope so restricted. The term
 "Person" in the e-mail abstract is obviously a typing error since it is
right in the draft using the term "entity". But there is another scope
restriction, ".may be included in the subjectAltName extension.". Why only
subjectAltName? The new syntax applies to OtherName type, so in fact it
applies to every extension witch use a General Name (GN) type, like
issuerAltName for example. The text is saying "may be", so it is not
restricting the possibility of using it in another extension, but I think
there is a space for interpretation, that implies confusion.

Based on previous conversation with Denis Pinkas, I think this is not a
typing error, so I would like to post my point.

Best regards,

Roberto Opazo - [email-masked]
CEO - www.acepta.com
Certification Authority for Chile

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Feb 2002 12:02:06 +0100

Anders,

> Actually it talkes about "entities" which IMO is anything worthy of an ID.

You noticed a difference between the advertisement made by the web editor
and the actual abstract.

The editor has kept the old abstract to advertise the new draft instead 
of using the new abstract.

The new abstract has been changed and now considers any kind of entity 
and is thus no more limited to physical persons.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 15 Feb 2002 12:18:21 +0100

Anders,

> I support issuer PIs as well.

As Roberto mentionned it, the syntax proposed in the draft allows to support
issuer PIs, but the text does not. It is an extension for GeneralNames, so
it could easily be supported.

Since PKIX-part 1 states: "The issuer field MUST contain a non-empty
distinguished name (DN)", the issuerAltName is usually not used.

I presently see two persons supporting issuer PIs. 
Anybody else for it or against it  ?

> So how do you fulfil 3039's DN uniqness requirement using the PI draft?

DN uniqueness has to be fulfiled, whatever the content of any extension 
(including the PI extension) may be.

> data, I feel some resistance to creating a scheme based on that.

There is a major difference. The number you place in the DN cannot tell you
it is, e.g. a RUN. It is a number that is not guaranteed to be unique by
itself. Only the combination country+name+number is unique. It happens that,
in your example, the "number" being used is unique, but nobody can take
advantage of it. The PI information on the contrary is by itself unique.

> kind of identifier telling what it denotes?

Applicable to any entity, as the text says.

Denis

---

From: "Anders Rundgren" <[email-masked]>
Date: Fri, 15 Feb 2002 16:15:13 +0100

Denis,
<snip>

>(including the PI extension) may be.

Agreed.

>it is, e.g. a RUN. 

Agreed, but there _could_ be a variant of the PI-option that points to other
elements holding the actual value.  This become particularly interesting
if the descriptor is not restricted to EE-level but is also usable on CA-level,
because then the existing population of pre-PI-certs could be PI-enabled
by regenerating the CA-cert with old keys and expiration data.  I know that
you don't support that, but I think that it is too much to ask CAs to recall
all certificates out there, when there are workarounds available.  I also
find it less attractive to be *forced* to put the "information that really counts"
for access control etc. in new places, not directly supported by current
crypto SW and associated GUI.

>It is a number that is not guaranteed to be unique by itself.

Agreed.

>Only the combination country+name+number is unique.

This is an *entirely* different discussion that is not PI-related but here is my
disagreeing view on that:
Another CA could *rightfully* issue a certificate with exactly these
datas and elements but for anoher purpose (including another subject).
At least 3039 does not do any assumptions that country indicates citizenship,
it could be "blue oyster club" membership in some way associated with
country in some way.  This is the X509 "Namespace" problem in a nutshell,
as described in a recent posting.

>It happens that, in your example, the "number" being used is unique, but nobody can take

Well, everybody using the aforementioned certificates *are* already
taking these advantages including for access control based on "knowledge".

>Applicable to any entity, as the text says.

That's good, but what about the last paragraph in my question?

Anders

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 18 Feb 2002 10:06:25 +0100

Anders,

> datas and elements but for anoher purpose (including another subject).

Correct. I should have said: 
"Only the combination country+name+number is unique for a given CA."

> taking these advantages including for access control based on "knowledge".

In a "private PKI", you can certainly have additional conventions. You may,
for example, state that all CNs are unique, even if additional attributes
are
present. But in an "open PKI" no one can take advantage of this additional
property and, in this WG, we are considering specifications for "open PKIs".

> That's good, but what about the last paragraph in my question?

I could not clearly understand the last paragraph and the question. 
Would you rephrase it ?

Denis