Extended Validation changes the situation somewhat in that when mozilla::pkix is verifying an EV certificate, it must do so for a particular policy OID, and only certain roots are trusted for particular policy OIDs. Other than that, path building proceeds as before. So, using the example from before, suppose R were a trust anchor but not for a particular EV OID. Further suppose that T is also a trust anchor but is trusted for a particular EV OID. When evaluating the potential chain E -> I -> R, the trust domain determines that R is not a trust anchor for the policy being verified for, so mozilla::pkix keeps searching. It finds potential chain E -> I -> R' -> T, where T is trusted for that EV OID, and thus it verifies and returns that chain.
Note that Firefox does not do AIA chasing. That is, it does not use information embedded in certificates to remotely fetch potential issuer certificates. So, if a server does not include the appropriate intermediate certificates in the TLS handshake, Firefox may not be able to verify its certificate. Firefox does currently cache intermediates from previous successful verifications, however, so if a necessary intermediate is available in the cache, then the verification may succeed.
Unlike the other NSS libraries, mozilla::pkix is written in C++ and can take advantage of more modern language features.
When the platform successfully verifies an end-entity certificate, it caches the intermediates from that verified chain in the profile (cert9.db) in case they will be useful in the future (for example, when connecting to a different peer that uses a certificate issued by the same CA but neglects to include intermediate certificates in the handshake).
Note that Firefox does not do AIA chasing. That is, it does not use information embedded in certificates to remotely fetch potential issuer certificates. So, if a server does not include the appropriate intermediate certificates in the TLS handshake, Firefox may not be able to verify its certificate.
=== Extended Validation ===