[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
PKCS 7 + PKCS 10 Proposal
All--
Back in San Jose and again in Memphis the PKIX WG expressed interest in
considering the use of PKCS 7 and PKCS 10 for PKI administrative
messaging. The draft below follows up on this topic from Memphis.
The question naturally emerges: How does this relate to PKIX Part 3,
considering that PKIX Part 3 accepted changes at the last IETF which
accomodate PKCS 7 and PKCS 10?
Carlisle and I today discussed the issues surrounding this question, in
the context of the draft below. We concluded it proposes a reasonable
approach towards leveraging the installed base of PKCS 7 capabilities.
To that end, I propose we consider this framework in Munich and determine
if and how it should move forward.
The authors also feel that this work merits attention within the IPSEC
Working Group, hence it cross-posting to that list.
Carlisle had the following specific observations:
1. The draft continues to promote the notion that one need only have a
single key.
2. It provides no means to certify a D-H key. Recognizing that the WG
has received a proposal to do so using PKCS 10 constructs, there still
remains a problem of coordinating parameters between the client and the
CA.
3. It does not adequately address the subscriber bootstrapping
problem.
4. More generally, the current draft clearly falls short of addressing
the entire set of capabilities provided by Part 3.
For each of these there exists a reasonable counter position. It's
tempting to rebut each, but in the interest of brevity I will address
only the last point, leaving the others to the list and Munich.
To the last point, I would observe that the draft is intended to address
only the most essential elements of a PKI service, with the thought in
mind that additional work would be needed to expand upon these basic
services.
Lastly, I apologize to the members of both lists for missing the deadline
and dumping this directly onto the lists.
(Carlisle, if I've misrepresented your position, I'm sure you'll have no
reservation whatsoever in correcting the public record!)
--Mike
Michael Myers
VeriSign, Inc.
mmyers@verisign.com
(415) 429-3402
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
PKIX Working Group Michael Myers (VeriSign)
Internet Draft Alex Deacon (VeriSign)
Xiaoyi Liu (Cisco)
<bigger>
Internet Public Key Infrastructure
</bigger>
1. Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and
may be updated, replaced, or obsoleted by other documents at any time.
It is inappropriate to use Internet-Drafts as reference material or to
cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munari.oz.au Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
2. Abstract
Part 3 of the Internet Public Key Infrastructure (PKIX Part 3) series of
draft PKI standards defines an application-level protocol for use
between PKI clients and PKI service providers. While Part 3 amply
addresses a robust set of PKI requirements, a need exists to more fully
leverage existing implementa-tion investment in the PKCS7 security
protocol and PKCS10 certification request specification. PKCS10 fails
however to address the full range of requirements addressed by PKIX Part
3. This draft combines PKIX Part 3 concepts and PKCS10 in the context of
PKCS7 security encapsulation to propose an alternative Certificate
Management Protocol (CMP).
3. Protocol Overview
3.1 Transaction-Based Services
A CMP Transaction is composed of the exchange of two or more messages
between a CMP Server and a CMP Client. This interaction is best
illustrated by the Certification Request transaction. The most complex
variation involves certification requests arriving at a Server when the
Server is operated in a manner that requires manual authentication of the
certification request.
The following figure illustrates the interactions. In this illustration,
the client produces a certification request and transmits it to a Server
config-ured for manual authentication. The Server immediately returns a
response message that indicates the certification request is pending
manual authentication. When a PENDING message is received for a
certificate request it sent, the client periodically polls for the
availability of the certificate. During the interval while a Certificate
Request is pending manual authentication, an individual at the CA hosting
the server is involved in authenticating the identification information
contained in the request. When the certificate is available, the Server
responds with a SUCCESS response message that contains the Client’s
certificate.
(The authors recognize that polling is sub-optimal for secure enclaves of
even modest scale. Future revisions of this draft will address Client
state management logic that enables more efficient utilization of
bandwidth in large scale situations.)
Client Server
| |
|----- Certification Request ---->|
| |
|<<------- PENDING Response -------|
| |
|------------- Poll ------------->|
| |
|<<------- PENDING Response -------|
| |
|------------- Poll ------------->|
| |
|<<------- PENDING Response -------|
| |
|------------- Poll ------------->|
| |
|<<------- SUCCESS Response -------|
All other CMP currently defined transactions complete with a single
request and response interchange. These include an immediate SUCCESS
response when the Server is configured for automatic authentication, and
transactions to retrieve certificates and CRLs. Section 8 of this draft
identifies areas where further work can be expected.
3.2 Transaction Synchronization
Each CMP transaction is identified and tracked using a transaction
identifier. Clients generate transaction identifiers and retain their
state until the server responds with a message that closes the
transaction. When the Server receives a message from a client, the
transaction identifier is also retained in the Server while the request
is being processed. During the processing of the request, if it is
necessary that the client and server exchange messages regarding the
state of the transaction, the transaction identifier is included in these
intermediate messages. When the Server completes processing of a
request, the transaction identifier is included in the response message
to the Client. If a Client receives a message for which it has no
retained transac-tion identifier, the message is discarded.
3.3 Replay Prevention
The CMP incorporates a Sender and Recipient nonce for the purpose of
replay prevention. Nonce values are random numbers. The message that
initiates a transaction contains only a Sender nonce.
The recipient of an initial message retains the Sender nonce and uses it
as the value of Recipient nonce in the next message back to the
transaction originator. The original recipient in turn generates its own
Sender nonce and includes this in the response message as the value for
Sender nonce.
Upon receipt of intermediate messages, the recipient compares the value
of the message’s Recipient nonce against a local store of Sender nonces
generated by the Recipient. If a match is not found, the message is
rejected. If a match is found, the recipient retains the value of Sender
nonce in the message for inclusion as Recipient nonce in any intermediate
messages back to the message originator. The recipient also generates a
new value for its Sender nonce and includes it as the value of message
Sender nonce.
Continuing with the Certification Request transaction example above, the
following figure illustrates CMP nonce state management. The column
labeled "Msg" corresponds to a message in the prior illustration.
The "Client Retains" and "Server Retains" columns are logically { (the
nonce I most recently sent you), (the nonce I most recently received from
you) }.
The "Client Sends" and "Server Sends" columns correspond to the {sender
nonce, recipient nonce} values in the message. Finally, the sequential
values in the table are for illustrative purposes only.
Msg Client Client Server Server
Retains Sends Sends Retains
|-----------------------------------------------------|
|Request | {1,-} {1,-} |
|-----------------------------------------------------|
|PENDING | {2,1} {2,1} |
|-----------------------------------------------------|
|Poll | {3,2} {3,2} |
|-----------------------------------------------------|
|PENDING | {4,3} {4,3} |
|-----------------------------------------------------|
|Poll | {5,4} {5,4} |
|-----------------------------------------------------|
|PENDING | {6,5} {6,5} |
|-----------------------------------------------------|
|Poll | {7,6} {7,6} |
|-----------------------------------------------------|
|SUCCESS | {8,7} {8,7} |
|-----------------------------------------------------|
3.4 Transport Model
This specification makes no assumptions about the underlying transport
mechanism. The use of PKCS 7 specifically is not meant to imply an
email-based transport. A prototype of this protocol currently in
operation demonstrates that HTTP is well suited to the CMP transaction
model.
3.5 Security Encapsulation
A CMP message is composed of a message body and one or more Service
Indica-tors. CMP Service Indicators are encoded as a set of authenticated
attributes of a PKCS7 SignedData construction. CMP message bodies are
first encrypted to become EnvelopedData and then included as the content
of SignedData. The message digest of the encrypted message body is then
signed together with the Service Indicators.
By separating the encryption and signing transformations, message
handling decisions based on the signed service indicators can be
determined prior to invoking security procedures specific to the message
body.
The following figure illustrates the essential characteristics of a CMP
message. Many interior details and fields have been omitted for clarity.
Not all of the indicated fields are present in every CMP message type.
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| content |
| Message Encryption Key (MEK) | encrypted under Recipient’s
public
| encrypted CMP message body | encrypted under MEK
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type | indicates msg body syntax
| transaction identifier |
| transaction status |
| sender nonce |
| recipient nonce |
|---------------------------------------|
| Message Signature |produced using originator’s
private
|---------------------------------------|operating on hash of AUTH.
ATTR.
3.6 Message Body
A CMP message encapsulated by PKCS7 syntax is constructed as follows.
The contentInfo field of a signedData type is populated with the
envelopedData content type. The encryptedContent of this envelopedData
may contain one of the following CMP message bodies:
- PKCSReq -- Request for a certificate
- CertRep -- Response to a certificate request
- GetCertInitial -- A means to poll for a pending certification
- GetCert -- A means to query for others’ certificates
- GetCRL -- A means to query for a CA’s CRL(s)
A PKCSReq message consists of a PKCS10 certificate signing request. It is
sent from the client to the CA. As currently specified, the request
shall contain the subject name, the subject public key and a
ChallengePassword attribute. It may contain an optional ExtensionReq
attribute used to indicate to the CA one or more certificate extensions.
Additional extensions to PKCS10 content should be anticipated as this
draft standard evolves.
A CertRep message is the CA’s response to a PKCSReq, GetCertInitial or
GetCert GetCRL. It may contain a certificate but always contains one or
more Service Indicators.
A GetCertInitial message is used to poll a CA for a requested certificate
in the circumstance when the PKIStatus of prior CertRep message indicates
PENDING.
Clients may use a GetCert or GetCRL message to access a CA’s repository
of certificates or CRL(s) respectively.
3.7 Service Indicators
Service indicators are included with a message body to form a complete
CMP message. The SignerInfos portion of the signedData content type
conveys additional information needed to complete the protocol. The
authenticatedAt-tributes element of the SignerInfos syntax is used to
identify an enveloped-Data content type carrying one of the following CMP
service indicators:
- transactionId
- messageType
- pkiStatus
- failinfo
- senderNonce
- recipientNonce
Each service element is uniquely identified by an OID that signals the
syntax following the OID. CMP processing systems would first detect the
service element OID and process the corresponding service indicator value
prior to processing the message body.
The transactionId service indicator identifies a given transaction. It
is used between client and server to manage the state of an operation.
The messageType service indicator identifies the syntax carried in the
message body.
The PKIStatus service indicator is used to convey information relevant to
a requested operation.
The failInfo service indicator conveys information relevant to the
interpreta-tion of a failure condition.
The senderNonce and recipientNonce service indicator can be used to
provide application-level replay prevention.
4. Protocol Elements
4.1 PKCS7 Encapsulation
The following syntax specifies the general content of CMP messages.
Required values for certain fields are specified as comments to selected
protocol elements. For the purposes of interoperability, CMP-compliant
applications shall implement these required values for the indicated
protocol elements. Applications may also implement additional values for
these fields to accommodate other operational environments.
PKIMessage ContentInfo ::= SEQUENCE {
contentType OBJECT IDENTIFIER -- {pkcs-7 2}, SignedData
content [0] } -- data to be signed
The data to be signed into a PKCS7 encapsulated CMP message shall be
struc-tured as follows.
With the exception of the response to a GetCRL request message, the
optional CRL component of a signedData content type shall not be included
in a CMP message.
SignedData ::= SEQUENCE {
version INTEGER,
digestAlgorithms AlgorithmIdentifier,
contentInfo SEQUENCE {
contentType OBJECT IDENTIFIER -- {pkcs-7 3},
EnvelopedData
content [0] } OPTIONAL -- encrypted message body
certificate [0] Certificate, -- signer’s certified
public key
signerInfos SignerInfos } -- contains Service
Indicators
The SignerInfos portion of SignedData carries one or more CMP Service
Indicators. SignerInfo shall be composed as follows:
SignerInfo ::= SEQUENCE {
version INTEGER,
issuerAndSerialNumber SEQUENCE {
issuer Name,
serialNumber INTEGER }
digestAlgorithm AlgorithmIdentifier,
authenticatedAttributes SET OF Attributes,
digestEncryptionAlgorithm AlgorithmIdentifier,
encryptedDigest OCTET STRING }
The value of authenticatedAttributes is hashed using the algorithm
specified by digestAlgorithm, signed using the originator’s private key
corresponding to digestEncryptionAlgorithm, the result encoded as an
OCTET STRING and assigned to the encryptedDigest field.
Since PKCS 7 requires the presence of a digest of the message content in
AuthenticatedAttributes, message content is indirectly bound to the
signature through the digest of AuthenticatedAttributes.
Specification of the syntax and semantics of the CMP service indicators
that can be included as AuthenticatedAttributes are presented in section
4.3.
Some CMP messages do not carry a contentInfo block in SignedData. These
messages are composed as SignedData consisting of version,
digestAlgorithm, certificate(s) and SignerInfo. When a CMP message
conveys additional content, this content is conveyed as an EnvelopedData
content type within the Con-tentInfo block of SignedData and is
structured as follows.
EnvelopedData ::= SEQUENCE {
version INTEGER,
recipientInfos SET OF SEQUENCE {
version INTEGER,
issuerAndSerialNumber SEQUENCE {
issuer Name,
serialNumber INTEGER }
keyEncryptionAlgorithm AlgorithmIdentifier,
encryptedKey OCTET STRING }
encryptedContentInfo SEQUENCE {
contentType ContentType,
contentEncryptionAlgorithm AlgorithmIdentifier,
encryptedContent [0] IMPLICIT OCTET STRING }
4.2 Object Identifier Base
The OIDs for CMP objects stem from the PKIX arc. PKIX Part 1 establishes
the following value as the base of the PKIX object identifier space:
pkix OBJECT IDENTIFIER ::= { 1 3 6 1 5 5 7 }
Objects associated with PKIX Certificate Management Protocol are
established under the following identifer space:
pkix-cmp OBJECT IDENTIFIER ::= { pkix X } --Get with Tim Polk on
this
4.3 Use of Authenticated Attributes
CMP Service Indicators are encoded as AuthenticatedAttributes within
Signed-Data. In accordance with PKCS7, when included in a PKCS7 message,
Authenticat-edAttributes must consist of at a minimum:
- A PKCS #9 content-type attribute having as its value the content type
of the ContentInfo value being signed.
- A PKCS #9 message-digest attribute, having as its value the message
digest of the content.
For the first, CMP chooses to use the PKCS9 attribute OID ContentInfo to
signal additional content interpretation information. This is the first
in the SET OF Attributes defining CMP’s AuthenticatedAttributes.
Following the ContentInfo OID, CMP includes the mandatory message digest
attribute. In addition to this required syntax, CMP currently defines
six authenticated attributes:
Service Indicator OID Syntax
----------------- ------------- ---------------
TransactionId pkix-cmp 1 PrintableString
messageType pkix-cmp 2 PrintableString
pkiStatus pkix-cmp 3 PrintableString
failinfo pkix-cmp 4 PrintableString
senderNonce pkix-cmp 5 OCTET STRING
recipientNonce pkix-cmp 6 OCTET STRING
The TransactionID, messageType, pkiStatus and failInfo service indicators
are decimal values expressed as a string.
The TransactionID Service Indicator uniquely identifies a transaction; it
is used to match responses to requests. To be effective, its value must
be unique within any reasonably chosen context. In the certificate
enrollment transac-tion, this requirement may be met by producing a
Certification Request transactionID using a hash on the end entity public
key value. CMP Servers SHALL NOT rely upon NOR enforce this behavior.
This attribute is required in all PKI messages.
The messageType service indicator specifies the type of operation
performed by the transaction. This attribute is required in all PKI
message. The following message types defined:
PKCSReq (19) -- Permits use of PKCS#10 certificate request
CertRep (3) -- Response to certificate request
GetCertInitial (20) -- Certificate polling in manual enrollment
GetCert (21) -- Retrieve a certificate
GetCRL (22) -- Retrieve a CRL
All response messages will include transaction status information which
is defined as pkiStatus service indicator:
SUCCESS (0) -- request successful
FAILURE (2) -- request rejected
PENDING (3) -- request pending
This PKIStatus service indicator is required for all PKI messages.
If the status in the response is FAILURE, then the failinfo service
indicator will contain one of the following failure reasons:
BADALG (0) -- Unrecognized or unsupported algorithm ident
BADMESSAGECHECK (1) -- integrity check failed
BADREQUEST (2) -- transaction not permitted or supported
BADTIME (3) -- Message time field was not sufficiently close
-- to the system time
BADCERTID (4) -- No certificate could be identified matching
the
-- provided criteria
The attributes of senderNonce and recipientNonce are random numbers
generated per transaction to prevent replay attack. This attribute is
required for all PKI messages.
In the first message of a transaction, no recipientNonce is transmitted;
a senderNonce is instantiated by the message originator and retained for
later reference. The recipient of a senderNonce reflects this value back
to the originator as a recipientNonce and includes it’s own senderNonce.
Upon reciept by the transaction originator of this message, the
originator compares the value of recipientNonce to its retained value.
If the values match, the message can be accepted for further security
processing. The received value for senderNonce is also retained for
inclusion in the next message associated with the same transaction.
4.4 Messages
4.4.1 PKCSReq Message Format
Clients shall produce a PKCS10 message body containing an unambiguous
identity and public key. The exact structure of this identity and the
means by which it is determined is a matter of operational policy.
PKCSReq CertificationRequest ::= SEQUENCE {
certificationRequestInfo SEQUENCE {
version INTEGER,
subject Name,
subjectPublicKeyInfo SEQUENCE {
algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING }
attributes [0] IMPLICIT SET OF Attribute }
signatureAlgorithm AlgorithmIdentifier,
signature BIT STRING }
The client may incorporate one or more standard X.509 v3 extensions in
the request as PKCS 9 attributes. This information shall be expressed in
the Attributes field of a PKCSReq as a iteration of individual objects of
the form EXTENSION as defined in X.509.
CMP-compliant CAs are not required to be able to process every v3 X.509
extension transmitted, nor are they required to be able to process other,
private extensions. However, in the circumstance when a CA denies the
certification request due to the inability to handle a requested
extension, the CA shall respond with a error that unambiguously
identifies the error condition.
Service Indicator OID Value
----------------- -------------------------- -----------------
contentType pkcs-9 3
messageDigest pkcs-9 4
transaction-id pkix-cmp 1
messageType pkix-cmp 2 PKCSREQ
senderNonce pkix-cmp 5
4.4.2 CertRep
Clients receive CertRep messages in response to a prior PKCSReq message.
The response may be one of:
--PENDING
--SUCCESS
--FAILURE
The general structure of a CertRep message is as follows. An "inner"
SignedData content type is encrypted and then encapsulated as
EnvelopedData. This encapsulation becomes the contentInfo of an "outer"
SignedData content type which is signed by the message originator. This
final encapsulation is then passed on to the intended message
recipient.
The figure below schematically illustrates the essential data structure
relationships. Specific content will vary by context. Some fields
omitted for clarity.
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| ENVELOPED DATA |
| MEK | - encrypted under Client’s
public
| encrypted content: | - encrypted under MEK
| SIGNED DATA | - content varies
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type |
| transaction identifier |
| transaction status |
| failure info |
| sender nonce |
| recipient nonce |
|---------------------------------------|
| MESSAGE SIGNATURE | - produced using CA’s private
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
4.4.2.1 PENDING
When the CA decides to manually authenticate the end entity, the CA
returns CertRep with pkiStatus set to PENDING and proceeds to perform the
required authentication.
The PENDING CertRep message is a SignedData content type with no
ContentInfo block. The SignerInfo block contains the following
Authenticated Attributes as indicated:
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type | - CERTREP
| transaction identifier | - from prior request
| transaction status | - PENDING
| sender nonce | - prior client nonce
| recipient nonce | - current server nonce
|---------------------------------------|
| Message Signature | - produced using CA’s private
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
4.4.2.2 FAILURE
CAs transmit a CertRep messages with a PKIStatus of FAILURE if the
certifica-tion request or its subsequent processing fails to meet the
requirements of the CA’s practices.
The message is a SignedData content type with no ContentInfo block. The
SignerInfo block contains the following Authenticated Attributes as
indicated:
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type | - CERTREP
| transaction identifier | - from prior request
| transaction status | - FAILURE
| failInfo | - reason code
| sender nonce | - prior client nonce
| recipient nonce | - current server nonce
|---------------------------------------|
| Message Signature | - produced using CA’s private
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
Failure reason codes are specified in Section 4.2.
4.4.2.3 SUCCESS response
When used to deliver a certificate, the Client’s certificate shall be
conveyed to the Client in the SignerInfo portion of a degenerate
SignedData content type. This is encapsulated by an EnvelopedData
content type which is in turn encapsulated by an outer SignedData. The
outer SignedData is signed by the originator of the CertRep message.
Schematically, the relationship among these elements is as follows (some
interior details omitted for clarity):
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| ENVELOPED DATA |
| MEK | - encrypted under Client’s
public
| encrypted content: | - encrypted under MEK
| SIGNED DATA | - degenerate, no content
| Client’s certificate | - includes client cert in
SignerInfo
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type | - CERTREP
| transaction identifier | - from prior request
| transaction status | - SUCCESS
| sender nonce | - prior client nonce
| recipient nonce | - current server nonce
|---------------------------------------|
| Message Signature | - produced using CA’s private
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
4.4.3 GetCertInitial
The GetCertInitial message is used to poll for the certificate associated
with prior request if the response to that prior request was a CertRep
message with a status of PENDING.
Certificates are normally referenced using the CA DN and the certificate
serial number. In this case however a certificate has not yet been
issued. Thus the CA and Subject DNs are present in the message as a
means to identify the requested certification.
The following syntax shall be included as the message body:
IssuerAndSubject ::= SEQUENCE {
issuer Name,
subject Name }
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| ENVELOPED DATA |
| MEK | - encrypted under CA’s public
| encrypted content: | - encrypted under MEK
| SIGNED DATA | - degenerate, no content
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES |
| Hash of Content |
| message type | - GETCERTINITIAL
| transaction identifier | - from previous request
| sender nonce | - new
| recipient nonce | - current server nonce
|---------------------------------------|
| Message Signature | - produced using Client’s pvt
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
4.4.4 GetCRL
This operation is used to retrieve CRLs from a CA’s repository. It
comple-ments PKIX Part 2 in that this function as specified is an
integral component of CMP and thus forms a standalone solution to
essential Certificate Management services.
It assumes the target CA maintains one and only one CRL relative to a
given private signing key. In order to provide Client a convenient means
of determining the network address needed to acquire a CA’s CRL,
PKIX-compliant CMP Servers and Clients should be capable of producing and
processing, respectively, the CRLDistributionPoints certificate
extension. The CRLDistributionPoint shall contain a URL that Clients
reference when directing a query for the CRL of a given certificate’s
Issuer. Alternatively, the Client may be pre-configured with the CMP
Server’s URL.
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| DATA |
| GetCRL message body |
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES | - See Appendix A for OIDs.
| Hash of Content | - binds requestor to request
| message type | - GETCRL
| transaction identifier | - new transaction
| sender nonce | - new sender nonce
|---------------------------------------|
| Message Signature | - produced using Client’s pvt
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
The GetCRL message body shall consist of the following syntax:
GetCRL ::= SEQUENCE {
issuerName Name,
time GeneralizedTime }
4.4.5 GetCert
When CMP Clients have no external configuration function to provide them
the network address of a CA’s Repository, CMP Clients may attempt the
value for CRLDistributionPoints as the value for a CA’s Repository
generally. CMP Servers should be configured to provide this
capability.
|---------------------------------------|
|SIGNED DATA |
|---------------------------------------|
| DATA |
| GetCert message body |
|---------------------------------------|
| ORIGINATOR’S CERTIFICATE |
|---------------------------------------|
| AUTHENTICATED ATTRIBUTES | - See Appendix A for OIDs.
| Hash of Content | - binds requestor to request
| message type | - GETCRL
| transaction identifier | - new transaction
| sender nonce | - new sender nonce
|---------------------------------------|
| Message Signature | - produced using Client’s pvt
key
| | operating on hash of AUTH.
ATTR.
|---------------------------------------|
The GetCert message body shall consist of the following syntax:
GetCert ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER }
5. PKI Transactions
5.1 Client Requests Certification of a Public Key
To obtain a certificate, a client creates a PKCS10 certificate signing
request (CSR) and signs it using the private key corresponding to the
public contained in the CSR. A content-encryption key is generated and
the CSR encrypted under this key. The result is placed into the
EncryptedContent portion of En-velopedData. The content encryption key
is in turn encrypted under the public key of the recipient CA and
included in the recipientInfo of envelopedData.
The client next generates a transactionID and a 16-byte random number for
senderNonce. The transactionID should be unique to guard against
transaction replay. A good source of uniqueness is a hash of the public
key contained in the CSR. Recipient CAs should make no assumptions about
this structure of transactionId.
PKCS7 requires that the signerInfo contain a issuerNameSerialNumber
value; however for this transaction, the certificate has yet to be issued
and therefore the serialNumber has not yet been assigned. Thus the
issuerName and SerialNumber value in the signerInfo are set to NULL and
zero, respectively.
Upon receipt of this message, the CA must first determine that the
signature validates using the supplied public key, thereby proving
possession of the private key. This check also provides integrity
assurance. Given the nature of this particular message however, this
check does not provide authentica-tion.
Alternatively, for those who do not have the ability to alter the DER
encoding of the PKCS7 message, (i.e. those using the toolkits such as
TIPEM) the end entity may generate a self-signed certificate and use it
to build the envelope PKCSReq message. In this self-signed certificate
the subject DN and issuer DN should both be the DN which has been
specified in the PKCS10 request. The serialNumber of this self-signed
certificate should be zero.
The client then constructs a SignedData object using the self-signed
certifi-cate, with the transactionId, senderNonce and message digest as
authenticated attributes. The attributes should be signed using the end
entity’s private key, completing the SignedData.
If the operational relationship between the client and the CA requires
manual identity confirmation, an operator must verify the end entity’s
request information in some out-of-band method before the request can be
granted. Examples of this out-of band method may include calling someone
on the phone to compare the hash values or via a pre-authenticated list
of entities. In this manual case, the end entity will receive a CertRep
message with status set to PENDING. If the end entity is not entitled to
the key usage it requested (via ExtensionReq), the request should be
rejected as part of the identity confirmation process.
5.1.1 Exception handling
Errors can occur during the enrollment phase that cause requests to be
placed in a partially fulfilled state from either the end entities or
CA’s perspec-tive. In such cases, the transactions must be
"re-synchronized" according to the following rules:
5.1.1.1 End entity does not receive a response
If a response to a PKCSReq is not received, the end entity should send
GetCertInitial request to the server with the same transactionID as the
original PKCSReq until a valid response is received or the number of
retries has been exceeded. In the latter case, the transaction is marked
as failed, and a new PKCSReq message will be sent to the CA with the same
transaction ID as the previous (failed) PKCSReq. When the CA receives the
new request, it will recognize that the new transaction has a pending
equivalent and will "cancel" the previous transaction.
5.1.1.2 User cannot open enveloped message:
Because the response is encrypted with the user’s public key, this error
would only occur if the message or private key is corrupt. This should be
treated as a protocol error and the user should request that the
certificate be revoked through the manual revocation process.
5.1.1.3 User cannot verify CA signature:
It may be issued from the CA’s perspective, but was never successfully
delivered to the user. The user should request that the certificate be
revoked through the manual revocation process.
5.1.1.4 Other abnormal errors
These are protocol errors where the user does not receive a response from
the CA to complete the transaction. In general, the user should retry
until it exceeds the retry limit, then "re-synchronize" by starting a new
transaction with the same transactionID. When the CA sees this duplicate
transaction, it should re-synchronize by canceling all equivalent pending
transactions. A transaction is considered to be "equivalent" if it is the
same message type from the same entity, and has the same transaction
ID.
5.2 End entity polls for its initial certificate
If the status in the CertRep is PENDING, the end entity creates and
transmits a GetCertInitial message. The encryptedContentInfo of this
message contains the IssuerAndSubject data structure that refers to the
end entity. The end entity repeats this request until the CertRep it
receives has a status of SUCCESS or FAILURE.
If the CA receives multiple GetCertInitial request from an end entity
with the same transactionID it will simple process the request as
normal.
5.3 Revocation
To revoke a certificate, the client communicates to the operator of the
CA Management System. That is, a user will communicate the revocation to
the CA operator, who will ask for the challenge phrase included in the
original certification request to confirm the identity of the user.
Additional confirmation steps may be necessary to ensure that the
revocation request is genuine and is the clear intent of the client to
whom the certificate was issued.
6. Security Considerations
7. Author’s Addresses
Michael Myers
VeriSign, Inc.
Xiaoyi Liu
Cisco Systems