RFC 5272
Certificate Management over CMS (CMC)
6.10. Get CRL Control
Everything described in this section is optional to implement. The Get CRL control is used to retrieve CRLs from a repository of CRLs. A CA, an RA, 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 is identified by the OID: id-cmc-getCRL ::= { id-cmc 16 }
The Get CRL control has the ASN.1 definition:
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 server responding to this request places the requested CRL in the
crls field of a SignedData. If the Get CRL control is the only
control in a Full PKI Request, the response should be a Simple PKI
Response.
6.11. Revocation Request Control
The Revocation Request control is used to request that a certificate
be revoked.
The Revocation Request control is identified by the OID:
id-cmc-revokeRequest ::= { id-cmc 17 }
The Revocation Request control has the ASN.1 definition:
RevokeRequest ::= SEQUENCE {
issuerName Name,
serialNumber INTEGER,
reason CRLReason,
invalidityDate GeneralizedTime OPTIONAL,
sharedSecret OCTET STRING OPTIONAL,
comment UTF8string OPTIONAL }
The fields of RevokeRequest have the following meaning:
issuerName is the issuerName of the certificate to be revoked.
serialNumber is the serial number of the certificate to be revoked.
reason is 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 is the suggested value for the Invalidity Date CRL
Extension. The CA can use this value at its discretion in
building the CRL.
sharedSecret is 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 is a human-readable comment.
For a revocation request to be reliable in the event of a dispute, a
strong proof-of-origin is required. However, in the instance when an
EE has lost use of its signature private key, it is impossible for
the EE to produce a digital signature (prior to the certification of
a new signature key pair). The Revoke Request control allows the EE
to send the CA a shared-secret that may be used as an alternative
authenticator in the instance of loss of use of the EE's signature
private key. The acceptability of this practice is a matter of local
security policy.
It is possible to sign the revocation for the lost certificate with a
different certificate in some circumstances. A client can sign a
revocation for an encryption key with a signing certificate if the
name information matches. Similarly, an administrator or RA can be
assigned the ability to revoke the certificate of a third party.
Acceptance of the revocation by the server depends on local policy in
these cases.
Clients MUST provide the capability to produce a digitally signed Revocation Request control. Clients SHOULD be capable of producing an unsigned Revocation Request control containing the EE shared- secret (the unsigned message consisting of a SignedData with no signatures). If a client provides shared-secret-based self- revocation, the client MUST be capable of producing a Revocation Request control 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 control. The shared-secret has a one-time use (i.e., it is used to request revocation of the certificate), 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 PKI Response MUST be returned for a revocation request.6.12. Registration and Response Information Controls
The Registration Information control allows for clients to pass additional information as part of a Full PKI Request. The Registration Information control is identified by the OID: id-cmc-regInfo ::= { id-cmc 18 } The Registration Information control has the ASN.1 definition: RegInfo ::= OCTET STRING The content of this data is based on bilateral agreement between the client and server. The Response Information control allows a server to return additional information as part of a Full PKI Response. The Response Information control is identified by the OID: id-cmc-responseInfo ::= { id-cmc 19 } The Response Information control has the ASN.1 definition: ResponseInfo ::= OCTET STRING
The content of this data is based on bilateral agreement between the client and server.6.13. Query Pending Control
In some environments, process requirements for manual intervention or other identity checks can delay the return of the certificate. The Query Pending control allows clients to query a server about the state of a pending certification request. The server returns a pendToken as part of the Extended CMC Status Info and the CMC Status Info controls (in the otherInfo field). The client copies the pendToken into the Query Pending control to identify the correct certification request to the server. The server returns a suggested time for the client to query for the state of a pending certification request. The Query Pending control is identified by the OID: id-cmc-queryPending ::= { id-cmc 21 } The Query Pending control has the ASN.1 definition: QueryPending ::= OCTET STRING If a server returns a pending or partial CMCStatusInfo (the transaction is still pending), the otherInfo MAY be omitted. If the otherInfo is not omitted, the value of 'pendInfo' MUST be the same as the original pendInfo value.6.14. Confirm Certificate Acceptance Control
Some CAs require that clients give a positive confirmation that the certificates issued to the EE are acceptable. The Confirm Certificate Acceptance control is used for that purpose. If the CMC Status Info on a PKI Response is confirmRequired, then the client MUST return a Confirm Certificate Acceptance control contained in a Full PKI Request. Clients SHOULD wait for the PKI Response from the server that the confirmation has been received before using the certificate for any purpose. The Confirm Certificate Acceptance control is identified by the OID: id-cmc-confirmCertAcceptance ::= { id-cmc 24 }
The Confirm Certificate Acceptance control has the ASN.1 definition:
CMCCertId ::= IssuerAndSerialNumber
CMCCertId contains the issuer and serial number of the certificate
being accepted.
Servers MUST return a Full PKI Response for a Confirm Certificate
Acceptance control.
Note that if the CA includes this control, there will be two full
round-trips of messages.
1. The client sends the certification request to the CA.
2. The CA returns a Full PKI Response with the certificate and this
control.
3. The client sends a Full PKI Request to the CA with an Extended
CMC Status Info control accepting and a Confirm Certificate
Acceptance control or an Extended CMC Status Info control
rejecting the certificate.
4. The CA sends a Full PKI Response to the client with an Extended
CMC Status Info of success.
6.15. Publish Trust Anchors Control
The Publish Trust Anchors control allows for the distribution of set
trust anchors from a central authority to an EE. The same control is
also used to update the set of trust anchors. Trust anchors are
distributed in the form of certificates. These are expected, but not
required, to be self-signed certificates. Information is extracted
from these certificates to set the inputs to the certificates
validation algorithm in Section 6.1.1 of [PKIXCERT].
The Publish Trust Anchors control is identified by the OID:
id-cmc-trustedAnchors ::= { id-cmc 26 }
The Publish Trust Anchors control has the ASN.1 definition:
PublishTrustAnchors ::= SEQUENCE {
seqNumber INTEGER,
hashAlgorithm AlgorithmIdentifier,
anchorHashes SEQUENCE OF OCTET STRING
}
The fields in PublishTrustAnchors have the following meaning:
seqNumber is an integer indicating the location within a sequence of
updates.
hashAlgorithm is the identifier and parameters for the hash
algorithm that is used in computing the values of the anchorHashes
field. All implementations MUST implement SHA-1 for this field.
anchorHashes are the hashes for the certificates that are to be
treated as trust anchors by the client. The actual certificates
are transported in the certificate bag of the containing
SignedData structure.
While it is recommended that the sender place the certificates that
are to be trusted in the PKI Response, it is not required as the
certificates should be obtainable using normal discovery techniques.
Prior to accepting the trust anchors changes, a client MUST at least
do the following: validate the signature on the PKI Response to a
current trusted anchor, check with policy to ensure that the signer
is permitted to use the control, validate that the authenticated
publish time in the signature is near to the current time, and
validate that the sequence number is greater than the previously used
one.
In the event that multiple agents publish a set of trust anchors, it
is up to local policy to determine how the different trust anchors
should be combined. Clients SHOULD be able to handle the update of
multiple trust anchors independently.
Note: Clients that handle this control must use extreme care in
validating that the operation is permissible. Incorrect handling of
this control allows for an attacker to change the set of trust
anchors on the client.
6.16. Authenticated Data Control
The Authenticated Data control allows a server to provide data back
to the client in an authenticated manner. This control uses the
Authenticated Data structure to allow for validation of the data.
This control is used where the client has a shared-secret and a
secret identifier with the server, but where a trust anchor has not
yet been downloaded onto the client so that a signing certificate for
the server cannot be validated. The specific case that this control
was created for use with is the Publish Trust Anchors control
(Section 6.15), but it may be used in other cases as well.
The Authenticated Data control is identified by the OID:
id-cmc-authData ::= { id-cmc 27 }
The Authenticated Data control has the ASN.1 definition:
AuthPublish ::= BodyPartID
AuthPublish is a body part identifier that refers to a member of the
cmsSequence element for the current PKI Response or PKI Data. The
cmsSequence element is AuthenticatedData. The encapsulated content
is an id-cct-PKIData. The controls in the controlSequence need to be
processed if the authentication succeeds. (One example is the
Publish Trust Anchors control in Section 6.15.)
If the authentication operation fails, the CMCFailInfo authDataFail
is returned.
6.17. Batch Request and Response Controls
These controls allow for an RA to collect multiple requests together
into a single Full PKI Request and forward it to a CA. The server
would then process the requests and return the results in a Full PKI
Response.
The Batch Request control is identified by the OID:
id-cmc-batchRequests ::= {id-cmc 28}
The Batch Response control is identified by the OID:
id-cmc-batchResponses ::= {id-cmc 29}
Both the Batch Request and Batch Response controls have the ASN.1
definition:
BodyPartList ::= SEQUENCE of BodyPartID
The data associated with these controls is a set of body part
identifiers. Each request/response is placed as an individual entry
in the cmcSequence of the new PKIData/PKIResponse. The body part
identifiers of these entries are then placed in the body part list
associated with the control.
When a server processes a Batch Request control, it MAY return the
responses in one or more PKI Responses. A CMCStatus value of partial
is returned on all but the last PKI Response. The CMCStatus would be
success if the Batch Requests control was processed; the responses
are created with their own CMCStatus code. Errors on individual requests are not propagated up to the top level. When a PKI Response with a CMCStatus value of partial is returned, the Query Pending control (Section 6.13) is used to retrieve additional results. The returned status includes a suggested time after which the client should ask for the additional results.6.18. Publication Information Control
The Publication Information control allows for modifying publication of already issued certificates, both for publishing and removal from publication. A common usage for this control is to remove an existing certificate from publication during a rekey operation. This control should always be processed after the issuance of new certificates and revocation requests. This control should not be processed if a certificate failed to be issued. The Publication Information control is identified by the OID: id-cmc-publishCert ::= { id-cmc 30 } The Publication Information control has the ASN.1 definition: CMCPublicationInfo ::= SEQUENCE { hashAlg AlgorithmIdentifier, certHashes SEQUENCE of OCTET STRING, pubInfo PKIPublicationInfo PKIPublicationInfo ::= SEQUENCE { action INTEGER { dontPublish (0), pleasePublish (1) }, pubInfos SEQUENCE SIZE (1..MAX) OF SinglePubInfo OPTIONAL } -- pubInfos MUST NOT be present if action is "dontPublish" -- (if action is "pleasePublish" and pubInfos is omitted, -- "dontCare" is assumed) SinglePubInfo ::= SEQUENCE { pubMethod INTEGER { dontCare (0), x500 (1), web (2), ldap (3) }, pubLocation GeneralName OPTIONAL } }
The fields in CMCPublicationInfo have the following meaning:
hashAlg is the algorithm identifier of the hash algorithm used to
compute the values in certHashes.
certHashes are the hashes of the certificates for which publication
is to change.
pubInfo is the information where and how the certificates should be
published. The fields in pubInfo (taken from [CRMF]) have the
following meanings:
action indicates the action the service should take. It has two
values:
dontPublish indicates that the PKI should not publish the
certificate (this may indicate that the requester intends to
publish the certificate him/herself). dontPublish has the
added connotation of removing from publication the
certificate if it is already published.
pleasePublish indicates that the PKI MAY publish the
certificate using whatever means it chooses unless pubInfos
is present. Omission of the CMC Publication Info control
results in the same behavior.
pubInfos pubInfos indicates how (e.g., X500, Web, IP Address) the
PKI SHOULD publish the certificate.
A single certificate SHOULD NOT appear in more than one Publication
Information control. The behavior is undefined in the event that it
does.
6.19. Control Processed Control
The Control Processed control allows an RA to indicate to subsequent
control processors that a specific control has already been
processed. This permits an RA in the middle of a processing stream
to process a control defined either in a local context or in a
subsequent document.
The Control Processed control is identified by the OID:
id-cmc-controlProcessed ::= { id-cmc 32 }
The Control Processed control has the ASN.1 definition:
ControlList ::= SEQUENCE {
bodyList SEQUENCE SIZE (1..MAX) OF BodyPartReference
}
bodyList is a series of body part identifiers that form a path to
each of the controls that were processed by the RA. This control
is only needed for those controls that are not part of this
standard and thus would cause an error condition of a server
attempting to deal with a control not defined in this document.
No error status is needed since an error causes the RA to return
the request to the client with the error rather than passing the
request on to the next server in the processing list.
7. Registration Authorities
This specification permits the use of RAs. An RA sits between the EE
and the CA. From the EE's perspective, the RA appears to be the CA,
and from the server, the RA appears to be a client. RAs receive the
PKI Requests, perform local processing and then forward them onto
CAs. Some of the types of local processing that an RA can perform
include:
o Batching multiple PKI Requests together,
o Performing challenge/response POP proofs,
o Adding private or standardized certificate extensions to all
certification requests,
o Archiving private key material,
o Routing requests to different CAs.
When an RA receives a PKI Request, it has three options: it may
forward the PKI Request without modification, it may add a new
wrapping layer to the PKI Request, or it may remove one or more
existing layers and add a new wrapping layer.
When an RA adds a new wrapping layer to a PKI Request, it creates a
new PKIData. The new layer contains any controls required (for
example, if the RA does the POP proof for an encryption key or the
Add Extension control to modify a PKI Request) and the client PKI
Request. The client PKI Request is placed in the cmsSequence if it
is a Full PKI Request and in the reqSequence if it is a Simple PKI
Request. If an RA is batching multiple client PKI Requests together,
then each client PKI Request is placed into the appropriate location in the RA's PKIData object along with all relevant controls. If multiple RAs are in the path between the EE and the CA, this will lead to multiple wrapping layers on the request. In processing a PKI Request, an RA MUST NOT alter any certification requests (PKCS #10 or CRMF) as any alteration would invalidate the signature on the certification request and thus the POP for the private key. An example of how this would look is illustrated by the following figure: SignedData (by RA) PKIData controlSequence RA added control statements reqSequence Zero or more Simple PKI Requests from clients cmsSequence Zero or more Full PKI Requests from clients SignedData (signed by client) PKIData Under some circumstances, an RA is required to remove wrapping layers. The following sections look at the processing required if encryption layers and signing layers need to be removed.7.1. Encryption Removal
There are two cases that require an RA to remove or change encryption in a PKI Request. In the first case, the encryption was applied for the purposes of protecting the entire PKI Request from unauthorized entities. If the CA does not have a Recipient Info entry in the encryption layer, the RA MUST remove the encryption layer. The RA 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 RA 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 RA. If the signing layer provided by the EE needs to also be removed, the RA can also remove this layer.
7.2. Signature Layer Removal
Only two instances exist where an RA should remove a signature layer on a Full PKI Request: if an encryption layer needs to be modified within the request, or if a CA will not accept secondary delegation (i.e., multiple RA signatures). In all other situations, RAs SHOULD NOT remove a signing layer from a PKI Request. If an RA removes a signing layer from a PKI Request, 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 RA.8. Security Considerations
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 controls described in Section 6.6. Developers of state-constrained PKI clients are strongly encouraged to incorporate the use of these controls. Extreme care needs to be taken when archiving a signing key. The holder of the archived key may have the ability to use the key to generate forged signatures. There are however reasons why a signing key should be archived. An archived CA signing key can be recovered in the event of failure to continue to produced CRLs following a disaster. 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]. Methods of avoiding the small subgroup attack can be found in [SMALL-GROUP]. CMC implementations ought to be aware of this attack when doing parameter validations.
When using a shared-secret for authentication purposes, the shared- secret should be generated using good random number techniques [RANDOM]. User selection of the secret allows for dictionary attacks to be mounted. Extreme care must be used when processing the Publish Trust Anchors control. Incorrect processing can lead to the practice of slamming where an attacker changes the set of trusted anchors in order to weaken security. One method of controlling the use of the Publish Trust Anchors control is as follows. The client needs to associate with each trust anchor accepted by the client the source of the trust anchor. Additionally, the client should associate with each trust anchor the types of messages for which the trust anchor is valid (i.e., is the trust anchor used for validating S/MIME messages, TLS, or CMC enrollment messages?). When a new message is received with a Publish Trust Anchors control, the client would accept the set of new trust anchors for specific applications only if the signature validates, the signer of the message has the required policy approval for updating the trust anchors, and local policy also would allow updating the trust anchors. The CMS AuthenticatedData structure provides message integrity, it does not provide message authentication in all cases. When using MACs in this document the following restrictions need to be observed. All messages should be for a single entity. If two entities are placed in a single message, the entities can generate new messages that have a valid MAC and might be assumed to be from the original message sender. All entities that have access to the shared-secret can generate messages that will have a successful MAC validation. This means that care must be taken to keep this value secret. Whenever possible, the SignedData structure should be used in preference to the AuthenticatedData structure.9. IANA Considerations
This document defines a number of control objects. These are identified by Object Identifiers (OIDs). The objects are defined from an arc delegated by IANA to the PKIX Working Group. No further action by IANA is necessary for this document or any anticipated updates.
10. Acknowledgments
The authors and the PKIX Working Group are grateful for the participation of Xiaoyi Liu and Jeff Weinstein in helping to author the original versions of this document. 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
11.1. Normative References
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004. [CRMF] Schaad, J., "Internet X.509 Certification Request Message Format", RFC 4211, January 2005. [DH-POP] Prafullchandra, H. and J. Schaad, "Diffie-Hellman Proof-of-Possession Algorithms", RFC 2875, June 2000. [PKCS10] Kaliski, B., "PKCS #10: Certification Request Syntax v1.5", RFC 2314, October 1997. Note that this version of PKCS #10 is used for compatibility with the use of 1988 ASN.1 syntax. An effort is currently underway in the PKIX working group to update to use 2003 ASN.1 syntax. [PKIXCERT] Housley, R., Ford, W., Polk, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.11.2. Informative References
[CMC-TRANS] Schaad, J. and M. Myers, "Certificate Management over CMS (CMC): Transport Protocols", RFC 5273, June 2008. [CMC-COMPL] Schaad, J. and M. Myers, "Certificate Management Messages over CMS (CMC): Compliance Requirements", RFC 5274, June 2008.
[PASSWORD] Burr, W., Dodson, D., and W. Polk, "Electronic Authentication Guideline", NIST SP 800-63, April 2006. [RANDOM] Eastlake, 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [SMALL-GROUP] Zuccherato, R., "Methods for Avoiding the "Small- Subgroup" Attacks on the Diffie-Hellman Key Agreement Method for S/MIME", RFC 2785, March 2000. [X942] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999. [RFC2797] Myers, M., Liu, X., Schaad, J., and J. Weinstein, "Certificate Management Messages over CMS", RFC 2797, April 2000.
(next page on part 4)
