次の方法で共有


3.2.1.4.2.1.4.8.1 Returning the Certificate as a CMS Certificate Response

If the client did not set the Y flag in the dwFlags parameter of ICertRequestD::Request or ICertRequestD2::Request2, the CA MUST use the CMS structures that are specified in [RFC3852] for constructing the response structure. If no end entity certificate is to be returned to the client (due to a failed, pending, or denied request), the CA MUST NOT build a CMS response and MUST return NULL in the pctbCertChain parameter. The following are the values for specific fields that the CA MUST set:

  • ContentType: szOID_PKCS_7_SIGNED (1.2.840.113549.1.7.2, id-signedData).

  • Content: SignedData (as specified in [RFC3852], section 5.1) with the following requirements:

    • version: See section [RFC3852], section 5.1.

    • digestAlgorithms: Not used.

    • encapContentInfo: EncapsulatedContentInfo structure (as specified in [RFC3852], section 5.2) with the eContentType set to the OID szOID_PKCS_7_DATA (1.2.840.113549.1.7.1, id-data) and the eContent field not used.

    • certificates: Contains the end entity certificate that has been issued or retrieved, as well as all CA certificates in its chain. If the request is pending with an issued precertificate, the precertificate is returned instead of the end entity certificate.

    • crls: If the client passed the X flag in the dwFlag parameter, this field MUST contain all current CRLs and delta CRLs for the CAs whose certificates were added to the certificates field. For each certificate in the certificates field, the CA SHOULD retrieve the CRL using the processing rules in section 3.2.1.4.1.3 by setting the ParameterCertificate parameter equal to the current certificate and by adding the returned ParameterCRL output parameter to the crls field.

    • signerInfos: Not used.