Process and order of verification of a X.509 certificate chain

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.