On 01/09/2009 02:08 AM, Ben Bucksch:
On 01/09/2009 01:12 AM, Ben Bucksch:
It's not an *endorsement*, but making it possible to use them without
fat warning
Which is exactly the same thing...
No. "Make it possible" and "endorse" are two entirely different things.
OK, let us disagree on that one for now. My opinion is, that it is made
possible and provides the technical details to do that securely (That is
for FF 3.1, not discussing FF 3.0 anymore).
the longer a key is used the better the chances of getting
compromised, isn't it?
It doesn't make a difference whether you have one key for two years on a
system or two keys for one year each, one after the other.
The longer a key is on a system, the chances are higher for compromise I
think.
If you want to change keys nevertheless, you can still do that. Just
make sure you authorize the new one, by signing the new key with the old
one.
Errr...this isn't PGP, besides, I don't want to sign anything new with
something old, otherwise I wouldn't need the new one in first place, no?
I did, I know this bug from long time ago. Perhaps help me understand
what I'm apparently missing here.
As I already explicitly said in the bug, there would be no warning. The
private key does not change, or the new key is signed with the old one.
You mean the same public key in form of a CSR is signed by the CA once
again and a new certificate issued in which case no new action should be
required. If the key changes than an error is issued. If this is
correct, it would be very inconvenient for the majority of users since
web sites 98% change the keys every while (after certificate
expiration). CAs which issue more frequently (shorter life-time) would
be at disadvantage - I stated it before.
What happens on first visit? A message to acknowledge the new key? Or
will it be silently accepted? As per your comment in the bug I assume
that to be the case - most likely accepting self-signed certs silently
on the way too I guess.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog: https://blog.startcom.org
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
