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 priority. We have more important things to worry about than people who are still using Firefox 4 in 2020. We can enforce whatever requirements we have on key lengths etc. using policy and cert. removals. We don't need a technical solution. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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, named CKA_START_DATE and CKA_END_DATE, which may be empty or may be an array of 8 bytes containing a string of the form MMDD. Note: date only, no time, and no time zone, so date is UTC. PKCS#11 says, of these attributes: When present, the application is responsible to set them to values that match the certificate’s encoded “not before” and “not after” fields (if any). Because these attributes are nominally empty, and when present, are defined to merely match the value in the cert itself, NSS makes no use of them. 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. The work would be in a) devising an NSS API to set them (maybe not necessary if we only do this for certs in the built-in read-only root CA certs token). b) propagating the value of these attributes, when not empty, into NSS's CERTCertificate structure, where they would be treated as if they were the actual notBefore and notAfter dates, superseding the values in the certs themselves. I imagine that there might be some confusion if people find that NSS is treating a cert as having a different expiration date than the date that actually appears in the certificate itself. Personally, I really would not want to have to answer those frequently asked questions. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 an operational matter it takes over a year and a half for requests to be evaluated anyway. -Kyle H On Fri, Jun 6, 2008 at 2:08 AM, Gervase Markham [EMAIL PROTECTED] wrote: 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 doesn't sound like very much to me. Picking 31st December 2010 would have the advantage of matching both the NIST date and the EV date. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 doesn't sound like very much to me. Picking 31st December 2010 would have the advantage of matching both the NIST date and the EV date. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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, for whatever reason, have not been submitted to us before. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 huge
challenge and investment for the CAs, necessitating modifications to
CPSes, triggering new audits, etc. etc. One gets the impression from
those replies that this is something the CAs would rather avoid at
(nearly) all cost.
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.
Or, instead of modifying the data that NSS holds for each certificate...
Yet another alternative option would be to make a modification to NSS's
certificate path processing code, so that whenever NSS is attempting to build
a certificate chain up to a trusted Root it would check:
- the current date/time.
- the key sizes of each certificate it is considering trusting.
- a hard-coded array of: { algorithm, key_size, soft_insecure_after_date,
hard_insecure_after_date }.
Whenever a key is found whose soft_insecure_after_date is in the past,
NSS/Firefox/etc would warn the user, but allow them to choose to navigate to
the HTTPS site if they really want to.
Whenever a key is found whose hard_insecure_after_date is in the past,
NSS/Firefox/etc would warn the user and refuse to allow them to navigate to
the HTTPS site.
I think it would make sense for the soft_insecure_after_dates to match
NIST's recommendations, but the hard_insecure_after_dates would be up to
Mozilla to define.
Also, the hard-coded array could be extended to define algorithm expiry
information for not only RSA key-sizes, but also...
- Hash algorithms used in signatures (e.g. NIST specify a 2010 deadline for
SHA-1; and I think MD2/4/5 and SHA-0 should already be deemed to have passed
their soft_insecure_after_date).
- ECC key-sizes and curves.
- Symmetric algorithms used in SSL cipher suites.
NSS could check all of these during certificate path processing and SSL/TLS
handshakes.
With this approach, Mozilla could even continue to accept new 1024-bit Root
Certificate submissions for the next few years (not that I'm advocating that,
of course!)
Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
--
Rob Stradling
Senior Research Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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 good thing to have anyway! Whenever a key is found whose soft_insecure_after_date is in the past, NSS/Firefox/etc would warn the user, but allow them to choose to navigate to the HTTPS site if they really want to. Whenever a key is found whose hard_insecure_after_date is in the past, NSS/Firefox/etc would warn the user and refuse to allow them to navigate to the HTTPS site. We need to make sure that this wouldn't affect other products, mainly Thunderbird. But also for web sites I'm not sure how good that would be (the hard fail), just imagine the hosting panel uses a certificate of an affected key and now the poor guy can't even get in there changing the certificate. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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: 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 good thing to have anyway! Whenever a key is found whose soft_insecure_after_date is in the past, NSS/Firefox/etc would warn the user, but allow them to choose to navigate to the HTTPS site if they really want to. Whenever a key is found whose hard_insecure_after_date is in the past, NSS/Firefox/etc would warn the user and refuse to allow them to navigate to the HTTPS site. We need to make sure that this wouldn't affect other products, mainly Thunderbird. But also for web sites I'm not sure how good that would be (the hard fail), just imagine the hosting panel uses a certificate of an affected key and now the poor guy can't even get in there changing the certificate. Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: Join the Revolution! Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 date. It's the same date NIST says you're supposed to stop using SHA-1. If we have any desire to have Mozilla and/or Thunderbird achieve FIPS 140 compliance, users are going to need to stop using these certs anyhow. See NIST SP 800-113. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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
fields of embedded trust anchors when figuring out whether to extend
trust.
The statement that NSS ... doesn't rely on *any* of the X.509v3 certificate
fields of embedded trust anchors when figuring out whether to extend
trust just isn't true, and never has been. I don't recall absolutely
everything I've ever written on the subject, but I'm pretty certain I
would not have written something about it that I knew to be untrue.
However, if you replace any with some in that statement, it is true.
In NSS, certs may be marked as trust anchors for particular usages (EKUs).
In all versions of NSS up through NSS 3.11.x, marking a certificate as a
trust anchor for a particular EKU causes SOME aspects of the cert itself to
be overridden when checking a chain's validity for that usage. These
include:
- The signature on the trust anchor cert is ignored.
- The absence of a Basic Constraints extension is treated as if the
extension was present and shows that the cert is a CA and that the path
length is unlimited. However, if the Basic Constraints extension is
present, its values are honored as-is. A cert whose basic constraints
extension is present and says it is NOT a CA certificate cannot be a trust
anchor even if marked as such.
- These extensions are ignored (overridden) in the marked trust anchor cert
- Key Usage (KU)
- Extended Key Usage (EKU)
- Name Constraints
That is, trust anchors are valid for all key usages and for all name
spaces, for the Extended Key Usage (or usages) for which it was marked
trusted.
Thus, changing it won't have any practical value anyway.
By it, I believe you are referring to the expiration date of the cert.
The Validity Period of a cert is never overridden.
(The argument was that X.509 makes a good container format for
distributing trust anchors -- the public keys -- along with display
metadata, but that the trust anchor itself could be distributed
separately from the X.509 container and thus should not be subject to
any policy statements included in that container. Which didn't make
any sense to me at the time, and still doesn't -- since that container
is signed by that key anyway, and I would expect it to adhere to the
CPS espoused by that key -- but that's how it was explained.)
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 does not require a trust anchor to be anything
more than a public key, and does not impose any checks on it for validity
dates, key usages, extended keys usages, name constraints, etc. etc.
In other words, the claim was that RFC 3280 considers a trust anchor to
be absolutely trusted in all respects for all purposes at all times.
(Put another way, the criteria for selection of a trust anchor are outside
the scope of the algorithms defined in RFC 3280, and any such criteria
have already been applied to the trust anchor before the algorithm defined
in RFC 3280 begins.)
The above views were used as the basis for a claim that the scheme used
in Mozilla (and other products) of having multiple self-signed CA certs
and using them all as trust anchors was non-conformant to the RFC. One
writer seemed to believe that, to conform to the RFC, it would be
necessary for the mozilla clients to have a single trust anchor key, and
for Mozilla (or its clients) to actually issue certificates,
cross-certifying the {subject name, key} pairs that appear in the root
certificates that Mozilla clients now mark as individual trust anchors
with trust flags.
I recall writing that the scheme that NSS now uses, with a set of root CA
certs marked with trust flags, is equivalent to the cross-certification
scheme that the writer wanted, and that the RFC allows any scheme that is
equivalent and produces the same results. I gather that the writer did
not accept that claim of equivalence, but never explained why.
/Nelson
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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 does not require a trust anchor to be anything more than a public key, and does not impose any checks on it for validity dates, key usages, extended keys usages, name constraints, etc. etc. This is correct, I opine. In other words, the claim was that RFC 3280 considers a trust anchor to be absolutely trusted in all respects for all purposes at all times. These other words are not correct, I opine. RFC 3280, and now RFC 5280, explicitly allow for limits on the trust, such as name constraints. (Put another way, the criteria for selection of a trust anchor are outside the scope of the algorithms defined in RFC 3280, and any such criteria have already been applied to the trust anchor before the algorithm defined in RFC 3280 begins.) Also, not correct, I opine. What I believe 3280/5280 say is that the metadata in the trust anchor certificate itself are not themselves part of the path processing. Instead, a trust anchor has metadata that the process doing the path processing assigns to the trust anchor. That could come from metadata that is in the cert (if it is a cert), or it can be outside. The fact that a trust anchor might be loaded in the form of a certificate is not inherently interesting to path processing. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 Root Certificates. Not sure what you mean here. Please see the follow-up comments from myself and Nelson. I hope they explain this issue enough. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? Definitely worth considering. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 CPSes, triggering new audits, etc. etc. One gets the impression from those replies that this is something the CAs would rather avoid at (nearly) all cost. I'm not convinced a new audit would be required, and I don't think CPS changes are quite as expensive as the CAs you cite have suggested. Yes, I agree with you. I suppose that this is part of the key management a CA performs, which in itself is audited. Issuing new keys according to the defined procedures and CP/CPS doesn't require re-auditing per se, perhaps only if there were substantial other changes to the infrastructure which aren't related to the mere issuing of additional keys. Also...just a thought...I wonder if any part of the Mozilla CA Certificate Policy could be updated to make 1024-bit Root Certificate replacement less hassle? I don't agree however with this. CAs usually have to go through the full cycle for having roots included and we shouldn't make other exceptions. The EV inclusions were exceptionally rushed enough I'd say...Also it's an excellent opportunity to review CAs which sometimes never were really looked at. 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. On a kind-of-related note... Bug 406794. GlobalSign want to do something very similar No, this isn't the same really, it's not a new key per se. Could that behaviour of NSS be changed? If future NSS versions were to treat authorityCertSerialNumber as merely a hint, then I don't think that any certs would need to be reissued for my proposal to work. Mhhh, maybe I'm missing something here, but how should replacing a root with a different key and key size not have an effect on this? Certs will have to be issued from the new root at some point and I'm not sure how a certificate signed from a 1024 bit key doesn't require re-issuance from a new 2048 key if the old key becomes obsolete and the EE cert is still valid. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 represents a huge challenge and investment for the CAs, necessitating modifications to CPSes, triggering new audits, etc. etc. One gets the impression from those replies that this is something the CAs would rather avoid at (nearly) all cost. I'm not convinced a new audit would be required, and I don't think CPS changes are quite as expensive as the CAs you cite have suggested. Yes, I agree with you. I suppose that this is part of the key management a CA performs, which in itself is audited. Issuing new keys according to the defined procedures and CP/CPS doesn't require re-auditing per se, perhaps only if there were substantial other changes to the infrastructure which aren't related to the mere issuing of additional keys. Also...just a thought...I wonder if any part of the Mozilla CA Certificate Policy could be updated to make 1024-bit Root Certificate replacement less hassle? I don't agree however with this. CAs usually have to go through the full cycle for having roots included and we shouldn't make other exceptions. The EV inclusions were exceptionally rushed enough I'd say...Also it's an excellent opportunity to review CAs which sometimes never were really looked at. I have no objection to Mozilla reviewing CAs which sometimes never were really looked at in days gone by. :-) 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. Not so. With my proposal, the old and new roots would *not* both be present in any NSS versions. The old one would be removed when the new one gets added. Eddy, I think you've missed the main point of my proposal. I am suggesting that each existing valid-for-too-long 1024-bit RSA Root Certificate should be replaced with a valid-for-not-too-far-beyond-2010 1024-bit RSA Root Certificates *WITH THE SAME KEY*. On a kind-of-related note... Bug 406794. GlobalSign want to do something very similar No, this isn't the same really, it's not a new key per se. Precisely. So, as I said, it is the same thing. Could that behaviour of NSS be changed? If future NSS versions were to treat authorityCertSerialNumber as merely a hint, then I don't think that any certs would need to be reissued for my proposal to work. Mhhh, maybe I'm missing something here, but how should replacing a root with a different key and key size not have an effect on this? Certs will have to be issued from the new root at some point and I'm not sure how a certificate signed from a 1024 bit key doesn't require re-issuance from a new 2048 key if the old key becomes obsolete and the EE cert is still valid. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone:+1.213.341.0390 -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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've missed the main point of my proposal. I am
suggesting that each existing valid-for-too-long 1024-bit RSA Root
Certificate should be replaced with a valid-for-not-too-far-beyond-2010
1024-bit RSA Root Certificates *WITH THE SAME KEY*.
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?
I didn't say expire in 2010.
Sorry for being slow...can you explain to me the logic of your proposal
(again)?
I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.
If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).
But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
I believe that my proposal solves both problems. The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on. And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.
Regards
Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org
Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED]
Blog: Join the Revolution! http://blog.startcom.org
Phone:+1.213.341.0390
--
Rob Stradling
Senior Research Development Scientist
Comodo - Creating Trust Online
Office Tel: +44.(0)1274.730505
Fax Europe: +44.(0)1274.730909
www.comodo.com
Comodo CA Limited, Registered in England No. 04058690
Registered Office:
3rd Floor, 26 Office Village, Exchange Quay,
Trafford Road, Salford, Manchester M5 3EQ
This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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?
I didn't say expire in 2010.
You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little
bit for clarity...
I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.
Correct.
If we were to remove any 1024-bit RSA Root Certificates from Mozilla today, it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).
Also correct.
But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
Update rates are apparently not so bad, but supposed CAs would replace
their keys with new and bigger ones, having a target date, when the old
roots will be removed, they would make sure that subscribers are using
certificates issued by a new root.
I believe that my proposal solves both problems. The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on.
Well, I think you are introducing an extra step here. Supposed that CAs
indeed would agree to re-issue their current 1024 and smaller keys with
a expiration date at some time around 2010, those CAs will most likely
also want to have a new root with a bigger key size ready from which
they'll want to issue certificates. Because the old root wouldn't be
valid anymore in 2010, they really would be at a disadvantage because
they won't have enough time to transition to a newer one.
Now, in practical terms such a process and transition takes about three
years from the moment the new root is created, submitted for inclusion,
starting to issue from the new root and make the old root obsolete. One
must take into account at least a one year transition period for the EE
certs which are still valid (there are some rumors that some CAs issue
certs with a validity of 10 years, so they would have to get new certs
anyway during that time ;-) ) and CRLs still must be issued from that
root until the lasts certificate expires or is revoked.
With your proposal, CAs would have first to change their 1024 bit keys
to an earlier expiration date, then obviously request to add a new root
anyway. I wouldn't want to be in the situation to have a root with
validity to only 2010 (or valid-for-not-too-far-beyond) without a
acceptable replacement and time to transition.
And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.
Keep in mind that the ones which usually don't update their browser will
also miss the changed 1024 bit keys with the shorter validity, hence I
think the gain would be rather minimal. Therefore I think the plan
suggested from Paul more realistic in every respect and 2012, maybe 2013
sounds to me doable and still within the time frame of such keys not
being a risk yet.
Regards
Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org
Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED]
Blog: Join the Revolution! http://blog.startcom.org
Phone: +1.213.341.0390
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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 to extend
trust. Thus, changing it won't have any practical value anyway.
(The argument was that X.509 makes a good container format for
distributing trust anchors -- the public keys -- along with display
metadata, but that the trust anchor itself could be distributed
separately from the X.509 container and thus should not be subject to
any policy statements included in that container. Which didn't make
any sense to me at the time, and still doesn't -- since that container
is signed by that key anyway, and I would expect it to adhere to the
CPS espoused by that key -- but that's how it was explained.)
-Kyle H
2008/6/5 Eddy Nigg (StartCom Ltd.) [EMAIL PROTECTED]:
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?
I didn't say expire in 2010.
You said valid-for-not-too-far-beyond-2010 :-) I shortened that a little bit
for clarity...
I think the key issue is that we don't want users of Mozilla software to be
relying on 1024-bit RSA Root Keys too far beyond 2010.
Correct.
If we were to remove any 1024-bit RSA Root Certificates from Mozilla today,
it
would be damaging to the CAs (who rely on the good browser ubiquity provided
by these Roots).
Also correct.
But, if we instead wait until, say, 2013 to remove those Root Certificates
from NSS, some users would still be relying on those 1024-bit Root Keys
until
nearer 2020 ('cos some users are *very* slow to upgrade their browsers).
Update rates are apparently not so bad, but supposed CAs would replace their
keys with new and bigger ones, having a target date, when the old roots will
be removed, they would make sure that subscribers are using certificates
issued by a new root.
I believe that my proposal solves both problems. The CAs' browser ubiquity
would not be damaged until such time that Mozilla decides the 1024-bit Keys
should be no longer be relied on.
Well, I think you are introducing an extra step here. Supposed that CAs
indeed would agree to re-issue their current 1024 and smaller keys with a
expiration date at some time around 2010, those CAs will most likely also
want to have a new root with a bigger key size ready from which they'll want
to issue certificates. Because the old root wouldn't be valid anymore in
2010, they really would be at a disadvantage because they won't have enough
time to transition to a newer one.
Now, in practical terms such a process and transition takes about three
years from the moment the new root is created, submitted for inclusion,
starting to issue from the new root and make the old root obsolete. One must
take into account at least a one year transition period for the EE certs
which are still valid (there are some rumors that some CAs issue certs with
a validity of 10 years, so they would have to get new certs anyway during
that time ;-) ) and CRLs still must be issued from that root until the lasts
certificate expires or is revoked.
With your proposal, CAs would have first to change their 1024 bit keys to an
earlier expiration date, then obviously request to add a new root anyway. I
wouldn't want to be in the situation to have a root with validity to only
2010 (or valid-for-not-too-far-beyond) without a acceptable replacement and
time to transition.
And in the future, Mozilla users (even
with...at that point in time...fairly out-of-date software) would be
prevented from relying on 1024-bit RSA Root Keys as soon as the date decided
by Mozilla arrives.
Keep in mind that the ones which usually don't update their browser will
also miss the changed 1024 bit keys with the shorter validity, hence I think
the gain would be rather minimal. Therefore I think the plan suggested from
Paul more realistic in every respect and 2012, maybe 2013 sounds to me
doable and still within the time frame of such keys not being a risk yet.
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: [EMAIL PROTECTED]
Blog: Join the Revolution!
Phone: +1.213.341.0390
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
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 accompli. January 1 2009 particularly because it provides slightly less than 2 quarters of notice. Honestly, I would be quite happy if it went into effect immediately; 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. I would treat 'new' as 'new request'. And I don't know if anyone's tried to submit a 1024-bit root recently. -Kyle H On Wed, Jun 4, 2008 at 2:14 AM, Gervase Markham [EMAIL PROTECTED] 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? 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) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC. It would make most sense to coordinate such a policy with other browser vendors, if possible. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 out 1024 bit keyed roots at a not so distant point in the future. 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 that expire well beyond 2010. For now, let soon after = before 2013 and well beyond = after 2013. I think that type A and B Root Certificates can be left to expire naturally before being removed from future versions of Mozilla software. I have a suggestion regarding what Mozilla could do *right now* with type C Root Certificates... 1. Remove each type C Root Certificate from Mozilla ASAP, but also... 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 Certificate (in terms of Subject name, Public Key and Subject Key Identifier), but would have a different Serial Number and a more acceptable Not After date. Advantages: + Mozilla would be able to prevent the reliance on 1024-bit RSA Root CA Keys according to a time schedule set by Mozilla. + This prevention time schedule would take effect ASAP. There would be no need to wait until 2013 to remove type C Root Certificates from Mozilla, which means that... + Versions of Mozilla software published between ASAP and 2013 would not trust any 1024-bit RSA Root Keys beyond 2013. (I think that, come 2013, we can expect some users to be using old versions of Mozilla software). Disadvantages: - Each affected CA would have to spend some time reissuing their Root Cetificate. - Mozilla representatives would have to spend some time checking the replacement certificates and writing patches to remove/include the original/replacement certificates. - 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 Root Certificates. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? I also hope that this will sort out some of the issues with root CA certs concerning so-called cross-signing and liberal use of sub CAs. are issued from that root since we've successfully transitioned to the newer 4096 bit root. FYI: A VPN product of a major vendor simply does not work with 4096 bit root. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 being a fait accompli. January 1 2009 particularly because it provides slightly less than 2 quarters of notice. Honestly, I would be quite happy if it went into effect immediately; 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. I would treat 'new' as 'new request'. And I don't know if anyone's tried to submit a 1024-bit root recently. I'm not aware of it, nor if any such root is requested to be included. I'd suggest to bring that date forward, meaning it could be 1st of January 2007 or 2008. We don't have to wait for 2009 really. As a matter of fact, Microsoft has already such a requirement and didn't wait for Mozilla to offer this great idea ;-) From http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true section general requirements #4: we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. Funnily they contradict themselves at the sentence right after that: We prefer expire before the year 2030, especially if they have a 2048-bit RSA modulus. Maybe they meant to say that roots should expire before 2030 if the key is 2048 bit and not bigger than that. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 this plan) they'll implement it and it'll end up being a fait accompli. FYI, Microsoft already require a minimum 2048-bit RSA key size for new Root Certificate submissions. http://www.microsoft.com/technet/archive/security/news/rootcert.mspx?mfr=true says... Updated: January 22, 2008 ... 4. Root certificates must comply with the Technical Requirements section below. In particular, we require a minimum crypto key size of RSA 2048-bit modulus for any root and all issuing CAs. Microsoft will no longer accept root certificates with RSA 1024-bit modulus of any expiration. We prefer that new roots are valid for at least 8 years from date of submission but expire before the year 2030, especially if they have a 2048-bit RSA modulus. January 1 2009 particularly because it provides slightly less than 2 quarters of notice. Honestly, I would be quite happy if it went into effect immediately; 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. I would treat 'new' as 'new request'. And I don't know if anyone's tried to submit a 1024-bit root recently. -Kyle H On Wed, Jun 4, 2008 at 2:14 AM, Gervase Markham [EMAIL PROTECTED] 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? 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) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC. It would make most sense to coordinate such a policy with other browser vendors, if possible. Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto -- Rob Stradling Senior Research Development Scientist Comodo - Creating Trust Online Office Tel: +44.(0)1274.730505 Fax Europe: +44.(0)1274.730909 www.comodo.com Comodo CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by Comodo for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 to be a CA and uses a 2048 bit key, I except support for at least that key size. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 Certificate (in terms of Subject name, Public Key and Subject Key Identifier), but would have a different Serial Number and a more acceptable Not After date. That plan appeals to me. Disadvantages: - Each affected CA would have to spend some time reissuing their Root Cetificate. 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 CPSes, triggering new audits, etc. etc. One gets the impression from those replies that this is something the CAs would rather avoid at (nearly) all cost. - 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 Root Certificates. Yes, that's also an issue. NSS treats AKID extensions as requirements. When the issuer says to the relying party, through an AKID extension, you must rely on the issuer cert with this issuer name and serial number NSS does so. I'm afraid the solution, for CAs that used that field, may be for them to reissue certs with the offending AKID extension. We keep telling CAs NOT to include the part of an AKID that names the issuer's issuer and the issuer's serial number, but many CAs keep on doing it anyway. The OpenSSL programs that create certs do that by default, IINM, requiring extra work (I gather) to avoid including that info in the AKID. I have suspected for some time now that the reason CAs keep including that info is because they haven't figured out how to stop the OpenSSL program from doing so. :( ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 the date. By new, do you mean newly-generated, or new to us? New to use. It truly doesn't matter when the certs are generated. Has any CA actually attempted to get a recently-generated 1024-bit root included? Dunno, but it doesn't really matter. b) Starting January 1 2014, all CA roots must be 2048 bit RSA or 256 bit EC. It would make most sense to coordinate such a policy with other browser vendors, if possible. Sure, but we could also be the leaders. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 that expire well beyond 2010. . . . I have a suggestion regarding what Mozilla could do *right now* with type C Root Certificates... 1. Remove each type C Root Certificate from Mozilla ASAP, but also... 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 Certificate (in terms of Subject name, Public Key and Subject Key Identifier), but would have a different Serial Number and a more acceptable Not After date. This sounds like an interesting proposal. Advantages: + Mozilla would be able to prevent the reliance on 1024-bit RSA Root CA Keys according to a time schedule set by Mozilla. + This prevention time schedule would take effect ASAP. There would be no need to wait until 2013 to remove type C Root Certificates from Mozilla, which means that... + Versions of Mozilla software published between ASAP and 2013 would not trust any 1024-bit RSA Root Keys beyond 2013. (I think that, come 2013, we can expect some users to be using old versions of Mozilla software). Disadvantages: - Each affected CA would have to spend some time reissuing their Root Cetificate. It is a trivial amount of work relative to getting a new audit for a new CP and/or CPS. - Mozilla representatives would have to spend some time checking the replacement certificates and writing patches to remove/include the original/replacement certificates. True. Possibly worth it. - 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 Root Certificates. Not sure what you mean here. Am I trying to make things too complicated? Or does anybody think that this idea is worth considering? Definitely worth considering. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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. I also hope that this will sort out some of the issues with root CA certs concerning so-called cross-signing and liberal use of sub CAs. are issued from that root since we've successfully transitioned to the newer 4096 bit root. FYI: A VPN product of a major vendor simply does not work with 4096 bit root. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 https://www.amazon.com/), has a 1024-bit RSA key and has an expiration date of Aug 1 23:59:59 2028. Yes, that's a bit over 20 years from now. 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 just not justified. But probably new CAs have an even later expiration date. If we want to ramp up the mandatory key sizes, we need to also simultaneously promise to pull out all CAs that don't meet those sizes at a reasonable time. Otherwise, we are just pretending to be helping. Yupp. 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. I'm fine with that. Maybe one could extend a) that 1024-bit keyed CA roots should not have an expiry date later than 2013-12-31. That would make the issue clear to CAs. If we adopt such a proposal, but later start to waver on (b), we immediately admit that (a) is silly from a security perspective. But it's not silly from a practical migration perspective. It does make sense for CAs. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 can freely choose to change them all at a time. Obviously that's not the case for the pre-installed root CA certs. Ciao, Michael. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 inclusion? Was/is the root intended for use in low-end devices where performance was deemed an issue? Did the CA not think about the issue of modulus length at all? And so on.) Ah! That sounds reasonable. Cause for further checking covers that without making it seem that we're concerned just about the length. I made a change to the wiki page to reflect my previous comments. 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 dialog. I haven't made a change for this yet. I think I need a separate questions relating to the public key scheme used; that would be an appropriate place to discuss this. Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 the private from a single CA, he gets the same power as all CAs, namely to mint certificates for whomever he wants. That has nothing to do with the whole pile of roots: just the opposite. Oh well, that's what I meant more or less... It's nevertheless interesting, considering that they used some 10,000 PCs and today's botnets comprise usually of many, many more compromised computers (some sources say up to a million). Sure, if you ignore the sieving requirements. Probably very few botnets exist where each of the machines has128 gigabytes of RAM; Which it itself is relaxing, however that will change in few years to come I guess. Remember when we used to pay a fortune just to get another 32MB of EDO RAM? Today we buy 8 GB sticks for a mere few hundred bucks or so, which tomorrow will be 64 GB and/or even part of the CPU...I guess that hurdle will be reached rather fast. ...which has not been done yet, at least in public. The largest is still 528 bits, I believe. Which reference? It's interesting to know about... Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 https://www.amazon.com/), has a 1024-bit RSA key and has an expiration date of Aug 1 23:59:59 2028. Yes, that's a bit over 20 years from now. That is correct; however, the CAs are not unaware of the NIST guidelines on key length. I suspect that these 1024-bit roots will be deprecated and eventually removed long before 2028. For example, the EV guidelines state that no certificate with less than 2048-bit keys may be used in an EV certificate chain after 31st December 2010, which I believe was chosen because it's the end of the recommended time for stopping using 1024-bit keys set by NIST. (Page 70 in guidelines v1.1) Gerv ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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, start requiring new CAs to use stronger keys. It is just not justified. I don't think it's nearly that black-and-white. Changing existing roots is a high-cost, long-lead process; raising the bar on new roots is cheap and fast. I don't understand why the two are incompatible, nor why progress should be gated upon perfection. See http://en.wikipedia.org/wiki/Security_theater. Adding strong locks to the front doors while the back doors still have weak locks is useless from a security standpoint. Are new CAs objecting to the use of stronger certs? Probably not, but why is that relevant? Mallory will always attack the weakest part of the system. Proposal: [...] A three-phase migration might be a bit more orderly: 1) short-term: raise bar on new CAs 2) mid-term: get existing CAs to switch to stronger roots 3) long-term: remove weak roots. #2 helps mitigate the impact of #3 on end-users, lest something force the issue sooner than desired. I see no difference between your list and mine other than terminology. If a significant browser like Firefox says that in five years, all CA roots have to be 2048 bits, that fact will get existing CAs to switch to stronger roots. BTW, 1024 bit roots are not weak. Even a decade from now, it will be incredibly expensive to break a 1024 bit RSA key, and the payback for doing so on a CA root will be very low because it is relatively easy to revoke a broken root in popular browsers. I predict that it would cost Mallory much less to simply set up a CA today, go through the audits and so on, and then lay low until he wants to attack. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 length for RSA keys, I think it's legitimate to question why a CA is applying to have a 1024-bit root included. 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 intended for use in low-end devices where performance was deemed an issue? Did the CA not think about the issue of modulus length at all? And so on.) As for having a formal schedule for transition (i.e., not accepting new 1024-bit roots after a certain date), I think that's a good idea. As for the ECC question: 256 bits is equivalent to 128 bits of symmetric strength, as in AES-128. Thanks! Frank -- Frank Hecker [EMAIL PROTECTED] ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 intended for use in low-end devices where performance was deemed an issue? Did the CA not think about the issue of modulus length at all? And so on.) Ah! That sounds reasonable. Cause for further checking covers that without making it seem that we're concerned just about the length. 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 dialog. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 their doors. If we all lived in one house, and all our valuables were available to anyone who penetrated any door, that analogy would be apt. But the information that Mallory actually gets from successfully attacking a connection (opening a door) is not the same for all connections. The information going over various connections is compartmentalized, analogous to separate items of value in separate houses with separate doors with separate locks of various strengths. Mallory will always attack the weakest part of the system. There will always be people who refuse to take adequate security measures. They will always be fair game for Mallory. The success of locks on doors is measured by how well they protect those who wish to use them and who do deploy them. Off hand, I can't think of a good physical analogy to the strange world of crypto-based security, in which our locks get weaker over time. Because physical locks do not tend to get weaker with time, people are not accustomed to upgrading their locks with time. They tend to install one lock and forget it. Here in this thread we hear Mozilla community members vocalizing their desire to make the world aware of the need to strengthen their locks, and to help prod the lock makers in that direction. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 considered the best current practice for the IETF. I am the co-author of the document, and before being published, it was widely reviewed by cryptographers whose names you would recognize. , because apparently a group of people succeeded in cracking the key with 650 and something bytes already about two years ago with about 40 64bit AMD dual machines in four month time. Googling that is failing me. I write this all from memory because I can't find that article again. OK, but an actual reference would be helpful. I'm sure a big cluster of always getting stronger CPUs (dual, quad, oct cores) will able to to get on 1024 bit keys in an ever shorter time until the point to make it economically interesting. Please say why you are sure. Yes, the existence of someone who is richer that Bill Gates and who wanted to spend all of his money to break a single key in about a decade would be economically interesting, but not in the way I think you meant. RFC 3766 is still used for making many important security decisions. The numbers and math in it are essentially the same as those used by NIST in the guidance that Nelson posted yesterday. To date, no one has asked us to update it, or even to make any significant corrections. If you know something we don't, it would be really useful to the whole Internet community to hear more. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 have possibly mentioned it, but no dice. If I remember correctly I saw it initially at heise.de or theregister.com. And I haven't bookmarked it either :-( I'm sure a big cluster of always getting stronger CPUs (dual, quad, oct cores) will able to to get on 1024 bit keys in an ever shorter time until the point to make it economically interesting. Please say why you are sure. Yes, the existence of someone who is richer that Bill Gates and who wanted to spend all of his money to break a single key in about a decade would be economically interesting, but not in the way I think you meant. RFC 3766 is still used for making many important security decisions. Do you believe it to be still accurate? I understand that it was written at a time before 2004 with references to Itanium 500, Celeron 400 and Dual Pentium II-350 which looks like childsplay to today's 64 bit quad processors with speeds of 3GH per core and 12MB direct cache. I guess those aren't even the strongest chips out there, but certainly in the same price league when comparing. What we are looking at is the to derive the private key from the public key which would be enough to compromise the CA key and with it the whole pile of roots in NSS (as you love to say). The numbers and math in it are essentially the same as those used by NIST in the guidance that Nelson posted yesterday. To date, no one has asked us to update it, or even to make any significant corrections. As the author, how do you estimate the situation? Do you feel it's still accurate or have developments and capabilities improved beyond expectations (and despite Moore's law)? 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... Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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://www.ercim.org/publication/Ercim_News/enw42/girard.html which must have been known to you at the time of writing the RFC. It's nevertheless interesting, considering that they used some 10,000 PCs and today's botnets comprise usually of many, many more compromised computers (some sources say up to a million). Also in that article there is the reference to crack a public-key system like RSA of at least 600 bits. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 -- - -- - 802 key 3DES L = 1024 N = 160 k = 1024 f = 160-223 112 3 key 3DES L = 2048 N = 224 k = 2048 f = 224-255 128 AES-128L = 3072 N = 256 k = 3072 f = 256-383 192 AES-192L = 7680 N = 384 k = 7680 f = 384-511 256 AES-256L = 15360 N = 512 k = 15360f = 512+ Yes, I know that. (I co-authored RFC 3766, which helped push NIST to publish the table above.) And it does not answer my question: What does is cause for concern mean when the majority of the certificates in our list are 1024 bits? Are we saying The majority of the certificates that we say you should trust are 'of concern'? If so, why the heck are we telling people to trust them? 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 Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 bit keys at some point in the future. For example StartCom will request by 2010 to remove its 1024 bit key from NSS and we stopped issuing from our old root since this month. Officially and effectively as per 1st of June 2008 no new certificates are issued from that root since we've successfully transitioned to the newer 4096 bit root. As I understood from previous discussions, such transitions will be encouraged and at some point mandated. Therefore it makes no sense to accept 1024 bit keys anymore and make stronger keys a requirement for inclusions. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 and then using the discovered public key to create forged certificates from that CA. Since *all* of the roots have the same effective power (they can certify any domain name in the DNS), Mallory will always want to attack the easiest target, namely the shortest public key. 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. Paul, are you questioning the stricter requirement for new root CAs, Yes; see above. Of course, we could have a rule that requires all CA keys in the root pile to have a certain minimum length, but that would eliminate many commercially-important roots, or would you like us to improve the language in the wiki? Yes. I see no reason to talk about concern for key sizes that we are telling all users to trust. Either we tell them to trust everything equally because we have vetted it, or they should trust nothing. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 might not improve security *immediately*, I don't see why a gradual transition to stricter requirements is a problem. Are you suggesting we're stuck with small keys forever, or that all CAs must switch simultaneously? Justin ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 stricter requirements is a problem. It is not a problem: it is also not a solution until the last of the smaller-keyed CAs are removed. Are you suggesting we're stuck with small keys forever, or that all CAs must switch simultaneously? If not the latter, the former for a reasonable value of forever. 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 https://www.amazon.com/), has a 1024-bit RSA key and has an expiration date of Aug 1 23:59:59 2028. Yes, that's a bit over 20 years from now. 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 just not justified. If we want to ramp up the mandatory key sizes, we need to also simultaneously promise to pull out all CAs that don't meet those sizes at a reasonable time. Otherwise, we are just pretending to be helping. 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 the date in (a). If we adopt such a proposal, but later start to waver on (b), we immediately admit that (a) is silly from a security perspective. --Paul Hoffman ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 the date in (a). That sounds like a good plan! Reality might hasten the arrival of (b) perhaps depending on developments we can't foresee. Regards Signer: Eddy Nigg, StartCom Ltd. http://www.startcom.org Jabber: [EMAIL PROTECTED] xmpp:[EMAIL PROTECTED] Blog: Join the Revolution! http://blog.startcom.org Phone: +1.213.341.0390 ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 just not justified. I don't think it's nearly that black-and-white. Changing existing roots is a high-cost, long-lead process; raising the bar on new roots is cheap and fast. I don't understand why the two are incompatible, nor why progress should be gated upon perfection. Are new CAs objecting to the use of stronger certs? Proposal: [...] A three-phase migration might be a bit more orderly: 1) short-term: raise bar on new CAs 2) mid-term: get existing CAs to switch to stronger roots 3) long-term: remove weak roots. #2 helps mitigate the impact of #3 on end-users, lest something force the issue sooner than desired. Justin ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
