Re: I-D ACTION:draft-ietf-pkix-pi-08.txt

["David P. Kemp" <[e-mail]>]

Denis and Tom,

It is my hope that PI will become an RFC in the near future, so
that certificates (from an un-named large PKI :-) that currently
handle PIs by munging them into Common Name (e.g.,
CN="Kemp.David.P.0514101404") will have a saner alternative.

Comments:

"Assigner Authority and Type" could and should be better explained,
in the I-D / RFC, but it is also clear what it means without such
an explanation.  See www.acq.osd.mil/uid/policy.html,
"Guide to Uniquely Identifying Items" for an example.  The
guide defines five "Issuing Agencies" (assigner authorities)
where each issuing agency defines the type of identifier it
assigns.  The issuing agencies (and types) are:

   1. EAN-International (EAN.UCC company prefix that goes on the
barcode of everything you buy in the supermarket)

   2. Telcordia Technologies (ANSI T1.220 numbers)

   3. Dun & Bradstreet (DUNS number)

   4. Allied Committee 135 (CAGE code - look up your favorite
company's number at www.dlis.dla.mil/cage_welcome.asp)

   5. European Health Industry Business Communications Council
(EHIBCC number)

There should not be a large number of PI assigner authorities,
but there will be more than five and the list will grow, so they
can't be enumerated within the RFC itself.   It is reasonable
to identify them by IANA-assigned value, or by OID.  It is not
completely unreasonable to identify them by URI, but there is
an impedance mismatch between the goals of PI (physical
organizations with stable business processes to establish
reliable identifiers) and the mechanism of URI (put up a
document/resource somewhere in cyberspace).  Not that a URI
couldn't point to a substantial, permanent organization, or
that the target of an OID couldn't be ephemeral, but OIDs
do have a more substantial "flavor" than URIs.

More to the point, an OID tells a machine implementation what
to do with a PI, whereas a URI is presumably intended to cause
the implementation to make an online access to find out what
to do.  That is an unreasonable burden.

I believe that the syntax of PI-08 is fine as is, and that with
Jim Schaad's corrections and perhaps some more explanatory text
the draft is ready to become an RFC.

Dave



Denis Pinkas wrote:
> 
> Anders,
> 
>> Well Jim,
>> The PI-draft is certainly an odd creature that has been in PKIX's
>> "custody" for now close to four(!) years.
>>
>> A few comments to PI in general and some draft-08 specific.
>>
>> Draft-08: identifierType    "The IdentifierType field, when present, 
>> is an OID which identifies    both the Assigner Authority and the type 
>> of that field. It is an OID"
>>
>> The words "type of that field" has never been explained.  But we all
>> know exactly what the authors' mean don't we?  :-|
>>
>> Draft-08: identifierType has, as you noted been reduced to only support
>> OIDs, probably due to the authors' belief that OIDs are more permanent.
> 
> 
> It was not exactly the author's belief, but the IESG belief.
> 
>> However, the rest of the computer industry have no problems using URIs
>> making PI "incompatible" and "deviating".  A URI also have the
>> big advantage that it may point to a document.
> 
> 
>  ... that has then disappeared, or even worse, pointing to a document 
> that is different from the original one.
> 
>> I find this "obsession" with permanence wrong, because if a CA 
>> disappears,
>> its regitered DNS name is taken by somebody else, 
> 
> 
> The URI was to designate an object defined by an Assigner Authority, not 
> by a CA.
> 
>> the certificates are
>> anaway no longer usable and names may indeed be reused. That is, OID 
>> or URI is a
>> deployment issue.  At best you can RECOMMEND the "serious"
>> implementer to use an OID.
>>
>> PI-General: During the PI development serialNumber has become
>> the de-facto standard for keeping a permanent (or static which is
>> really more what we are talking about) identifier.
> 
> 
> You have already made this comment in the past. serialNumber serves a 
> different purpose. Please take a look at RFC 3039 :
> 
>    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.
> 
>> Anyway, PI-using relying party software have little reason to
>> bother about PI as the existing systems I know of simply does
>> not "decipher" certificates looking for the most "attractive"
>> name form(?), they just _assume_ that things are as the CP says. Most 
>> of these CAs also obey to Anders' nowadays (in)famous
>>  "best practice CA formula":
>>
>>                    CA <=> Policy
>>
>> which makes identifierType redundant and also eliminating the
>> need for additional Subject name forms like PI.
> 
> 
> If you do not have a need for the PI, then that's fine; but other people 
> may wish to use it, as soon/long as it is defined.
> 
> Denis
> 
> 
> 
>> Anders
>>
>> ----- Original Message ----- From: "Jim Schaad" <[e-mail]>
>> To: "'Denis Pinkas'" <[e-mail]>; "'Tom Gindin'" 
>> <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, January 22, 2004 03:22
>> Subject: RE: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>
>>
>>
>> Comments on draft -08.
>>
>> 1.  Privacy concerns should be additionally outlined and covered in the
>> security considerations section.
>>
>> 2.  Section 1, para 9: Text here allows for an AA to have a unique URI
>> name.  Has been removed from the syntax.
>>
>> 3.  Section 1, para 14:  Suggested text "both the same permanent
>> identifier value and the same Authority Identifer Value, then these".
>> (I find the use of identityType to be confusing since I consider this to
>> relate to type choice of IdentifierValue as well.)
>>
>> 4.  Section 2:  What is the criteria for use of iA5String vs uTF8String?
>>
>>
>> 5.  Section 2:  When doing comparisons do I need to cross compare these
>> two different value items?
>>
>> 6.  Section 2: The statement 'It is an OID.' is redundant and can be
>> removed.
>>
>> 7.  Section 3: Contains a paragraph dealing with matching rules.  Since
>> this is no longer a field in the structure the paragraph should be
>> re-written to state what the one and only matching rule is.
>>
>> 8.  Appendix A.1:  New request, please put a reference to the document
>> containing the pkix module into the pkix document (i.e. something like
>> "-- found in [RFC 3280]".  This prevents documents from importing
>> modules that are lower in the standards process without having any
>> explicit reference to them.
>>
>> jim
>>
>>
>>
>>> -----Original Message-----
>>> From: [e-mail] 
>>> [mailto:[e-mail]] On Behalf Of 
>>> [e-mail]
>>> Sent: Wednesday, January 21, 2004 1:27 PM
>>> To: IETF-Announce:
>>> Cc: [e-mail]
>>> Subject: I-D ACTION:draft-ietf-pkix-pi-08.txt
>>>
>>>
>>> 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-08.txt
>>> Pages : 12
>>> Date : 2004-1-21
>>>
>>> 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 an entity.
>>> The permanent identifier is an optional feature that may be used by a 
>>> CA to indicate that the certificate relates to the same entity even 
>>> if the name or the affiliation of that entity stored in the subject 
>>> or another name form in the subjectAltName extension has changed.
>>> The subject name, carried in the subject field, is only unique for 
>>> each subject entity certified by the one CA as defined by the issuer 
>>> name field. Also, the new name form can carry a name that is unique 
>>> for each subject entity certified by a CA.
>>>
>>> A URL for this Internet-Draft is: 
>>> http://www.ietf.org/internet-drafts/draft-> ietf-pkix-pi-08.txt