0

While going through the rfc5280 Certificate Path Validation to understand how the X.509 certificate chain is validated, I found out that the X.509 path processing Algorithm processes the chain in an order from trust anchor to the end entity. After reading this, I am a bit confused as to how the chains are validated. Is my understanding correct that Certificate Path validation mentioned in the RFC is sufficient to validate an X.509 certificate chain ?

The Algorithm accepts 9 parameters, out of which one is

 (d)  trust anchor information, describing a CA that serves as a
       trust anchor for the certification path.  The trust anchor
       information includes:

     (1)  the trusted issuer name,

     (2)  the trusted public key algorithm,

     (3)  the trusted public key, and

     (4)  optionally, the trusted public key parameters associated
          with the public key.

How does a verifier know what trust anchor to use before the path is validated.

The outputs of this algorithm as state by the RFC is

If path processing succeeds, the procedure terminates, returning a success indication together with final value of the valid_policy_tree, the working_public_key, the working_public_key_algorithm, and the working_public_key_parameters.

It's returning the working_public_key* attributes and a success indication. Is that sufficient.

My understanding of the X.509 chain validation.

For certificates supplied as Cert[1] signed by Cert[2] signed by Cert[3] where Cert[3] is a CA,

  1. Find certificate responsible for Cert[1].AKID and extract public key
  2. Verify Cert[1]'s signature and other attributes
  3. Check if Cert[2].SKID is trusted in the system trust/loaded trust of the client performing the operation. If not found, exit with an invalid verdict.
  4. If yes, the chain is trusted, exit with a valid verdict
  5. If no, then repeat the steps from 1 with Cert[2].

If my understanding is correct, why is the RFC version written in such a way.

Reasons of why I think the RFC mentions the chain is processed in the reverse order

  1. The prospective certificate path section 6.1

    (a) for all x in {1, ..., n-1}, the subject of certificate x is the issuer of certificate x+1;

    (b) certificate 1 is issued by the trust anchor;

    This states that certificate is ordered from trust anchor to end entity. Also supported by Subject(x) == Issuer(x + 1). Meaning, Cert[n] is the end entity cert

  2. Certificate processing in section 6.1.3.

     The basic path processing actions to be performed for 
     certificate i (for all i in [1..n]) are listed below.
    

    This also reads the certificates from 1, i.e. the trust anchor.

  3. In the section for Preparation for Certificate i+1,

    To prepare for processing of certificate i+1, perform the following steps for certificate i:

    (c)  Assign the certificate subject name to working_issuer_name.
    

The subject of Cert[i] is assigned to Cert[i + 1] as an issuer.

  1. In the section for Wrap-Up Procedure
    To complete the processing of the target certificate, perform the following 
    steps for certificate n:
    

This also mentions Cert[n] as the target certificate.

3

I think you are conflating certificate path validation with certificate path building (RFC4158). Building is most often done from the end entity by fetching the AIA URI and should include elements of validation to help guide the path to the correct destination (i.e. trust anchor). Validation is then performed on the output of the path building which necessarily always includes the trust anchor.

3
  • Is it a 2 step process ? Is the chain built using RFC4158 and then validated using RFC5280..? – pikaynu Jun 5 '20 at 7:39
  • Correct, first you build the path from the end entity to the trust anchor, then you validate the path according to RFC5280. RFC4158 is an informational document that can be used in whole or in part to help you design an effective algorithm for building certificate paths, particularly in complex environments such as the US Federal PKI. In such environments adding elements of validation such as certificate policy and name constraint processing to the path-building algorithm will yield much more reliable results. – Matt Jun 5 '20 at 14:06
  • Awesome, so it's possible to build the certificate path in both directions but it depends on how the relying party is implementing. There are optimisations present for both directions. It's usually simple to do it end entity to trust anchor. Thanks for the clarification @matt. – pikaynu Jun 5 '20 at 14:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.