Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5272

Certificate Management over CMS (CMC)

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

Top   ToC   RFC5272 - 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   RFC5272 - 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
   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 }
Top   ToC   RFC5272 - 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   RFC5272 - 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   RFC5272 - 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 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 }
Top   ToC   RFC5272 - 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
       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 }
Top   ToC   RFC5272 - Page 55
   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.
Top   ToC   RFC5272 - 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 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
Top   ToC   RFC5272 - 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   RFC5272 - 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
         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 }
Top   ToC   RFC5272 - 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 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,
Top   ToC   RFC5272 - 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
   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.
Top   ToC   RFC5272 - 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 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.
Top   ToC   RFC5272 - 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
   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.
Top   ToC   RFC5272 - 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   RFC5272 - 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.


(next page on part 4)

Next Section