3.1.1.4.3 ICertRequestD::Request and ICertRequestD2::Request2 Processing
The processing for the ICertRequestD::Request method and the ICertRequestD2::Request2 method MUST be identical on the client side, except for the handling of the additional pwszSerialNumber parameter.
Rules for each argument passed to ICertRequestD::Request and ICertRequestD2::Request2 are as follows.
pwszAuthority: The client MUST follow the processing rules for pwszAuthority as specified in section 3.1.1.4.2.
dwFlags: The client MUST set the dwFlags parameter as specified in section 3.2.1.4.3.1.1.
pwszSerialNumber: For new requests, clients MUST set this parameter to NULL. To retrieve the status on an issued certificate, clients MUST set this parameter to the serial number of the issued certificate.
pdwRequestId: For new requests, clients MUST set this parameter to 0. To retrieve the status of a pending certificate request, the client MUST set this parameter to the request ID of the pending request.
pwszAttributes: The client MAY set the pwszAttributes parameter to a string representing a collection of attributes to be applied to the enrollment request. For specifications on the format of the string, see section 2.2.2.7.
pctbRequest: The pb member of CERTTRANSBLOB MUST be the encoded certificate request, and the cb member MUST be the length in bytes of the encoded certificate request. The Windows Client Certificate Enrollment Protocol can be used as the transport for four types of certificate requests, specified as follows.
The following table shows the various request types and request formats that are used when constructing each certificate request.
Certificate request types |
CMS with PKCS #10 |
PKCS #10 |
CMS with CMC |
Netscape KEYGEN |
---|---|---|---|---|
New request |
Yes |
Yes |
Yes |
Yes |
Renewal request |
Yes |
No |
Yes |
No |
Enroll On Behalf Of (EOBO) request |
Yes |
No |
Yes |
No |
Key archival request |
No |
No |
Yes |
No |
Initial key attestation request |
Yes |
Yes |
Yes |
No |
"Yes" indicates that this format is supported for this request type. "No" indicates that this format is not supported by this protocol.
The following sections define the requirement for the certificate request types in the table. Fields that are not defined in the following sections MUST be submitted by using the definitions from the relevant RFC as specified in [RFC3852] for CMS, [RFC2797] for CMC requests, [HTMLQ-keygen] for Netscape request format, and [RFC2986] for PKCS #10 certificate requests.
pdwDisposition: Upon a successful return from an ICertRequestD::Request or ICertRequestD2::Request2 method invocation, the client receives the pdwDisposition parameter as an output value.
If this value is 0x00000005 (CR_DISP_UNDER_SUBMISSION), the CA has not finished processing the enrollment request and the certificate has not been signed. This request is considered to be pending. See section 3.1.1.4.3.7 for information about how to retrieve pending requests from a CA.
If the value is any other nonzero value, the server has encountered an error. Unless otherwise specified in this document, the client SHOULD NOT rely on any specific error for its processing rules.
pctbDispositionMessage: Upon a successful return from an ICertRequestD::Request or ICertRequestD2::Request2 method invocation, the client receives the pctbDispositionMessage parameter as an output value. The client MUST NOT interpret or process this information in any way for anything other than display purposes. If the method encounters an error, the error string associated with the error code is returned. Error codes are specified in [MS-ERREF]. The client SHOULD NOT use the value in this field.