Partager via

3.1.1.4.3.3.3 Enroll on Behalf of Certificate Request Using CMS and CMC Request Formats

  • Article

The request MUST be an ASN.1 DER encoded CMS message (as specified in [RFC3852]) that includes a CMC request (as specified in [RFC2797]). The ASN.1 structure includes the following fields:

  • The client MUST construct a CMC request with the following requirements:

    • TaggedRequest: This field MUST contain exactly one certificate request. The certificate request MUST be the PKCS #10 constructed in the preceding step. See also section 2.2.2.6.5.

    • TaggedAttributes: The client MAY pass additional enrollment attributes in the RegInfo attribute as specified in [RFC2797] section 5.12. The semantics for the value of this attribute are identical to the ones that are defined for the pwszAttributes parameter for ICertRequestD::Request and ICertRequestD2::Request2. Specifications on the supported attributes are in section 3.1.1.4.3.1.1. The format of the value is specified in section 2.2.2.6.3. The value of the attribute MUST include the requestername name-value pair. The value of requestername MUST be the requested value for the Subject field in the Issued certificate.

  • The client MUST construct a CMS with the following requirement:

    • ContentType: This field MUST be the OID szOID_RSA_signedData (1.2.840.113549.1.7.2, id-signedData).

    • Content: This field MUST be a SignedData with the following values for its fields:

      • encapContentInfo: This field MUST have the following values for its fields:

        • eContentType: This field MUST be the OID szOID_CT_PKI_DATA (1.3.6.1.5.5.7.12.2, Id-cct-PKIData).

        • eContent: This field MUST be the CMC certificate request constructed as specified in the section 3.1.1.4.3.1.3 or retrieved from the OtherEndEntityRequest data.

      • Certificates: This field MUST include the certificate associated with the private key used to sign the certificate request.

      • SignerInfos: This collection MUST include at least two SignerInfo structures.

        • The first signerInfo MUST either use the subjectKeyIdentifier form of signerInfo, as specified in [RFC2797] section 4.2, or MUST use the No-Signature Signature Mechanism as specified in [RFC2797] section 3.3.3.1.

        • The second SignerInfo MUST be done with the key associated to the certificate that is passed in the preceding Certificates field.