Re: Evaluation: draft-ietf-pkix-pi - Internet X.509 Public Key Infrastructure Permanent Identifier to Proposed Standard

["Steven M. Bellovin" <smb@research.att.com>]

In message <3E9C7AED.1020503@thinkingcat.com>, Leslie Daigle writes:
>
>
>
>Hmmm, well, just to play devil's advocate for a second (and
>because the alternative is that I have to back to playing
>with powerpoint tables)...

Speaking of the devil....

>
>
>Steven M. Bellovin wrote:
>> In message <200304101701.NAA26528@ietf.org>, IESG Secretary writes:
>> 
>>>Last Call to expire on: 2002-12-9
>>>
>>>	Please return the full line with your position.
>>>
>>>                   Yes    No-Objection  Discuss *  Abstain  
>>>
>>>
>>>Steve Bellovin      [   ]     [   ]       [ X ]      [   ] 
>> 
>> 
>> Permanent universally-unique names strike me as a singularly bad
>> idea in general, and even worse as specified here.  A name can only
>> be guaranteed to be unique (even in theory) within the scope of a
>> single CA; there's no way to make any assumptions if different CAs
>> are involved.  Sure, they're supposed to be URIs, but that's not
>> enforceable except by referring to the parent certificate, and if
>> you're going to do that why bother with a URI at all?  The notion
>> of using permanent identifiers in ACLs is even worse.
>
>Is it any more wrong than using, say, an e-mail address?  (Which
>is unique at any given moment in time).  Then, each certificate
>is a binding of:  a DN (which is more or less an "address" for
>the cert, in some way), a public key, the PI-as-data (e-mail address) and
>the CA's signature on that public key.  You can't trust this
>binding any more than you trust the CA that signed it.
>
>So, you shouldn't use PI's in ACLs, without the additional
>enforcement of trusting the CA that signed the cert
>(or else, as Ted pointed out when he & I were chatting on 
>the phone) you can self-sign a certificate with the requisite
>PI and in you go...
>
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?

>> 
>> 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?

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com (2nd edition of "Firewalls" book)