Tải bản đầy đủ
4 PKI Protocol-Related Components 212

4 PKI Protocol-Related Components 212

Tải bản đầy đủ

The Framework: Public Key Infrastructure (PKI)

213

of cryptography-related formats, known collectively as Public Key
Cryptography Standards (PKCS); each member of the family has its
own number, which is appended to the family name. In particular,
PKCS #10 [3] defines the format for CRs, most often used by a
hopeful certificate owner to ask a CA to create a certificate (that does
not yet exist). Certificate requests can also be used by potential certificate users who want to access or download a specific certificate. In
addition, they appear in IKE CR payloads to ask the peer to send
one or more existing certificates. PKCS #7 [4] is a format that can
be used for a number of cryptographic entities, including digitally
signed certificates and digitally signed CRLs. It also can be used
to send “digital envelopes,” which consist of data encrypted with a
symmetric key, along with the symmetric key encrypted with a public key. A newer specification, Certificate Request Message Format
(CRMF), also can be used for CRs.
• Operational protocols. Potential peers of a certificate’s holder need to

be able to retrieve the certificate. They also need to check its current
status, to ascertain whether it is still valid or has been revoked. Placing the certificates in an accessible directory is a good first step,
but standardized protocols are necessary to accomplish the
certificate-accessing and status-checking operations. Certificates and
CRLs can be retrieved from a directory [5] using LDAP [6–8]. They
also can be requested and obtained via FTP, HTTP, or email.
An alternative to the use of static, periodically updated CRLs is an
online query protocol known as Online Certificate Status Protocol
(OCSP) [9], which allows a potential certificate user to check the
up-to-the-minute status of a certificate.

• Management protocols. CAs and RAs require a different set of proto-

cols than certificate users. CAs need to store, update, and remove
certificates and CRLs. They also must be able to communicate with
other CAs for the purpose of cross-certification and CA hierarchy
establishment. Aspiring certificate holders need to be able to request
a new certificate from the CA, securely provide the CA and RA with
the necessary information, and possibly download the private key
from the CA.
A number of competing protocols have been defined for certificate establishment and maintenance. Each has its own strengths and
weaknesses, and each is currently used or planned for use by one or
more commercial CAs or CA providers.

214

Demystifying the IPsec Puzzle









Certificate Management Protocol (CMP) [10]. This is a full certificate life cycle management protocol, specifying all the necessary
messages that could possibly be exchanged by the CA, RA, and
certificate holder or any combination thereof. It is a heavy-duty
protocol, especially because many alternative behaviors are
allowed, and only a few mandatory ones are specified. For example, the RA is an optional entity, but if it exists, it can perform
any or all of an array of functions, from user authentication to key
generation. Any required functions not performed by the RA are
assumed by the CA. The preferred message syntax is CRMF. For
backward compatibility, CRs in PKCS#10 format are accepted,
but strongly discouraged. This protocol is actively supported by
Entrust Technologies and Baltimore Technologies.
Certificate Management Protocol Using CMS (CMC) [11]. This
is a recursive acronym; CMS stands for cryptographic message
syntax. CMC is also a full-service protocol, lacking only the
ability to perform cross-certification. Its messages can be encoded
in multiple formats, including CRMF and PKCS. This protocol
has been blessed by Verisign, Cisco, and Microsoft.
Simple Certificate Enrollment Protocol (SCEP) [12]. This is a
somewhat limited protocol, created to fill the need for a straightforward interactive protocol that can create certificates for
network (specifically IPsec) devices. It was intended for rapid
implementation and deployment while other more complicated
and complete protocols worked their way through the standardization process. Web-based HTTP messages are exchanged to perform certificate issuing and revocation and to access certificates
and CRLs. CRs are in PKCS#10 format; all messages are
PKCS#7-encoded. There is no explicit facility for certificate
renewal; to accomplish that, the certificate holder first must
revoke the certificate and then request a new certificate. A
number of vendors have announced their intentions to implement SCEP.
PKCS10 Plus Out of Band (P10POUB). This method will not
be found in any of the standard PKI literature. It was invented
by members of the IPsec community, desperate to successfully
interoperate in the absence of a global PKI infrastructure, and
formally defined in the IKE PKI profile [13]. Communication
with the CA takes place via email messages or through Web
access, with the applicant filling out a form that constitutes the

