Subject: PI's RFC number

From: "Roberto Opazo Gazmuri" <[email-masked]>
Date: Thu, 17 Apr 2003 11:39:28 -0400

Hello everybody:

Is there anybody who could estimate a date when we could reference the IETF
Permanent Identifier work with an RFC number?

The last call was on Mon, 25 Nov 2002.

Best regards,

Roberto Opazo

---

From: Stephen Kent <[email-masked]>
Date: Thu, 17 Apr 2003 13:03:09 -0400

>The last call was on Mon, 25 Nov 2002.

Roberto,

The document was returned by the IESG with a variety of minor and 
major concerns, which are now being worked. The document cannot 
progress ot an RFC until the issues they raised are addressed.

Steve

---

From: Russ Housley <[email-masked]>
Date: Fri, 18 Apr 2003 11:09:35 -0400

The IESG sent some concerns to the authors earlier this week.  Those need 
to be resolved.

Russ

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 19 Apr 2003 10:57:10 +0200

Russ,

In case you are doing updates I would drop the following paragraph:

   "The permanent identifier identifies the entity, irrespective of any 
   attribute extension. When a public key certificate contains 
   attribute extensions, the permanent identifier, if present, should 
   not be used for access control purposes but only for audit purposes. 
   The reason is that since these attributes may change, access could 
   be granted on attributes that were originally present in a 
   certificate issued to that entity but are no more present in the 
   current certificate."

As a permanent identifier is just another subject name form, semantics of
PKCs augmented with PIs do not change unless other things regarding
policy is changed as well.   The exact relation between identity and
attribute extensions w.r.t. access control seems to me to be outside
of what should be written in a standard.  As an implementer however, 
I have to _select_ between certificate-based attributes for access-control or
identity-based access-control using lookups in access control databases. 
The text above more or less implies, that implementers do not understand
how to build access control systems.

Another paragraph worth a revision:

         "For non-repudiation, the permanent identifier may be used to 
         link different transactions to the same entity, even when 
         the subject name of the entity changes."

"non-repudiation" should be replaced by the more general "signed messages",
as the entity may be a device, server or whatever, to which the human-related
term "non-repudiation" usually does not apply.

Anders

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>; <[email-masked]>
Sent: Friday, April 18, 2003 17:09
Subject: Re: PI's RFC number

Russ

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 19 Apr 2003 14:45:45 +0200

I don't know the status and appropriateness of these comments but I would 
agree with Anders observation.

In the second sentence I would remove the beginning all together and start 
with "The permanent identifier may ..."

Or why not remove the whole draft (since I fear it will do more harm than 
good), but I guess we are past that :)

/Stefan

> >The last call was on Mon, 25 Nov 2002.

_____________________________
Stefan Santesson,  Retrospekt AB
http://www.retrospekt.com
+46-706 443351

---

From: "Roberto Opazo" <[email-masked]>
Date: Sat, 19 Apr 2003 22:58:14 -0400

Anders,

This time a disagree with you, but I think we should discuss this topic
after having the first version of the standard.

Best regards,

Roberto Opazo

> -----Mensaje original-----
> De: Anders Rundgren [mailto:[email-masked]]
> Enviado el: sábado, 19 de abril de 2003 4:57
> Para: [email-masked]; Russ Housley
> CC: Roberto Opazo Gazmuri
> Asunto: Re: PI's RFC number
>
>
> Russ,
>

---

From: "Anders Rundgren" <[email-masked]>
Date: Sun, 20 Apr 2003 10:16:37 +0200

Thanx Stefan,

Here is another paragraph which I have a problem with:

   "The IdentifierType field, when present, identifies both the 
   Assigner Authority and the type of that field."

That it has a "type" is true (OID or URI) but this is a self-reference
and then you usually do not name things xxxType but rather something
descriptive that implicitly has a type.  Like "PermanentIdentifierNamespace"
(which is closer to its real function as far as I can tell).

