[MS-WCCE]: Windows Client Certificate Enrollment Protocol

This topic lists the Errata found in [MS-WCCE] since it was last published. Since this topic is updated frequently, we recommend that you subscribe to these RSS or Atom feeds to receive update notifications.

Errata are subject to the same terms as the Open Specifications documentation referenced.

RSS

Atom

To view a PDF file of the errata for the previous versions of this document, see the following ERRATA Archives:

October 16, 2015 - Download

June 30, 2015 - Download

July 18, 2016 - Download

September 29, 2020 – Download

October 6, 2021 - Download

Errata below are for Protocol Document Version V47.0 – 2021/10/06.

Errata Published*

Description

2022/08/09


In Section 3.2.1.1.1.2 Request Table Optional Data Elements:

Added 'Issuer_Name_Id' data element to the optional data elements request table.

Changed from:

".....

  • Request_Endorsement_Key_Hash

§ Request_Endorsement_Certificate_Hash"

Changed to:

".....

  • Request_Endorsement_Key_Hash

  • Request_Endorsement_Certificate_Hash

  • Issuer_Name_Id"

In Section 3.2.1.4.2.1.1.4 Storing Request Parameters in the Request Table

Added and defined the Issuer_Name_Id data element to the request parameters in the Request Table.

Changed from:

Column name

Processing rules

….

….

Request_Endorsement_Certificate_Hash

The CA MUST store the SHA2 hash of the trust module certificate used for attestation

from the certificate request as a hexadecimal string with no spaces.

Changed to:

Column name

Processing rules

….

….

Request_Endorsement_Certificate_Hash

The CA MUST store the SHA2 hash of the trust module certificate used for attestation from the certificate request as a hexadecimal string with no spaces.

Issuer_Name_Id

The CA MUST store the version information (section 3.2.1.4.3.2.39) of the current CA signing certificate as stored in the Signing_Cert_Certificate datum.

In Section 3.2.1.4.3.2.16, PropID = 0x00000010 (CR_PROP_CAXCHGCERTCHAIN) "CA Exchange Certificate Chain",

"The CA MUST follow the specified processing rule updates to process a client's request for the CA exchange certificate, its complete chain, and all relevant CRLs; which includes updated instructions for constructing a signed CMS message."

Changed from:

§ If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

§ Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

§ Construct a signed CMS message with the following fields:

