Subject: PIC and RFC 2510

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Aug 2001 10:04:10 -0700 (PDT)

RFC 2510 (and its successor in progress, 
draft-ietf-pkix-rfc2510bis-04.txt),  includes a number of requirements for
Public Key Infrastructure Certificate Management Protocols. From page 7 of RFC 2510bis:

"5. PKI management protocols must allow the use of different
industry-standard cryptographic algorithms, (specifically
including RSA, DSA, MD5, SHA-1)....

6. PKI management protocols must not preclude the generation of 
key pairs by the end-entity concerned..."

However, http://www.ietf.org/internet-drafts/draft-ietf-ipsra-pic-03.txt
notes in section A.4:

"The protocol as described requires the policies of Client and Server to
match regarding credentials. For example, an unrecoverable protocol error
results if the Client is unable to produce a private key but the server requires this
capability. 
    
Several approaches for credential negotiation were considered and rejected
for this protocol, in the interest of simplicity. The general case would
require negotiation of multiple properties in parallel, for example: 
    
   - Is the private key generated by the Client or the AS. 
   - What type of certificate is required, in particular which algorithm. 
   - What length of keys is required, for each of the credential's
       components."

It would therefore appear that PIC does not meet the RFC 2510 requirements
for certificate management protocols. How do we resolve this?

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 31 Aug 2001 11:50:09 -0700

At 10:04 AM -0700 8/31/01, Bernard Aboba wrote:
>Public Key Infrastructure Certificate Management Protocols.

Well, that is one way to look at 2510. Another way is to look at the 
twisted history of the PKIX Working Group and see that 2510 describes 
*one* of the standardized certificate management protocols, and that 
the "requirements" section in fact is a self-justification for the 
particular protocol.

For those of you who love IETF politics (which, of course, is not 
wholly unrelated to the existence this very Working Group), the 
"other" certificate management protocol to come out of the PKIX WG is 
CMC, RFC 2797. The two do essentially the same thing, but using 
different formats for the messages. The politics of why there are 
even two different protocols is out of scope for this working group 
(and should have been out of scope for PKIX, but wasn't).

>for this protocol, in the interest of simplicity.

Right.

>  The general case would

Smells like IKE. :-)

>for certificate management protocols.

Right. Remember, this WG even considered getting RFC 2510 (CMP) 
extended to handle multiple round trip legacy auth as the protocol 
for this group. We instead chose PIC.

>  How do we resolve this?

No need to resolve anything. PIC is not a generic certificate 
management protocol: it has a particular function for use in IPsec, 
and meets a particular requirement ("don't do the legacy 
authentication where most people want to do it, namely in IKE").

--Paul Hoffman, Director
--VPN Consortium