3.1.1.4.3.2.2 Renew Certificate Request Using CMS and CMC Request Formats
The request MUST be an ASN.1 DER encoded CMS request (as specified in [RFC3852]) that includes a CMC request (as specified in [RFC2797]). The ASN.1 structure includes the following fields:
The client SHOULD construct a request for a new certificate by using the PKCS #10 certificate format as specified in section 2.2.2.6.5, 3.1.1.4.3.1.1, or 3.1.1.4.3.4.<25>
The client MUST add an attribute to the Attributes field in the PKCS #10. The attribute is szOID_RENEWAL_CERTIFICATE (1.3.6.1.4.1.311.13.1) as specified in section 2.2.2.7.3. The value for this attribute MUST be the ASN.1 DER encoded certificate to be renewed.
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 first of the preceding steps.
TaggedAttributes: The client MAY pass additional enrollment attributes in the RegInfo attribute as specified in [RFC2797] section 5.12. The cosemantics for the value of this attribute are identical to the ones that are defined for the pwszAttributes parameter for ICertRequestD::Request and ICertRequestD2::Request2. To read more on the supported attributes, see section 3.1.1.4.3.1.1. The format of the value is specified in section 2.2.2.6.3.
The client MUST construct a CMS with the following requirements:
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 in the preceding (first) step.
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 use the key associated with the certificate to be renewed.