Re: Modulus length (was Re: Draft CA information checklist)

Nelson B Bolyard wrote: > But one could imagine that we make use of them, and allow the values of > the CKA_END_DATE to be different from (earlier than) the notAfter date > in the related certificate. It's good to know that this is technically possible. But actually, I don't see this as a high pr

Re: Modulus length (was Re: Draft CA information checklist)

Gervase Markham wrote, On 2008-06-06 02:07: > Another option would be to make a (small? :-) modification to NSS to > allow us to store an expiry date which overrode the one in the > certificate. Not small, I think. But not infeasible. PKCS#11 does define attributes for certificate objects, na

Re: Modulus length (was Re: Draft CA information checklist)

At 12:54 PM -0700 6/6/08, Nelson B Bolyard wrote: >I recall a long discussion on this list in which certain people observed >(or opined) that the cert path validation algorithm defined in RFC 3280 >has the characteristics you describe above. That is, the claim was made >that RFC 3280's algorithm d

Re: Modulus length (was Re: Draft CA information checklist)

Kyle Hamilton wrote, On 2008-06-05 07:46: > I must also point out something: > > NSS (at least up until 2004 -- I don't know if this has been changed, > but the MoFo position espoused by I believe Nelson and Frank was that > it wouldn't change) doesn't rely on any of the X.509v3 certificate > fie

Re: Modulus length (was Re: Draft CA information checklist)

At 2:20 AM -0700 6/6/08, Kyle Hamilton wrote: >The NIST date and EV date are the dates when they should no longer be >used, not 'no longer admitted for use', unless I'm completely >misreading the table on page 66 of the NIST SP800-57. You are not misreading the table. That's a "do not use after" d

Re: Modulus length (was Re: Draft CA information checklist)

I wholeheartedly believe that placing an arbitrary policy limitation in general-purpose software is ill-advised at best and reason for the product to be dismissed out of consideration for any usage at worst. -Kyle H 2008/6/6 Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]>: > Rob Stradling: > > Anot

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling: Another option would be to make a (small? :-) modification to NSS to allow us to store an expiry date which overrode the one in the certificate. Good idea. That would be much less hassle (compared to my proposal) for both the CAs and Mozilla. Yes, that's perhaps a go

Re: Modulus length (was Re: Draft CA information checklist)

On Friday 06 June 2008 10:07:20 Gervase Markham wrote: > Nelson B Bolyard wrote: > > Rob, in the past, any time that we have suggested that a CA issue a new > > root CA cert for any reason, even if only to change something minor, > > we've received much feedback saying that doing so represents a hu

Re: Modulus length (was Re: Draft CA information checklist)

Gervase Markham: Rob Stradling wrote: FYI, Microsoft already require a minimum 2048-bit RSA key size for new Root Certificate submissions. Then we might want to implement the same policy, with an exception (for compatibility reasons) for roots which already have a signficant degree o

Re: Modulus length (was Re: Draft CA information checklist)

The NIST date and EV date are the dates when they should no longer be used, not 'no longer admitted for use', unless I'm completely misreading the table on page 66 of the NIST SP800-57. I'm all for much more immediate cessation of adding new roots into the browser of 1024 bits, simply because as a

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling wrote: > FYI, Microsoft already require a minimum 2048-bit RSA key size for new Root > Certificate submissions. Then we might want to implement the same policy, with an exception (for compatibility reasons) for roots which already have a signficant degree of deployment but which, fo

Re: Modulus length (was Re: Draft CA information checklist)

Kyle Hamilton wrote: > There has been evidence of Microsoft, at the least, following this > group and acting on good ideas that started here. We do talk to each other, you know :-) > January 1 2009 particularly because it provides slightly less than 2 > quarters of notice. Indeed. Which does

Re: Modulus length (was Re: Draft CA information checklist)

Nelson B Bolyard wrote: > Rob, in the past, any time that we have suggested that a CA issue a new > root CA cert for any reason, even if only to change something minor, > we've received much feedback saying that doing so represents a huge > challenge and investment for the CAs, necessitating modifi

Re: Modulus length (was Re: Draft CA information checklist)

On Thursday 05 June 2008 15:46:54 Kyle Hamilton wrote: > I must also point out something: > > NSS (at least up until 2004 -- I don't know if this has been changed, > but the MoFo position espoused by I believe Nelson and Frank was that > it wouldn't change) doesn't rely on any of the X.509v3 certif

Re: Modulus length (was Re: Draft CA information checklist)

