Tech-invite   3GPPspecs   Glossaries   IETFRFCs   Groups   SIP   ABNFs   Ti+   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: PKIX

RFC 5272

Certificate Management over CMS (CMC)

Pages: 83
Proposed STD
Obsoletes:  2797
Updated by:  6402
Part 3 of 4 – Pages 49 to 64
First   Prev   Next

Top   ToC   Page 49   prevText
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 }
Top   ToC   Page 50
   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

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 }
Top   ToC   Page 51
   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.
Top   ToC   Page 52
   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
Top   ToC   Page 53
   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

   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

   The Confirm Certificate Acceptance control is identified by the OID:

      id-cmc-confirmCertAcceptance     ::= { id-cmc 24 }
Top   ToC   Page 54
   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

   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
Top   ToC   Page 55
   The fields in PublishTrustAnchors have the following meaning:

   seqNumber  is an integer indicating the location within a sequence of

   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

   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.
Top   ToC   Page 56
   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

   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

      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
Top   ToC   Page 57
   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 }
Top   ToC   Page 58
   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

         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

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 }
Top   ToC   Page 59
   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

   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,
Top   ToC   Page 60
   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

      SignedData (by RA)
               RA added control statements
               Zero or more Simple PKI Requests from clients
               Zero or more Full PKI Requests from clients
                  SignedData (signed by client)

   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

   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.
Top   ToC   Page 61
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

   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

   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.
Top   ToC   Page 62
   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

   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
Top   ToC   Page 63
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.
Top   ToC   Page 64
   [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.