3.2.2.6.2.1.3 Storing Request Parameters in the Request Table

Unless specified otherwise in this section, the CA MUST store the request parameters as specified in section 3.2.1.4.2.1.4.4.

If a request is a key archival request as specified in section 3.2.2.6.2.1.2.2:

  • The CA MUST remove the unauthenticated attribute szOID_ARCHIVED_KEY_ATTR (1.3.6.1.4.1.311.21.13) from the outer CMS message before saving the request to the Request_Raw_Request column as specified in section 3.2.1.4.2.1.4.4.

  • If the CA implements the ICertAdminD2 interface specified in [MS-CSRA], it MUST follow these steps to archive the client's private key from the szOID_ARCHIVED_KEY_ATTR (1.3.6.1.4.1.311.21.13) attribute:

    1. If the Config_CA_KRA_Cert_List is empty, return a non-zero error to the client.

    2. If the Config_CA_KRA_Cert_Count is less than a number of certificates in the Config_CA_KRA_Cert_List, return a non-zero error to the client.

    3. From the Config_CA_KRA_Cert_List select Config_CA_KRA_Cert_Count number of certificates. These certificates will be used in steps 4 and 6.

    4. Construct an enveloped CMS message as specified in section 6 of [RFC3852] with the following requirements:

      • RecipientInfos: Use certificates selected in step 3.

      • EncryptedContent: Encrypt the private key from the szOID_ARCHIVED_KEY_ATTR (1.3.6.1.4.1.311.21.13) attribute of the certificate request.

    5. Save the message from the previous step in the Request_Raw_Archived_Key column.

    6. Save the SHA1 hashes of the certificates selected in step 3 by following these steps:

      1. Convert each hash into a string form by using hexadecimal digits and separating each byte with a space. Use lower case for letters 'a' through 'f'. For example, "01 23 fe dc".

      2. Concatenate each hash into a single string separating them with a '\n' character.

      3. Save the resultant string in the Request_Key_Recovery_Hashes column.

  • If the CA doesn't implement the ICertAdminD2 interface specified in [MS-CSRA], it MAY archive the client's private key by implementation specific means.

If the request is a key attestation request as specified in section 3.2.2.6.2.1.2.5, the CA MUST store the request parameters as specified in section 3.2.1.4.2.1.4.3:

  • If the request contains an szOID_ENROLL_EK_INFO attribute, then the CA MUST set the CR_FLG_CHALLENGEPENDING bit in the Request_Request_Flags column when key attestation begins and the CR_FLG_CHALLENGESATISFIED bit when key attestation is completed.

    If the request contains an szOID_ENROLL_AIK_INFO attribute, then the CA MUST set the CR_FLG_CHALLENGESATISFIED bit in the Request_Request_Flags column when processing is completed.

  • Save the SHA2 hash of the trust module certificate in the Request_Endorsement_Certificate_Hash column as a hexadecimal string with no spaces.

  • If the request is validly formed, set the CR_FLG_TRUSTONUSE flag in the Request_Request_Flags column and store the hash of the EK or AIK public key contained in the Client_HardwareKeyInfo ADM element as a hexadecimal string with no spaces in the Request_Endorsement_Key_Hash column.

  • If attestation processing succeeded according to section 3.2.2.6.2.1.2.5.1, set the CR_FLG_TRUSTEKCERT flag in the Request_Request_Flags column and store the hash of the succeeding certificate as a hexadecimal string with no spaces in the Request_Endorsement_Certificate_Hash column.

  • If attestation processing happened according to section 3.2.2.6.2.1.2.5.2, set the CR_FLG_TRUSTEKKEY flag in the Request_Request_Flags column.

  • If the request contains an szOID_ENROLL_EK_INFO attribute, then the CA MUST save the secret that was encrypted with the CA exchange key in the Request_Attestation_Challenge column.