tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5272

 
 
 

Certificate Management over CMS (CMC)

Part 2 of 4, p. 23 to 49
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 23 
4.  PKI Responses

   Two types of PKI Responses exist.  This section gives the details on
   both types.

4.1.  Simple PKI Response

   Clients MUST be able to process the Simple PKI Response.  The Simple
   PKI Response consists of a SignedData with no EncapsulatedContentInfo
   and no SignerInfo.  The certificates requested in the PKI Response
   are returned in the certificate field of the SignedData.

   Clients MUST NOT assume the certificates are in any order.  Servers
   SHOULD include all intermediate certificates needed to form complete
   certification paths to one or more trust anchors, not just the newly
   issued certificate(s).  The server MAY additionally return CRLs in
   the CRL bag.  Servers MAY include the self-signed certificates.
   Clients MUST NOT implicitly trust included self-signed certificate(s)
   merely due to its presence in the certificate bag.  In the event
   clients receive a new self-signed certificate from the server,
   clients SHOULD provide a mechanism to enable the user to use the
   certificate as a trust anchor.  (The Publish Trust Anchors control
   (Section 6.15) should be used in the event that the server intends
   the client to accept one or more certificates as trust anchors.  This
   requires the use of the Full PKI Response message.)

Top      Up      ToC       Page 24 
4.2.  Full PKI Response

   Clients MUST be able to process a Full PKI Response.

   The Full PKI Response consists of a SignedData or AuthenticatedData
   encapsulating a PKIResponse content type.  The certificates issued in
   a PKI Response are returned in the certificates field of the
   immediately encapsulating SignedData.

   Clients MUST NOT assume the certificates are in any order.  Servers
   SHOULD include all intermediate certificates needed to form complete
   chains to one or more trust anchors, not just the newly issued
   certificate(s).  The server MAY additionally return CRLs in the CRL
   bag.  Servers MAY include self-signed certificates.  Clients MUST NOT
   implicitly trust included self-signed certificate(s) merely due to
   its presence in the certificate bag.  In the event clients receive a
   new self-signed certificate from the server, clients MAY provide a
   mechanism to enable the user to explicitly use the certificate as a
   trust anchor.  (The Publish Trust Anchors control (Section 6.15)
   exists for the purpose of allowing for distribution of trust anchor
   certificates.  If a trusted anchor publishes a new trusted anchor,
   this is one case where automated trust of the new trust anchor could
   be allowed.)

4.2.1.  PKIResponse Content Type

   The PKIResponse content type is used for the Full PKI Response.  The
   PKIResponse content type is identified by:

     id-cct-PKIResponse ::= {id-pkix id-cct(12) 3  }

   The ASN.1 structure corresponding to the PKIResponse content type is:

      PKIResponse ::= SEQUENCE {
          controlSequence   SEQUENCE SIZE(0..MAX) OF TaggedAttribute,
          cmsSequence       SEQUENCE SIZE(0..MAX) OF TaggedContentInfo,
          otherMsgSequence  SEQUENCE SIZE(0..MAX) OF OtherMsg
      }

      ReponseBody ::= PKIResponse

   Note: In [RFC2797], this ASN.1 type was named ResponseBody.  It has
   been renamed to PKIResponse for clarity and the old name kept as a
   synonym.

Top      Up      ToC       Page 25 
   The fields in PKIResponse have the following meaning:

   controlSequence  is a sequence of controls.  The controls defined in
      this document are found in Section 6.  Controls can be defined by
      other parties.  Details on the TaggedAttribute structure are found
      in Section 3.2.1.1.

   cmsSequence  is a sequence of [CMS] message objects.  See
      Section 3.2.1.3 for more details.

   otherMsgSequence  is a sequence of arbitrary data objects.  Data
      objects placed here are referred to by one or more controls.  This
      allows for controls to use large amounts of data without the data
      being embedded in the control.  See Section 3.2.1.4 for more
      details.

   Processing of PKIResponse by a recipient is as follows:

   1.  All controls should be examined and processed in an appropriate
       manner.  The appropriate processing is to complete processing at
       this time, to ignore the control, or to place the control on a
       to-do list for later processing.

   2.  Additional processing of non-element items includes the saving of
       certificates and CRLs present in wrapping layers.  This type of
       processing is based on the consumer of the element and should not
       be relied on by generators.

   No processing is required for cmsSequence or otherMsgSequence members
   of the PKIResponse, if items are present and are not referenced by a
   control.  In this case, the cmsSequence and otherMsgSequence members
   are to be ignored.

5.  Application of Encryption to a PKI Request/Response

   There are occasions when a PKI Request or Response must be encrypted
   in order to prevent disclosure of information in the PKI Request/
   Response from being accessible to unauthorized entities.  This
   section describes the means to encrypt Full PKI Requests and
   Responses (Simple PKI Requests cannot be encrypted).  Data portions
   of PKI Requests and Responses that are placed in the cmsSequence
   field can be encrypted separately.

   Confidentiality is provided by wrapping the PKI Request/Response (a
   SignedData) in an EnvelopedData.  The nested content type in the
   EnvelopedData is id-SignedData.  Note that this is different from
   S/MIME where there is a MIME layer placed between the encrypted and
   signed data.  It is recommended that if an EnvelopedData layer is