I must also point out something: NSS (at least up until 2004 -- I don't know if this has been changed, but the MoFo position espoused by I believe Nelson and Frank was that it wouldn't change) doesn't rely on any of the X.509v3 certificate fields of embedded trust anchors when figuring out whether

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling: Sorry Rob, yes I missed that one. But why doing that? Why not replace with something better and remove the "offending" root? Perhaps I'm not objective enough because we actually replaced a small key with a bigger one. What's the logic for having a pile of roots which expire in 2010

Re: Modulus length (was Re: Draft CA information checklist)

On Thursday 05 June 2008 12:59:13 Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > >> Additionally, most of the times the old and the new root will be both > >> present in NSS for some time in order to allow a smooth transition, > >> until the old root is being removed. > > > > Eddy, I think you

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling: Additionally, most of the times the old and the new root will be both present in NSS for some time in order to allow a smooth transition, until the old root is being removed. Eddy, I think you've missed the main point of my proposal. I am suggesting that each existing valid-for-

Re: Modulus length (was Re: Draft CA information checklist)

On Thursday 05 June 2008 12:05:42 Eddy Nigg (StartCom Ltd.) wrote: > Rob Stradling: > >> Rob, in the past, any time that we have suggested that a CA issue a new > >> root CA cert for any reason, even if only to change something minor, > >> we've received much feedback saying that doing so represent

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling: Rob, in the past, any time that we have suggested that a CA issue a new root CA cert for any reason, even if only to change something minor, we've received much feedback saying that doing so represents a huge challenge and investment for the CAs, necessitating modifications to CPSe

Re: Modulus length (was Re: Draft CA information checklist)

On Wednesday 04 June 2008 21:59:54 Paul Hoffman wrote: > > ... > > - There may be some (solvable, I think) interoperability problems for > > CAs that choose to include the "authorityCertSerialNumber" field in the > > Authority Key Identifier extension of certificates issued by their > > 1024-bit

Re: Modulus length (was Re: Draft CA information checklist)

On Wednesday 04 June 2008 21:32:17 Nelson B Bolyard wrote: > Rob Stradling wrote, On 2008-06-04 04:45: > > 2. Give each affected CA the opportunity to submit a replacement > > 1024-bit RSA Root Certificate for inclusion in new versions of Mozilla > > software. Each of these replacement Root Cert

Re: Modulus length (was Re: Draft CA information checklist)

At 12:45 PM +0100 6/4/08, Rob Stradling wrote: >For those 1024-bit RSA Root Certificates that are *already included* in >Mozilla software, I think that a distinction should be drawn between: > A. Those that expire before NIST's 2010 deadline. > B. Those that expire soon after 2010. > C. Those

Re: Modulus length (was Re: Draft CA information checklist)

At 10:14 AM +0100 6/4/08, Gervase Markham wrote: >Paul Hoffman wrote: >> Proposal: >> a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256 >> bit EC. > >Why January 1 2009 particularly? No big reason. It gives us six months to agree. If we take longer, just add months to th

Re: Modulus length (was Re: Draft CA information checklist)

Rob Stradling wrote, On 2008-06-04 04:45: > 2. Give each affected CA the opportunity to submit a replacement 1024-bit > RSA Root Certificate for inclusion in new versions of Mozilla software. Each > of these replacement Root Certificates would exactly match the to-be-removed > Root Certific

Re: Modulus length (was Re: Draft CA information checklist)

Kyle Hamilton wrote: > I do know that some Cisco VPN equipment doesn't like 4096-bit root > keys. Yupp. > I don't know if it likes 2048-bit keys. It works with 2048-bit keys. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozill

Re: Modulus length (was Re: Draft CA information checklist)

Kyle Hamilton: however, I do know that some Cisco VPN equipment doesn't like 4096-bit root keys. I don't know if it likes 2048-bit keys. Regarding Cisco routers, even though it's a known problem, I think the newer updates provide support for bigger keys. Considering that Cisco also wants

Re: Modulus length (was Re: Draft CA information checklist)

On Wednesday 04 June 2008 12:25:32 Kyle Hamilton wrote: > There has been evidence of Microsoft, at the least, following this > group and acting on good ideas that started here. While it'd be nice > if that organization would comment here, I think that if they like > this plan (or anything like thi

Re: Modulus length (was Re: Draft CA information checklist)

Kyle Hamilton: There has been evidence of Microsoft, at the least, following this group and acting on good ideas that started here. While it'd be nice if that organization would comment here, I think that if they like this plan (or anything like this plan) they'll implement it and it'll end up b

Re: Modulus length (was Re: Draft CA information checklist)

