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
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
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
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
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
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
[Please respect the Followup-To header, set to mozilla.dev.security]
Many of you will know about the problem with weak keys generated on
Debian or Debian-derivative systems between certain dates.[0] This
affects SSL certificates generated on those systems. CAs trusted by
Firefox have signed, and
I've been looking at a request from Entrust (bug 416544) to (among other
things) have its new Entrust Root Certification Authority root enabled
for EV. This is a new Entrust root that was approved for inclusion last
year by Gerv (bug 382352) and subsequently added to NSS (bug 387892).
(NOTE:
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
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.
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
Frank Hecker:
(NOTE: This has nothing to do with Entrust legacy roots in NSS, and
nothing to do with Entrust cross-signing of other CA's roots. AFAICT
this root is used only for Entrust EV certificates. In bug 416544
Entrust has also requested EV status for its legacy roots, but I'm
handling
Eddy Nigg (StartCom Ltd.) wrote:
Does the document http://www.entrust.net/CPS/pdf/webcps051404.pdf not
apply for this root and if so how do you know about it?
Per Entrust, at present this root has only one subordinate CA, the
Entrust Certification Authority - L1A used to issue EV
Yevgeniy Gubenko wrote:
You were right about the absence of a certificate in generated with JKS
format client.private file. But unfortunately, attempt to generate the
self-signed certificate for the keystore, then converting it to PKCS12
format (client.privatepkcs12) and finally, import it
14 matches
Mail list logo