Top      Up      ToC       Page 26 
   applied to a PKI Request/Response, a second signature layer be placed
   outside of the EnvelopedData layer.  The following figure shows how
   this nesting would be done:

     Normal              Option 1                  Option 2
     ------              --------                  --------
     SignedData          EnvelopedData             SignedData
      PKIData             SignedData                EnvelopedData
                           PKIData                   SignedData
                                                      PKIData

   Note: PKIResponse can be substituted for PKIData in the above figure.

   Options 1 and 2 prevent leakage of sensitive data by encrypting the
   Full PKI Request/Response.  An RA that receives a PKI Request that it
   cannot decrypt MAY reject the PKI Request unless it can process the
   PKI Request without knowledge of the contents (i.e., all it does is
   amalgamate multiple PKI Requests and forward them to a server).

   After the RA removes the envelope and completes processing, it may
   then apply a new EnvelopedData layer to protect PKI Requests for
   transmission to the next processing agent.  Section 7 contains more
   information about RA processing.

   Full PKI Requests/Responses can be encrypted or transmitted in the
   clear.  Servers MUST provide support for all three options.

   Alternatively, an authenticated, secure channel could exist between
   the parties that require confidentiality.  Clients and servers MAY
   use such channels instead of the technique described above to provide
   secure, private communication of Simple and Full PKI Requests/
   Responses.

6.  Controls

   Controls are carried as part of both Full PKI Requests and Responses.
   Each control is encoded as a unique OID followed by the data for the
   control (see syntax in Section 3.2.1.1.  The encoding of the data is
   based on the control.  Processing systems would first detect the OID
   (TaggedAttribute attrType) and process the corresponding control
   value (TaggedAttribute attrValues) prior to processing the message
   body.

Top      Up      ToC       Page 27 
   The OIDs are all defined under the following arc:

      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 }

   The following table lists the names, OID, and syntactic structure for
   each of the controls described in this document.

    Identifier  Description       OID       ASN.1 Structure      Section
    --------------------------------------------------------------------
    id-cmc-statusInfo            id-cmc 1   CMCStatusInfo        6.1.2
    id-cmc-identification        id-cmc 2   UTF8String           6.2.3
    id-cmc-identityProof         id-cmc 3   OCTET STRING         6.2.2
    id-cmc-dataReturn            id-cmc 4   OCTET STRING         6.4
    id-cmc-transactionId         id-cmc 5   INTEGER              6.6
    id-cmc-senderNonce           id-cmc 6   OCTET STRING         6.6
    id-cmc-recipientNonce        id-cmc 7   OCTET STRING         6.6
    id-cmc-addExtensions         id-cmc 8   AddExtensions        6.5.2
    id-cmc-encryptedPOP          id-cmc 9   EncryptedPOP         6.7
    id-cmc-decryptedPOP          id-cmc 10  DecryptedPOP         6.7
    id-cmc-lraPOPWitness         id-cmc 11  LraPOPWitness        6.8
    id-cmc-getCert               id-cmc 15  GetCert              6.9
    id-cmc-getCRL                id-cmc 16  GetCRL               6.10
    id-cmc-revokeRequest         id-cmc 17  RevokeRequest        6.11
    id-cmc-regInfo               id-cmc 18  OCTET STRING         6.12
    id-cmc-responseInfo          id-cmc 19  OCTET STRING         6.12
    id-cmc-queryPending          id-cmc 21  OCTET STRING         6.13
    id-cmc-popLinkRandom         id-cmc 22  OCTET STRING         6.3.1
    id-cmc-popLinkWitness        id-cmc 23  OCTET STRING         6.3.1
    id-cmc-popLinkWitnessV2      id-cmc 33  OCTET STRING         6.3.1.1
    id-cmc-confirmCertAcceptance id-cmc 24  CMCCertId            6.14
    id-cmc-statusInfoV2          id-cmc 25  CMCStatusInfoV2      6.1.1
    id-cmc-trustedAnchors        id-cmc 26  PublishTrustAnchors  6.15
    id-cmc-authData              id-cmc 27  AuthPublish          6.16
    id-cmc-batchRequests         id-cmc 28  BodyPartList         6.17
    id-cmc-batchResponses        id-cmc 29  BodyPartList         6.17
    id-cmc-publishCert           id-cmc 30  CMCPublicationInfo   6.18
    id-cmc-modCertTemplate       id-cmc 31  ModCertTemplate      6.5.1
    id-cmc-controlProcessed      id-cmc 32  ControlsProcessed    6.19
    id-cmc-identityProofV2       id-cmc 34  IdentityProofV2      6.2.1

                 Table 1: CMC Control Attributes

Top      Up      ToC       Page 28 
6.1.  CMC Status Info Controls

   The CMC Status Info controls return information about the status of a
   client/server request/response.  Two controls are described in this
   section.  The Extended CMC Status Info control is the preferred
   control; the CMC Status Info control is included for backwards
   compatibility with RFC 2797.

   Servers MAY emit multiple CMC status info controls referring to a
   single body part.  Clients MUST be able to deal with multiple CMC
   status info controls in a PKI Response.  Servers MUST use the
   Extended CMC Status Info control, but MAY additionally use the CMC
   Status Info control.  Clients MUST be able to process the Extended

   CMC Status Info control.

6.1.1.  Extended CMC Status Info Control

   The Extended CMC Status Info control is identified by the OID:

      id-cmc-statusInfoV2 ::= { id-cmc 25 }

   The Extended CMC Status Info control has the ASN.1 definition:

   CMCStatusInfoV2 ::= SEQUENCE {
      cMCStatus             CMCStatus,
      bodyList              SEQUENCE SIZE (1..MAX) OF BodyPartReference,
      statusString          UTF8String OPTIONAL,
      otherInfo             OtherStatusInfo OPTIONAL
   }

   OtherStatusInfo ::= CHOICE {
      failInfo              CMCFailInfo,
      pendInfo              PendInfo,
      extendedFailInfo      ExtendedFailInfo
   }

   PendInfo ::= SEQUENCE {
      pendToken           OCTET STRING,
      pendTime            GeneralizedTime
   }

   ExtendedFailInfo ::= SEQUENCE {
      failInfoOID            OBJECT IDENTIFIER,
      failInfoValue          ANY DEFINED BY failInfoOID
   }

