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