On Tuesday 03 June 2008 07:28:33 Michael Ströder wrote: > Eddy Nigg (StartCom Ltd.) wrote: > > Paul, I think that the general idea (of Frank and others) is, to make a > > requirement on new roots and act on the 1024 bit keys at some point in > > the future. > > I also support the idea of throwing o

Re: Modulus length (was Re: Draft CA information checklist)

There has been evidence of Microsoft, at the least, following this group and acting on good ideas that started here. While it'd be nice if that organization would comment here, I think that if they like this plan (or anything like this plan) they'll implement it and it'll end up being a fait accom

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > Proposal: > a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256 > bit EC. Why January 1 2009 particularly? By new, do you mean newly-generated, or new to us? Has any CA actually attempted to get a recently-generated 1024-bit root included? > b) Startin

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > I was arguing that people > who have weak locks on their doors should not bothering upgrading some > of the weak locks until they upgrade all of them. That's right strictly from the security perspective. But that requires that you have all locks under your control and you

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > > Let's talk specifics. Greatly appreciated. > The Verisign "Class 3 Public Primary Certification > Authority", which is widely used to create popular SSL certs on the > Internet (see ), has a 1024-bit RSA key and has > an expiration date of Aug

Re: Modulus length (was Re: Draft CA information checklist)

Eddy Nigg (StartCom Ltd.) wrote: > Paul, I think that the general idea (of Frank and others) is, to make a > requirement on new roots and act on the 1024 bit keys at some point in > the future. I also support the idea of throwing out 1024 bit keyed roots at a not so distant point in the future.

Re: Modulus length (was Re: Draft CA information checklist)

At 1:53 PM -0400 6/2/08, Frank Hecker wrote: > > BTW, I would flag *all* ECC certs with "Cause for further checking" due >> to the very low amount of interop testing that has been done with them. >> Again, not to say "don't do this", just "we want to ask a few questions >> that might start a di

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > At 11:02 AM -0400 5/30/08, Frank Hecker wrote: >> I'd be glad to soften the language >> about "cause for concern", but I still want to flag 1024-bit roots as >> worthy of a further explanation. (E.g., is this a root created some time >> ago that is only now being proposed for

Re: Modulus length (was Re: Draft CA information checklist)

At 9:12 PM -0700 5/31/08, Kyle Hamilton wrote: >http://eprint.iacr.org/2007/205 is the most recent I can find. They >factored a number of greater than 1024 bits, published on May 31 2007. They factored a *special* number. The chance that someone would pick a Mersenne number as their key is as cl

Re: Modulus length (was Re: Draft CA information checklist)

http://eprint.iacr.org/2007/205 is the most recent I can find. They factored a number of greater than 1024 bits, published on May 31 2007. -Kyle H On Fri, May 30, 2008 at 1:31 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: > At 9:49 PM +0300 5/30/08, Eddy Nigg (StartCom Ltd.) wrote: >>Paul Hoffman:

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > Let's talk specifics. The Verisign "Class 3 Public Primary Certification > Authority", which is widely used to create popular SSL certs on the > Internet (see ), has a 1024-bit RSA key and has > an expiration date of Aug 1 23:59:59 2028. Yes, that's a

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman: There is a possibility that it doesn't exist. Such a result would be widely-referenced in the crypto community. Maybe it has been withdrawn aftera) or b) happened? There could be a few reasons for this... That is not what I said at all. I said that if Mallory derives

Re: Modulus length (was Re: Draft CA information checklist)

At 4:04 AM +0300 5/31/08, Eddy Nigg (StartCom Ltd.) wrote: >Paul Hoffman: >>OK, but an actual reference would be helpful. > >Yes, and it's obviously pretty bad from me not being able to back it >up. I tried to locate it and even went through mails I sent in 2006 >where I could have possibly menti

Re: Modulus length (was Re: Draft CA information checklist)