Top      Up      ToC       Page 29 
   BodyPartReference ::= CHOICE {
      bodyPartID           BodyPartID,
      bodyPartPath         BodyPartPath
   }

   The fields in CMCStatusInfoV2 have the following meaning:

   cMCStatus  contains the returned status value.  Details are in
      Section 6.1.3.

   bodyList  identifies the controls or other elements to which the
      status value applies.  If an error is returned for a Simple PKI
      Request, this field is the bodyPartID choice of BodyPartReference
      with the single integer of value 1.

   statusString  contains additional description information.  This
      string is human readable.

   otherInfo  contains additional information that expands on the CMC
      status code returned in the cMCStatus field.

   The fields in OtherStatusInfo have the following meaning:

   failInfo  is described in Section 6.1.4.  It provides an error code
      that details what failure occurred.  This choice is present only
      if cMCStatus contains the value failed.

   pendInfo  contains information about when and how the client should
      request the result of this request.  It is present when the
      cMCStatus is either pending or partial. pendInfo uses the
      structure PendInfo, which has the fields:

      pendToken  is the token used in the Query Pending control
         (Section 6.13).

      pendTime  contains the suggested time the server wants to be
         queried about the status of the certification request.

   extendedFailInfo  includes application-dependent detailed error
      information.  This choice is present only if cMCStatus contains
      the value failed.  Caution should be used when defining new values
      as they may not be correctly recognized by all clients and
      servers.  The CMCFailInfo value of internalCAError may be assumed
      if the extended error is not recognized.  This field uses the type
      ExtendedFailInfo.  ExtendedFailInfo has the fields:

      failInfoOID  contains an OID that is associated with a set of
         extended error values.

Top      Up      ToC       Page 30 
      failInfoValue  contains an extended error code from the defined
         set of extended error codes.

   If the cMCStatus field is success, the Extended CMC Status Info
   control MAY be omitted unless it is the only item in the response.

6.1.2.  CMC Status Info Control

   The CMC Status Info control is identified by the OID:

      id-cmc-statusInfo ::= { id-cmc 1 }

   The CMC Status Info control has the ASN.1 definition:

         CMCStatusInfo ::= SEQUENCE {
              cMCStatus           CMCStatus,
              bodyList            BodyPartList,
              statusString        UTF8String OPTIONAL,
              otherInfo           CHOICE {
                failInfo            CMCFailInfo,
                pendInfo            PendInfo } OPTIONAL
         }

   The fields in CMCStatusInfo have the following meaning:

   cMCStatus  contains the returned status value.  Details are in
      Section 6.1.3.

   bodyList  contains the list of controls or other elements to which
      the status value applies.  If an error is being returned for a
      Simple PKI Request, this field contains a single integer of value
      1.

   statusString  contains additional description information.  This
      string is human readable.

   otherInfo  provides additional information that expands on the CMC
      status code returned in the cMCStatus field.

      failInfo  is described in Section 6.1.4.  It provides an error
         code that details what failure occurred.  This choice is
         present only if cMCStatus is failed.

      pendInfo  uses the PendInfo ASN.1 structure in Section 6.1.1.  It
         contains information about when and how the client should
         request results of this request.  The pendInfo field MUST be
         populated for a cMCStatus value of pending or partial.  Further

Top      Up      ToC       Page 31 
         details can be found in Section 6.1.1 (Extended CMC Status Info
         Control) and Section 6.13 (Query Pending Control ).

   If the cMCStatus field is success, the CMC Status Info control MAY be
   omitted unless it is the only item in the response.  If no status
   exists for a Simple or Full PKI Request, then the value of success is
   assumed.

6.1.3.  CMCStatus Values

   CMCStatus is a field in the Extended CMC Status Info and CMC Status
   Info controls.  This field contains a code representing the success
   or failure of a specific operation.  CMCStatus has the ASN.1
   structure:

      CMCStatus ::= INTEGER {
           success                (0),
           -- reserved            (1),
           failed                 (2),
           pending                (3),
           noSupport              (4),
           confirmRequired        (5),
           popRequired            (6),
           partial                (7)
      }

   The values of CMCStatus have the following meaning:

   success  indicates the request was granted or the action was
      completed.

   failed  indicates the request was not granted or the action was not
      completed.  More information is included elsewhere in the
      response.

   pending  indicates the PKI Request has yet to be processed.  The
      requester is responsible to poll back on this Full PKI request.
      pending may only be returned for certification request operations.

   noSupport  indicates the requested operation is not supported.

   confirmRequired  indicates a Confirm Certificate Acceptance control
      (Section 6.14) must be returned before the certificate can be
      used.

   popRequired  indicates a direct POP operation is required
      (Section 6.3.1.3).

Top      Up      ToC       Page 32 
   partial  indicates a partial PKI Response is returned.  The requester
      is responsible to poll back for the unfulfilled portions of the
      Full PKI Request.

