Re: New wiki page on certificate revocation plans
Sorry, wrong thread. Expect to see a security blog post about revocation soon, summarizing some recent work :) On Sat, Nov 21, 2015 at 11:59 AM, Richard Barnes wrote: > I took a hack at the blog post. I kept your outline, but ended up > text-editing a bunch of it. I think it's pretty good now. > > On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes > wrote: > >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve >> revocation checking in our PKI stack, consolidating a bunch of ideas from >> earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" >> on a new wiki page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're >> planning to adopt a centralized revocation list model for CA certificates, >> which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) >> In addition to covering CA certifcates, we're also considering covering >> some end-entity (EE) certificates with OneCRL too. But there are some >> drawbacks to this approach, so it's not certain that we will include this >> in the final plan. Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html >> ___ >> dev-security-policy mailing list >> dev-security-pol...@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
I took a hack at the blog post. I kept your outline, but ended up text-editing a bunch of it. I think it's pretty good now. On Thu, Jul 31, 2014 at 10:07 PM, Richard Barnes wrote: > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new > wiki page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan > > It would be really helpful if people could review and provide feedback on > this plan. > > There's one major open issue highlighted in the wiki page. We're planning > to adopt a centralized revocation list model for CA certificates, which > we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In > addition to covering CA certifcates, we're also considering covering some > end-entity (EE) certificates with OneCRL too. But there are some drawbacks > to this approach, so it's not certain that we will include this in the > final plan. Feedback on this point would be especially valuable. > > Thanks a lot, > --Richard > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > ___ > dev-security-policy mailing list > dev-security-pol...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
On 07/08/14 23:17, fhw...@gmail.com wrote: > Curious to know the process by which cert holders will get their > certs added to these lists. How much of that flow and the necessary > security measures have been worked out? Cert holders get their certs added to CRLs maintained by their CA. Cert holders won't be communicating with Mozilla directly. Even in the case of high-profile misissuance, we normally work with the CA rather than the cert holder. If you are asking "how do CAs get their CRLs on the list", the answer is that they submit them to us via a to-be-designed process. We have contacts with the CAs, and there are a manageable number of them. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
Curious to know the process by which cert holders will get their certs added to these lists. How much of that flow and the necessary security measures have been worked out? Original Message From: Richard Barnes Sent: Thursday, August 7, 2014 3:59 PM To: Rob Stradling Cc: mozilla-dev-tech-cry...@lists.mozilla.org; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: New wiki page on certificate revocation plans On Aug 7, 2014, at 9:47 AM, Rob Stradling wrote: > http://dev.chromium.org/Home/chromium-security/crlsets says: > "The limit of the CRLSet size is 250KB" > > Have Mozilla decided what the maximum OneCRL size will be? No, we haven't. The need for a limit largely depends on whether we cover EE certificates. If we cover only intermediate CAs, of which there are roughly 1,800, then there is no size issue -- we can include the full SHA-256 digest of every CA certificate and only come to around 56KB. (Or just use a 1800-bit bitmap!) If we choose to cover EE certificates (as CRLSets do), then we will have to impose a size limit. In some initial experiments in representing CRLs with Golomb compressed encoding, we've been able to get down to roughly N bits per entry for 2^-N false positive rate. Since we'll still have OCSP as a fall-back, we can tolerate a high failure rate, maybe as high as 0.5% (2^-9). At that rate, a 250KB limit would fit around 220,000 CRL entries. So we would need to do some experimentation to see how that capacity compares to the size of CRLs in the wild. --Richard > > On 01/08/14 03:07, Richard Barnes wrote: >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve revocation >> checking in our PKI stack, consolidating a bunch of ideas from earlier work >> [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki >> page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're planning to >> adopt a centralized revocation list model for CA certificates, which we're >> calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to >> covering CA certifcates, we're also considering covering some end-entity >> (EE) certificates with OneCRL too. But there are some drawbacks to this >> approach, so it's not certain that we will include this in the final plan. >> Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-pol...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
On Aug 7, 2014, at 9:47 AM, Rob Stradling wrote: > http://dev.chromium.org/Home/chromium-security/crlsets says: > "The limit of the CRLSet size is 250KB" > > Have Mozilla decided what the maximum OneCRL size will be? No, we haven't. The need for a limit largely depends on whether we cover EE certificates. If we cover only intermediate CAs, of which there are roughly 1,800, then there is no size issue -- we can include the full SHA-256 digest of every CA certificate and only come to around 56KB. (Or just use a 1800-bit bitmap!) If we choose to cover EE certificates (as CRLSets do), then we will have to impose a size limit. In some initial experiments in representing CRLs with Golomb compressed encoding, we've been able to get down to roughly N bits per entry for 2^-N false positive rate. Since we'll still have OCSP as a fall-back, we can tolerate a high failure rate, maybe as high as 0.5% (2^-9). At that rate, a 250KB limit would fit around 220,000 CRL entries. So we would need to do some experimentation to see how that capacity compares to the size of CRLs in the wild. --Richard > > On 01/08/14 03:07, Richard Barnes wrote: >> Hi all, >> >> We in the Mozilla PKI team have been discussing ways to improve revocation >> checking in our PKI stack, consolidating a bunch of ideas from earlier work >> [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki >> page with our initial plan: >> >> https://wiki.mozilla.org/CA:RevocationPlan >> >> It would be really helpful if people could review and provide feedback on >> this plan. >> >> There's one major open issue highlighted in the wiki page. We're planning >> to adopt a centralized revocation list model for CA certificates, which >> we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In >> addition to covering CA certifcates, we're also considering covering some >> end-entity (EE) certificates with OneCRL too. But there are some drawbacks >> to this approach, so it's not certain that we will include this in the final >> plan. Feedback on this point would be especially valuable. >> >> Thanks a lot, >> --Richard >> >> [1] https://wiki.mozilla.org/CA:ImprovingRevocation >> [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > > -- > Rob Stradling > Senior Research & Development Scientist > COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
http://dev.chromium.org/Home/chromium-security/crlsets says: "The limit of the CRLSet size is 250KB" Have Mozilla decided what the maximum OneCRL size will be? On 01/08/14 03:07, Richard Barnes wrote: Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
I am generally in favour of this plan - I think it's the right way to go. I am not sure we will ever get to hard-fail for plain OCSP, but I am very happy for that to be a data-driven decision somewhere down the line. On 01/08/14 03:07, Richard Barnes wrote: > There's one major open issue highlighted in the wiki page. We're > planning to adopt a centralized revocation list model for CA > certificates, which we're calling OneCRL. (Conceptually similar to > Chrome's CRLsets.) In addition to covering CA certifcates, we're > also considering covering some end-entity (EE) certificates with > OneCRL too. But there are some drawbacks to this approach, so it's > not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. I think we should _not_ try and add EE certs (beyond high-profile misissuances) to OneCRL. Here are my reasons, some of which are already noted in the wiki page: * The number of certificates involved means that either the data set is of large size (bad for download and disk performance) or we use a Bloom filter or equivalent which has a false positive rate. This would be such that if a given cert was a false positive, it would be a false positive for every user all the time, until the unrelated revoked cert it was false-positived to fell out of the filter, e.g. by expiring. This means that if Fred owns fred.com and Joe owns joe.com, and joe.com's cert happens to be a Bloom match for a revoked cert, joe.com will have worse performance than fred.com (because every Firefox user will end up doing a hard-fail live OCSP lookup) in a way which is not obvious to Joe. This random aspect to the performance of the solution is not good. * The Bloom filter part is extra engineering which is not needed for the intermediate-only version. Even if the data is transmitted together, OneCRL effectively becomes TwoCRLs, one for intermediates and one for EEs, which work differently. We need to trade off this extra engineering requirement against the priority of the many other things we'd like to be doing. * If we put the EE CRLs of all publicly-trusted CAs into OneCRL, we have a significant information management issue for all the changing data. If we don't, we have to make decisions about who is in and who is out. Whatever we decide and however, the people who end up out suffer a performance (and therefore market) disadvantage for their certs. We are effectively playing favourites. I.e. we could be open and transparent, but it's impossible to be neutral. * If a CA has managed to persuade us to include their CRL in OneCRL, they have no incentive to encourage their users to deploy must-staple or short-lived, because revocation already works fine. That has a number of negative effects, including that there will be less pressure for greater ecosystem support for these technologies. Non publicly-trusted CAs can _only_ use these solutions (they can't be in OneCRL) so they need to work and be well supported. So I am of the opinion that must-staple OCSP and short-lived certs together (plus OneCRL for malicious misissuance) should be our solution for EE cert revocation. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: New wiki page on certificate revocation plans
On Jul 31, 2014, at 11:23 PM, Jeremy Rowley wrote: > This is great. Thanks Richard! Thanks go to the whole team. This was very much a group effort. > For OneCRL and the EE certs, establishing parameters around when an EE is > eligible for inclusion would give guidance to CAs about when to report > revocations. Is the OneCRL intended for when the cert is compromised because > of a breach of the CA? Or can high profile domains with stolen keys request > inclusion? There are two types of EE coverage you could imagine: 1. One-off "exceptional" inclusions of individual certificates 2. Bulk inclusion of an EE-issuing CA's CRL I think most of the discussion/controversy here is about the bulk inclusion. One-off exceptional inclusion in OneCRL is something that we will almost certainly do for high-profile cases. By definition, it's a small enough set that the burden to include it will not be that high. Is there a reason to discriminate between the two cases you describe? The earlier proposal for something like OneCRL included some instructions for requesting revocation be distributed through OneCRL. We should produce something similar once we're ready to accept such requests. https://wiki.mozilla.org/CA:ImprovingRevocation#Preload_Revocations_of_Certain_End-Entity_Certificates Hope that helps, --Richard > Jeremy > > -Original Message- > From: dev-security-policy > [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] > On Behalf Of Richard Barnes > Sent: Thursday, July 31, 2014 8:08 PM > To: mozilla-dev-security-pol...@lists.mozilla.org; > mozilla-dev-tech-cry...@lists.mozilla.org > Subject: New wiki page on certificate revocation plans > > Hi all, > > We in the Mozilla PKI team have been discussing ways to improve revocation > checking in our PKI stack, consolidating a bunch of ideas from earlier work > [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki > page with our initial plan: > > https://wiki.mozilla.org/CA:RevocationPlan > > It would be really helpful if people could review and provide feedback on > this plan. > > There's one major open issue highlighted in the wiki page. We're planning to > adopt a centralized revocation list model for CA certificates, which we're > calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to > covering CA certifcates, we're also considering covering some end-entity (EE) > certificates with OneCRL too. But there are some drawbacks to this approach, > so it's not certain that we will include this in the final plan. Feedback on > this point would be especially valuable. > > Thanks a lot, > --Richard > > [1] https://wiki.mozilla.org/CA:ImprovingRevocation > [2] https://www.imperialviolet.org/2012/02/05/crlsets.html > ___ > dev-security-policy mailing list > dev-security-pol...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
RE: New wiki page on certificate revocation plans
This is great. Thanks Richard! For OneCRL and the EE certs, establishing parameters around when an EE is eligible for inclusion would give guidance to CAs about when to report revocations. Is the OneCRL intended for when the cert is compromised because of a breach of the CA? Or can high profile domains with stolen keys request inclusion? Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Richard Barnes Sent: Thursday, July 31, 2014 8:08 PM To: mozilla-dev-security-pol...@lists.mozilla.org; mozilla-dev-tech-cry...@lists.mozilla.org Subject: New wiki page on certificate revocation plans Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html ___ dev-security-policy mailing list dev-security-pol...@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
New wiki page on certificate revocation plans
Hi all, We in the Mozilla PKI team have been discussing ways to improve revocation checking in our PKI stack, consolidating a bunch of ideas from earlier work [1][2] and some maybe-new-ish ideas. I've just pressed "save" on a new wiki page with our initial plan: https://wiki.mozilla.org/CA:RevocationPlan It would be really helpful if people could review and provide feedback on this plan. There's one major open issue highlighted in the wiki page. We're planning to adopt a centralized revocation list model for CA certificates, which we're calling OneCRL. (Conceptually similar to Chrome's CRLsets.) In addition to covering CA certifcates, we're also considering covering some end-entity (EE) certificates with OneCRL too. But there are some drawbacks to this approach, so it's not certain that we will include this in the final plan. Feedback on this point would be especially valuable. Thanks a lot, --Richard [1] https://wiki.mozilla.org/CA:ImprovingRevocation [2] https://www.imperialviolet.org/2012/02/05/crlsets.html -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
