Re: Short-lived certs
On 17/09/14 08:34, Kurt Roeckx wrote: A browser could perfectly reject a certificate that doesn't comply with the BR because the required OCSP URI is missing. It could. If such browsers existed, I agree it would have a negative effect on the likelihood of success of a short-lived certs plan. But I do not know of any such browsers. Do you? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
I wouldn't be worried about a browser rejecting a cert that doesn't comply. Instead, I'd be worried about a qualified audit showing non-compliance. Although Mozilla might not care about that particular non-compliance, other browsers and partners might. Jeremy On 9/22/2014 8:36 AM, Gervase Markham wrote: On 17/09/14 08:34, Kurt Roeckx wrote: A browser could perfectly reject a certificate that doesn't comply with the BR because the required OCSP URI is missing. It could. If such browsers existed, I agree it would have a negative effect on the likelihood of success of a short-lived certs plan. But I do not know of any such browsers. Do you? Gerv ___ 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
Re: Short-lived certs
On 16/09/14 23:13, Richard Barnes wrote: From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. From a technical perspective, that is true. However, if we have an interest in making short-lived certs a usable option, we have to consider the ecosystem. CAs will have to do engineering work to issue (and reissue) such certs every 24 hours, and sites will have to do engineering work to request and deploy those certificates. Whether those things are worth doing depends on the gain you get. If the improved speed is only for a small population of browsers, it is probably a lot less worth it than if it makes things faster for almost everyone. The latter is only achievable if it's permitted to remove the revocation pointers. I can look at the validity interval and make a decision to check revocation or not, regardless of whether the OCSP URI is there or not. In fact, a short-lived cert with an OCSP URI gets the benefit of added speed from browsers that suppress OCSP for short-lived certs, while at the same time working with legacy browsers. A short-lived cert _without_ an OCSP URI also works with legacy browsers. Unless you are using some other definition of works? So in units of Gerv's options below, the only action for Mozilla is (2). As I noted, this would result in reduced take-up of the idea. We could do (0) in addition, or support similar efforts by CAs to get the BRs update to let them out of OCSP obligations for short-lived certs. Honestly, I would prefer if CAs led, since they're the ones that benefit. If this is something we want to be part of our revocation strategy, then we benefit if we make it attractive to sites and CAs. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 2014-09-17 09:25, Gervase Markham wrote: A short-lived cert _without_ an OCSP URI also works with legacy browsers. Unless you are using some other definition of works? A browser could perfectly reject a certificate that doesn't comply with the BR because the required OCSP URI is missing. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham g...@mozilla.org wrote: On 16/09/14 23:13, Richard Barnes wrote: From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. From a technical perspective, that is true. However, if we have an interest in making short-lived certs a usable option, we have to consider the ecosystem. CAs will have to do engineering work to issue (and reissue) such certs every 24 hours, and sites will have to do engineering work to request and deploy those certificates. Changing a server to properly and safely support replacing its certificate on the fly is a very error-prone and difficult thing to do, compared to changing a server to properly and safely support OCSP stapling. For example, when the server updates its certificate, it needs to verify that the new certificate is the right one. Otherwise, the updated certificate could contain a public key for which an attacker owns the private key, and the server would be facilitating its own compromise by switching to that new certificate. In contract, with OCSP stapling, an attacker can never replace your server's public key, and so there is much less risk of catastrophe with OCSP stapling. Because of the added risk and added complication of short-lived certificates relative to OCSP stapling, and because OCSP stapling is already well-specified and quite widely implemented (though not yet commonly enabled), it would be better to prioritize shortening the maximum acceptable OCSP response validity period (e.g. to 72 hours) and to define and implement Must-Staple, over defining new standards for short-lived certificates. Those two improvements would have an immediate positive impact. Note, also, that browsers already effectively support short-lived certificates, even without any CABForum or browser policy work. And, also, I do support defining standards for short-lived certificates; I just think that fixing OCSP stapling should be a higher priority. Cheers, Brian ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Short-lived certs
I agree that we should reduce the validity period of OCSP responses and also that must staple is a high priority. 10 day responses is way too long (although I doubt any CAs are actually doing 10 days). Mozilla appears to be considering their entire revocation policy at this time, including future projects. Better to work out what is required now rather than make an exception to the policy after the changes are set in motion. I'd support a change on all three issues (even if short lived are the last to be implemented)! Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Brian Smith Sent: Wednesday, September 17, 2014 2:22 AM To: Gervase Markham Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On Wed, Sep 17, 2014 at 12:25 AM, Gervase Markham g...@mozilla.org wrote: On 16/09/14 23:13, Richard Barnes wrote: From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. From a technical perspective, that is true. However, if we have an interest in making short-lived certs a usable option, we have to consider the ecosystem. CAs will have to do engineering work to issue (and reissue) such certs every 24 hours, and sites will have to do engineering work to request and deploy those certificates. Changing a server to properly and safely support replacing its certificate on the fly is a very error-prone and difficult thing to do, compared to changing a server to properly and safely support OCSP stapling. For example, when the server updates its certificate, it needs to verify that the new certificate is the right one. Otherwise, the updated certificate could contain a public key for which an attacker owns the private key, and the server would be facilitating its own compromise by switching to that new certificate. In contract, with OCSP stapling, an attacker can never replace your server's public key, and so there is much less risk of catastrophe with OCSP stapling. Because of the added risk and added complication of short-lived certificates relative to OCSP stapling, and because OCSP stapling is already well-specified and quite widely implemented (though not yet commonly enabled), it would be better to prioritize shortening the maximum acceptable OCSP response validity period (e.g. to 72 hours) and to define and implement Must-Staple, over defining new standards for short-lived certificates. Those two improvements would have an immediate positive impact. Note, also, that browsers already effectively support short-lived certificates, even without any CABForum or browser policy work. And, also, I do support defining standards for short-lived certificates; I just think that fixing OCSP stapling should be a higher priority. Cheers, Brian ___ 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
Re: Short-lived certs
In an open forum like here, we discuss on standard practice, policy and baseline requirements so to make browsing the Internet more secure. Ad-hoc pre-approval process is not a good practice because it probably has no rules. Moreover, who is going to approve it? Mozilla or members in this group? Will it become another super Authority? On 9/6/2014 12:27 AM, Ben Wilson wrote: Maybe an ad-hoc pre-approval process would work. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, September 4, 2014 1:07 PM To: Ben Wilson Cc: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On Thu, Sep 4, 2014 at 7:54 AM, Ben Wilson ben.wil...@digicert.com wrote: Options for trying this out might fit under an exception, if one were created, for test, experimental, temporary, pilot, provisional, etc. certificate types. Ben, I think there is value in allowing some level of non-compliance for the purposes of testing and development, as that is the only way to get real world data. However the challenge is going to be not creating a loophole large enough to drive a truck (or business) through. I have no question there are customers who would love to pay a CA to issue a 1024-bit RSA certificate directly from a root with a subject of CN=exchange with no subject alternative name. What would prevent a CA from issuing such a certificate as a test, experimental, temporary, pilot, provisional, etc. type certificate? Thanks, Peter ___ 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
Re: Short-lived certs
On 04/09/14 14:14, Hubert Kario wrote: From what I heard (and my limited personal experience matches), is that the vast majority of clients not only completely ignore failures in OCSP retrieval (soft-fail) but completely lack any mechanism for revocation checking (be it OCSP or CRL). I believe all browsers have some mechanisms for revocation checking. Firefox does indeed soft-fail OCSP; our revocation plan as referenced in the parent post demonstrates how we are hoping to improve this, with short-lived certs part of the mix. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 04/09/14 19:20, Phillip Hallam-Baker wrote: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Yes; I think short-lived certs meet that criterion. 2) Ditto for legacy servers and this is actually a harder problem as upgrading a server can force a complete redesign if they are using a middleware layer that has changed radically. I don't agree; as others have said, no-one is forced to use such certs. 3) The status vulnerability window needs to be no longer than 48 hours for a machine with an accurate clock How do you come up with your figure of 48 hours? 4) The scheme must tolerate some degree of clock skew, though the amount might vary over time. Investigation of clock skew still needs to be done. We think that the problem may not be insurmountable. Because of (1), the AIA field is going to have to be populated in EV certs for a very long time and so we probably don't need to raise any of this in CABForum right now. Lets do the work then let them follow the deployment. A browser doesn't have to check the AIA field just because it is there. As my original post noted, a lot of the advantage of short-lived certs evaporates if they contain revocation pointers. Short lived certs are just as easy in theory BUT they require some new infrastructure to do the job right. At minimum there needs to be a mechanism to tell the server how to get its supply of short lived certificates. And we haven't designed a standard for that yet or really discussed how to do it and so it isn't ready to press the fire button on. I don't think it necessarily requires a standard. 1) Join in the IETF discussion on the TLS/PKIX lists saying that you support my TLS Feature extension proposal aka MUST STAPLE. We definitely support it. 3) Implement an appropriate response to a certificate that specifies a MUST STAPLE condition when the server does not staple. This could be (1) Hard Fail immediately I think that's what we will be doing. or (2) attempt to do an OCSP lookup and hard fail if it does not succeed or (3) choose randomly between options 1 and 2 so as to disincentivize CAs misusing setting the flag to force hard fail. I don't quite understand the problem you are trying to mitigate here; can you expand? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 05/09/14 00:06, Brian Smith wrote: Precisely defining a short-lived certificate is a prerequisite for a proper discussion of policy for short-lived certificates. It seems likely to me that short-lived certificates will be defined as certificates that would expire before the longest-acceptable-life OCSP response for that certificate would expire. Then it would be easy to understand the security properties of short-lived certificates, given that we understand the security properties of OCSP. I strongly want to avoid ratholing on this discussion; if I say OK, let's say for the sake of argument that short-lived is the same as the max OCSP lifetime, then someone else will say but that's still too long! and so on. I realise that this issue would need to be resolved precisely before short-lived certs were allowed by policy; but I just don't want to focus on it right _now_. I want to assume that we could come up with an appropriate time window, and work out how Mozilla should push towards making short-lived certs possible, using the options I outlined above. Previously, we decided it was important that we have evidence that the OCSP responder know about all certificates that were issued by the CA, so we made it a requirement that OCSP responders must return not return Good for certificates that they do not know about. But, accepting short-lived certificates is equivalent to an OCSP responder returning Good for all certificates, whether it knows about them or not. Is that actually true? I am assuming that if a cert is mis-issued, for a few minutes at least the CA will stand by their issuance, and that the attacker can obtain a good OCSP response for it with a lifetime of X, and staple that response during their attack. So the security properties of that are about the same as those for a cert with lifetime X. Hmm... is there some mileage in saying that OCSP responses for certs during their first week of existence must have a max lifetime of significantly less than for the rest of their lives? That wouldn't increase OCSP server load much, but would perhaps mitigate this issue if the CA were to discover the misissuance soon after it happened. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 04/09/14 19:32, fhw...@gmail.com wrote: Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable? See other messages in this thread - it saves a significant amount of setup time not to have to wait for a response from the OCSP server. I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? What if I say it's treated the same as any other expired cert? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 05/09/14 10:47, Rob Stradling wrote: Unless the recently expired cert is found to be revoked, in which case you'd show Secure Connection Failed I presume? Yes :-) but after that we switch to Secure Connection Failed. What do you think of that idea? If the false positive rate drops to near-zero by 3 months after expiry, then I think that could work. However, it would need to work equally well for both long-lived certs and short-lived certs. Therefore, short-lived certs would still need to provide revocation info, even if the browser only uses that revocation info if it encounters the short-lived cert after its expiry date. Short-lived certs have different characteristics here, because if someone is deploying them, we know that they have the infrastructure to rotate certs quickly. It's not going to be some admin forgetting a yearly renewal. So I think that we would leave revocation info out of short-lived certs, but we would switch to Secure Connection Failed after hours or a day rather than 3 months. Or even go straight there. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 05/09/14 10:55, Gervase Markham wrote: On 05/09/14 10:47, Rob Stradling wrote: snip If the false positive rate drops to near-zero by 3 months after expiry, then I think that could work. However, it would need to work equally well for both long-lived certs and short-lived certs. Therefore, short-lived certs would still need to provide revocation info, even if the browser only uses that revocation info if it encounters the short-lived cert after its expiry date. Short-lived certs have different characteristics here, because if someone is deploying them, we know that they have the infrastructure to rotate certs quickly. It's not going to be some admin forgetting a yearly renewal. So I think that we would leave revocation info out of short-lived certs, but we would switch to Secure Connection Failed after hours or a day rather than 3 months. Or even go straight there. OK. That would work. :-) -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On Fri, Sep 5, 2014 at 5:30 AM, Gervase Markham g...@mozilla.org wrote: On 04/09/14 14:25, Rob Stradling wrote: When attempting to access an HTTPS site with an expired cert on Firefox 32, you'll see a This Connection is Untrusted page that lets you add an exception and proceed. But when attempting to access an HTTPS site with a revoked cert, you'll see Secure Connection Failed and Firefox 32 does NOT let you proceed. Would it make sense to treat expired certs in the same way as revoked certs? (And if not, why not?) Logically, it does make sense. In practice, revocation has a near-zero false-positive rate, whereas expired sadly has a much greater false-positive rate. Which is why Firefox treats them differently. Which means that expired short lived certs probably need to be treated differently. We probably need to mark them in some way as being intended to be short lived. And we certainly need to fix the problem of getting them renewed efficiently. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Phillip Hallam-Baker ph...@hallambaker.com To: Gervase Markham g...@mozilla.org Cc: Rob Stradling rob.stradl...@comodo.com, mozilla-dev-security-pol...@lists.mozilla.org, Hubert Kario hka...@redhat.com Sent: Friday, September 5, 2014 2:11:09 PM Subject: Re: Short-lived certs We probably need to mark them in some way as being intended to be short lived. And we certainly need to fix the problem of getting them renewed efficiently. I'd say that this is purely CA problem. Since the short lived certs are supposed to be a replacement for the revocation checking, using the same key for those certs is not a problem. As such, the CA may just re-sign the certificate on a daily basis and publish it in a non-obvious directory (e.g. SHA-1 hash of the certificate public key) if they don't want to make it easy to compute how many certificate they issue. Then the server downloads the certificate over HTTP, FTP, or gets it in email, validates if it matches the key it has, validates the signature and issuer and then starts serving it to clients. If you want to use new key for every certificate you'll have to use Simple Certificate Enrollment Protocol (SCEP), Certificate Management Protocol (CMP) or something similar. So it is possible to have a full spectrum between trivial and very complex as far as certificate re-issuance and management goes. I don't think it is good idea to mandate one specific implementation over another... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Short-lived certs
Maybe an ad-hoc pre-approval process would work. -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, September 4, 2014 1:07 PM To: Ben Wilson Cc: Gervase Markham; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On Thu, Sep 4, 2014 at 7:54 AM, Ben Wilson ben.wil...@digicert.com wrote: Options for trying this out might fit under an exception, if one were created, for test, experimental, temporary, pilot, provisional, etc. certificate types. Ben, I think there is value in allowing some level of non-compliance for the purposes of testing and development, as that is the only way to get real world data. However the challenge is going to be not creating a loophole large enough to drive a truck (or business) through. I have no question there are customers who would love to pay a CA to issue a 1024-bit RSA certificate directly from a root with a subject of CN=exchange with no subject alternative name. What would prevent a CA from issuing such a certificate as a test, experimental, temporary, pilot, provisional, etc. type certificate? Thanks, Peter smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
+1 Short lifetime certs don't solve every problem with revocation. But they allow us to drastically reduce the problem space. That makes applying other mechanisms viable. The end goal has to be to reduce the time window of vulnerability to the time it takes people to respond to phishing sites and other attacks. That is minutes, not days. We are not going to get there soon. But that is where we have to aim for. On Fri, Sep 5, 2014 at 12:43 PM, fhw...@gmail.com wrote: Hi Gerv, you've been busy! The cases Jeremy identified (thanks, Jeremy!) are all good problems to address and while I'm not unsympathetic I don't necessarily find them all that compelling. The situations involving network meddling by someone in power is especially troubling and goes beyond what I'm interested in covering in this discussion. That said, the case for performance is troubling for a couple reasons. First is that I've seen many times where someone says (whatever) would work so much better if we could bypass this security stuff. I don't mean to suggest that people who want small cert chains are wanting to bypass security but a practice such as this does open the door for people who might consider such things. So my initial concern is where this might lead, and what protections might be needed to ensure it doesn't go further. The bigger problem I have with this, however, really has nothing to do with people who have good server configs and are competent server admins. In such cases, we can probably assume there are likely to be fewer mistakes made and thus less of an impact to security. My problem is what happens when the cert holder loses control of the private key, no matter what the reason is. Relying on the expiration date is only a partial answer for 2 reasons: 1) a user might choose to allow the expired cert with the compromised key anyway (hence my asking about its treatment); and 2) a short expiry might still be long enough to cause harm. Consider that a phishing site might only exist for 2 days, just as an example. So in order to safely proceed with a small cert solution I think we need to flesh out how key compromises can be mitigated. *From: *Gervase Markham *Sent: *Friday, September 5, 2014 4:47 AM *To: *fhw...@gmail.com; Jeremy Rowley; mozilla-dev-security-pol...@lists.mozilla.org *Subject: *Re: Short-lived certs On 04/09/14 19:32, fhw...@gmail.com wrote: Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable? See other messages in this thread - it saves a significant amount of setup time not to have to wait for a response from the OCSP server. I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? What if I say it's treated the same as any other expired cert? Gerv ___ 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
Short-lived certs
Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus. How should we approach the issue of short-lived certs? It seems to me we can do the following: 0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face. 1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs. 2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments. 3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can emulate short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation). 4) Something else? Gerv [0] https://wiki.mozilla.org/CA:RevocationPlan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Gervase Markham g...@mozilla.org To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, September 4, 2014 12:21:50 PM Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. I'm not sure what gives us the removal of revocation info from certificate. I mean, if the recommendation for PKIX is to not check revocation info for certificates that have total validity period of less than, say 2 days, then inclusion or exclusion of AIA extension is secondary. There's also the must-staple extension in the works, which can be part of the plan: you either get short lived certs or you get a long lived with must-staple. They would provide the same security guarantees. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of short-lived is something I want to declare out of scope for this particular discussion. I'm not sure what gives us the removal of revocation info from certificate. Because there are lots of clients out there who check revocation info always if the pointers are present. The only way to stop them doing that (and so realise the speed advantage) is by not putting revocation info in the cert. I mean, if the recommendation for PKIX is to not check revocation info for certificates that have total validity period of less than, say 2 days, then inclusion or exclusion of AIA extension is secondary. We can't update all the software in the world to magically follow our recommendation. There's also the must-staple extension in the works, which can be part of the plan: you either get short lived certs or you get a long lived with must-staple. They would provide the same security guarantees. It is part of the plan, if you read it :-) https://wiki.mozilla.org/CA:RevocationPlan Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
- Original Message - From: Gervase Markham g...@mozilla.org To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, September 4, 2014 3:04:33 PM Subject: Re: Short-lived certs On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of short-lived is something I want to declare out of scope for this particular discussion. I'm not sure what gives us the removal of revocation info from certificate. Because there are lots of clients out there who check revocation info always if the pointers are present. The only way to stop them doing that (and so realise the speed advantage) is by not putting revocation info in the cert. From what I heard (and my limited personal experience matches), is that the vast majority of clients not only completely ignore failures in OCSP retrieval (soft-fail) but completely lack any mechanism for revocation checking (be it OCSP or CRL). In fact, that is the main driver behind must-staple. Can you provide examples to the contrary? -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 04/09/14 14:04, Gervase Markham wrote: On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of short-lived is something I want to declare out of scope for this particular discussion. I'm not sure what gives us the removal of revocation info from certificate. Because there are lots of clients out there who check revocation info always if the pointers are present. The only way to stop them doing that (and so realise the speed advantage) is by not putting revocation info in the cert. Today, if an end-entity cert contains no AIA-OCSP URL and the server sends no stapled OCSP response, it's a violation of the BRs. I wonder if any clients out there would reject the cert in this situation? (I suspect not, but it's something to watch out for). -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
When attempting to access an HTTPS site with an expired cert on Firefox 32, you'll see a This Connection is Untrusted page that lets you add an exception and proceed. But when attempting to access an HTTPS site with a revoked cert, you'll see Secure Connection Failed and Firefox 32 does NOT let you proceed. Would it make sense to treat expired certs in the same way as revoked certs? (And if not, why not?) On 04/09/14 12:52, Hubert Kario wrote: - Original Message - From: Gervase Markham g...@mozilla.org To: mozilla-dev-security-pol...@lists.mozilla.org Sent: Thursday, September 4, 2014 12:21:50 PM Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. I'm not sure what gives us the removal of revocation info from certificate. I mean, if the recommendation for PKIX is to not check revocation info for certificates that have total validity period of less than, say 2 days, then inclusion or exclusion of AIA extension is secondary. There's also the must-staple extension in the works, which can be part of the plan: you either get short lived certs or you get a long lived with must-staple. They would provide the same security guarantees. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Short-lived certs
Options for trying this out might fit under an exception, if one were created, for test, experimental, temporary, pilot, provisional, etc. certificate types. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Thursday, September 4, 2014 4:22 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus. How should we approach the issue of short-lived certs? It seems to me we can do the following: 0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face. 1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs. 2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments. 3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can emulate short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation). 4) Something else? Gerv [0] https://wiki.mozilla.org/CA:RevocationPlan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
Hi Mark. I think that makes sense. Historically, the Development manager for the affected product has been invited to SARB. He or she has taken on the task of communicating with the relevant product managers. Relevant product managers should include those with responsibility for services. The service product managers should ensure that service components are remediated in an expeditious manner and that (where not already publicly disclosed) the security bulletin is not released until this has been done. I don't think that contradicts anything in the proposed amendment. We just have to make sure that the Development manager brings ALL the relevant product managers into the discussion. All the best. Tim. On Sep 4, 2014, at 12:41 PM, Ben Wilson ben.wil...@digicert.com wrote: Options for trying this out might fit under an exception, if one were created, for test, experimental, temporary, pilot, provisional, etc. certificate types. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Thursday, September 4, 2014 4:22 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus. How should we approach the issue of short-lived certs? It seems to me we can do the following: 0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face. 1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs. 2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments. 3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can emulate short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation). 4) Something else? Gerv [0] https://wiki.mozilla.org/CA:RevocationPlan ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
Oops. Does it look like I replied to wrong email? Red-faced. Tim. On Sep 4, 2014, at 1:33 PM, Tim Moses tim.mo...@entrust.com wrote: Hi Mark. I think that makes sense. Historically, the Development manager for the affected product has been invited to SARB. He or she has taken on the task of communicating with the relevant product managers. Relevant product managers should include those with responsibility for services. The service product managers should ensure that service components are remediated in an expeditious manner and that (where not already publicly disclosed) the security bulletin is not released until this has been done. I don't think that contradicts anything in the proposed amendment. We just have to make sure that the Development manager brings ALL the relevant product managers into the discussion. All the best. Tim. On Sep 4, 2014, at 12:41 PM, Ben Wilson ben.wil...@digicert.com wrote: Options for trying this out might fit under an exception, if one were created, for test, experimental, temporary, pilot, provisional, etc. certificate types. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+ben=digicert@lists.mozilla.org] On Behalf Of Gervase Markham Sent: Thursday, September 4, 2014 4:22 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Short-lived certs Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential across all browsers. (The logic is that a 3-day expiry misissued cert with no revocation pointers has a similar risk profile to a 1-year expiry misissued cert where the attacker has captured a valid 3-day expiry OCSP response they can staple to it). I've just been reviewing discussions from July 2012 on the CAB Forum mailing lists about short-lived certs. There was some significant opposition to removing revocation information from short-lived certs at the time (although things may be different now, I don't know). I personally think much of that opposition was mistaken, but the discussion nevertheless did not result in consensus. How should we approach the issue of short-lived certs? It seems to me we can do the following: 0) Try and get a motion passed to change the BRs to allow short-lived certs to not have any revocation information. This would probably require us to review the original discussion and make a wiki page outlining our proposal and rebutting objections. We may still run into heavy weather. We could also discuss it at the face-to-face. 1) Write an exception in Mozilla's policy that short-lived certs don't have to have revocation info. This would likely have no effect, because CAs would want to continue issuing to the BRs. 2) Stop checking revocation information for short-lived certs unilaterally. This would result in reduced take-up of the idea, because there would be no advantage in other browsers, and one would still need to implement all the mechanisms, both at the CA and at the site, for frequent cert renewals and deployments. 3) Configure Firefox to not bother checking revocation information for any cert newer than N days. This way, you can emulate short-lived certs by just reissuing an X-year cert every N days or less. It also 'fixes' the clock-skew problem in one direction, because the certs will still work for users whose clocks are some way in the future (although their browsers would check revocation). 4) Something else? Gerv [0] https://wiki.mozilla.org/CA:RevocationPlan ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]: How should we approach the issue of short-lived certs? Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their residence so as to prevent tracing them. The same is true of distributors of malware. If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Short-lived certs
They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of David E. Ross Sent: Thursday, September 4, 2014 11:36 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]: How should we approach the issue of short-lived certs? Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their residence so as to prevent tracing them. The same is true of distributors of malware. If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ 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
Re: Short-lived certs
Hi Jeremy, Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable? Are there really cases where the extra 50 bytes (or whatever) for the revocation info is too great a burden? Or is the desire really to short circuit the revocation checks? Or...? I'm also wondering what the plan is for handling an expired short term cert. Will the user be given a choice of allowing an exception or does it get special handling? Original Message From: Jeremy Rowley Sent: Thursday, September 4, 2014 12:46 PM To: 'David E. Ross'; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Short-lived certs They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of David E. Ross Sent: Thursday, September 4, 2014 11:36 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]: How should we approach the issue of short-lived certs? Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their residence so as to prevent tracing them. The same is true of distributors of malware. If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On 9/4/2014 10:44 AM, Jeremy Rowley wrote: They aren't subject to less stringent security in issuing the certificate. The benefit is that the certificate doesn't include revocation information (smaller size) and doesn't need to check revocation status (faster handshake). The issuance of the certificate still must meet all of the Mozilla root store requirements. Jeremy Are you suggesting that NO certificate authority applying stringent procedures has ever signed a subscriber certificate for someone who intended to use it for malevolent purposes? -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of David E. Ross Sent: Thursday, September 4, 2014 11:36 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On 9/4/2014 3:21 AM, Gervase Markham wrote [in part]: How should we approach the issue of short-lived certs? Spammers change their E-mail addresses quite frequently, using the same address for only a day or two. Hackers also frequently change their residence so as to prevent tracing them. The same is true of distributors of malware. If short-lived certificates are subjected to less stringent security by client applications, I would fear that they would become hacker and malware tools. -- David E. Ross The Crimea is Putin's Sudetenland. The Ukraine will be Putin's Czechoslovakia. See http://www.rossde.com/editorials/edtl_PutinUkraine.html. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Short-lived certs
On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote: Some constraints: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Sure. However, this requires a definition of legacy. 2) Ditto for legacy servers and this is actually a harder problem as upgrading a server can force a complete redesign if they are using a middleware layer that has changed radically. Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as an option. No one's requiring they exclusively limit issuance to it. There's no concern for legacy servers. If you're a legacy server, you don't use this. It's that simple. 3) The status vulnerability window needs to be no longer than 48 hours for a machine with an accurate clock That's an opinion, and not a hard requirement memorialized in the current Baseline Requirements or Mozilla program. So I don't think it's fair or reasonable to introduce it as a requirement upon some new scheme or proposal. 4) The scheme must tolerate some degree of clock skew, though the amount might vary over time. That's up to the server operator, not the CA, and whether or not the solution is viable for them. Which is to say, a solution that tolerates no degree of clock skew is still immensely viable for a group of people. The more clock skew supported, the more viable it becomes for others, but that is NOT a gating factor to the overall scheme. Because of (1), the AIA field is going to have to be populated in EV certs for a very long time and so we probably don't need to raise any of this in CABForum right now. Lets do the work then let them follow the deployment. A browser doesn't have to check the AIA field just because it is there. I'm not sure I agree with your conclusion for 1. As noted elsewhere, a short-lived cert is effectively the same as the maximal attack window for a revocation response. That's it. The AIA can be dropped if they're equivalent. At worst we reword the requirements on browsers to say that they have to verify that the status is current and not specify how. Short lived certs would automatically qualify. Must Staple and short lived certs are pretty much the same as far as the security requirements go. The difference is that the server requirements for supporting stapling with must staple are pretty simple. All that is needed is that the server specify the must staple extension when the certificate is applied for (just a flag on the key generator) and then the server pulls the OCSP token from the AIA extension every n hours which is already implemented almost everywhere. Short lived certs are just as easy in theory BUT they require some new infrastructure to do the job right. At minimum there needs to be a mechanism to tell the server how to get its supply of short lived certificates. And we haven't designed a standard for that yet or really discussed how to do it and so it isn't ready to press the fire button on. I disagree here. What's at stake is not the particular mechanisms of doing so, nor would I endorse going down the route of standardizing such mechanisms as you do. I would much rather see the relevant frameworks - Mozilla and the BRs - altered to support them, and then allow site operators and CAs interested in this model to work to develop the infrastructure and, based on real world experience, rough consensus, and running code, rather than idealized abstractions. What I suggest browsers do right now is 1) Join in the IETF discussion on the TLS/PKIX lists saying that you support my TLS Feature extension proposal aka MUST STAPLE. 2) Read and comment on the proposal you have just committed to. 3) Implement an appropriate response to a certificate that specifies a MUST STAPLE condition when the server does not staple. This could be (1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard fail if it does not succeed or (3) choose randomly between options 1 and 2 so as to disincentivize CAs misusing setting the flag to force hard fail. This is something you should nail down before 1 or 2. The correct answer is hard fail. Any other answers and we'll be back here again in 5 years with the same issues. 4) Implement a mechanism that regards certificates with a total validity interval of 72 hours or less to be valid without checking. I do not expect this feature to be used very soon but implementing the feature in the browser is probably a gating function on starting the server folk thinking about the best way to implement the cert update feature. And implementing it in policy is the gating function before thinking about implementing it in the server or the browser. The simplest way to do cert update would be for the server to keep the same key throughout and just issue fresh certs for the same old key. A much better approach that provides a lot of robustness in all sorts of ways
RE: Short-lived certs
Yeah - the cert would have to be shorter than the longest acceptable OCSP response for certificates. I think that's set to 10 days in the CAB Forum, but I'd be surprised if anyone issues OCSP responses that are valid that long. The issue of revocation checking is where the proposal died in the CAB Forum. Opponents argued that mis-issued certificates are revoked immediately after issuance, meaning that traditional revocation is, on average, faster than short-lived certificate since the revocation usually occurs before the revocation information is cached. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert@lists.mozilla.org] On Behalf Of Brian Smith Sent: Thursday, September 4, 2014 5:07 PM To: Gervase Markham Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Short-lived certs On Thu, Sep 4, 2014 at 6:04 AM, Gervase Markham g...@mozilla.org wrote: On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of short-lived is something I want to declare out of scope for this particular discussion. Precisely defining a short-lived certificate is a prerequisite for a proper discussion of policy for short-lived certificates. It seems likely to me that short-lived certificates will be defined as certificates that would expire before the longest-acceptable-life OCSP response for that certificate would expire. Then it would be easy to understand the security properties of short-lived certificates, given that we understand the security properties of OCSP. Previously, we decided it was important that we have evidence that the OCSP responder know about all certificates that were issued by the CA, so we made it a requirement that OCSP responders must return not return Good for certificates that they do not know about. But, accepting short-lived certificates is equivalent to an OCSP responder returning Good for all certificates, whether it knows about them or not. So, we need to decide whether this aspect (a type of multi-factor authentication or counter-signature mechanism) is really important or not. It seems wrong for us to make it mandatory for long-lived certificates but not short-lived certificates, considering that the highest period of risk is immediately after issuance. Cheers, Brian ___ 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
Re: Short-lived certs
On Thu, Sep 4, 2014 at 6:43 PM, Ryan Sleevi ryan-mozdevsecpol...@sleevi.com wrote: On Thu, September 4, 2014 11:20 am, Phillip Hallam-Baker wrote: Some constraints: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Sure. However, this requires a definition of legacy. 2) Ditto for legacy servers and this is actually a harder problem as upgrading a server can force a complete redesign if they are using a middleware layer that has changed radically. Respectfully, Phillip, I disagree. CAs MAY offer such short-lived certs as an option. No one's requiring they exclusively limit issuance to it. There's no concern for legacy servers. If you're a legacy server, you don't use this. It's that simple. It is still a problem. The point I am trying to get across here is that there are very few good reasons for an end user sticking to an obsolete browser and almost all would upgrade given the choice. This is not the case for servers and there are lots of folk who will complain if they are forced to upgrade their server because that might require them to change their PHP version which in turn requires them to completely rework a ton of spaghetti code piled on top. Because of (1), the AIA field is going to have to be populated in EV certs for a very long time and so we probably don't need to raise any of this in CABForum right now. Lets do the work then let them follow the deployment. A browser doesn't have to check the AIA field just because it is there. I'm not sure I agree with your conclusion for 1. As noted elsewhere, a short-lived cert is effectively the same as the maximal attack window for a revocation response. That's it. The AIA can be dropped if they're equivalent. It can be dropped as far as security is concerned. But that is only going to save a few bytes and might cause legacy issues. So why make being allowed to drop it a major concern at this point? Dropping AIA is useful for the CA as I don't need to bother with OCSP at all. But I can only drop AIA if it is not going to cause legacy browsers to squeak about a missing OCSP distribution point. If there are browsers that give appropriate treatment to short lived certs then I am sure getting CABForum to update the BRs etc. is not going to be hard. All I am saying here is that is not a critical path concern. Short lived certs are just as easy in theory BUT they require some new infrastructure to do the job right. At minimum there needs to be a mechanism to tell the server how to get its supply of short lived certificates. And we haven't designed a standard for that yet or really discussed how to do it and so it isn't ready to press the fire button on. I disagree here. What's at stake is not the particular mechanisms of doing so, nor would I endorse going down the route of standardizing such mechanisms as you do. I would much rather see the relevant frameworks - Mozilla and the BRs - altered to support them, and then allow site operators and CAs interested in this model to work to develop the infrastructure and, based on real world experience, rough consensus, and running code, rather than idealized abstractions. I am not interested in issuing any product until my customers can use it. And I don't see how they can use it until the cert update process can be automated. What I suggest browsers do right now is 1) Join in the IETF discussion on the TLS/PKIX lists saying that you support my TLS Feature extension proposal aka MUST STAPLE. 2) Read and comment on the proposal you have just committed to. 3) Implement an appropriate response to a certificate that specifies a MUST STAPLE condition when the server does not staple. This could be (1) Hard Fail immediately or (2) attempt to do an OCSP lookup and hard fail if it does not succeed or (3) choose randomly between options 1 and 2 so as to disincentivize CAs misusing setting the flag to force hard fail. This is something you should nail down before 1 or 2. OK, if I have to nail it down I will pick 1. The correct answer is hard fail. Any other answers and we'll be back here again in 5 years with the same issues. That is my preference. 4) Implement a mechanism that regards certificates with a total validity interval of 72 hours or less to be valid without checking. I do not expect this feature to be used very soon but implementing the feature in the browser is probably a gating function on starting the server folk thinking about the best way to implement the cert update feature. And implementing it in policy is the gating function before thinking about implementing it in the server or the browser. I don't see the need to gate on policy changes. What do you think stops me issuing a 72 hour certificate today? I can't think of anything. Rotating the server private key every 24 hours practically eliminates key compromise due to a server or hard drive being disposed