§ ContentType: szOID_RSA_signedData (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: Same digest algorithm as was used to sign current CA's certificate stored in Signing_Cert_Certificate datum.

§ 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 set to the CA's exchange certificate from the Current_CA_Exchange_Cert datum.

§ certificates: Contains CA's certificate stored in the Signing_Cert_Certificate datum and its parent certificates. To obtain parent certificates, the CA SHOULD use Authority Information Access (AIA) extension of its certificate and its parent certificates. The AIA extension is specified in [RFC3280] section 4.2.2.1.

Changed to:

§ If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

§ Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

§ Retrieve the Issuer_Name_Id from the request database by finding the row with the Certificate_Hash equal to the Current_CA_Exchange_Cert hash value.

§ Find the CA signing certificate corresponding to the Current_CA_Exchange_Cert by looking for an entry in the Signing_Cert table with the certificate index (section 3.2.1.4.3.2.39) matching the lower 16 bits of the Issuer_Name_Id value retrieved in step 3 of this procedure.91

§ Construct a signed CMS message with the following fields:

§ ContentType: szOID_RSA_signedData (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: Same digest algorithm as was used by the CA signing certificate retrieved in step 4 of this procedure, to sign the Current_CA_Exchange_Cert. 

§ 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 set to the CA's exchange certificate from the Current_CA_Exchange_Cert datum.

§ certificates: Contains CA's certificate (1), as retrieved in step 4 of this procedure, and its parent certificates (1). To obtain parent certificates, the CA SHOULD use Authority Information Access (AIA) extension of its certificate and its parent certificates. The AIA extension is specified in [RFC3280] section 4.2.2.1.

91 In some cases, the CA signing certificate with "certificate index" zero could be returned instead of the actual signing certificate that issued Current_CA_Exchange_Cert. This behavior can be automatically fixed by restarting certificate service whenever a new exchange certificate is created.

In Section 3.2.1.4.3.2.33 PropID = 0x00000021 (CR_PROP_CAXCHGCERTCRLCHAIN) "CA Exchange Certificate Chain and CRL"

"The CA MUST follow the specified processing rule updates to process a client's request for the CA exchange certificate, its complete chain, and all relevant CRLs; which includes updated instructions for constructing a signed CMS message."

Changed from:

§ If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

§ Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

§ Construct a signed CMS message with the following fields:

§ ContentType: szOID_RSA_signedData (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: Same digest algorithm as was used to sign current CA's certificate stored in Signing_Cert_Certificate datum.

§ 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 set to the CA's exchange certificate from the Current_CA_Exchange_Cert datum.

§ certificates: Contains CA's certificate stored in the Signing_Cert_Certificate datum and its parent certificates. To obtain parent certificates, the CA SHOULD use Authority Information Access (AIA) extension of its certificate and its parent certificates. The AIA extension is specified in [RFC3280] section 4.2.2.1.

Changed to:

§ If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

§ Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

§ Retrieve the Issuer_Name_Id from the request database by finding the row with the Certificate_Hash equal to the Current_CA_Exchange_Cert hash value.

§ Find the CA signing certificate corresponding to the Current_CA_Exchange_Cert by looking for an entry in the Signing_Cert table with the certificate index (section 3.2.1.4.3.2.39) matching the lower 16 bits of the Issuer_Name_Id value retrieved in step 3 of this procedure.95

§ Construct a signed CMS message with the following fields:

§ ContentType: szOID_RSA_signedData (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: Same digest algorithm as was used by the CA signing certificate retrieved in step 4 of this procedure, to sign the Current_CA_Exchange_Cert.

§ 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 set to the CA's exchange certificate from the Current_CA_Exchange_Cert datum.

§ certificates: Contains CA's certificate (1), as retrieved in step 4 of this procedure, and its parent certificates (1). excluding the root certificate. To obtain parent certificates, the CA SHOULD use Authority Information Access (AIA) extension of its certificate and its parent certificates. The AIA extension is specified in [RFC3280] section 4.2.2.1.

95 In some cases, the CA signing certificate with "certificate index" zero could be returned instead of the actual signing certificate that issued Current_CA_Exchange_Cert. This behavior can be automatically fixed by restarting certificate service whenever a new exchange certificate is created.

In Section 3.2.1.4.3.2.39 PropID = 0x00000027 (CR_PROP_CACERTVERSION) "CA Signing Certificates Revisions"

Bolded "version information"

Changed from:

The CA MUST return the array in a CERTTRANSBLOB (section 2.2.2.2) structure. Each ULONG value in the returned array MUST contain version information for a signing certificate in little-endian format.


Changed to:

The CA MUST return the array in a CERTTRANSBLOB (section 2.2.2.2) structure. Each ULONG value in the returned array MUST contain version information for a signing certificate in little-endian format.

2022/07/26

In Section 3.2.1.4.3.2.16 PropID = 0x00000010 (CR_PROP_CAXCHGCERTCHAIN) "CA Exchange Certificate Chain": Removed the statement 'excluding the root certificate' as actual server behavior does not exclude the root certificate in a CMS message.

Changed from:

"The client has requested the CA exchange certificate and its complete chain. The CA MUST follow these processing rules to process the

client's request:

1. If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

2. Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

3. Construct a signed CMS message with the following fields:

§ ContentType: ...........

§ Content: ...............

§ version: ................

§ digestAlgorithms: .......

§ encapContentInfo: .......

§ certificates: Contains CA's certificate (1) stored in the Signing_Cert_Certificate datum and its parent certificates (1) excluding the root certificate."

Changed to:

"The client has requested the CA exchange certificate and its complete chain. The CA MUST follow these processing rules to process the

client's request:

1. If PropIndex parameter is not equal to 0x0 or 0xFFFFFFFF, return the E_INVALIDARG (0x80070057) error to the client.

2. Validate that the Current_CA_Exchange_Cert datum contains a current, valid CA exchange certificate by executing steps 2 and 3 in section 3.2.1.4.3.2.15.

3. Construct a signed CMS message with the following fields:

§ ContentType: ...........

§ Content: ...............

§ version: ................

§ digestAlgorithms: .......

§ encapContentInfo: .......

§ certificates: Contains CA's certificate (1) stored in the Signing_Cert_Certificate datum and its parent certificates (1)."excluding the root certificate

2022/06/28

In Section 3.2.2.6.2.1.4.4.1 Flags

Description: "Updated the value of the CT_FLAG_DONOTPERSISTINDB flag from 0x00000400 to 0x00001000."

Changed from:

"0x00000400

CT_FLAG_DONOTPERSISTINDB

If this flag is set and if the certificate (1) has been issued, the CA SHOULD NOT persist the information about the request in the Request table that is specified in section 3.2.1.1.1."

Changed to:

"0x00001000

CT_FLAG_DONOTPERSISTINDB

If this flag is set and if the certificate (1) has been issued, the CA SHOULD NOT persist the information about the request in the Request table that is specified in section 3.2.1.1.1."

2022/06/14

In Section 3.2.2.6.2.1.4.4.1 Flags

Description: "Updated the value of the CT_FLAG_DONOTPERSISTINDB flag from 0x00000400 to 0x00001000."

Changed from:

"0x00000400

CT_FLAG_DONOTPERSISTINDB

If this flag is set and if the certificate (1) has been issued, the CA SHOULD NOT persist the information about the request in the Request table that is specified in section 3.2.1.1.1."

Changed to:

"0x00001000

CT_FLAG_DONOTPERSISTINDB

If this flag is set and if the certificate (1) has been issued, the CA SHOULD NOT persist the information about the request in the Request table that is specified in section 3.2.1.1.1."

2022/05/10

Section 2.2.2.7.7.4 szOID_NTDS_CA_SECURITY_EXT

Description: "Created new topic to define the szOID_NTDS_CA_SECURITY_EXT security extension for enhanced security protections. Also added operating system applicability [MSFT-CVE-2022-26931] for this security update."

Changed From:

""

Changed To:

"OID = 1.3.6.1.4.1.311.25.2.

Internal Name: szOID_NTDS_CA_SECURITY_EXT11.

Description: Contains objectSid of the Active Directory object whose information is being used to construct the subject information of an issued certificate. The CA MUST consider this extension from request attributes only when the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set on the corresponding certificate template object. See section 3.2.2.6.2.1.4.5.9 for specifics on how the CA processes this extension. This extension value MUST be DER-encoded ([X690]). The critical field for this extension SHOULD be set to FALSE.

szOID_NTDS_OBJECTSID: 1.3.6.1.4.1.311.25.2.1.

Format: The following is the ASN.1 format ([X690]) for this attribute.

OtherName ::= SEQUENCE {

type-id szOID_NTDS_OBJECTSID,

value    octet string}

11This security extension is supported by the operating systems specified in [MSFT-CVE-2022-26931], each with its related KB article download installed."

Section 2.3   Directory Service Schema Elements

Description: Added 'objectSid' descriptor to the Computer class and User class lists in the Class/Attribute table.

Changed From:

"Computer   cn

distinguishedName

dNSHostName

objectGuid

Changed To:

"Computer   cn

distinguishedName

dNSHostName

objectGuid

objectSid

Changed From:

"User   cn

distinguishedName

objectGuid

mail

userCertificate

userPrincipalName"

Changed To:

"User   cn

distinguishedName

objectGuid

objectSid

mail

userCertificate

userPrincipalName"

Section 3.2.2.1.2.1 Search Requests

Description: "Added the attribute 'objectSid' to the list of attributes that the CA should use for an LDAP SearchRequest message."

Changed From:

● mail

● objectGUID

● userPrincipalName

Changed To:

● mail

● objectGUID

● objectSid

● userPrincipalName

Section 3.2.2.1.3.1 Search Requests

Description: Added the attribute 'objectSid' to the list of attributes that the CA should use for an LDAP SearchRequest message.

Changed From:

● mail

● objectGUID

● userPrincipalName

Changed To:

● mail

● objectGUID

● objectSid

● userPrincipalName

Section 3.2.2.6.2.1.4.5.9 msPKI-Certificate-Name-Flag

Description: "Enhanced the processing instructions to specify that the CA must add the new szOID_NTDS_CA_SECURITY_EXT security extension to the issued certificate when the CT_FLAG_NO_SECURITY_EXTENSION flag is not set; and to do the same when the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set and CT_FLAG_NO_SECURITY_EXTENSION is not set."

Changed From:

"4. If CT_FLAG_SUBJECT_REQUIRE_EMAIL is set, the CA MUST set the Subject field of the issued certificate (1) as a DN (1) whose E component value is obtained from the value of the mail attribute (1) of the requestor's user object in the working directory (1). For this, the CA MUST invoke the processing rules in section 3.2.2.1.2 with input parameter EndEntityDistinguishedName set equal to the requester's user object distinguished name (1) and retrieve the mailattribute (1)​ from the returned EndEntityAttributes output parameter."

Changed To:

"4. If CT_FLAG_SUBJECT_REQUIRE_EMAIL is set, the CA MUST set the Subject field of the issued certificate (1) as a DN (1) whose E component value is obtained from the value of the mail attribute (1) of the requestor's user object in the working directory (1). For this, the CA MUST invoke the processing rules in section 3.2.2.1.2 with input parameter EndEntityDistinguishedName set equal to the requester's user object distinguished name (1) and retrieve the mail attribute (1) from the returned EndEntityAttributes output parameter.

5. If the CT_FLAG_NO_SECURITY_EXTENSION flag is not set, the CA MUST add the szOID_NTDS_CA_SECURITY_EXT security extension, as specified in section 2.2.2.7.7.4, to the issued certificate with the value set to the string format of the objectSid attribute obtained from the requestor’s user object in the working directory. For this, the CA MUST invoke the processing rules in section 3.2.2.1.2, with input parameter EndEntityDistinguishedName set equal to the requester's user object distinguished name, and retrieve the objectSid attribute from the returned EndEntityAttributes output parameter."

Changed From:

"3. If CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set, then the CA MUST use the subject and subject alternative name information provided in the certificate (1) request. If no subject name is provided in the request, the CA MUST reject the request."

Changed To:

"3. If CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set, then the CA MUST use the subject and subject alternative name information provided in the certificate (1) request. If no subject name is provided in the request, the CA MUST reject the request.

4. If CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set and CT_FLAG_NO_SECURITY_EXTENSION is not set, then the CA MUST add the szOID_NTDS_CA_SECURITY_EXT security extension (section 2.2.2.7.7.4) to the issued certificate, that is, if it is provided as an extension in the request."

2022/05/10

In Section 3.2.2.6.2.1.4.5.6 msPKI-Enrollment-Flag

Description: Updated client processing instructions to indicate that the CA MUST also enforce the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag when the conditions specified in new section 3.2.2.6.2.1.4.8 are met.

Also revised client processing instructions to specify the conditions under which the subject alternative name (SAN) extension MUST be added to the new certificate being issued.

Changed From:

Flag

Client processing

0x00000040  CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT

The CA MUST enforce this flag only for certificate renewal requests.

If this flag is set in the template:

● The CA MUST NOT enforce the  signature processing rules specified for the following attributes:  msPKI-RA-Signature, msPKI-RA-Policies, and msPKI-Application-Policy.

● The CA MUST ignore the  CT_FLAG_PEND_ALL_REQUESTS flag.

Changed To:

Flag

Client processing

0x00000040  CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT

The CA MUST enforce this flag only for certificate renewal requests and  only when the conditions specified in section 3.2.2.6.2.1.4.8 are met.

If this flag is set in the template:

● The CA MUST NOT enforce the  signature processing rules specified for the following attributes:  msPKI-RA-Signature, msPKI-RA-Policies, and msPKI-Application-Policy.

● The CA MUST ignore the  CT_FLAG_PEND_ALL_REQUESTS flag.

● If the  CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT is set and the old certificate, based on  which reenrollment is occurring, contains the subject alternative name (SAN)  extension, then the same SAN extension MUST be added to the new certificate  being issued.

In Section 3.2.2.6.2.1.4.8 CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT Enforcement Conditions

Description: Created new topic to specify the conditions that are required to be met before enforcing the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag, that is, if the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag is set in the template.

Changed From:

""

Changed To:

"If the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag is set in the template, the CA MUST verify that all the following conditions are satisfied before enforcing the CT_FLAG_PREVIOUS_APPROVAL_VALIDATE_REENROLLMENT flag:

● The old certificate, based on which the reenrollment is occurring, MUST contain the Certificate Template OID extension, as specified in section 2.2.2.7.7.2.

● The TemplateID from the old certificate MUST match the TemplateID of the current template.

● If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is set, then the CA MUST verify that subject name is supplied in the request, and that it matches with the subject of the old certificate.

● If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, then the old certificate MUST contain the subject alternative name (SubjectAltName) extension.

● If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, then the SubjectAltName extension from the old certificate MUST contain either an rfc822Name or otherName with OID szOID_NT_PRINCIPAL_NAME (1.3.6.1.4.1.311.20.2.3).

● If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set and the SubjectAltName contains otherName, then the value of otherName MUST match the value of the userPrincipalName attribute from the requestor's user object in the working directory.

● If the CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT flag is not set, and the SubjectAltName contains the rfc822Name, then the value of rfc822Name MUST match the value of the mail attribute from the requestor's user object in the working directory."

*Date format: YYYY/MM/DD