Hello,

I am a researcher from Carleton University and I have a few questions about how 
Firefox handles TLS certificates, if this is the wrong place to ask please let 
me know where should I reach out.

1) Firstly, how does Firefox's behavior differ when encountering leaf 
certificates which fall under the following categories:
1.1) Leaf certificate which is revoked by the issuing authority (Specifically 
included in a CRL or OSCP response)
1.2) Leaf certificate which chains back to a root that is currently not present 
within Mozilla's root program (Not included in certdata.txt)
1.3) Leaf certificate which either chains back to a root/intermediary or itself 
has been explicitly distrusted/blacklisted. (What if Mozilla encountered a 
fraudulent *google.com certificate issued by Diginotar assuming there is a 
repeat of that case with another CA with unexpired certs in the wild and that 
CA being explicitly distrusted)
1.4) Leaf certificate which either chains intermediary present in OneCRL
1.5) Leaf certificate which while not revoked, chains back to a root that has 
been revoked.
Behavior refers to whether Firefox allows me to bypass certificate warning to 
visit the webpage and the error message displayed. Are these functionally the 
same between revoked and blacklisted certificates?

2) In the dev.security.policy discussion over the WoSign CA issues, an option 
was floated where the WoSign would be allowed for only issue certificates for 
the .cn domain which is the TLD for China. As such I would like to ask how 
Mozilla is currently enforcing name and other gTLD/TLD constraints on root 
certificates? Is this done within the NSS, if so is there some code or file 
which contains these bits? Similar to the NSS trust objects present in 
certdata.txt (Mozilla's root certificates). If the name constraints extension 
within the x509 is being used to enforce these restrictions only a very few 
(Less than 3 if I remember correctly) even have name constraints on the 
certificate, does that mean that name/TLD/gTLD constraints are rarely enforced?

3) Taking about root certificate removals/revocations/blacklists, I have some 
questions about the terminology. My assumptions are as follows:
3.1)  Certificates included within certdata.txt that are marked "Explicitly 
Distrust" are currently blacklisted certificates (Diginotar). As such Mozilla's 
mechanism to blacklist root certificates is to include partial information 
about the certificate  in certdata.txt and mark it as explicitly distrusted. A 
question remains if whether are blacklisted certificates included within 
Mozilla root certificates in the first place?
3.2) Certificates shown in CA/Removed certificates (in the Mozilla wiki site) 
are certificates previously present within the root store that have been 
removed for various reasons (WoSign/Startcom certificates)
3.3) If I were to create a list of Mozilla root certificates that have been 
revoked (Included in some CRL or notified by the CA), I would have to combine 
the removals list with the blacklisted certificates. Is it fair to assume that 
removed certificates are revoked?
Are these assumptions accurate?

4) Regarding Mozilla's OneCRL. Are additions to OneCRL only conducted when a CA 
notifies about an intermediary being revoked. Are there possibilities for 
OneCRL to have additions even if the CA did not contact Mozilla?

5) If there are functional differences between how Firefox treats revoked and 
blacklisted certificates (Question 1) Are certificates present in OneCRL 
considered revoked certificates or blacklisted certificates? To clarify if a CA 
notified Mozilla about an intermediate certificate but did not add it to a 
CRL/OCSP response (Due to some delay) would that certificate be treated as a 
revoked certificate (Considering it was not revoked by the CA) or a blacklisted 
certificate?


Thank you very much,

Jegan Purushothaman


_______________________________________________
dev-security mailing list
dev-security@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security

Reply via email to