P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
PKI MANAGEMENTPROTOCOLS 161prospective certificate holder, a current certificate holder,
or a registration authority (RA). The CA has a different
relationship with each of these participants.
A prospective certificate holder is essentially unknown
to the CA but has requested acceptance into the PKI. The
potential subscriber would like the CA to issue a certificate
containing a specific identity and public key. The prospec-
tive certificate holder can provide this information in an
initial certificate request, but the CA cannot determine
from the data itself whether the name is appropriate. A CA
can cryptographically verify that the requester has posses-
sion of the private key, however. For signature keys, the
requester can simply digitally sign the request. For key
management keys, a challenge-response mechanism may
be required.
A certificate holder that possesses a currently valid
certificate may request a new certificate. The requested
certificate may have a different public key or include
new name forms. The CA knows the subscriber’s identity;
otherwise, it would not have issued the current certificate.
The current key pair may be used for authentication, and,
as described previously, the CA can also cryptographically
verify that the requester possesses the private key. The
CA might not trust its subscribers to claim new names,
however.
A certificate holder that possesses a currently valid cer-
tificate may also request revocation of one of his or her
current certificates. The CA should always revoke a cer-
tificate upon the request of the certificate holder, so the
signed request contains all the information required by
the CA. This does not necessarily mean that the CA trusts
the subscriber for this information or that the subscriber
is telling the truth. If the holder of a private key asserts
that it is no longer valid, this request must be honored. If
the signed request came from another source, then the pri-
vate key has been compromised, and the certificate must
be revoked anyway.
The RA is empowered by the CA to collect informa-
tion and verify its correctness. For certificate request op-
erations, the RA may verify the prospective subscriber’s
identity and their e-mail address or other contact infor-
mation. For revocation requests, the RA may identify the
certificate subject and verify the reason for revocation.
The RA is generally a certificate holder as well. RA digital
signatures allow the CA to authenticate messages readily
from the RA. An RA can review the documentation and
determine whether a CA should honor a request.
PKI management transactions must be designed so
that the CA obtains reliable transaction information. For
some transactions, the CA and the certificate holder can
implement the transaction without assistance. These are
two-party transaction models.In other cases, the transac-
tions leverage an RA to fill in the gaps in the trust relation-
ships between the CA and prospective subscriber. These
arethree-party transaction models. The following is a brief
survey of common PKI management protocols.PKCS #10
Public Key Cryptography Standard (PKCS) #10, Certi-
fication Request Syntax Standard, describes a message
syntax for certification requests. The certification requestconsists of a distinguished name (DN), the public key, an
optional set of attributes, an algorithm identifier, and a
digital signature. The optional attributes were designed
to convey attributes for inclusion in the certificate (for
example, an e-mail address), to provide the CA with ad-
ditional information (for example, a postal address), and
to establish achallenge passwordfor use in a subsequent
revocation request. The request is signed by the entity re-
questing certification using the corresponding private key.
This signature is intended to achieve private key proof-of-
possession.
PKCS #10 defines the syntax of a single request mes-
sage, not a full protocol. The contents or format of the
response is outside the scope of PKCS #10, although a
PKCS #7 message is suggested as one possibility. Almost
every PKCS #10 implementation employs PKCS #7 to re-
turn the certificate. The syntax and protocol used to re-
quest certificate revocation is also unspecified. PKCS #10
must be used with other message formats and protocols
to provide functionality of a complete PKI management
protocol.
PKCS #10 was not designed to be algorithm indepen-
dent. The specification assumes the private key may be
used to generate a digital signature, as is the case with the
RSA algorithm. Proof-of-possession for key agreement al-
gorithms, such as Diffie-Hellman, are outside the scope of
PKCS #10. Proof-of-possession can be achieved using op-
tional attributes to convey additional information, how-
ever. Despite these limitations, PKCS #10 remains the
most widely used certificate request tool.Certificate Management Protocol
When the IETF PKIX Working Group began develop-
ment of a protocol for PKI management, they decided
not to leverage PKCS #7 and PKCS #10. At the time,
RSA Security held the copyright for the PKCS documents,
so the IETF could not have change control. In addition,
the working group wanted to develop a comprehensive
protocol to support a broad variety of models, including
RA participation, and implement algorithm-independent
proof-of-possession. At the time, it was unclear whether
PKCS #7 and #10 were an appropriate starting point to
meet these goals.
The PKIX Working Group developed a new proto-
col defined by the combination of the Certificate Man-
agement Protocol (CMP; in RFC 2510), and the Certifi-
cate Request Management Framework (CRMF; in RFC
2511). The resulting protocol is comprehensive, can sup-
port practically any RA issuance model, and supports
algorithm-independent proof-of-possession. The proto-
col also includes its own cryptographic message pro-
tection format, and it supports four transport proto-
cols.
CMP defines seven transaction sequences, employing
both request and response messages. These message pairs
support three types of certificate requests, a CA certifi-
cate request, revocation, and key recovery operations. A
proof-of-possession challenge sequence is defined for use
in conjunction with the certificate request messages. The
complexity of the CMP messages means that different im-
plementations may not support the same combination