6.1.4.   CMCFailInfo

   CMCFailInfo is a field in the Extended CMC Status Info and CMC Status
   Info controls.  CMCFailInfo conveys more detailed information
   relevant to the interpretation of a failure condition.  The
   CMCFailInfo has the following ASN.1 structure:

      CMCFailInfo ::= INTEGER {
           badAlg            (0),
           badMessageCheck   (1),
           badRequest        (2),
           badTime           (3),
           badCertId         (4),
           unsupportedExt     (5),
           mustArchiveKeys   (6),
           badIdentity       (7),
           popRequired       (8),
           popFailed         (9),
           noKeyReuse        (10),
           internalCAError   (11),
           tryLater          (12),
           authDataFail      (13)
      }

   The values of CMCFailInfo have the following meanings:

   badAlg  indicates unrecognized or unsupported algorithm.

   badMessageCheck  indicates integrity check failed.

   badRequest  indicates transaction was not permitted or supported.

   badTime  indicates message time field was not sufficiently close to
      the system time.

   badCertId  indicates no certificate could be identified matching the
      provided criteria.

   unsupportedExt  indicates a requested X.509 extension is not
      supported by the recipient CA.

   mustArchiveKeys  indicates private key material must be supplied.

   badIdentity  indicates identification control failed to verify.

Top      Up      ToC       Page 33 
   popRequired  indicates server requires a POP proof before issuing
      certificate.

   popFailed  indicates POP processing failed.

   noKeyReuse  indicates server policy does not allow key reuse.

   internalCAError  indicates that the CA had an unknown internal
      failure.

   tryLater  indicates that the server is not accepting requests at this
      time and the client should try at a later time.

   authDataFail  indicates failure occurred during processing of
      authenticated data.

   If additional failure reasons are needed, they SHOULD use the
   ExtendedFailureInfo item in the Extended CMC Status Info control.
   However, for closed environments they can be defined using this type.
   Such codes MUST be in the range from 1000 to 1999.

6.2.  Identification and Identity Proof Controls

   Some CAs and RAs require that a proof-of-identity be included in a
   certification request.  Many different ways of doing this exist with
   different degrees of security and reliability.  Most are familiar
   with a bank's request to provide your mother's maiden name as a form
   of identity proof.  The reasoning behind requiring a proof-of-
   identity can be found in Appendix C of [CRMF].

   CMC provides a method to prove the client's identity based on a
   client/server shared-secret.  If clients support the Full PKI
   Request, clients MUST implement this method of identity proof
   (Section 6.2.2).  Servers MUST provide this method, but MAY
   additionally support bilateral methods of similar strength.

   This document also provides an Identification control
   (Section 6.2.3).  This control is a simple method to allow a client
   to state who they are to the server.  Generally, a shared-secret AND
   an identifier of that shared-secret are passed from the server to the
   client.  The identifier is placed in the Identification control, and
   the shared-secret is used to compute the Identity Proof control.

6.2.1.  Identity Proof Version 2 Control

   The Identity Proof Version 2 control is identified by the OID:

      id-cmc-identityProofV2 ::= { id-cmc 34 }

Top      Up      ToC       Page 34 
   The Identity Proof Version 2 control has the ASN.1 definition:

      IdentifyProofV2 ::= SEQUENCE {
          hashAlgID        AlgorithmIdentifier,
          macAlgID         AlgorithmIdentifier,
          witness          OCTET STRING

      }

   The fields of IdentityProofV2 have the following meaning:

   hashAlgID  is the identifier and parameters for the hash algorithm
      used to convert the shared-secret into a key for the MAC
      algorithm.

   macAlgID  is the identifier and the parameters for the message
      authentication code algorithm used to compute the value of the
      witness field.

   witness  is the identity proof.

   The required method starts with an out-of-band transfer of a token
   (the shared-secret).  The shared-secret should be generated in a
   random manner.  The distribution of this token is beyond the scope of
   this document.  The client then uses this token for an identity proof
   as follows:

   1.  The PKIData reqSequence field (encoded exactly as it appears in
       the Full PKI Request including the sequence type and length) is
       the value to be validated.

   2.  A hash of the shared-secret as a UTF8 string is computed using
       hashAlgID.

   3.  A MAC is then computed using the value produced in Step 1 as the
       message and the value from Step 2 as the key.

   4.  The result from Step 3 is then encoded as the witness value in
       the Identity Proof Version 2 control.

   When the server verifies the Identity Proof Version 2 control, it
   computes the MAC value in the same way and compares it to the witness
   value contained in the PKI Request.

   If a server fails the verification of an Identity Proof Version 2
   control, the CMCFailInfo value MUST be present in the Full PKI
   Response and MUST have a value of badIdentity.

Top      Up      ToC       Page 35 
   Reuse of the shared-secret on certification request retries allows
   the client and server to maintain the same view of acceptable
   identity proof values.  However, reuse of the shared-secret can
   potentially open the door for some types of attacks.

   Implementations MUST be able to support tokens at least 16 characters
   long.  Guidance on the amount of entropy actually obtained from a
   given length token based on character sets can be found in Appendix A
   of [PASSWORD].

6.2.2.  Identity Proof Control

   The Identity Proof control is identified by the OID:

      id-cmc-identityProof ::= { id-cmc 3 }

   The Identity Proof control has the ASN.1 definition:

      IdentifyProof ::= OCTET STRING

   This control is processed in the same way as the Identity Proof
   Version 2 control.  In this case, the hash algorithm is fixed to
   SHA-1 and the MAC algorithm is fixed to HMAC-SHA1.

6.2.3.  Identification Control

   Optionally, servers MAY require the inclusion of the unprotected
   Identification control with an Identification Proof control.  The
   Identification control is intended to contain a text string that
   assists the server in locating the shared-secret needed to validate
   the contents of the Identity Proof control.  If the Identification
   control is included in the Full PKI Request, the derivation of the
   key in Step 2 (from Section 6.2.1) is altered so that the hash of the
   concatenation of the shared-secret and the UTF8 identity value
   (without the type and length bytes) are hashed rather than just the
   shared-secret.

   The Identification control is identified by the OID:

      id-cmc-identification ::= { id-cmc 2 }

   The Identification control has the ASN.1 definition:

      Identification ::= UTF8String