But maybe "type" is rather derived from the following paragraph?

   "Characteristically, when an OID is used, the prefix of the OID 
   identifies the Assigner Authority, and a suffix is used to identify 
   the type of permanent identifier being identified. Essentially the 
   same thing is true of URI's."

What does "type of permanent identifier" mean?  I think I know,
but there is not a trace of an explanation to this in the draft.
BTW, there is nothing in the draft assuring that the name space
identified by "IdentifierType" can be used for anything but as a
name space, because a type implies issuance constraints.

The draft's mixing of "Assigner Authority" and "Name Space" is
another thing I find a bit confusing.  "http://registry.org/members" 
is a name space, but the authority is rather "registry.org" as there
could be an "http://registry.org/clients" as well.

Anders

----- Original Message ----- 
From: "Stefan Santesson" <[email-masked]>
To: "Anders Rundgren" <[email-masked]>; <[email-masked]>; "Russ Housley" <[email-masked]>
Cc: "Roberto Opazo Gazmuri" <[email-masked]>
Sent: Saturday, April 19, 2003 14:45
Subject: Re: PI's RFC number

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 21 Apr 2003 01:25:33 +0200

Anders,

I don't feel I can go into the details of this standard since I basically 
don't believe that IETF should produce this standard in the first place.

I don't think this standard should be produced unless the industry without 
any doubts have failed to reasonably address these issues through existing 
mechanisms of X.509 and related standards.

On the contrary I firmly believe that the industry will seek to solve these 
issues through existing mechanisms regardless of this RFC.

I respect though if it is to late to have that discussion.

/Stefan

---

From: "Roberto Opazo" <[email-masked]>
Date: Sun, 20 Apr 2003 23:26:12 -0400

Here we go:

Last year we had a long discussion to get an agreement about PI. It was not
a consensus, but an agreement. On those time, we had the opportunity to
standardize the way we use to code permanent identifier in an X.509v3
certificate, but we still haven't an standard.

Some thinks must be recognized...

The comments received in the WG, an the "minor and major" comment sent by
the IESG to the draft's authors, makes think we have to start again, because
an standard can't be a football goal.

RFC 3280 states than Subject is a mandatory field, but with the actual
draft, this field can't contain a PI, so when you have an End Entity
identified only by one or more PI, you have to put some garbage in the
Subject field and code the PI in the SubjectAltName extension, that is a
crazy idea! Also, it is not very useful to identify the CA with a PI,
because in practice every program need the Issuer field, not the
IssuerAltName.

Some countries are actually using the Subject field to code their main PIs.

It is easy to see than there are good reasons to use DN to code PIs, but
last year, we decided not to use DN to code PIs for many reasons, I hope
this is a good summary:

* DN are already overloaded.

* One entity can have many PIs, but just one DN.

* DN have no way to indicate the nature of the SerialNumber field, so two
entities with the same SerialNumber and other DN's attributes could be
different entities.

Are this reasons invincible? Not in my opinion...

In short, I propose the following:

* Let's recognize than a new discussion is needed.

* Let's use SerialNumber in DN to code a "main entity PI".

* Let's use an extension to indicate when SerialNumber is been used to code
a "main entity PI", and also the Assigner Authority and the type of that PI.
Maybe we could use Certificate Policies for that.

* Let's indicate, that when PI is been used in a DN, then other attributes
in DN (like CN) are just informative.

* Let's continue using the PI draft syntax to code alternative entity's PIs.

Best regards,

Roberto Opazo

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 21 Apr 2003 13:09:37 +0200

Roberto,

RFC 3039 has basically the functionality you ask for.
RFC 3039 specifies a mechanism where you can define the semantics of the 
information carried in the serialNumber attribute (or any other attribute) 
in the DN.

Yes I agree that this (use of serialNumber) should be (as it already is and 
probably will be) the mainstream solution to this type of issue.

There is definitely an overlapping of functionality between RFC 3039 and PI 
draft here.

/Stefan