Eddy Nigg (StartCom Ltd.): If you know something we don't, it would be really useful to the whole Internet community to hear more. I will look for it somewhat more...it can't have disappeared like that... The only thing I found so far (and which isn't the one I was referring to) is http

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman: I write this all from memory because I can't find that article again. OK, but an actual reference would be helpful. Yes, and it's obviously pretty bad from me not being able to back it up. I tried to locate it and even went through mails I sent in 2006 where I could

Re: Modulus length (was Re: Draft CA information checklist)

At 9:49 PM +0300 5/30/08, Eddy Nigg (StartCom Ltd.) wrote: >Paul Hoffman: > >> >> >>Again, I strongly strongly doubt that Mallory will try to break a >>1024-bit key for this attack, at least for 20 years or more. >> >> > >I'm not sure from where you got this information RFC 3766, which is consider

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman: Again, I strongly strongly doubt that Mallory will try to break a 1024-bit key for this attack, at least for 20 years or more. I'm not sure from where you got this information, because apparently a group of people succeeded in cracking the key with 650 and something bytes a

Re: Modulus length (was Re: Draft CA information checklist)

At 10:15 AM -0700 5/30/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-05-30 07:17: > >> Adding strong locks to the front doors while the back doors still have >> weak locks is useless from a security standpoint. > >You seem to be arguing that no-one should bother to put locks on their >

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote, On 2008-05-30 07:17: > Adding strong locks to the front doors while the back doors still have > weak locks is useless from a security standpoint. You seem to be arguing that no-one should bother to put locks on their doors while there remain some people who have no locks on

Re: Modulus length (was Re: Draft CA information checklist)

At 11:02 AM -0400 5/30/08, Frank Hecker wrote: >I'd be glad to soften the language >about "cause for concern", but I still want to flag 1024-bit roots as >worthy of a further explanation. (E.g., is this a root created some time >ago that is only now being proposed for inclusion? Was/is the root >in

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > What does "is cause for concern" mean when the majority of the > certificates in our list are 1024 bits? (I think that is still true) As noted by others, the checklist is for new roots, not legacy roots. If we're going to have a gradual transition to 2048-bit modulus

Re: Modulus length (was Re: Draft CA information checklist)

At 9:45 PM -0700 5/29/08, Justin Dolske wrote: >Paul Hoffman wrote: > >> Unless Mozilla says "we are going to yank that particular Verisign >> certificate, and all the ones with similar key lengths, decades before >> they expire", there is absolutely no reason for us to, 20 years in >> advance,

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > Unless Mozilla says "we are going to yank that particular Verisign > certificate, and all the ones with similar key lengths, decades before > they expire", there is absolutely no reason for us to, 20 years in > advance, start requiring "new" CAs to use stronger keys. It is ju

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman: Proposal: a) Starting January 1 2009, all new CA roots must be 2048 bit RSA or 256 bit EC. b) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC. Dates and sizes can be argued, of course. I would argue against the date in (b) being more than five years after th

Re: Modulus length (was Re: Draft CA information checklist)

At 7:09 PM -0700 5/29/08, Justin Dolske wrote: >So? While it might not improve security *immediately*, It will not improve security for the foreseeable future (assuming that we take the expiration dates on some of the root certs at face value). > I don't see why a >gradual transition to strict

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman wrote: > Thus, if we have any > 1024-bit keys in the root pile (and we might still have ones > shorter...), requiring all new CA keys to be 2048 bits (for example) has > no effect on Mallory: he still attacks one of the current roots and gets > the exact same effect. So? While it mig

Re: Modulus length (was Re: Draft CA information checklist)

At 5:51 PM -0700 5/29/08, Wan-Teh Chang wrote: >It is reasonable to impose a stricter key size requirement on new root >CAs than the currently accepted root CAs. Why? (I mean that seriously.) The attack we are worried about is Mallory factoring the public key of any of the CAs in our root store

Re: Modulus length (was Re: Draft CA information checklist)

Paul Hoffman: Unless we want to put a lower limit on the key size used in our CA pile, saying that some (most!) of the ones we accept are "of concern" is confusing at best. Paul, I think that the general idea (of Frank and others) is, to make a requirement on new roots and act on the 1024 bi

Re: Modulus length (was Re: Draft CA information checklist)

It is reasonable to impose a stricter key size requirement on new root CAs than the currently accepted root CAs. Paul, are you questioning the stricter requirement for new root CAs, or would you like us to improve the language in the wiki? Wan-Teh ___ d

Re: Modulus length (was Re: Draft CA information checklist)

At 4:46 PM -0700 5/29/08, Nelson B Bolyard wrote: >In http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf >Nist publishes a table of equivalent crypto algorithm/key strengths. > >security Symmetric DSA,DHRSA ECDSA >bits algorithms > --

Re: Modulus length (was Re: Draft CA information checklist)

In http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf Nist publishes a table of equivalent crypto algorithm/key strengths. security Symmetric DSA,DHRSA ECDSA bits algorithms -- - -- - 80

Modulus length (was Re: Draft CA information checklist)

The wiki currently says: Modulus length. (The length of the RSA modulus for the root CA public and private keys. Note that although the Mozilla CA certificate policy does not specify a minimum modulus length, in practice a modulus length of less than 2048 bits is cause for concern.) [What is t