The Framework: Public Key Infrastructure (PKI)

215

CR. In either case, the CR is in PKCS#10 format, including the
applicant’s public key; the request also should include the desired
alternative name and certificate extensions. (Certificate fields
are examined later in this chapter.) The CA then sends back the
newly minted certificate in one of a variety of formats.
• Certificate policies and practices. CAs need to specify and adhere

to their individual certificate policy (CP) and certification practice
statement (CPS) [14]. They relate to operational matters and security, including the methods used to verify potential certificate holders’ identities, security of physical objects and personnel procedures,
and revocation polices. They affect the level of trust that can be
accorded to the CA’s certificates.

10.5 Certificates and CRLs
A common repository for certificates and CRLs is an X.500 directory. The
directory is a distributed database, which is capable of holding many different types of data. In the PKI world, it is used to hold certificates and CRLs.
Those objects are often accessed via the Lightweight Directory Access Protocol [8] (LDAP), which permits directory objects to be downloaded. LDAP
does allow for the use of optional access controls and confidentiality, but
they generally are omitted for certificate and CRL retrieval. Because the certificates’ and CRLs’ contents are authenticated through the use of the CA’s
digital signature, they can be fetched using an insecure protocol. PKIX also
has defined certificate and CRL access using FTP [15, 16], HTTP [15, 17],
and email. For IKE, those methods suffice if certificates and CRLs are
obtained before the IKE negotiation. IKE can then validate the certificate,
ensuring that its CA is trusted and its contents have not been tampered with,
before using the certificate’s key as part of the peer authentication process.
When the certificates are exchanged as part of the IKE phase 1 exchange with
peer authentication through digital signatures, it is preferable to send the certificate in Main Mode message 5 or 6, when it can be encrypted and its integrity guaranteed by the authenticating hash. That maximizes the possibility
that the exchange can proceed without sabotage by an attacker that could
otherwise alter the certificate’s contents.
CRLs can be stored and accessed in the same manner as certificates.
CRLs generally are issued at fixed intervals. Certificate revocation can occur
at any time; in particular, it can occur after one CRL has been issued but well
before the next one. Thus, CRLs are not a foolproof method of ensuring the

216

Demystifying the IPsec Puzzle

currency of a certificate. OCSP provides more up-to-the-minute information, but that protocol has its own complications for IKE, because an IKE
negotiation can time out while waiting for an OCSP response.

10.6 Certificate Formats
For certificates and CRLs to be universally useful, it is important to establish
a standard, unambiguous way in which to describe their components. Ideally, that is the function of Abstract Syntax Notation One [18, 19], generally
referred to as ASN.1. It is a symbolic language, consisting of a series of
rules that, together, definitively describe a composite object; in our case, the
ultimate objects we want to define are certificates, CRs, and CRLs. That is
accomplished in an iterative manner. The initial ASN.1 rule describes the
highest level object in terms of a series of components. Successive rules refine
the definition of each component in an increasingly concrete manner, until
the lowest level, that of digits and characters, is reached.
Figure 10.2 shows the ASN.1 representation of two portions of a
certificate. The first rule defines the general structure of a certificate, which
consists of a “tbscertificate,” the portion of the certificate that will be digitally
signed, an identifier for the algorithm used to create the digital signature, and
the signature itself. The second rule defines the time-related validity period
of the certificate.
Now that we have an abstract way to describe certificates, we need to
be able to translate this structure into an encoding that consists of bits and
bytes. That is where basic encoding rules (BER) and distinguished encoding
rules (DER) come in [20]. Each ASN.1 component is assigned a unique
identifier, a numeric object identifier (OID). BER and DER are used to
Certificate

::=

SEQUENCE

{

tbsCertificate

TBSCertificate,

signatureAlgorithm

AlgorithmIdentifier,

signatureValue

BIT STRING

Validity ::= SEQUENCE {
notBefore

Time,

notAfter

Time }

Figure 10.2 Sample ASN.1 rules.

}