On Tuesday, August 15, 2017 at 12:32:01 PM UTC, Gervase Markham wrote: > OneCRL does not obsolete certdata.txt-based distrust because not > everyone checks OneCRL. While we can't add every cert in OneCRL to > certdata.txt, we should add the big dis-trusts to it. Do you think > there's anything missing?
I'm not following this CA stuff for that long, but one thing that comes to mind is the us gov pki. The symantec cross-sign has expired by now and the identrust one only has 5 months left, so going by current public info this will resolve itself soon. Still, for 2 years now a huge, intransparent, complex subtree is (probably) blocked for OneCRL clients, but trusted for non-OneCRL (+non-OCSP) users. Imho this is/was a little more high-profile than most other entries. Another situation: Old Wosign/StartCom roots are slated to be removed from certdata soon afaik. Finally, end of that story, right? But old WoSign has a revoked cross-signed by Certum until 2020. So Firefox and OCSP clients will get the expected result: No more old WoSign. "Just certdata"-consumers will still have it trusted and hardly anybody will know that this is happening or how. Candidate for addition? In general: When I read the messages on this list, I get the following impression: 1. GOOD: Revocation alone is "not really enough", mis-issuance is still bad and it reflects badly on a CA if there are too many issues or their handling is poor. 2. HOWEVER: In practice, once a cert is revoked and added to OneCRL, both the CA and Mozilla consider that particular issue resolved. A revoked cert or subtree is considered "not in scope" any more (and understandably so, there isn't much more that can be done on the technical level save removing the entire root for really bad cases). So to me it kinda felt like non-OneCRL is not taken into account by Mozilla any more. But since you said certdata distrust might still be used, a suggestion: The Mozilla workflow seems to be missing a step that checks whether a revoked subCA will 1. keep issuing certs (e.g. I just read up on the Disney CA that was revoked, then started issuing non-compliant certs) and 2. whether exisiting certs at the time of revocation had critical issues (e.g. failed validation). In both cases certdata addition should be at least considered. Otoh, additions stemming from e.g. the recent reports seem to be good candidates for OneCRL-only distrust. Same if a subCA just moved roots or stopped operating and that was the reason for revocation. Basically: Figure out/inquire why the revocation happened and classify as high or low risk. Maybe Mozilla's policy could be adjusted to require CAs to provide such an explanation on revocation? I'm aware that there is a "revocation reason" in OCSP already, but that is insufficient (e.g. "cessation of operation" for identrust federal bridge cross...). _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
