none
[MS-WCCE] ICertAdmin2D::GetCAProperty, how does "CR_PROP_CRLSTATE" work? RRS feed

  • Question

  • In [MS-WCCE], §3.2.1.4.3.2.20 description for CR_PROP_CRLSTATE explains the behavior as follows:

    The CA MUST do the following for each one of the rows in Signing_Cert table:

    • The CA MUST evaluate the certificate status stored in the Signing_Cert_Certificate column by building its chain based on the specification defined in [RFC3280].
    • If the certificate is not valid the CA uses one of the status codes in the following table as the status for this signing certificate.
    • If the signing certificate is valid, the CA MUST evaluate the base CRL stored in the CRL_Raw_CRL column of the CRL table row where the value of CRL_Name_Id is equal to the row of the preceding signing certificate and verify that it was signed by the key associated with the signing certificate stored in the Signing_Cert_Certificate column. If the signature does not match to the public key of the signing certificate, then the CA MUST return the status 0x01 as specified in the following table.
    • If the signing certificate is valid and its associated key was used to sign the base CRL stored in the same row, the CA MUST return 0x00 as the status for this signing certificate.

    This description is misleading to me and my observations. Let's explain, what I get from actual implementation (ADCS):

    Scenario 1

    ADCS CA with one key and two CA certificates with the following configuration:

    Certificate index Key index Cert status   propIndex CR_PROP_CACERTSTATE CR_PROP_CRLSTATE
    0 0 Expired x 0 CA_DISP_INVALID CA_DISP_VALID
    1 0 Ok x 1 CA_DISP_VALID CA_DISP_ERROR

    this table suggests that the following statements are incorrect:

    If the certificate is not valid the CA uses one of the status codes in the following table as the status for this signing certificate.

    In a given example, certificate at index 0 is expired, but "CR_PROP_CRLSTATE" returns CA_DISP_VALID. The actual behavior doesn't much the documentation.

    If the signing certificate is valid, the CA MUST evaluate the base CRL stored in the CRL_Raw_CRL column of the CRL table row where the value of CRL_Name_Id is equal to the row of the preceding signing certificate and verify that it was signed by the key associated with the signing certificate stored in the Signing_Cert_Certificate column. If the signature does not match to the public key of the signing certificate, then the CA MUST return the status 0x01 as specified in the following table.

    certificate at index 1 shares the same key as certificate at index 0, thus CRL signature can be successfully validated using any CA certificate. The actual behavior doesn't much the documentation.

    Scenario 2

    ADCS CA with four keys and four CA certificates with the following configuration:

    Certificate index Key index Cert status   propIndex CR_PROP_CACERTSTATE CR_PROP_CRLSTATE
    0 0 Expired x 0 CA_DISP_INVALID CA_DISP_VALID
    1 1 Expired x 1 CA_DISP_INVALID CA_DISP_VALID
    2 2 Expired, revoked x 2 CA_DISP_INVALID CA_DISP_VALID
    3 3 Expired x 3 CA_DISP_INVALID CA_DISP_VALID
    4 4 Ok x 4 CA_DISP_VALID CA_DISP_VALID

    again, the actual behavior doesn't much the documentation.

    Scenario 3

    ADCS with two keys and three CA certificates with the following configuration:

    Certificate index Key index Cert status   propIndex CR_PROP_CACERTSTATE CR_PROP_CRLSTATE
    0 0 Revoked x 0 CA_DISP_REVOKED CA_DISP_REVOKED
    1 0 Ok x 1 CA_DISP_VALID CA_DISP_ERROR
    2 1 Ok x 2 CA_DISP_VALID CA_DISP_VALID

     


    The actual implementation in Microsoft ADCS CA is inferred from Certification Authority Renewal doc (in exact order):

    1. if certificate index (identified by Signing_Cert_Certificate column) doesn't match the key index, the CA MUST return the status CA_DISP_VALID
    2. if signing certificate is revoked, the CA MUST return the status CA_DISP_REVOKED
    3. if certificate index (identified by Signing_Cert_Certificate column) doesn't match the key index, the CA MUST return the status CA_DISP_ERROR

    And the table in the [MS-WCCE] doc is incorrect. Meaning for return values is (from certsrv.h):

    Value Meaning
    CA_DISP_ERROR (0x01) This Cert's CRL is managed by another Cert.
    CA_DISP_REVOKED (0x02) All unexpired certs using this Cert's CRL have been revoked.
    CA_DISP_VALID (0x03) This Cert is still publishing CRLs as needed.
    CA_DISP_INVALID (0x04) All certs using this Cert's CRL are expired.

    this table more or less matches the observed behavior, except for CA_DISP_INVALID case. I wasn't able to make a configuration that would return this status (see my behavior description above).


    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.


    Wednesday, June 10, 2020 10:16 AM

All replies

  • Hi Vadims

    Thanks for the question about Open Specifications.

    One of the Open Specifications Engineer will respond shortly to assist you.


    HungChun Yu (MSFT)

    Wednesday, June 10, 2020 2:50 PM
  • Hi Vadims:

    I'll help you with this issue and will be in touch as soon as I have an answer.


    Regards, Obaid Farooqi

    Sunday, June 14, 2020 4:49 PM
    Owner
  • Hi Vadims,

    I have a question about your inferred processing rules that you derived from the Certification Authority Renewal doc: 

    1. if certificate index (identified by Signing_Cert_Certificate column) doesn't match the key index, the CA MUST return the status CA_DISP_VALID
    2. if signing certificate is revoked, the CA MUST return the status CA_DISP_REVOKED
    3. if certificate index (identified by Signing_Cert_Certificate column) doesn't match the key index, the CA MUST return the status CA_DISP_ERROR

    Rules 1 and 3 appear to be checking for the same condition. If the certificate index doesn't match the key index, won't you have already returned CA_DISP_VALID in rule 1, so what is left to return CA_DISP_ERROR for rule 3?

    Is there a typo, or am I misunderstanding the processing?

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Tuesday, June 30, 2020 11:04 PM
    Moderator
  • Sorry, it seems there was a copy/paste typo. Correct sequence is:

    1. if signing certificate is revoked, the CA MUST return the status CA_DISP_REVOKED
    2. if certificate index (identified by Signing_Cert_Certificate column) doesn't match the key index, the CA MUST return the status CA_DISP_ERROR
    3. if certificate index (identified by Signing_Cert_Certificate column) matches the key index, the CA MUST return the status CA_DISP_VALID

    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Thursday, July 2, 2020 5:16 PM
  • Thank you, Vadims! That makes more sense.

    I have filed a request to update the documentation and will follow up. 

    Thanks,


    Jeff McCashland | Microsoft Protocols Open Specifications Team

    Friday, July 3, 2020 1:31 AM
    Moderator
  • Just to add: I'm still not sure about the order of 1 and 2.

    Vadims Podāns, aka Crypt32
    My weblog: www.sysadmins.lv
    PowerShell PKI Module: PSPKI
    Check out new: SSL Certificate Verifier
    Check out new: ASN.1 Editor tool.

    Friday, July 3, 2020 5:29 PM