Top      Up      ToC       Page 36 
6.2.4.  Hardware Shared-Secret Token Generation

   The shared-secret between the EE and the server is sometimes computed
   using a hardware device that generates a series of tokens.  The EE
   can therefore prove its identity by transferring this token in plain
   text along with a name string.  The above protocol can be used with a
   hardware shared-secret token generation device by the following
   modifications:

   1.  The Identification control MUST be included and MUST contain the
       hardware-generated token.

   2.  The shared-secret value used above is the same hardware-generated
       token.

   3.  All certification requests MUST have a subject name, and the
       subject name MUST contain the fields required to identify the
       holder of the hardware token device.

   4.  The entire certification request MUST be shrouded in some fashion
       to prevent eavesdropping.  Although the token is time critical,
       an active eavesdropper cannot be permitted to extract the token
       and submit a different certification request with the same token
       value.

6.3.  Linking Identity and POP Information

   In a Full PKI Request, identity information about the client is
   carried in the signature of the SignedData containing all of the
   certification requests.  Proof-of-possession information for key
   pairs, however, is carried separately for each PKCS #10 or CRMF
   certification request.  (For keys capable of generating a digital
   signature, the POP is provided by the signature on the PKCS #10 or
   CRMF request.  For encryption-only keys, the controls described in
   Section 6.7 are used.)  In order to prevent substitution-style
   attacks, the protocol must guarantee that the same entity generated
   both the POP and proof-of-identity information.

   This section describes two mechanisms for linking identity and POP
   information: witness values cryptographically derived from the
   shared-secret (Section 6.3.1.3) and shared-secret/subject
   distinguished name (DN) matching (Section 6.3.2).  Clients and
   servers MUST support the witness value technique.  Clients and
   servers MAY support shared-secret/subject DN matching or other
   bilateral techniques of similar strength.  The idea behind both
   mechanisms is to force the client to sign some data into each
   certification request that can be directly associated with the

Top      Up      ToC       Page 37 
   shared-secret; this will defeat attempts to include certification
   requests from different entities in a single Full PKI Request.

