3.6 Example 6: Enroll on Behalf of Request and Renewal

This example demonstrates the Enroll for a certificate, Enroll Certificate on Behalf of User and Renew Certificate use cases described in section 2.5.3.1.

This example builds on the example in section 3.3 by introducing a cosigner for the certificate request. In this example, the enrollment agent creates and signs the initial certificate request. The enrollment agent then submits the signed request to the CA. The CA returns the issued certificate to the enrollment agent, who then provides the issued certificate to the end entity via an out-of-band process.

Later, when a certificate needs to be renewed, the end entity creates a renewal request and signs it with the key that is associated with its current certificate. The certificate template is configured to allow renewals when the request is signed by the end entity's existing valid certificate that is based on the same template. The end entity submits the renewal request to the CA. If the certificate that is used for the signature is still valid, the CA automatically renews the certificate and returns the issued certificate to the client.

Smart card certificates are typically provisioned in the following manner: The smart card users might visit an enrollment agent in person so that their identity can be verified. The enrollment agent can then submit the certificate request on their behalf. The end entity, however, is allowed to renew their certificate without again requiring the involvement of the enrollment agent. By signing the renewal request with its existing valid certificate, it is providing evidence that the identity has already been verified.

Initial System State and Prerequisites

This example has the following additional assumptions, in addition to ones that are described in the example in section 3.3:

• A certificate template has been defined in Active Directory that has the msPKI-RA-Application-Policies attribute set with enhanced key usage (EKU); for example, 1.3.6.1.4.1.311.20.2.1, Certificate Request Agent. The certificate template also has the 0x00000040 (CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT) bit set on the msPKI-Enrollment-Flag field.

• The enrollment agent has a certificate containing an EKU with the same object identifier (OID) as defined in the previous template's msPKI-RA-Application-Policies attribute.

Sequence

The sequence of the steps for this example is organized into the following sections:

A. Query for available certificate templates from the Active Directory server

B. Request for a certificate on behalf of another user

C. Query for available templates and renew the certificate on behalf of another user

A. Query for available certificate templates from the Active Directory server

Figure 23: Query for available certificate templates

1. Upon startup, the CA-WCCE server requests the certificate template data from the Active Directory server via an LDAP search request, as described in [MS-WCCE] section 3.2.2.1.

2. The Active Directory server processes the request and responds with certificate template data in the format that is specified in [MS-WCCE] section 3.2.2.1.1.

3. The CA-WCCE server registers itself to receive change notifications, as specified in [MS-ADTS] section 3.1.1.3.4.1.9, when an attribute of a certificate template is being modified in order to stay up-to-date with any changes and to avoid retrieving the templates for each request.

4. The enrollment agent, by using a WCCE client component, requests the certificate templates from the Active Directory server via an LDAP search.

5. Active Directory processes the request and returns the certificate templates.

B. Request for certificate on behalf of another user

Figure 24: Request for certificate on behalf of another user

1. The enrollment agent generates a Cryptographic Message Syntax (CMS) structure with an embedded CMC request on behalf of another user, as specified in [MS-WCCE] section 3.1.1.4.3.3, and submits it to the CA by calling the Request method, as specified in [MS-WCCE] section 3.1.2.4.2.

2. The CA determines that the certificate template that corresponds to the request requires the enrollment agent's signature. It validates the signature and verifies that the certificate that is associated with the signature has the required EKUs, as specified in [MS-WCCE] section 3.2.2.6.2.1.2.1.2. When validation is completed, the CA issues the certificate and sends it to the enrollment agent.

   Note

   The enrollment agent then transfers the new certificate to the end entity via an out-of-band process. The process for this communication is not defined within this document.

C. Query for certificate templates and renew the certificate

Figure 25: Query for certificate templates and renew the certificate

1. When it is time to renew the certificate, the end entity uses a WCCE client component to retrieve the certificate templates from the Active Directory server via an LDAP search request.

2. The Active Directory server validates the request and returns the certificate templates.

3. The client creates a CMS renewal request and sends it to the CA, as specified in [MS-WCCE] section 3.1.1.4.3.2.

4. When the CA receives the request, it checks the certificate template for the msPKI-Enrollment-Flag and confirms that the 0x00000040 (CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT) bit is set, which allows the use of the previous certificate to sign the request, as specified in [MS-WCCE] section 3.2.2.6.2.1.2.3. The CA issues the renewed certificate and sends it to the end entity.

Final System State

The end entity has the renewed certificate.

• The CA-WCCE Server stores the request fields in the Request table, as specified in [MS-WCCE] sections 3.2.1.4.2.1.4.4 and 3.2.1.4.2.1.4.5, along with certificate status and the requested end entity details.