[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Evaluation: draft-ietf-pkix-pi - Internet X.509 Public Key Infrastructure Permanent Identifier to Proposed Standard
I am not too familiar with URIs either.
What I DO know is that OIDs have been used for a long time
and once assigned are damned stable.
Thanks,
Bert
> -----Original Message-----
> From: Russ Housley [mailto:housley@vigilsec.com]
> Sent: donderdag 24 april 2003 21:33
> To: Leslie Daigle
> Cc: iesg@ietf.org
> Subject: Re: Evaluation: draft-ietf-pkix-pi - Internet X.509
> Public Key
> Infrastructure Permanent Identifier to Proposed Standard
>
>
> Leslie:
>
> I have little experience with URIs, and I would be please to provide
> constructive feedback to the authors in this area. In fact,
> I would be
> fine with limiting the authority name to an OID.
>
> What do others on the IESG think?
>
> Russ
>
> At 03:19 PM 4/24/2003 -0400, Leslie Daigle wrote:
>
> >Howdy,
> >
> >I'm not that concerned about the motivation -- I believe
> >I did understand that from the document (though the specifics
> >you cite add colour :-) and was trying to make that distinction
> >for Steve, who didn't seem to buy it.
> >
> >Where I (still) have issues with the document (not the proposal) is:
> >
> >> The IdentifierType field may contain either:
> >> a) an Object Identifier (i.e. an OID), or
> >> b) a permanent URI using IA5String.
> >> 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.
> >
> >
> >This last sentence is the most concrete thing the document
> >has to say about the use of URIs as identifiers (here, identifiers
> >of IdentifierType).
> >
> >You wrote:
> >>So, is the question how the authorities are named? Two
> alternatives are
> >>supported: OIDs and URIs. OIDs have a registration
> process, and it is
> >>working pretty well. I have less exposure to URIs, but I
> know that the
> >>XML community is using them. I have not heard about any
> disasters, so I
> >>assume that it is working.
> >
> >Issues:
> >
> > 1/ What is a "permanent URI"?
> >
> > Is this meant to identify some ethereal subclass of
> > URIs that are engineered to have persistence
> (e.g., URNs)?
> >
> > Or is there some hand-wavey assumption that the URIs
> > used will somehow be dedicated? But most URIs
> > have domain components, and while many many people
> > have itched to claim that these can be used as permanent
> > or persistent identifiers, it's simply not true
> -- domain
> > names get reassigned.
> >
> > Something else entirely?
> >
> >
> > 2/ "Essentially the same thing is true of URI's"
> >
> > Does this mean that some prefix of the URI
> > is intended for use as the *IdentifierType* identifier?
> > Would that be like "http://aa.ibm.com";? And then
> > is the identifier value "/someidentifier", so that
> > the whole URI is recomposed to
> > "http://aa.ibm.com/someidentifier";?
> >
> > Or is it supposed to be a URI to identify
> > the IdentifierType, and a separate URI (perhaps) for
> > the IdentifierValue?
> >
> > Or does it really not matter? (In which case, it's
> > not really about URIs, it's about random strings
> > with assertions of permanence).
> >
> >As I said -- I think these are all things that could be clarified,
> >and I rather believe they *should* be clarified. But,
> that's a personal
> >opinion, based on rather too much exposure to URIs, their uses, and
> >their abuses.
> >
> >
> >Leslie.
> >
> >Russ Housley wrote:
> >>Leslie:
> >>Let's back up to the motivation for this document. As I
> said, I really
> >>do not want to be seen as the advocate for this document.
> I was one of
> >>the loudest critics in the PKIX working group while this
> document was
> >>being developed. However, I do think that this aspect of
> the document is
> >>satisfactory.
> >>This problem has been around for a long time. The initial solution
> >>resulted in X.509v2, which added the optional unique
> identifier to the
> >>certificate. This identifier did not include an authority,
> it just had a
> >>value. As a result, it did not really solve the problem,
> and no one
> >>makes use of this optional feature. This document
> represents the next
> >>generation.
> >>The original driver for the development of this standard
> was European,
> >>where national identity cards are common practice. In
> fact, many of
> >>countries are issuing smart cards that contain X.509
> certificates (as
> >>well as the associated private key). The inclusion of
> these national
> >>identifiers is important to this community.
> >>In this situation, the authority is a particular country.
> I have little
> >>concern that a national infrastructure will assign the same
> identifier to
> >>more than one person inappropriately.
> >>Another place where a Permanent Identifier can be used is
> in a company.
> >>Consider the employee number. Again, I have no concern
> that a company
> >>will assign the same identifier to more than one person.
> It would make a
> >>huge mess in the human resource database.
> >>Some people think that a Certification Authority (CA)
> might do this as a
> >>service to relying parties. For example, Verisign could
> include a
> >>unique identifier in each certificate subject. I am not sure what
> >>customer base is demanding this service, but it seems to be a very
> >>straightforward thing to implement. In this case, the CA is
> >>authoritative for the name space.
> >>So, is the question how the authorities are named? Two
> alternatives are
> >>supported: OIDs and URIs. OIDs have a registration
> process, and it is
> >>working pretty well. I have less exposure to URIs, but I
> know that the
> >>XML community is using them. I have not heard about any
> disasters, so I
> >>assume that it is working.
> >>One must trust a CA to bind a public key to an identity.
> This is a core
> >>concept to certificates. This is just defining another
> form of identity
> >>that could be bound to a public key. The CA must develop
> procedures that
> >>ensure the robust verification of the identity before issuing the
> >>certificate. Again, this is not new. It is a burden that
> we already
> >>impose on the CA.
> >>Russ
> >>
> >>At 10:02 PM 4/16/2003 -0400, Leslie Daigle wrote:
> >>
> >>>Sure there is a syntax. But in my experience of dealing
> >>>with identifiers, saying "there will be a part that identifies
> >>>the authority and some other unique string" is insufficient
> >>>as semantics.
> >>>
> >>>Leslie.
> >>>
> >>>Russ Housley wrote:
> >>>
> >>>>Leslie:
> >>>>I do not want to be viewed as strongly defending this
> document, but
> >>>>there is a type field. It is quite clear from the ASN.1:
> >>>> PermanentIdentifier ::= SEQUENCE {
> >>>> identifierValue IdentifierValue,
> >>>> identifierType IdentifierType
> OPTIONAL,
> >>>> matchingRule [0] IMPLICIT OBJECT
> IDENTIFIER OPTIONAL
> >>>> }
> >>>> IdentifierType ::= CHOICE {
> >>>> registeredOID OBJECT IDENTIFIER,
> >>>> uri IA5String
> >>>> }
> >>>>The text tells what an absent identifierType means as well....
> >>>>Russ
> >>>>At 07:39 PM 4/16/2003 -0400, Leslie Daigle wrote:
> >>>>
> >>>>>Steven M. Bellovin wrote:
> >>>>>
> >>>>>>Precisely -- any sort of name, permanent or not, is
> useless outside
> >>>>>>of the administrative context. That's why I think this
> is such a bad
> >>>>>>idea, especially as specified here. Why, for example,
> does it need
> >>>>>>to have the CA's name in the PI field, when you always
> have to carry
> >>>>>>the CA name elsewhere in the certificate?
> >>>>>
> >>>>>
> >>>>>
> >>>>>Hmmm. I did not think the document said that. The Assignment
> >>>>>Authority is supposed to be represented in the Identifier
> >>>>>Type:
> >>>>>
> >>>>>" The IdentifierType field, when present, identifies both the
> >>>>>Assigner Authority and the type of that field."
> >>>>>
> >>>>>But the Assigner Authority doesn't have to be the CA.
> >>>>>
> >>>>>The document is not clear enough about how you go about
> >>>>>creating IdentifierType's -- I think that goes to Ted's
> >>>>>points. There are some underlying assumptions (aka hand
> >>>>>waving) that need to be reviewed.
> >>>>>
> >>>>>OTOH, if there is no "IdentifierType" field, then the AA is
> >>>>>assumed to be the CA, and it is essentially local to that
> >>>>>CA. But that's not the same as repeating the CA identifier.
> >>>>>
> >>>>>>
> >>>>>>>>Beyond that, the comparison rules for UTF8 strings
> look wrong --
> >>>>>>>>I'm glad there's a matching rule specified, but from
> the little I
> >>>>>>>>understand about such things there will be a lot of complaints
> >>>>>>>>about the lack of more CJK-friendly matching rules.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>Actually, they should not -- because URIs, as currently
> >>>>>>>defined, are strictly a subset of 0-127 ascii. If you
> >>>>>>>want anything else, you have to encode it (e.g., hex encoding).
> >>>>>>
> >>>>>>
> >>>>>>OK -- but in that case, why does the document say that
> the identifier
> >>>>>>can be a UTV8 string?
> >>>>>
> >>>>>
> >>>>>
> >>>>>Probably 'cause most people don't realize that URIs are
> >>>>>ascii character strings :-) I.e., I only pointed out the
> >>>>>matching rules should work; that may be by accident.
> >>>>>
> >>>>>So, I think there are some engineering issues, but I think
> >>>>>we've understood the proposal differently, and perhaps
> >>>>>buffing off some of the engineering burrs would yield something
> >>>>>rational.
> >>>>>Leslie.
> >>>>>
> >>>>>--
> >>>>>
> >>>>>---------------------------------------------------------
> ----------
> >>>>>"Reality:
> >>>>> Yours to discover."
> >>>>> -- ThinkingCat
> >>>>>Leslie Daigle
> >>>>>leslie@thinkingcat.com
> >>>>>---------------------------------------------------------
> ----------
> >>>
> >>>--
> >>>
> >>>-------------------------------------------------------------------
> >>>"Reality:
> >>> Yours to discover."
> >>> -- ThinkingCat
> >>>Leslie Daigle
> >>>leslie@thinkingcat.com
> >>>-------------------------------------------------------------------
> >>>
> >
> >
> >--
> >
> >-------------------------------------------------------------------
> >"Reality:
> > Yours to discover."
> > -- ThinkingCat
> >Leslie Daigle
> >leslie@thinkingcat.com
> >-------------------------------------------------------------------
> >
> >
>