Re: Mozilla not compliant with RFC 5280
I would hope not! And yet...Firefox has no revocation checking right now (or if you prefer, for the last 17 years). So what's a Firefox user to do...besides not use Firefox? From: Phillip Hallam-BakerSent: Friday, November 8, 2013 11:51 AMTo: Jeremy RowleyCc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Mozilla not compliant with RFC 5280I don't believe there are any parties who you would want as CAs that support the idea of getting rid of revocation checking. On Fri, Nov 8, 2013 at 9:35 AM, Jeremy Rowley jeremy.row...@digicert.com wrote: I imagine every CA would agree with you. OCSP stapling is a great idea, but the number of servers deploying it are very low. I don’t believe any CAs support the idea of getting rid of revocation checking. From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of fhw...@gmail.com Sent: Friday, November 08, 2013 6:42 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too? Or...? Thanks. From: fhw...@gmail.com Sent: Friday, November 1, 2013 5:50 PM To: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I think that is correct, Matthias. What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.) I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not. From: Matthias Hunstock Sent: Friday, November 1, 2013 10:46 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 Am 29.10.2013 19:37, schrieb Kathleen Wilson: The goal is for the revocation-push mechanism to be used instead of traditional CRL checking, for reasons described in the wiki page and the research paper. Everyone with a "self-made" CA will be completely cut off from revocation checking, except there is an OCSP responder? Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Website: http://hallambaker.com/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Mozilla not compliant with RFC 5280
They currently check revocation information, just not in the most ideal way. 1) They don’t check intermediates. Fortunately, intermediates are rarely revoked, and a CA can email Mozilla when it happens. 2) They don’t check CRLs, which is one of the reasons the CAB Forum requires CAs to provide OCSP information. 3) They do check end-entity OCSP responses, which all CAs are required to provide. Since every CA provides OCSP, there are assurances that users will be aware when a certificate is revoked. If Mozilla removes OCSP checks, CAs won’t be able to provide revocation information. Although Mozilla will check stapled responses, use of OCSP stapling on servers is low. Even with Mozilla driving clients to OCSP stapling, any transition will take a minimum of two years. FireFox users will be unable to really rely on a certificate until that time. The change also raises questions on how this affects CA practices. Many CAs invested substantially in infrastructure to provide reliable OCSP services. Most of us boast more than a 99.9% uptime with servers distributed throughout the world. What does this mean for CAs who, relying on Mozilla’s checking of OCSP and support of the baseline requirements, established an expensive and geographically diverse infrastructure? Mozilla’s main argument is that revocation checking without hard-fail provides little security. Although I disagree with the premises, if the lack of hard-fail is really the issue, the obvious solution is to turn it on. Most of the CAs would be happy about that. From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of fhw...@gmail.com Sent: Friday, November 08, 2013 11:09 AM To: dev-security-policy@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I would hope not! And yet...Firefox has no revocation checking right now (or if you prefer, for the last 17 years). So what's a Firefox user to do...besides not use Firefox? From: Phillip Hallam-Baker Sent: Friday, November 8, 2013 11:51 AM To: Jeremy Rowley Cc: fhw...@gmail.com; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I don't believe there are any parties who you would want as CAs that support the idea of getting rid of revocation checking. On Fri, Nov 8, 2013 at 9:35 AM, Jeremy Rowley jeremy.row...@digicert.com wrote: I imagine every CA would agree with you. OCSP stapling is a great idea, but the number of servers deploying it are very low. I don’t believe any CAs support the idea of getting rid of revocation checking. From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley mailto:dev-security-policy-bounces%2Bjeremy.rowley =digicert@lists.mozilla.org] On Behalf Of fhw...@gmail.com Sent: Friday, November 08, 2013 6:42 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I was hoping to see more responses on this issue. Does that mean people agree it's a problem but aren't sure what to do about it? Is it a small problem because Firefox already does OCSP and all the CA's do too? Or...? Thanks. From: fhw...@gmail.com Sent: Friday, November 1, 2013 5:50 PM To: Matthias Hunstock; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 I think that is correct, Matthias. What's more is that anyone who issues an end-entity cert will be unable to stop FF from using that cert in the future--without OCSP setup--until the expiration date. (I'll need someone to correct me on that.) I gotta believe there are people out there who issue(d) CRL's thinking that they are now protected when in reality they are not. From: Matthias Hunstock Sent: Friday, November 1, 2013 10:46 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Mozilla not compliant with RFC 5280 Am 29.10.2013 19:37, schrieb Kathleen Wilson: The goal is for the revocation-push mechanism to be used instead of traditional CRL checking, for reasons described in the wiki page and the research paper. Everyone with a self-made CA will be completely cut off from revocation checking, except there is an OCSP responder? Matthias ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- Website: http://hallambaker.com/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla not compliant with RFC 5280
This is good information, Kathleen, and I'm certainly in favor of making improvements. I do wish there was more info on the report author and any affiliations he might have.That said I can't find clear, unambiguous detail on what CRL capabilities are actually working in Firefox, and for which versions.There was some talk at one time how CRL never worked anyway or some such thing but I think we need clarification on that now.The worst case here is that some capabilities are missing from current (and future) versions and the worst case for missing functionality could be very bad indeed.Thanks. From: Kathleen WilsonSent:Tuesday, October 29, 2013 1:38 PMTo:mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Mozilla not compliant with RFC 5280On 10/29/13 5:20 AM, fhw...@gmail.com wrote: Changing the subject line because compliance is at the heart of this issue. I also would like to thank Brian for his comment below, because it seems we're discussing less the merits of CRLs and more rationalizing the cost to implement.snip So...if Mozilla can't implement CRL support because of staffing issues and priorities, that's fine. Actually it's completely understandable. In the meantime, Mozilla is not 5280 compliant--and that should be a big deal.Please see https://wiki.mozilla.org/CA:ImprovingRevocationThere is also an interesting research paper attached to that page about revocation.Folks are working towards adding a revocation-push mechanism so that Firefox preloads certain revocation information for intermediate and end-entity certificates. I started the discussion about which types of revocations should be included for intermediate certs here:https://groups.google.com/d/msg/mozilla.dev.security.policy/cNd16FZz6S8/t3GwjaFXx-kJThere will be a similar discussion for end-entity cert revocations, I just haven't started it yet.The goal is for the revocation-push mechanism to be used instead of traditional CRL checking, for reasons described in the wiki page and the research paper.In my opinion, the sequence in which certain changes (like ripping out the CRL user interface) could have been better, such as happening after the revocation-push mechanism was in place. But, in my opinion, we are heading the right direction -- there will be revocation checking, it just will be done in a better and more efficient way.Kathleen___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Mozilla not compliant with RFC 5280 (was: Netcraft blog, violations of CABF Baseline ...)
Changing the subject line because compliance is at the heart of this issue. I also would like to thank Brian for his comment below, because it seems we're discussing less the merits of CRLs and more rationalizing the cost to implement.Regarding the merits, here's a simple case that I hope will illustrate the importance of CRLs:- Site admin: someone hacked my server and probably took my private key and SSL certificate - CA: okay, generate a new key pair and send over the signing request and we'll get you a new certificate; in the mean time we'll issue a CRL so nobody uses the old cert anymore- Mozilla: meh, I don't see the big deal, I'm sure everything will be fine if I continue to allow the cert anywaySo, to put it another way, the decision to use a revoked cert is not Mozilla's to make - - the decision to revoke has to be respected. Here's why:- Cert thief: cool, all Firefox users will still recognize this cert so now I can sell it on the black market! Since this cert is for a high value target, I should be able to get some good money for it. I'll start the bidding at $50,000.So...if Mozilla can't implement CRL support because of staffing issues and priorities, that's fine. Actually it's completely understandable. In the meantime, Mozilla is not 5280 compliant--and that should be a big deal. ... I hope you can understandhow a software engineer would have trouble arguing in favor of such anexpensive feature as CRL fetching (or even OCSP fetching) without avalid argument in favor of doing it. Right now we're lacking validarguments for doing it.Cheers,Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
