P1: JDW
PublicKey WL040/Bidgolio-Vol I WL040-Sample.cls June 19, 2003 16:56 Char Count= 0
162 PUBLICKEYINFRASTRUCTURE(PKI)of optional fields. As a result, conforming implemen-
tations may not interoperate for all possible transac-
tions. Nonetheless, the CMP specification defines the five
common transactions in detail. These transactions are
mandatory for conforming implementations, and they are
specified in sufficient detail to achieve interoperability.
Unfortunately, therevocation requestandrevocation re-
sponseis not among these five transactions.
CMP messages are designed to handle multiple re-
quests in a single message. This feature permits a user
with two key pairs (one for signature and another for key
management) to submit a single request. This feature also
permits batch processing by RAs.Certificate Management Messages over CMS
Over time, the IETF PKIX Working Group grew and be-
came more diverse. Not everyone was comfortable with
the direction of the CMP protocol. A group emerged that
felt that it was crucial to leverage the installed base of
PKCS #7 and PKCS #10. To these vendors, CMP repre-
sented a radical departure from a working, deployed pro-
tocol. CMP defined too many messages, and the CMP
transactions demanded too many roundtrips. In their
eyes, the comparative complexity of CMP overwhelmed
the new functionality.
The PKIX Working Group fragmented into two camps.
Those with a significant investment in CMP pointed out
the weaknesses in PKCS #7 and PKCS #10, as well as the
historic intellectual property issues. Those with a signi-
ficant investment in PKCS #7 and PKCS #10 pointed out
that a majority of PKIs used the RSA algorithm exclusively
and that most PKIs did not involve RAs in protocols di-
rectly. When RSA Security decided to relinquish change
control for PKCS #7 and PKCS #10 to the IETF S/MIME
Working Group, RSA Security also resolved the intellec-
tual property issues.
Eventually, a truce was achieved, and a second pro-
tocol emerged. Both protocols share the same certificate
request format. The second protocol would use the new
Cryptographic Message Syntax (CMS; in RFC 2630) speci-
fication to provide cryptographic protection for messages.
The Certificate Management Messages over CMS (CMC;
in RFC 2797) references PKCS #10 for a basic certificate
request format, and CRMF for the more fully featured
certificate request format. Furthermore, CMC offers al-
gorithm independence and include support for direct in-
volvement of RAs.
CMC specifies only two complete transactions: the sim-
ple enrollment protocol and the full enrollment proto-
col. These transactions each require two messages. The
CA determines which type of certificate request has been
received from the content itself. CMC began as a sim-
ple structure, but complexity was added to provide all
of the necessary security and functionality. CMC control
attributes determine the overall control flow. CMC de-
fines 24 control attributes. These control attributes pro-
vide many of the features found in the CMP header,
such as nonces and transaction identifiers. They are also
used to implement proof-of-possession, pass arbitrary
data, and indicate which extensions should appear in a
certificate.Simple Certificate Enrollment Protocol
Cisco Systems developed the Simple Certificate Enroll-
ment Protocol (SCEP), and, as such, it is not an open stan-
dard like CMP or CMC. SCEP supports the secure issuance
of certificates to network devices in a scalable manner,
and it makes use of existing technology whenever possi-
ble. The existing technology includes the RSA algorithm,
the DES algorithm, the PKCS #7 and PKCS #10 message
formats, hypertext transfer protocol (HTTP), and LDAP.
The protocol supports four transactions: distribution of
CA and RA public keys, certificate requests, certificate
queries, and CRL queries. The latter two transactions are
actually repository functions, but they are included in
the SCEP specification. The protocol also supports out-
of-band revocation requests by establishing a revocation
challenge password during the certificate request.
SCEP requires that end systems obtain three pieces of
information as an initial condition: the CA IP (Internet
protocol) address or domain name, the CA HTTP script
path, and the URL for CRL queries if CRLs will be ob-
tained from a directory. The end system uses an unpro-
tected HTTP Get operation to obtain CA and RA certifi-
cates. At this point, the end system must contact the CA
operator through out-of-band means and verify the hash
of the certificate to ensure the integrity of this operation.
End entities begin the PKI enrollment process by gen-
erating their own public/private key pair, then they issue
themselves a self-signed certificate. This certificate will
be used for both authentication and key management, so
the RSA algorithm is used. This provides each entity with
a temporary, syntactically correct X.509 certificate. This
step is required, because a digital signature protects all
messages in the certificate request transaction, or signed
and encrypted using PKCS #7, which assumes that a pub-
lic key certificate is available. PKCS #7 requires an issuer
name and serial number to identify the certificate.POLICIES AND PROCEDURES
The bulk of this chapter focuses on PKI technical mecha-
nisms, but technical mechanisms are insufficient on their
own; they must be used in combination with a set of proce-
dures to implement a particular security policy. Two doc-
uments describe the policies and procedures associated
with a PKI. The first document is known as acertificate
policy(CP), and the second is called acertification prac-
tices statement(CPS). These documents share a common
format but have different audiences and different goals.
RFC 2527, theCertificate Policy and Certification Practices
Framework,established the recognized format for both a
CP and a CPS.
Most PKI users will not refer to the CP or CPS. Users
usually obtain the policy information indirectly by pro-
cessing the certificate policies, policy mapping, and pol-
icy constraints extensions. There is a direct relationship
between the contents of these extensions and the CP and
CPS, however.
The CP is a high-level document that describes a secu-
rity policy for issuing certificates and maintaining certifi-
cate status information. This security policy describes the
operation of the CA, as well as the users’ responsibilities