Re: Exceptions to 1024-bit cert revocation requirement
On 21/12/13 22:22, Kathleen Wilson wrote: On 12/20/13 11:45 AM, Rob Stradling wrote: To me, cert revocation means replying revoked via OCSP for that cert's serial number, and also adding that cert's serial number to the CRL. I understand that new versions of browsers will stop accepting 1024-bit certs and that site operators will naturally stop using 1024-bit certs. But neither stopping using nor stopping accepting are the same thing as revocation. My question is simple: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? If Yes, where is this requirement written? If No, please simply reply No. No. To my knowledge there is not a written requirement for CAs to revoke all unexpired 1024-bit certs by a cut-off date. Kathleen, thanks for clarifying. snip -- 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: Exceptions to 1024-bit cert revocation requirement
On 21/12/13 22:57, Phillip Hallam-Baker wrote: I thought that what we were trying to do here is break a deadlock where Cas wait for browsers and vice versa. I have no trouble telling a customer with a 15 year 512 bit cert that they need to change for a new one if they want it to work for ssl with the browsers Indeed. Everyone agrees. Revoking it without their consent is a problem though. Indeed. The subject of this thread is misleading. Kathleen's last post clearly confirmed... Rob: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? Kathleen: No. -- 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: Exceptions to 1024-bit cert revocation requirement
On Mon, Dec 23, 2013 at 8:54 AM, Rob Stradling rob.stradl...@comodo.comwrote: On 21/12/13 22:57, Phillip Hallam-Baker wrote: I thought that what we were trying to do here is break a deadlock where Cas wait for browsers and vice versa. I have no trouble telling a customer with a 15 year 512 bit cert that they need to change for a new one if they want it to work for ssl with the browsers Indeed. Everyone agrees. Revoking it without their consent is a problem though. Indeed. The subject of this thread is misleading. Kathleen's last post clearly confirmed... Rob: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? Kathleen: No. It would be good if the sequence of operations to follow was documented for future reference. One of the problems that we have had in the industry is people assuming the decision lies with another party. When I was with my last employer I had to keep telling people not to follow our lead in choice of crypto because we are forced to follow rather than lead the market. A CA can't introduce a new crypto algorithm without the browsers implementing it five years, preferably a decade earlier. -- Website: http://hallambaker.com/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/20/13 11:45 AM, Rob Stradling wrote: To me, cert revocation means replying revoked via OCSP for that cert's serial number, and also adding that cert's serial number to the CRL. I understand that new versions of browsers will stop accepting 1024-bit certs and that site operators will naturally stop using 1024-bit certs. But neither stopping using nor stopping accepting are the same thing as revocation. My question is simple: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? If Yes, where is this requirement written? If No, please simply reply No. No. To my knowledge there is not a written requirement for CAs to revoke all unexpired 1024-bit certs by a cut-off date. But everyone should keep the following in mind... https://wiki.mozilla.org/CA:MD5and1024 All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013. Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013. This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible. Some long-lived certs were issued before the statement was made and communicated. Some CAs have needed to re-issue 1024-bit certs that are valid beyond 2013 in order for their customers to maintain operation while transitioning to new software and hardware that will support 2048-bit certs. (I am OK with this) At this point in time, I think the 1024-bit certs will work in Mozilla products until the April 2014 time frame. But, as per https://wiki.mozilla.org/CA:MD5and1024, Mozilla will take these actions earlier and at its sole discretion if necessary to keep our users safe. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
I thought that what we were trying to do here is break a deadlock where Cas wait for browsers and vice versa. I have no trouble telling a customer with a 15 year 512 bit cert that they need to change for a new one if they want it to work for ssl with the browsers Revoking it without their consent is a problem though. Sent from my difference engine On Dec 21, 2013, at 5:23 PM, Kathleen Wilson kwil...@mozilla.com wrote: On 12/20/13 11:45 AM, Rob Stradling wrote: To me, cert revocation means replying revoked via OCSP for that cert's serial number, and also adding that cert's serial number to the CRL. I understand that new versions of browsers will stop accepting 1024-bit certs and that site operators will naturally stop using 1024-bit certs. But neither stopping using nor stopping accepting are the same thing as revocation. My question is simple: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? If Yes, where is this requirement written? If No, please simply reply No. No. To my knowledge there is not a written requirement for CAs to revoke all unexpired 1024-bit certs by a cut-off date. But everyone should keep the following in mind... https://wiki.mozilla.org/CA:MD5and1024 All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013. Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013. This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible. Some long-lived certs were issued before the statement was made and communicated. Some CAs have needed to re-issue 1024-bit certs that are valid beyond 2013 in order for their customers to maintain operation while transitioning to new software and hardware that will support 2048-bit certs. (I am OK with this) At this point in time, I think the 1024-bit certs will work in Mozilla products until the April 2014 time frame. But, as per https://wiki.mozilla.org/CA:MD5and1024, Mozilla will take these actions earlier and at its sole discretion if necessary to keep our users safe. Kathleen ___ 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: Exceptions to 1024-bit cert revocation requirement
On 12/13/13 4:03 AM, Rob Stradling wrote: On 12/12/13 01:08, fhw...@gmail.com wrote: That's the great part about this, Rob, you don't actually have to revoke anything. Peter, thanks for sharing your interpretation. What concerns me is that the same interpretation is not shared by everyone. I don't really care whether or not these certs need to be revoked by the end of 2013. What I am concerned about is the possibility that CAs might be reprimanded because they failed to follow an unwritten rule! In my opinion, it is OK for CAs to take a little more time to finish transitioning their existing customers off of 1024-bit certs. The certs will just stop working at some point. Correct. I'm being somewhat facetious but that's really the bottom line. Perhaps we should not use the word revocation here because in a strict technical sense that's not what will happen and nor is revocation really necessary. CAs have been transitioning their customers off of 1024-bit certs, because they don't want their customers to suddenly have their certs stop working. Some of those customers are coming back and saying that they need more time for various reasons (often having to do with the hardware that they're using). The April 2014 time frame seems to be when most customers can complete their migration off of 1024-bit certs. I'm OK with that. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 20/12/13 17:40, Kathleen Wilson wrote: On 12/13/13 4:03 AM, Rob Stradling wrote: On 12/12/13 01:08, fhw...@gmail.com wrote: That's the great part about this, Rob, you don't actually have to revoke anything. Peter, thanks for sharing your interpretation. What concerns me is that the same interpretation is not shared by everyone. I don't really care whether or not these certs need to be revoked by the end of 2013. What I am concerned about is the possibility that CAs might be reprimanded because they failed to follow an unwritten rule! In my opinion, it is OK for CAs to take a little more time to finish transitioning their existing customers off of 1024-bit certs. Kathleen, perhaps I'm still failing to express my concern clearly. I am trying to understand exactly what you mean by 1024-bit cert revocation requirement. To me, cert revocation means replying revoked via OCSP for that cert's serial number, and also adding that cert's serial number to the CRL. I understand that new versions of browsers will stop accepting 1024-bit certs and that site operators will naturally stop using 1024-bit certs. But neither stopping using nor stopping accepting are the same thing as revocation. My question is simple: Will CAs need to revoke all unexpired 1024-bit certs by the cut-off date? If Yes, where is this requirement written? If No, please simply reply No. Thanks. snip -- 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: Exceptions to 1024-bit cert revocation requirement
Kathleen, I think that even if you agree to extend the deadline, it's a moot point unless Microsoft and other browsers follow suit. Unless there are web site owners that only support Firefox. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/13 01:08, fhw...@gmail.com wrote: That's the great part about this, Rob, you don't actually have to revoke anything. Peter, thanks for sharing your interpretation. What concerns me is that the same interpretation is not shared by everyone. I don't really care whether or not these certs need to be revoked by the end of 2013. What I am concerned about is the possibility that CAs might be reprimanded because they failed to follow an unwritten rule! The certs will just stop working at some point. I'm being somewhat facetious but that's really the bottom line. Perhaps we should not use the word revocation here because in a strict technical sense that's not what will happen and nor is revocation really necessary. Sorry, I should have mentioned that I'm thinking primarily about long-lived certificates that were issued before the BRs became effective. BRs Section 1 says: Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date. Where is it written that 2048-bit certs that predate the BRs need to be revoked by end of 2013? -- 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: Exceptions to 1024-bit cert revocation requirement
Am 2013-12-11 23:31, schrieb Kathleen Wilson: I am inclined to grant more time to CAs for customers who are working hard to transition off of 1024-bit certs, but need a little more time to complete their transition. We need to distinguish between roots, intermediates and end-entity certificates. A 1024-bit certificate for an end-entity only endangers said entity *and its users*, but not users of other sites. 1024-bit roots and intermediates, however, endanger everyone. For this reason, I don't think we should grant any exceptions in terms of roots and intermediates. Roots can be removed by disabling the trust bits (i.e. a reasonably simple change). This should be done ASAP after the relevant date - shouldn't it have been included in the Gecko/Firefox 27 beta currently running? Can it still be included, or is it too late for that? Disabling intermediates and end-entity certificates with less than 2048 bits will require a code change. Currently, Firefox will happily accept certificates with 512-bit signatures (WTF - the corresponding bug #360126 has been around for half a decade). Thus, this will likely be a non-trivial change. Preferably, CAs should be expected to revoke any 1024 bit intermediates if any of them still exist. Hopefully, attacks against RSA-1024 for the purpose of gaining end-entity certificates are going to stay uneconomical in the foreseeable future. For this reason, I don't have a strong opinion on forcing CAs to revoke end-entity certificates 2048 bit. We should not provide any assurances to CAs as to how long it will take us to disable 1024 bit certificates. Deadlines set by Mozilla already seem to be treated as suggestions by CAs, granting further exceptions will solidify this. I suspect that no matter the policy decision, we *will* grant CAs an unintentional extension (again) simply due to the time it takes to implement the changes. Firefox 16, which disabled MD5 signature support, got released on October 9, 2012 - over a year after the announced date. This probably contributed to CAs treating our deadlines as suggestions. Firefox 29, which is the current nightly, is scheduled to be released on 2014-04-29. We should try to get the code in there. In the future, we should start getting the patches for disabling insecure algorithms ready when the announcement is made to keep people from relying on slow development. Regarding the security of RSA 1024: RSA-768 has been practically broken in 2010: http://eprint.iacr.org/2010/006.pdf The authors note that factoring a 1024-bit RSA modulus would be about a thousand times harder. I wouldn't call that a comfortable safety margin. They claim that On a single core 2.2 GHz AMD Opteron processor with 2 GB RAM, sieving would have taken about fifteen hundred years. Whenever I say CPU without any details below, I mean such a CPU. Let's assume that one such CPU is equal to two GCEU or EC2 compute units. At Amazon, one m3.2xlarge instance would be equivalent to 13 CPUs with 2 GB RAM per CPU. Let's assume $0.5 per hour for such an instance - may be half or less with spot instances, would be double with on-demand instances. At Google, n1-standard-8 would be equivalent to 11 CPUs with nearly 3 GB RAM per CPU and cost $0.83/hour. Using the Amazon estimate, we have ~92 cents per day per CPU. Thus, for half a million dollars, you have the required 1500 CPU-years to perform the sieving step for 768 bit keys, which is the largest part of the computation. Note that this is a very rough estimate. Pricing may be less than half of the estimate if spot instances are used, and the researches oversieved by a factor of 2. Even taking this into account, breaking a 1024 bit modulus using cloud services would likely cost at least $100 million, unless significant advances in factorization have been made since that paper was released. (Please feel free to double-check my numbers, this is just a quick back-of-the-envelope calculation.) If someone managed to use GPUs for sieving, this could quickly become a lot cheaper - I have no idea if that is feasible. If someone has hardware laying around and doesn't need to pay a premium for cloud services, it becomes significantly cheaper. This paper http://www.hyperelliptic.org/tanja/SHARCS/talks/shark_paper.pdf estimates the cost of an ASIC-based device that breaks RSA-1024 in a year to be less than $200 million. This paper http://tau.ac.il/~tromer/papers/twirl.pdf (one of the authors is Adi Shamir himself) suggests that a different type of device could achieve it wihtin a year at a cost on $10 million for the device plus $20M for RD. All this assumes that no significant improvements on factoring have been found outside the public research community. Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention FROM NG in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers...
Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/13 2:11 AM, Jan Schejbal wrote: Roots can be removed by disabling the trust bits (i.e. a reasonably simple change). This should be done ASAP after the relevant date - shouldn't it have been included in the Gecko/Firefox 27 beta currently running? Can it still be included, or is it too late for that? Relevant bugs: https://bugzilla.mozilla.org/show_bug.cgi?id=881553 https://bugzilla.mozilla.org/show_bug.cgi?id=936304 (non-Symantec roots) https://bugzilla.mozilla.org/show_bug.cgi?id=936105 (Symantec roots) To summarize the current status of 1024-bit roots, all but the Symantec-owned roots will be either removed or have the websites and code signing trust bits disabled in Firefox 28. Symantec owes me a schedule for removing or turning off the websites and code signing trust bits for the roots listed in bug #936105. Symantec is aware that this work needs to be completed as soon as possible and within the first half of 2014. The problem is that the root certs that Symantec acquired had issued a lot of long-lived 1024-bit certs. Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/2013 12:31 AM, From Kathleen Wilson: I understand that this is not fair to the CAs who have done a great job of transitioning off of 1024-bit certs. Right - potential customers knock at various doors in respect to such certificates and I believe to have given the right answers to them that it's not possible to obtain such certificates anymore when approached. Indeed if this isn't something applied equally it might be very difficult to enforce other requirements in the future if at the first opportunity there is yet another exception to the previous exception etc...if experience shows that it doesn't pay out to comply to requirements, than why care next time? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Exceptions to 1024-bit cert revocation requirement
If you are granting more time, I have a whole bunch of customers who are not happy about the 2013 cutoff. Extending it for some CAs is patently unfair to those of us who have taken a hard stance on the deadline and not requested extensions of time. If you are granting some CAs an extension, you'll probably get a lot more requests from the rest of us. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Kathleen Wilson Sent: Wednesday, December 11, 2013 3:32 PM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Exceptions to 1024-bit cert revocation requirement All, There are a few cases where customers are asking CAs for more time to transition off of their 1024-bit certificates. According to the Baseline Requirements, 1024-bit Subscriber Certificates are supposed to be no longer valid by 31 Dec 2013. According to https://wiki.mozilla.org/CA:MD5and1024 All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013. Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013. This date could get moved up substantially if necessary to keep our users safe. We recommend all parties involved in secure transactions on the web move away from 1024-bit moduli as soon as possible. According to http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/ policy/maintenance/ We consider the following algorithms and key sizes to be acceptable and supported in Mozilla products: ... RSA 1024 bits (only until December 31, 2013). Starting a few months ago, CAs began contacting me with their concerns about meeting this deadline, and needing a little bit longer for customers to complete their transitions. I understand that this is not fair to the CAs who have done a great job of transitioning off of 1024-bit certs. But I also understand some of the timing issues that CAs' customers are running into. We have not yet made the code change to prohibit 1024-bit certs, so for Mozilla this is a question of policy. I am inclined to grant more time to CAs for customers who are working hard to transition off of 1024-bit certs, but need a little more time to complete their transition. Rather than creating another date for folks to complete their transitions off of 1024-bit certs, I think I'd prefer to handle time extensions on a case-by-case basis. I'll appreciate your constructive input on this. Kathleen ___ 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: Exceptions to 1024-bit cert revocation requirement
On 11/12/13 14:31, Kathleen Wilson wrote: There are a few cases where customers are asking CAs for more time to transition off of their 1024-bit certificates. What exactly are CAs asking for? Are they asking for permission to continue issuing such certs? Or are they asking for permission to not revoke such certs? Are the certs concerned ones which are in environments where the servers using them would be accessed by a consumer web browser? According to the Baseline Requirements, 1024-bit Subscriber Certificates are supposed to be no longer valid by 31 Dec 2013. So such CAs would fail a BR audit if one were to take place between 31st Dec 2013 and the time when those certs expire or are revoked? Starting a few months ago, CAs began contacting me with their concerns about meeting this deadline, and needing a little bit longer for customers to complete their transitions. Are we able to say roughly how many CAs are involved? And of those CAs, how many customers have problems? And for those customers, how many certs are involved? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On Wed, Dec 11, 2013 at 2:48 PM, Jeremy Rowley jeremy.row...@digicert.com wrote: If you are granting more time, I have a whole bunch of customers who are not happy about the 2013 cutoff. Extending it for some CAs is patently unfair to those of us who have taken a hard stance on the deadline and not requested extensions of time. If you are granting some CAs an extension, you'll probably get a lot more requests from the rest of us. Indeed, it would be unfair — and unwise. No exceptions. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
Well let's be clear about one thing: in Firefox land (as in others) there is no such thing as revocation; there is only changing the code.I think what Kathleen is saying is that starting Jan 1, Mozilla would like to take out the code supporting certs with small keys. What needs to be negotiated then is when end-entity cert holders will be prepared for their small keys to no longer work on _future_ versions of Mozilla products.A 1024-bit cert will always work with FF 24, for example. It may or may not work on version 30. If a cert holder is ok with that, I don't think there is really a problem.PKI gymnastics anyone?From: Rob StradlingSent: Wednesday, December 11, 2013 5:15 PMTo: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.orgSubject: Re: Exceptions to 1024-bit cert revocation requirementOn 11/12/13 22:31, Kathleen Wilson wrote:snip According to https://wiki.mozilla.org/CA:MD5and1024 "All end-entity certificates with RSA key size smaller than 2048 bits must expire by the end of 2013.Kathleen, are you saying that "must expire by the end of 2013" is a "revocation requirement" ?Expiration != Revocation.Is there actually a requirement that says "By the end of 2013, CAs MUST revoke all unexpired certificates with 2048-bit RSA keys" ?If so, where is it written and when was it communicated to the CAs?(If it's not actually written anywhere, then can you actually enforce it?)-- Rob StradlingSenior Research Development ScientistCOMODO - Creating Trust Online___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/11/13 2:55 PM, Gervase Markham wrote: On 11/12/13 14:31, Kathleen Wilson wrote: There are a few cases where customers are asking CAs for more time to transition off of their 1024-bit certificates. What exactly are CAs asking for? Are they asking for permission to continue issuing such certs? Or are they asking for permission to not revoke such certs? They are asking for permission to not revoke such certs. Are the certs concerned ones which are in environments where the servers using them would be accessed by a consumer web browser? According to the Baseline Requirements, 1024-bit Subscriber Certificates are supposed to be no longer valid by 31 Dec 2013. Correct, but the effective date of the BRs was 01-Jul-12... So such CAs would fail a BR audit if one were to take place between 31st Dec 2013 and the time when those certs expire or are revoked? Yes. https://wiki.mozilla.org/CA:CertificatePolicyV2.1#Baseline_Requirements The first BR audit for each CA and subCA may include a reasonable list of BRs that the CA (or subCA) is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved. Starting a few months ago, CAs began contacting me with their concerns about meeting this deadline, and needing a little bit longer for customers to complete their transitions. Are we able to say roughly how many CAs are involved? And of those CAs, how many customers have problems? And for those customers, how many certs are involved? Well, I received an influx of emails from CAs as soon as I posted this. I thought it was 3 or 4 CAs that would need longer, but now it looks like more. From Jeremy: If you are granting more time, I have a whole bunch of customers who are not happy about the 2013 cutoff. Extending it for some CAs is patently unfair to those of us who have taken a hard stance on the deadline and not requested extensions of time. If you are granting some CAs an extension, you'll probably get a lot more requests from the rest of us. Good point. So, if we are going to grant any extended timelines, we should set another date. The dates I've heard cluster around the May 2014 time frame. From Rob: Kathleen, are you saying that must expire by the end of 2013 is a revocation requirement ? Expiration != Revocation. Is there actually a requirement that says By the end of 2013, CAs MUST revoke all unexpired certificates with 2048-bit RSA keys ? If so, where is it written and when was it communicated to the CAs? (If it's not actually written anywhere, then can you actually enforce it?) In BR Appendix A Subscriber Certificates Minimum RSA modulus Validity period ending on or before 31 Dec 2013 1024 Validity period ending after 31 Dec 2013 2048 From Peter: A 1024-bit cert will always work with FF 24, for example. It may or may not work on version 30. If a cert holder is ok with that, I don't think there is really a problem. Correct. Mozilla policy and wiki pages say Under no circumstances should any party expect continued support for RSA key size smaller than 2048 bits past December 31, 2013 Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Exceptions to 1024-bit cert revocation requirement
The only criteria on the Webtrust BR audit (http://www.webtrust.org/homepage-documents/item27839.aspx) is section 11. Since the BRs will only apply to certificates issued since the last audit, and the MS policy prohibited issuance after Dec 2010, there shouldn't be many/any audits with a qualification because of non-revoked 1024 bit certs. -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Jeremy Rowley Sent: Wednesday, December 11, 2013 6:01 PM To: 'Rob Stradling'; 'Kathleen Wilson'; mozilla-dev-security-pol...@lists.mozilla.org Subject: RE: Exceptions to 1024-bit cert revocation requirement The requirement is from Mozilla's policy, not the BRs: https://wiki.mozilla.org/CA:MD5and1024 Note that the Microsoft policy doesn't require revocation. Instead, they required all CAs to stop issuing 1024 bit certs as of Dec 31, 2010 (http://technet.microsoft.com/en-us/library/cc751157.aspx). The certificates are expiring naturally. Jeremy -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digicert.com@lists.mozilla .org] On Behalf Of Rob Stradling Sent: Wednesday, December 11, 2013 5:44 PM To: Kathleen Wilson; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Exceptions to 1024-bit cert revocation requirement On 12/12/13 00:25, Kathleen Wilson wrote: snip From Rob: Kathleen, are you saying that must expire by the end of 2013 is a revocation requirement ? Expiration != Revocation. Is there actually a requirement that says By the end of 2013, CAs MUST revoke all unexpired certificates with 2048-bit RSA keys ? If so, where is it written and when was it communicated to the CAs? (If it's not actually written anywhere, then can you actually enforce it?) In BR Appendix A Subscriber Certificates Minimum RSA modulus Validity period ending on or before 31 Dec 2013 1024 Validity period ending after 31 Dec 2013 2048 Sure, and BRs Section 13.1.5 says: The CA SHALL revoke a (Subscriber) Certificate within 24 hours if ... 9. The CA is made aware that the Certificate was not issued in accordance with these Requirements... Sorry, I should have mentioned that I'm thinking primarily about long-lived certificates that were issued before the BRs became effective. BRs Section 1 says: Except where explicitly stated otherwise, these requirements apply only to relevant events that occur on or after the Effective Date. Where is it written that 2048-bit certs that predate the BRs need to be revoked by end of 2013? -- 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 ___ 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