6.3.1.  Cryptographic Linkage

   The first technique that links identity and POP information forces
   the client to include a piece of information cryptographically
   derived from the shared-secret as a signed extension within each
   certification request (PKCS #10 or CRMF).

6.3.1.1.  POP Link Witness Version 2 Controls

   The POP Link Witness Version 2 control is identified by the OID:

      id-cmc-popLinkWitnessV2 ::= { id-cmc 33 }

   The POP Link Witness Version 2 control has the ASN.1 definition:

      PopLinkWitnessV2 ::= SEQUENCE {
          keyGenAlgorithm   AlgorithmIdentifier,
          macAlgorithm      AlgorithmIdentifier,
          witness           OCTET STRING
      }

   The fields of PopLinkWitnessV2 have the following meanings:

   keyGenAlgorithm  contains the algorithm used to generate the key for
      the MAC algorithm.  This will generally be a hash algorithm, but
      could be a more complex algorithm.

   macAlgorithm  contains the algorithm used to create the witness
      value.

   witness  contains the computed witness value.

   This technique is useful if null subject DNs are used (because, for
   example, the server can generate the subject DN for the certificate
   based only on the shared-secret).  Processing begins when the client
   receives the shared-secret out-of-band from the server.  The client
   then computes the following values:

   1.  The client generates a random byte-string, R, which SHOULD be at
       least 512 bits in length.

   2.  The key is computed from the shared-secret using the algorithm in
       keyGenAlgorithm.

Top      Up      ToC       Page 38 
   3.  A MAC is then computed over the random value produced in Step 1,
       using the key computed in Step 2.

   4.  The random value produced in Step 1 is encoded as the value of a
       POP Link Random control.  This control MUST be included in the
       Full PKI Request.

   5.  The MAC value produced in Step 3 is placed in either the POP Link
       Witness control or the witness field of the POP Link Witness V2
       control.

       *  For CRMF, the POP Link Witness/POP Link Witness V2 control is
          included in the controls field of the CertRequest structure.

       *  For PKCS #10, the POP Link Witness/POP Link Witness V2 control
          is included in the attributes field of the
          CertificationRequestInfo structure.

   Upon receipt, servers MUST verify that each certification request
   contains a copy of the POP Link Witness/POP Link Witness V2 control
   and that its value was derived using the above method from the
   shared-secret and the random string included in the POP Link Random
   control.

   The Identification control (see Section 6.2.3) or the subject DN of a
   certification request can be used to help identify which shared-
   secret was used.

6.3.1.2.  POP Link Witness Control

   The POP Link Witness control is identified by the OID:

      id-cmc-popLinkWitness ::= { id-cmc 23 }

   The POP Link Witness control has the ASN.1 definition:

      PopLinkWitness ::= OCTET STRING

   For this control, SHA-1 is used as the key generation algorithm.
   HMAC-SHA1 is used as the mac algorithm.

6.3.1.3.  POP Link Random Control

   The POP Link Random control is identified by the OID:

      id-cmc-popLinkRandom  ::= { id-cmc 22 }

Top      Up      ToC       Page 39 
   The POP Link Random control has the ASN.1 definition:

      PopLinkRandom ::= OCTET STRING

6.3.2.  Shared-Secret/Subject DN Linking

   The second technique to link identity and POP information is to link
   a particular subject distinguished name (subject DN) to the shared-
   secrets that are distributed out-of-band and to require that clients
   using the shared-secret to prove identity include that exact subject
   DN in every certification request.  It is expected that many client-
   server connections that use shared-secret-based proof-of-identity
   will use this mechanism.  (It is common not to omit the subject DN
   information from the certification request.)

   When the shared-secret is generated and transferred out-of-band to
   initiate the registration process (Section 6.2), a particular subject
   DN is also associated with the shared-secret and communicated to the
   client.  (The subject DN generated MUST be unique per entity in
   accordance with the CA policy; a null subject DN cannot be used.  A
   common practice could be to place the identification value as part of
   the subject DN.)  When the client generates the Full PKI Request, it
   MUST use these two pieces of information as follows:

   1.  The client MUST include the specific subject DN that it received
       along with the shared-secret as the subject name in every
       certification request (PKCS #10 and/or CRMF) in the Full PKI
       Request.  The subject names in the certification requests MUST
       NOT be null.

   2.  The client MUST include an Identity Proof control (Section 6.2.2)
       or Identity Proof Version 2 control (Section 6.2.1), derived from
       the shared-secret, in the Full PKI Request.

   The server receiving this message MUST (a) validate the Identity
   Proof control and then, (b) check that the subject DN included in
   each certification request matches that associated with the shared-
   secret.  If either of these checks fails, the certification request
   MUST be rejected.

6.3.3.  Renewal and Rekey Messages

   When doing a renewal or rekey certification request, linking identity
   and POP information is simple.  The client copies the subject DN for
   a current signing certificate into the subject name field of each
   certification request that is made.  The POP for each certification
   request will now cover that information.  The outermost signature
   layer is created using the current signing certificate, which allows

Top      Up      ToC       Page 40 
   the original identity to be associated with the certification
   request.  Since the name in the current signing certificate and the
   names in the certification requests match, the necessary linking has
   been achieved.

6.4.  Data Return Control

   The Data Return control allows clients to send arbitrary data
   (usually some type of internal state information) to the server and
   to have the data returned as part of the Full PKI Response.  Data
   placed in a Data Return control is considered to be opaque to the
   server.  The same control is used for both Full PKI Requests and
   Responses.  If the Data Return control appears in a Full PKI Request,
   the server MUST return it as part of the PKI Response.

   In the event that the information in the Data Return control needs to
   be confidential, it is expected that the client would apply some type
   of encryption to the contained data, but the details of this are
   outside the scope of this specification.

   The Data Return control is identified by the OID:

      id-cmc-dataReturn  ::= { id-cmc 4 }

   The Data Return control has the ASN.1 definition:

      DataReturn ::= OCTET STRING

   A client could use this control to place an identifier marking the
   exact source of the private key material.  This might be the
   identifier of a hardware device containing the private key.

6.5.  RA Certificate Modification Controls

   These controls exist for RAs to be able to modify the contents of a
   certification request.  Modifications might be necessary for various
   reasons.  These include addition of certificate extensions or
   modification of subject and/or subject alternative names.

   Two controls exist for this purpose.  The first control, Modify
   Certification Request (Section 6.5.1), allows the RA to replace or
   remove any field in the certificate.  The second control, Add
   Extensions (Section 6.5.2), only allows for the addition of
   extensions.

Top      Up      ToC       Page 41 
6.5.1.  Modify Certification Request Control

   The Modify Certification Request control is used by RAs to change
   fields in a requested certificate.

   The Modify Certification Request control is identified by the OID:

      id-cmc-modCertTemplate  ::= { id-cmc 31 }

   The Modify Certification Request has the ASN.1 definition:

     ModCertTemplate ::= SEQUENCE {
         pkiDataReference             BodyPartPath,
         certReferences               BodyPartList,
         replace                      BOOLEAN DEFAULT TRUE,
         certTemplate                 CertTemplate
     }

   The fields in ModCertTemplate have the following meaning:

   pkiDataReference  is the path to the PKI Request containing
      certification request(s) to be modified.

   certReferences  refers to one or more certification requests in the
      PKI Request referenced by pkiDataReference to be modified.  Each
      BodyPartID of the certReferences sequence MUST be equal to either
      the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
      certReqId of the CertRequest within a CertReqMsg (CRMF).  By
      definition, the certificate extensions included in the
      certTemplate field are applied to every certification request
      referenced in the certReferences sequence.  If a request
      corresponding to bodyPartID cannot be found, the CMCFailInfo with
      a value of badRequest is returned that references this control.

   replace  specifies if the target certification request is to be
      modified by replacing or deleting fields.  If the value is TRUE,
      the data in this control replaces the data in the target
      certification request.  If the value is FALSE, the data in the
      target certification request is deleted.  The action is slightly
      different for the extensions field of certTemplate; each extension
      is treated individually rather than as a single unit.

   certTemplate  is a certificate template object [CRMF].  If a field is
      present and replace is TRUE, it replaces that field in the
      certification request.  If the field is present and replace is
      FALSE, the field in the certification request is removed.  If the
      field is absent, no action is performed.  Each extension is
      treated as a single field.

Top      Up      ToC       Page 42 
   Servers MUST be able to process all extensions defined, but not
   prohibited, in [PKIXCERT].  Servers are not required to be able to
   process every X.509v3 extension transmitted using this protocol, nor
   are they required to be able to process other, private extensions.
   Servers are not required to put all RA-requested extensions into a
   certificate.  Servers are permitted to modify RA-requested
   extensions.  Servers MUST NOT alter an extension so as to reverse the
   meaning of a client-requested extension.  If a certification request
   is denied due to the inability to handle a requested extension and a
   Full PKI Response is returned, the server MUST return a CMCFailInfo
   value with the value of unsupportedExt.

   If a certification request is the target of multiple Modify
   Certification Request controls, the behavior is:

   o  If control A exists in a layer that contains the layer of control
      B, control A MUST override control B.  In other words, controls
      should be applied from the innermost layer to the outermost layer.

   o  If control A and control B are in the same PKIData (i.e., the same
      wrapping layer), the order of application is non-determinate.

   The same order of application is used if a certification request is
   the target of both a Modify Certification Request control and an Add
   Extensions control.

6.5.2.  Add Extensions Control

   The Add Extensions control has been deprecated in favor of the Modify
   Certification Request control.  It was replaced so that fields in the
   certification request other than extensions could be modified.

   The Add Extensions control is used by RAs to specify additional
   extensions that are to be included in certificates.

   The Add Extensions control is identified by the OID:

      id-cmc-addExtensions  ::= { id-cmc 8 }

   The Add Extensions control has the ASN.1 definition:

     AddExtensions ::= SEQUENCE {
         pkiDataReference             BodyPartID,
         certReferences               SEQUENCE OF BodyPartID,
         extensions                   SEQUENCE OF Extension
     }

Top      Up      ToC       Page 43 
   The fields in AddExtensions have the following meaning:

   pkiDataReference  contains the body part identity of the embedded
      certification request.

   certReferences  is a list of references to one or more of the
      certification requests contained within a PKIData.  Each body part
      identifier of the certReferences sequence MUST be equal to either
      the bodyPartID of a TaggedCertificationRequest (PKCS #10) or the
      certReqId of the CertRequest within a CertReqMsg (CRMF).  By
      definition, the listed extensions are to be applied to every
      certification request referenced in the certReferences sequence.
      If a certification request corresponding to bodyPartID cannot be
      found, the CMCFailInfo with a value of badRequest is returned
      referencing this control.

   extensions  is a sequence of extensions to be applied to the
      referenced certification requests.

   Servers MUST be able to process all extensions defined, but not
   prohibited, in [PKIXCERT].  Servers are not required to be able to
   process every X.509v3 extension transmitted using this protocol, nor
   are they required to be able to process other, private extensions.
   Servers are not required to put all RA-requested extensions into a
   certificate.  Servers are permitted to modify RA-requested
   extensions.  Servers MUST NOT alter an extension so as to reverse the
   meaning of a client-requested extension.  If a certification request
   is denied due to the inability to handle a requested extension and a
   response is returned, the server MUST return a CMCFailInfo with the
   value of unsupportedExt.

   If multiple Add Extensions controls exist in a Full PKI Request, the
   exact behavior is left up to the CA policy.  However, it is
   recommended that the following policy be used.  These rules would be
   applied to individual extensions within an Add Extensions control (as
   opposed to an "all or nothing" approach).

   1.  If the conflict is within a single PKIData, the certification
       request would be rejected with a CMCFailInfo value of badRequest.

   2.  If the conflict is between different PKIData, the outermost
       version of the extension would be used (allowing an RA to
       override the requested extension).

Top      Up      ToC       Page 44 
6.6.  Transaction Identifier Control and Sender and Recipient Nonce
      Controls

   Transactions are identified and tracked with a transaction
   identifier.  If used, clients generate transaction identifiers and
   retain their value until the server responds with a Full PKI Response
   that completes the transaction.  Servers correspondingly include
   received transaction identifiers in the Full PKI Response.

   The Transaction Identifier control is identified by the OID:

      id-cmc-transactionId  ::= { id-cmc 5 }

   The Transaction Identifier control has the ASN.1 definition:

      TransactionId ::= INTEGER

   The Transaction Identifier control identifies a given transaction.
   It is used by client and server to manage the state of an operation.
   Clients MAY include a Transaction Identifier control in a request.
   If the original request contains a Transaction Identifier control,
   all subsequent requests and responses MUST include the same
   Transaction Identifier control.

   Replay protection is supported through the use of the Sender and
   Recipient Nonce controls.  If nonces are used, in the first message
   of a transaction, a Recipient Nonce control is not transmitted; a
   Sender Nonce control is included by the transaction originator and
   retained for later reference.  The recipient of a Sender Nonce
   control reflects this value back to the originator as a Recipient
   Nonce control and includes its own Sender Nonce control.  Upon
   receipt by the transaction originator of this response, the
   transaction originator compares the value of Recipient Nonce control
   to its retained value.  If the values match, the message can be
   accepted for further security processing.  The received value for a
   Sender Nonce control is also retained for inclusion in the next
   message associated with the same transaction.

   The Sender Nonce and Recipient Nonce controls are identified by the
   OIDs:

      id-cmc-senderNonce     ::= { id-cmc 6 }
      id-cmc-recipientNonce  ::= { id-cmc 7 }

   The Sender Nonce control has the ASN.1 definition:

      SenderNonce ::= OCTET STRING

Top      Up      ToC       Page 45 
   The Recipient Nonce control has the ASN.1 definition:

      RecipientNonce ::= OCTET STRING

   Clients MAY include a Sender Nonce control in the initial PKI
   Request.  If a message includes a Sender Nonce control, the response
   MUST include the transmitted value of the previously received Sender
   Nonce control as a Recipient Nonce control and include a new value as
   its Sender Nonce control.

6.7.  Encrypted and Decrypted POP Controls

   Servers MAY require that this POP method be used only if another POP
   method is unavailable.  Servers SHOULD reject all certification
   requests contained within a PKIData if any required POP is missing
   for any element within the PKIData.

   Many servers require proof that the entity that generated the
   certification request 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 steps:

   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.

   3.  Client decrypts the POP challenge using the private key that
       corresponds to the presented public key and sends the plaintext
       back to the server.

   4.  Server validates the decrypted POP challenge and continues
       processing the certification request.

   CMC defines two different controls.  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.

Top      Up      ToC       Page 46 
   The Encrypted POP control is used to send the encrypted challenge
   from the server to the client as part of the PKIResponse.  (Note that
   it is assumed that the message sent in Step 1 above is a Full PKI
   Request and that the response in Step 2 is a Full PKI Response
   including a CMCFailInfo specifying that a POP is explicitly required,
   and providing the POP challenge in the encryptedPOP control.)

   The Encrypted POP control is identified by the OID:

      id-cmc-encryptedPOP     ::= { id-cmc 9 }

   The Encrypted POP control has the ASN.1 definition:

      EncryptedPOP ::= SEQUENCE {
           request        TaggedRequest,
           cms            ContentInfo,
           thePOPAlgID    AlgorithmIdentifier,
           witnessAlgID   AlgorithmIdentifier,
           witness        OCTET STRING
      }

   The Decrypted POP control is identified by the OID:

      id-cmc-decryptedPOP     ::= { id-cmc 10 }

   The Decrypted POP control has the ASN.1 definition:

      DecryptedPOP ::= SEQUENCE {
           bodyPartID     BodyPartID,
           thePOPAlgID    AlgorithmIdentifier,
           thePOP         OCTET STRING
      }

   The encrypted POP algorithm works as follows:

   1.  The server randomly generates the POP Proof Value and associates
       it with the request.

   2.  The server returns the Encrypted POP control with the following
       fields set:

       request  is the original certification request (it is included
          here so the client need not keep a copy of the request).

       cms  is an EnvelopedData, the encapsulated content type being id-
          data and the content being the POP Proof Value; this value
          needs to be long enough that one cannot reverse the value from
          the witness hash.  If the certification request contains a

Top      Up      ToC       Page 47 
          Subject Key Identifier (SKI) extension, then the recipient
          identifier SHOULD be the SKI.  If the issuerAndSerialNumber
          form is used, the IssuerName MUST be encoded as NULL and the
          SerialNumber as the bodyPartID of the certification request.

       thePOPAlgID  identifies the algorithm to be used in computing the
          return POP value.

       witnessAlgID  identifies the hash algorithm used on the POP Proof
          Value to create the field witness.

       witness  is the hashed value of the POP Proof Value.

   3.  The client decrypts the cms field to obtain the POP Proof Value.
       The client computes H(POP Proof Value) 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 containing a CMC Status Info control with CMCFailInfo
       value of popFailed.

   4.  The client creates the Decrypted POP control as part of a new
       PKIData.  The fields in the DecryptedPOP are:

       bodyPartID  refers to the certification request in the new PKI
          Request.

       thePOPAlgID  is copied from the encryptedPOP.

       thePOP  contains the possession proof.  This value is computed by
          thePOPAlgID using the POP Proof Value and the request.

   5.  The server then re-computes the value of thePOP from its cached
       value 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.  The POP
   Proof Value is used as the secret value in the HMAC algorithm and the
   request is used as the data.  If the POP Proof Value is greater than
   64 bytes, only the first 64 bytes of the POP Proof Value is used as
   the secret.

Top      Up      ToC       Page 48 
   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.
   The following 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 certification 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 certification request structure. y should not be predictable
       based on knowledge of R, thus the use of a one-way function like
       HMAC-SHA1.

6.8.  RA POP Witness Control

   In a certification request scenario that involves an RA, the CA may
   allow (or require) that the RA perform the POP protocol with the
   entity that generated the certification request.  In this case, the
   RA needs a way to inform the CA that it has done the POP.  The RA POP
   Witness control addresses this issue.

   The RA POP Witness control is identified by the OID:

      id-cmc-lraPOPWitness     ::= { id-cmc 11 }

   The RA POP Witness control has the ASN.1 definition:

      LraPopWitness ::= SEQUENCE {
          pkiDataBodyid   BodyPartID,
          bodyIds         SEQUENCE of BodyPartID
      }

   The fields in LraPOPWitness have the following meaning:

   pkiDataBodyid  contains the body part identifier of the nested
      TaggedContentInfo containing the client's Full PKI Request.
      pkiDataBodyid is set to 0 if the request is in the current
      PKIData.

   bodyIds  is a list of certification requests for which the RA has
      performed an out-of-band authentication.  The method of
      authentication could be archival of private key material,
      challenge-response, or other means.

Top      Up      ToC       Page 49 
   If a certification server does not allow an RA to do the POP
   verification, it returns a CMCFailInfo with the value of popFailed.
   The CA MUST NOT start a challenge-response to re-verify the POP
   itself.

6.9.  Get Certificate Control

   Everything described in this section is optional to implement.

   The Get Certificate control is used to retrieve a previously issued
   certificate from a certificate repository.  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 Certificate control is identified by the OID:

      id-cmc-getCert     ::= { id-cmc 15 }

   The Get Certificate control has the ASN.1 definition:

      GetCert ::= SEQUENCE {
          issuerName    GeneralName,
          serialNumber  INTEGER }

   The fields in GetCert have the following meaning:

   issuerName  is the name of the certificate issuer.

   serialNumber  identifies the certificate to be retrieved.

   The server that responds to this request places the requested
   certificate in the certificates field of a SignedData.  If the Get
   Certificate control is the only control in a Full PKI Request, the
   response should be a Simple PKI Response.



(page 49 continued on part 3)

Next RFC Part