the outermost PKIdata object. TransactionIds on inner PKIdata objects
are for intermediate entities.
Replay protection can be supported through the use of sender and
recipient nonces. If nonces are used, 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 sender nonce reflects this value back
to the originator as a recipientNonce and includes it's own
senderNonce. Upon receipt 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.
The senderNonce and recipientNonce attribute can be used to provide
application-level replay prevention. Clients MAY include a
senderNonce in the initial request message. Originating messages
include only a value for senderNonce. If a message includes a
senderNonce, the response MUST include the transmitted value of the
previously received senderNonce as recipientNonce and include new
value for senderNonce. A server MUST use only nonces in the outermost
PKIdata object. Nonces on inner PKIdata objects are for intermediate
entities.
5.7 Proof-of-possession (POP) for encryption-only keys
Everything described in this section is optional to implement, for
both servers and clients. Servers MAY require this POP method be used
only if another POP method is unavailable. Servers SHOULD reject all
requests contained within a PKIData if any required POP is missing
for any element within the PKIData.
Many servers require proof that an entity requesting a certificate
for a public key actually possesses the corresponding private
component of the key pair. For keys that can be used as signature
keys, signing the certification request with the private key serves
as a POP on that key pair. With keys that can only be used for
encryption operations, POP MUST be performed by forcing the client to
decrypt a value. See Section 5 of [CRMF] for a detailed discussion
of POP.
By necessity, POP for encryption-only keys cannot be done in one
round-trip, since there are four distinct phases:
1. Client tells the server about the public component of a new
encryption key pair.
2. Server sends the client a POP challenge, encrypted with the
presented public encryption key, which the client must decrypt.
3. Client decrypts the POP challenge and sends it back to the server.
4. Server validates the decrypted POP challenge and continues
processing the certificate request.
CMC defines two different attributes. The first deals with the
encrypted challenge sent from the server to the user in step 2. The
second deals with the decrypted challenge sent from the client to the
server in step 3.
The encryptedPOP attribute is used to send the encrypted challenge
from the server to the client. As such, it is encoded as a tagged
attribute within the controlSequence of a ResponseBody. (Note that
we assume that the message sent in Step 1 above is an enrollment
request and that the response in step 2 is a Full Enrollment Response
including a failureInfo specifying that a POP is explicitly required,
and providing the POP challenge in the encryptedPOP attribute.)
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms contentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
The encrypted POP algorithm works as follows:
1. The server generates a random value y and associates it with the
request.
2. The server returns the encrypted pop with the following fields
set:
a. request is the certificate request in the original request
message (it is included here so the client need not key a copy
of the request),
b. cms is an EnvelopedData object, the content type being id-data
and the content being the value y. If the certificate request
contains a subject key identifier (SKI) extension, then the
recipient identifier SHOULD be the SKI. If the
issuerAndSerialNumber form is used, the IsserName MUST be
encoded as NULL and the SerialNumber as the bodyPartId of the
certificate request,
c. thePOPAlgID contains the algorithm to be used in computing the
return POP value,
d. witnessAlgID contains the hash algorithm used on y to create
the field witness,
e. witness contains the hashed value of y.
3. The client decrypts the cms field to obtain the value y. The
client computes H(y) using the witnessAlgID and compares to the
value of witness. If the values do not compare or the decryption
is not successful, the client MUST abort the enrollment process.
The client aborts the process by sending a request message
containing a CMCStatusInfo control attribute with failInfo value
of popFailed.
4. The client creates the decryptedPOP as part of a new PKIData
message. The fields in the decryptedPOP are:
a. bodyPartID refers to the certificate request in the new
enrollment message,
b. thePOPAlgID is copied from the encryptedPOP,
c. thePOP contains the possession proof. This value is computed
by thePOPAlgID using the value y and request referenced in
(4a).
5. The server then re-computes the value of thePOP from its cached
value of y and the request and compares to the value of thePOP.
If the values do not match, the server MUST NOT issue the
certificate. The server MAY re-issue a new challenge or MAY fail
the request altogether.
When defining the algorithms for thePOPAlgID and witnessAlgID care
must be taken to ensure that the result of witnessAlgID is not a
useful value to shortcut the computation with thePOPAlgID. Clients
MUST implement SHA-1 for witnessAlgID. Clients MUST implement HMAC-
SHA1 for thePOPAlgID. The value of y is used as the secret value in
the HMAC algorithm and the request referenced in (4a) is used as the
data. If y is greater than 64 bytes, only the first 64 bytes of y
are used as the secret.
One potential problem with the algorithm above is the amount of state
that a CA needs to keep in order to verify the returned POP value.
This describes one of many possible ways of addressing the problem by
reducing the amount of state kept on the CA to a single (or small
set) of values.
1. Server generates random seed x, constant across all requests. (The
value of x would normally be altered on a regular basis and kept
for a short time afterwards.)
2. For certificate request R, server computes y = F(x,R). F can be,
for example, HMAC-SHA1(x,R). All that's important for
statelessness is that y be consistently computable with only known
state constant x and function F, other inputs coming from the cert
request structure. y should not be predictable based on knowledge
of R, thus the use of a OWF like HMAC-SHA1.
5.8 LRA POP Witnesses Control Attribute
In an enrollment scenario involving an LRAs the CA may allow (or
require) the LRA to perform the POP protocol with the entity
requesting certification. In this case the LRA needs a way to inform
the CA it has done the POP. This control attribute has been created
to address this issue.
The ASN.1 structure for the LRA POP witness is as follows:
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE of BodyPartID
}
-- pkiDataBodyid field contains the body part id of the nested CMS
body object containing the client's full request message.
pkiDataBodyid is set to 0 if the request is in the current
PKIRequest body.
-- bodyIds contains a list of certificate requests for which the
LRA has performed an out-of-band authentication. The method of
authentication could be archival of private key material,
challenge-response or other means.
If a certificate server does not allow for an LRA to do the POP
verification, it returns an error of POPFAILURE. The CA MUST NOT
start a challenge-response to re-verify the POP itself.
5.9 Get Certificate Control Attribute
Everything described in this section is optional to implement.
The get certificate control attribute is used to retrieve previously
issued certificates from a repository of certificates. A Certificate
Authority, an LRA or an independent service may provide this
repository. The clients expected to use this facility are those
operating in a resource-constrained environment. (An example of a
resource-constrained client would be a low-end IP router that does
not retain its own certificate in non-volatile memory.)
The get certificate control attribute has the following ASN.1
structure:
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
The service responding to the request will place the requested
certificate in the certificates field of a SignedData object. If the
get certificate attribute is the only control in a Full PKI Request
message, the response would be a Simple Enrollment Response.
5.10 Get CRL Control Attribute
Everything described in this section is optional to implement.
The get CRL control attribute is used to retrieve CRLs from a
repository of CRLs. A Certification Authority, an LRA or an
independent service may provide this repository. The clients
expected to use this facility are those where a fully deployed
directory is either infeasible or undesirable.
The get CRL control attribute has the following ASN.1 structure:
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
The fields in a GetCRL have the following meanings:
-- issuerName is the name of the CRL issuer.
-- cRLName may be the value of CRLDistributionPoints in the
subject certificate or equivalent value in the event the
certificate does not contain such a value.
-- time is used by the client to specify from among potentially
several issues of CRL that one whose thisUpdate value is less than
but nearest to the specified time. In the absence of a time
component, the CA always returns with the most recent CRL.
-- reasons is used to specify from among CRLs partitioned by
revocation reason. Implementers should bear in mind that while a
specific revocation request has a single CRLReason code--and
consequently entries in the CRL would have a single CRLReason code
value--a single CRL can aggregate information for one or more
reasonFlags.
A service responding to the request will place the requested CRL in
the crls field of a SignedData object. If the get CRL attribute is
the only control in a full enrollment message, the response would be
a simple enrollment response.
5.11 Revocation Request Control Attribute
The revocation request control attribute is used to request that a
certificate be revoked.
The revocation request control attribute has the following ASN.1
syntax:
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
-- issuerName contains the issuerName of the certificate to be
revoked.
-- serialNumber contains the serial number of the certificate to
be revoked
-- reason contains the suggested CRLReason code for why the
certificate is being revoked. The CA can use this value at its
discretion in building the CRL.
-- invalidityDate contains the suggested value for the Invalidity
Date CRL Extension. The CA can use this value at its discretion
in building the CRL.
-- sharedSecret contains a secret value registered by the EE when
the certificate was obtained to allow for revocation of a
certificate in the event of key loss.
-- comment contains a human readable comment.
For a revocation request to become a reliable object in the event of
a dispute, a strong proof of originator authenticity is required.
However, in the instance when an end-entity has lost use of its
signature private key, it is impossible for the end-entity to produce
a digital signature (prior to the certification of a new signature
key pair). The RevRequest provides for the optional transmission from
the end-entity to the CA of a shared secret that may be used as an
alternative authenticator in the instance of loss of use. The
acceptability of this practice is a matter of local security policy.
(Note that in some situations a Registration Authority may be
delegated authority to revoke certificates on behalf of some
population within its scope control. In these situations the CA
would accept the LRA's digital signature on the request to revoke a
certificate, independent of whether the end entity still had access
to the private component of the key pair.)
Clients MUST provide the capability to produce a digitally signed
revocation request control attribute. Clients SHOULD be capable of
producing an unsigned revocation request containing the end-entity's
shared secret. If a client provides shared secret based self-
revocation, the client MUST be capable of producing a revocation
request containing the shared secret. Servers MUST be capable of
accepting both forms of revocation requests.
The structure of an unsigned, shared secret based revocation request
is a matter of local implementation. The shared secret does not need
to be encrypted when sent in a revocation request. The shared secret
has a one-time use, that of causing the certificate to be revoked,
and public knowledge of the shared secret after the certificate has
been revoked is not a problem. Clients need to inform users that the
same shared secret SHOULD NOT be used for multiple certificates.
A full response message MUST be returned for a revocation request.
5.12 Registration and Response Information Control Attributes
The regInfo control attribute is for clients and LRAs to pass
additional information as part a PKI request. The regInfo control
attribute uses the ASN.1 structure:
RegInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the
client and server.
If a server (or LRA) needs to return information back to a requestor
in response to data submitted in a regInfo attribute, then that data
is returned as a responseInfo control attribute. The content of the
OCTET STRING for response information is based on bilateral agreement
between the client and server.
5.13 Query Pending Control Attribute
In some environments, process requirements for manual intervention or
other identity checking can cause a delay in returning the
certificate related to a certificate request. The query pending
attribute allows for a client to query a server about the state of a
pending certificate request. The server returns a token as part of
the CMCStatusInfo attribute (in the otherInfo field). The client
puts the token into the query pending attribute to identify the
correct request to the server. The server can also return a
suggested time for the client to query for the state of a pending
certificate request.
The ASN.1 structure used by the query pending control attribute is:
QueryPending ::= OCTET STRING
If a server returns a pending state (the transaction is still
pending), the otherInfo MAY be omitted. If it is not omitted then
the same value MUST be returned (the token MUST NOT change during the
request).
5.14 Confirm Certificate Acceptance
Some Certification Authorities require that clients give a positive
conformation that the certificates issued to it are acceptable. The
Confirm Certificate Acceptance control attribute is used for that
purpose. If the CMCStatusInfo on a certificate request is
confirmRequired, then the client MUST return a Confirm Certificate
Acceptance prior to any usage of the certificate. Clients SHOULD
wait for the response from the server that the conformation has been
received.
The confirm certificate acceptance structure is:
CMCCertId ::= IssuerSerial
-- CMCCertId contains the issuer and serial number of the
certificate being accepted.
Servers MUST return a full enrollment response for a confirm
certificate acceptance control.
6. Local Registration Authorities
This specification permits the use of Local Registration Authorities
(LRAs). An LRA sits between the end-entity and the Certification
Authority. From the end-entity's perspective, the LRA appears to be
the Certification Authority and from the server the LRA appears to be
a client. LRAs receive the enrollment messages, perform local
processing and then forward onto Certificate Authorities. Some of the
types of local processing that an LRA can perform include:
- batching multiple enrollment messages together,
- challenge/response POP proofs,
- addition of private or standardized certificate extensions to all
requests,
- archival of private key material,
- routing of requests to different CAs.
When an LRA receives an enrollment message it has three options: it
may forward the message without modification, it may add a new
wrapping layer to the message, or it may remove one or more existing
layers and add a new wrapping layer.
When an LRA adds a new wrapping layer to a message it creates a new
PKIData object. The new layer contains any control attributes
required (for example if the LRA does the POP proof for an encryption
key or the addExtension control attribute to modify an enrollment
request) and the client enrollment message. The client enrollment
message is placed in the cmsSequence if it is a Full Enrollment
message and in the reqSequence if it is a Simple Enrollment message.
If an LRA is batching multiple client messages together, then each
client enrollment message is placed into the appropriate location in
the LRA's PKIData object along with all relevant control attributes.
(If multiple LRAs are in the path between the end-entity and the
Certification Authority, this will lead to multiple wrapping layers
on the message.)
In processing an enrollment message, an LRA MUST NOT alter any
certificate request body (PKCS #10 or CRMF) as any alteration would
invalidate the signature on the request and thus the POP for the
private key.
An example of how this would look is illustrated by the following
figure:
SignedData (by LRA)
PKIData
controlSequence
LRA added control statements
reqSequence
Zero or more Simple CertificationRequests from clients
cmsSequence
Zero or more Full PKI messages from clients
SignedData (by client)
PKIData
Under some circumstances an LRA is required to remove wrapping
layers. The following sections look at the processing required if
encryption layers and signing layers need to be removed.
6.1 Encryption Removal
There are two cases that require an LRA to remove or change
encryption in an enrollment message. In the first case the
encryption was applied for the purposes of protecting the entire
enrollment request from unauthorized entities. If the CA does not
have a recipient info entry in the encryption layer, the LRA MUST
remove the encryption layer. The LRA MAY add a new encryption layer
with or without adding a new signing layer.
The second change of encryption that may be required is to change the
encryption inside of a signing layer. In this case the LRA MUST
remove all signing layers containing the encryption. All control
statements MUST be merged according to local policy rules as each
signing layer is removed and the resulting merged controls MUST be
placed in a new signing layer provided by the LRA. If the signing
layer provided by the end-entity needs to be removed to the LRA can
remove the layer.
6.2 Signature Layer Removal
Only two instances exist where an LRA should remove a signature layer
on a Full Enrollment message. If an encryption needs to be modified
within the message, or if a Certificate Authority will not accept
secondary delegation (i.e. multiple LRA signatures). In all other
situations LRAs SHOULD NOT remove a signing layer from a message.
If an LRA removes a signing layer from a message, all control
statements MUST be merged according to local policy rules. The
resulting merged control statements MUST be placed in a new signing
layer provided by the LRA.
7. Transport Wrapping
Not all methods of transporting data allow for sending unlabeled raw
binary data, in may cases standard methods of encoding can be used to
greatly ease this issue. These methods normally consist of wrapping
some identification of the content around the binary data, possibly
applying an encoding to the data and labeling the data. We document
for use three different wrapping methods.
-- MIME wrapping is for transports that are natively MIME based such
as HTTP and E-mail.
-- Binary file transport is defined since floppy disk transport is
still very common. File transport can be done either as MIME
wrapped (section 7.1) or bare (section 7.2).
-- Socket based transport uses the raw BER encoded object.
7.1 MIME Wrapping
MIME wrapping is defined for those environments that are MIME native.
These include E-Mail based protocols as well as HTTP.
The basic mime wrapping in this section is taken from [SMIMEV2] and
[SMIMEV3]. Simple enrollment requests are encoded using the
application/pkcs10 content type. A file name MUST be included either
in a content type or content disposition statement. The extension
for the file MUST be ".p10".
Simple enrollment response messages MUST be encoded as content-type
application/pkcs7-mime. An smime-type parameter MUST be on the
content-type statement with a value of "certs-only." A file name with
the ".p7c" extension MUST be specified as part of the content-type or
content-disposition.
Full enrollment request messages MUST be encoded as content-type
application/pkcs7-mime. The smime-type parameter MUST be included
with a value of "CMC-enroll". A file name with the ".p7m" extension
MUST be specified as part of the content-type or content-disposition
statement.
Full enrollment response messages MUST be encoded as content-type
application/pkcs7-mime. The smime-type parameter MUST be included
with a value of "CMC-response." A file name with the ".p7m"
extensions MUST be specified as part of the content-type or content-
disposition.
MIME TYPE File Extension SMIME-TYPE
application/pkcs10 .p10 N/A
(simple PKI request)
application/pkcs7-mime .p7m CMC-request
(full PKI request)
application/pkcs7-mime .p7c certs-only
(simple PKI response)
application/pkcs7-mime .p7m CMC-response
(full PKI response)
7.2 File-Based Transport
Enrollment messages and responses may also be transferred between
clients and servers using file system-based mechanisms, such as when
enrollment is performed for an off-line client. When files are used
to transport binary, BER-encoded Full Enrollment Request and Response
messages, the following file type extensions SHOULD be used:
Message Type File Extension
Full PKI Request .crq
Full PKI Response .crp
7.3 Socket-Based Transport
When enrollment messages and responses are sent over sockets, no
wrapping is required. Messages SHOULD be sent in their binary, BER-
encoded form.
8. Interoperability
8.1 Mandatory and Optional Algorithms
CMC clients and servers MUST be capable of producing and processing
message signatures using the Digital Signature Algorithm [DSA]. DSA
signatures MUST be indicated by the DSA AlgorithmIdentifier value (as
specified in section 7.2.2 of [PKIXCERT]). PKI clients and servers
SHOULD also be capable of producing and processing RSA signatures (as
specified in section 7.2.1 of [PKIXCERT]).
CMC clients and servers MUST be capable of protecting and accessing
message encryption keys using the Diffie-Hellman (D-H) key exchange
algorithm. D-H/3DES protection MUST be indicated by the D-H
AlgorithmIdentifier value specified in [CMS]. PKI clients and
servers SHOULD also be capable of producing and processing RSA key
transport. When used for PKI messages, RSA key transport MUST be
indicated as specified in section 7.2.1 of [PKIXCERT].
8.2 Minimum Conformance Requirements
A minimally compliant CMC server:
a) MUST accept a Full PKI Request message
i) MUST accept CRMF Request Bodies within a Full PKI Request
ii) MUST accept PKCS#10 Request Bodies within a Full PKI Request
b) MUST accept a Simple Enrollment Request message
c) MUST be able to return a Full PKI Response. (A Full PKI Response
is always a valid response, but for interoperability with
downlevel clients a compliant server SHOULD use the Simple
Enrollment Response whenever possible.)
A minimally-complaint CMC client:
a) MAY use either the Simple Enrollment Message or the Full PKI
Request.
i) clients MUST use PKCS#10 with the Simple Enrollment Message
ii) clients MAY use either PKCS#10 or CRMF with the Full PKI
Request
b) MUST understand the Simple Enrollment Response.
c) MUST understand the Full PKI Response.
9. Security Considerations
Initiation of a secure communications channel between an end-entity
and a CA or LRA (and, similarly, between an LRA and another LRA or
CA) necessarily requires an out-of-band trust initiation mechanism.
For example, a secure channel may be constructed between the end-
entity and the CA via IPSEC or TLS. Many such schemes exist and the
choice of any particular scheme for trust initiation is outside the
scope of this document. Implementers of this protocol are strongly
encouraged to consider generally accepted principles of secure key
management when integrating this capability within an overall
security architecture.
Mechanisms for thwarting replay attacks may be required in particular
implementations of this protocol depending on the operational
environment. In cases where the CA maintains significant state
information, replay attacks may be detectable without the inclusion
of the optional nonce mechanisms. Implementers of this protocol need
to carefully consider environmental conditions before choosing
whether or not to implement the senderNonce and recipientNonce
attributes described in section 5.6. Developers of state-constrained
PKI clients are strongly encouraged to incorporate the use of these
attributes.
Under no circumstances should a signing key be archived. Doing so
allows the archiving entity to potentially use the key for forging
signatures.
Due care must be taken prior to archiving keys. Once a key is given
to an archiving entity, the archiving entity could use the keys in a
way not conducive to the archiving entity. Users should be made
especially aware that proper verification is made of the certificate
used to encrypt the private key material.
Clients and servers need to do some checks on cryptographic
parameters prior to issuing certificates to make sure that weak
parameters are not used. A description of the small subgroup attack
is provided in [X942]. CMC implementations ought to be aware of this
attack when doing parameter validations.
10. Acknowledgments
The authors would like to thank Brian LaMacchia for his work in
developing and writing up many of the concepts presented in this
document. The authors would also like to thank Alex Deacon and Barb
Fox for their contributions.
11. References
[CMS] Housley, R., "Cryptographic Message Syntax", RFC2630,
June 1999.
[CRMF] Myers, M., Adams, C., Solo, D. and D. Kemp, "Internet
X.509 Certificate Request Message Format", RFC2511, March
1999.
[DH] B. Kaliski, "PKCS 3: Diffie-Hellman Key Agreement v1.4"
[DH-POP] H. Prafullchandra, J. Schaad, "Diffie-Hellman Proof-of-
Possession Algorithms", Work in Progress.
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC2104, February
1997.
[PKCS1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC
2313, March 1998.
[PKCS7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax v1.5",
RFC2315, October 1997.
[PKCS8] RSA Laboratories, "PKCS#8: Private-Key Information Syntax
Standard, Version 1.2", November 1, 1993.
[PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax
v1.5", RFC2314, October 1997.
[PKIXCERT] Housley, R., Ford, W., Polk, W. and D. Solo "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC2459, January 1999.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[SMIMEV2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and L.
Repka, "S/MIME Version 2 Message Specification", RFC2311,
March 1998.
[SMIMEV3] Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC2633, June 1999.
[X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC
2631, June 1999.
12. Authors' Addresses
Michael Myers
VeriSign Inc.
1350 Charleston Road
Mountain View, CA, 94043
Phone: (650) 429-3402
EMail: mmyers@verisign.com
Xiaoyi Liu
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
Phone: (480) 526-7430
EMail: xliu@cisco.com
Jim Schaad
EMail: jimsch@nwlink.com
Jeff Weinstein
EMail: jsw@meer.net
Appendix A ASN.1 Module
EnrollmentMessageSyntax
{ iso(1) identified-organization(3) dod(4) internet(1)
security(5) mechansims(5) pkix(7) id-mod(0) id-mod-cmc(6) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
-- EXPORTS All --
-- The types and values defined in this module are exported for use
-- in the other ASN.1 modules. Other applications may use them for
-- their own purposes.
IMPORTS
-- Information Directory Framework (X.501)
Name
FROM InformationFramework { joint-iso-itu-t ds(5)
modules(1) informationFramework(1) 3 }
-- Directory Authentication Framework (X.509)
AlgorithmIdentifier, AttributeCertificate, Certificate,
CertificateList, CertificateSerialNumber
FROM AuthenticationFramework { joint-iso-itu-t ds(5)
module(1) authenticationFramework(7) 3 }
-- PKIX Part 1 - Implicit
GeneralName, CRLReason, ReasonFlags
FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-implicit-88(2)}
-- PKIX Part 1 - Explicit
SubjectPublicKeyInfo, Extension
FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-pkix1-explicit-88(1)}
-- Cryptographic Message Syntax
ContentInfo, Attribute
FROM CryptographicMessageSyntax { 1 2 840 113549 1 9 16 0 1}
-- CRMF
CertReqMsg
FROM CRMF { 1 3 6 1 5 5 7 0 5 };
id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
dod(6) internet(1) security(5) mechanisms(5) pkix(7) }
id-cmc OBJECT IDENTIFIER ::= {id-pkix 7} -- CMC controls
id-cct OBJECT IDENTIFIER ::= {id-pkix 12} -- CMC content types
-- The following controls have simple type content (usually OCTET
STRING)
id-cmc-identification OBJECT IDENTIFIER ::= {id-cmc 2}
id-cmc-identityProof OBJECT IDENTIFIER ::= {id-cmc 3}
id-cmc-dataReturn OBJECT IDENTIFIER ::= {id-cmc 4}
id-cmc-transactionId OBJECT IDENTIFIER ::= {id-cmc 5}
id-cmc-senderNonce OBJECT IDENTIFIER ::= {id-cmc 6}
id-cmc-recipientNonce OBJECT IDENTIFIER ::= {id-cmc 7}
id-cmc-regInfo OBJECT IDENTIFIER ::= {id-cmc 18}
id-cmc-responseInfo OBJECT IDENTIFIER ::= {id-cmc 19}
id-cmc-queryPending OBJECT IDENTIFIER ::= {id-cmc 21}
id-cmc-popLinkRandom OBJECT IDENTIFIER ::= {id-cmc 22)
id-cmc-popLinkWitness OBJECT IDENTIFIER ::= (id-cmc 23)
-- This is the content type used for a request message in the
protocol
id-cct-PKIData OBJECT IDENTIFIER ::= { id-cct 2 }
PKIData ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
reqSequence SEQUENCE SIZE(0..MAX) OF TaggedRequest,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
bodyIdMax INTEGER ::= 4294967295
BodyPartID ::= INTEGER(0..bodyIdMax)
TaggedAttribute ::= SEQUENCE {
bodyPartID BodyPartId,
attrType OBJECT IDENTIFIER,
attrValues SET OF AttributeValue
}
AttributeValue ::= ANY
TaggedRequest ::= CHOICE {
tcr [0] TaggedCertificationRequest,
crm [1] CertReqMsg
}
TaggedCertificationRequest ::= SEQUENCE {
bodyPartID BodyPartID,
certificationRequest CertificationRequest
}
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
}
TaggedContentInfo ::= SEQUENCE {
bodyPartID BodyPartId,
contentInfo ContentInfo
}
OtherMsg ::= SEQUENCE {
bodyPartID BodyPartID,
otherMsgType OBJECT IDENTIFIER,
otherMsgValue ANY DEFINED BY otherMsgType }
-- This defines the response message in the protocol
id-cct-PKIResponse OBJECT IDENTIFIER ::= { id-cct 3 }
ResponseBody ::= SEQUENCE {
controlSequence SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
cmsSequence SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
otherMsgSequence SEQUENCE SIZE(0..MAX) OF OtherMsg
}
-- Used to return status state in a response
id-cmc-cMCStatusInfo OBJECT IDENTIFIER ::= {id-cmc 1}
CMCStatusInfo ::= SEQUENCE {
cMCStatus CMCStatus,
bodyList SEQUENCE SIZE (1..MAX) OF INTEGER,
statusString UTF8String OPTIONAL,
otherInfo CHOICE {
failInfo CMCFailInfo,
pendInfo PendInfo } OPTIONAL
}
PendInfo ::= SEQUENCE {
pendToken INTEGER,
pendTime GENERALIZEDTIME
}
CMCStatus ::= INTEGER {
success (0),
-- you got exactly what you asked for
failed (2),
-- you don't get it, more information elsewhere in the message
pending (3),
-- the request body part has not yet been processed,
-- requester is responsible to poll back on this
noSupport (4)
-- the requested operation is not supported
}
CMCFailInfo ::= INTEGER {
badAlg (0),
-- Unrecognized or unsupported algorithm
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
unsuportedExt (5),
-- A requested X.509 extension is not supported by the recipient
CA.
mustArchiveKeys (6),
-- Private key material must be supplied
badIdentity (7),
-- Identification Attribute failed to verify
popRequired (8),
-- Server requires a POP proof before issuing certificate
popFailed (9),
-- Server failed to get an acceptable POP for the request
noKeyReuse (10)
-- Server policy does not allow key re-use
internalCAError (11)
tryLater (12)
}
-- Used for LRAs to add extensions to certificate requests
id-cmc-addExtensions OBJECT IDENTIFIER ::= {id-cmc 8}
AddExtensions ::= SEQUENCE {
pkiDataReference BodyPartID,
certReferences SEQUENCE OF BodyPartID,
extensions SEQUENCE OF Extension
}
id-cmc-encryptedPOP OBJECT IDENTIFIER ::= {id-cmc 9}
id-cmc-decryptedPOP OBJECT IDENTIFIER ::= {id-cmc 10}
EncryptedPOP ::= SEQUENCE {
request TaggedRequest,
cms ContentInfo,
thePOPAlgID AlgorithmIdentifier,
witnessAlgID AlgorithmIdentifier,
witness OCTET STRING
}
DecryptedPOP ::= SEQUENCE {
bodyPartID BodyPartID,
thePOPAlgID AlgorithmIdentifier,
thePOP OCTET STRING
}
id-cmc-lraPOPWitness OBJECT IDENTIFIER ::= {id-cmc 11}
LraPopWitness ::= SEQUENCE {
pkiDataBodyid BodyPartID,
bodyIds SEQUENCE OF BodyPartID
}
--
id-cmc-getCert OBJECT IDENTIFIER ::= {id-cmc 15}
GetCert ::= SEQUENCE {
issuerName GeneralName,
serialNumber INTEGER }
id-cmc-getCRL OBJECT IDENTIFIER ::= {id-cmc 16}
GetCRL ::= SEQUENCE {
issuerName Name,
cRLName GeneralName OPTIONAL,
time GeneralizedTime OPTIONAL,
reasons ReasonFlags OPTIONAL }
id-cmc-revokeRequest OBJECT IDENTIFIER ::= {id-cmc 17}
RevRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
passphrase OCTET STRING OPTIONAL,
comment UTF8String OPTIONAL }
id-cmc-confirmCertAcceptance OBJECT IDENTIFIER ::= {pkix-cmc 24}
CMCCertId ::= IssuerSerial
-- The following is used to request V3 extensions be added to a
certificate
id-ExtensionReq OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs-9(9) 14}
ExtensionReq ::= SEQUENCE OF Extension
-- The following exists to allow Diffie-Hellman Certificate Requests
Messages to be
-- well-formed
id-alg-noSignature OBJECT IDENTIFIER ::= {id-pkix id-alg(6) 2}
NoSignatureValue ::= OCTET STRING
END
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.