On Sat, Jan 4, 2025 at 8:52 AM bruce lee <[email protected]> wrote:
> Dear Browser Development Team, > > I am writing to inquire about the specific logic and algorithms employed > by your browser when constructing certificate chains, particularly in > scenarios involving multiple intermediate certificates. I am looking for a > thorough explanation of the decision-making process and, if possible, the > location of the relevant code within your codebase. > > My specific area of interest is in how the browser handles situations > where it encounters multiple potential intermediary certificates that could > link to a given end-entity certificate, specifically: > > Scenario: Consider an end-entity certificate "C". This certificate can > potentially be linked to two intermediate certificates, "A" and "B". > Key and Subject Identity: Intermediate certificates "A" and "B" share the > same private key and have the same subject name. > Field Differences: However, other fields within "A" and "B" are different > (e.g., different validity periods, subject alternative names, extensions, > etc.). > > In such a case, end-entity certificate "C" could be successfully linked to > either "A" or "B", resulting in two potential certificate chain paths. > > My questions are: > > 1. Selection Criteria: What specific criteria or properties does the > browser prioritize when selecting between such multiple intermediate > certificates with the same subject name and public key? Is this selection > based on the most recently issued certificate, or the one with the longer > validity period, or some other factors? Please provide a complete list of > these criteria, ordered by priority. > Candidate issuers are determined by subject name alone during path building. The public key/signature is verified when validating a particular path. Firefox tries candidate issuers in the following order. If there are multiple certificates in a particular category, they are tried in no particular order. 1. Built-in root certificates 2. Third-party root certificates 3. Intermediate certificates from the TLS handshake 4. Third-party intermediate certificates 5. Preloaded intermediate certificates (the set of disclosed intermediate certificates in the CCADB) 6. Root certificates found in the NSS cert DB 7. Intermediate certificates found in the NSS cert DB > 2. Algorithm: Could you describe the detailed algorithm (or pseudo-code) > used by the browser when making this selection? I am interested in > understanding the complete process flow. > Firefox uses mozilla::pkix to build and verify certificate chains. This is done in two parts: path building and chain validation. Path building is essentially depth-first search to find a path to a trust anchor (this is where e.g. basic constraints are checked). The depth is limited to 8 certificates, and loops are disallowed. Once a path to a trust anchor has been found, it is validated (this is where signature and revocation checking happens). If a path turns out to not be valid, path building continues with the next suitable candidate certificate. > 3. Implementation Location: Could you please provide information on the > location within the browser's codebase where this certificate chain > selection logic is implemented? If possible, please include specific file > paths or code modules. > mozilla::pkix: https://searchfox.org/mozilla-central/source/security/nss/lib/mozpkix/ Firefox's TrustDomain implementation: https://searchfox.org/mozilla-central/source/security/certverifier/NSSCertDBTrustDomain.cpp Firefox's CertVerifier: https://searchfox.org/mozilla-central/source/security/certverifier/CertVerifier.cpp > 4. Rationale: What is the reasoning behind these design choices, and what > are some potential edge cases or known issues that they are designed to > mitigate? > This is the original design document: https://briansmith.org/insanity-pkix The short version is that among other issues, Firefox's previous implementation wouldn't fully traverse all available paths, which would lead to unexpected errors. In particular, it made implementing key pinning impossible. > 5. Specific Examples: If there are any practical examples or case studies > of where the logic is relevant, could you share a few cases? > The prioritization in 1 is largely for performance reasons. If Firefox can find a short path to a trust anchor, that means fewer signatures to verify, which is faster. If it can find intermediates and eventually a trust anchor without accessing the NSS cert DB, that is also faster. I understand the complexity of this area and appreciate any detailed > information you can provide. I am particularly interested in the technical > specifics behind these choices, as it directly relates to the security and > reliability of web browsing. > > Thank you for your time and consideration. I look forward to your > response. > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/8375bf7d-d061-4aef-b888-b1bbbd408fe6n%40mozilla.org > <https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/8375bf7d-d061-4aef-b888-b1bbbd408fe6n%40mozilla.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAHP1u2j7KRJBQzKKAZMK9%3D9n1hGfSAoaHX_Bakx4BMQ-xBBgMw%40mail.gmail.com.
