Eddy Nigg (StartCom Ltd.) wrote:
Yes, in case the attacker managed to get a copy of the previously used
and signed key. Not, in case the subscriber managed to change his cert
before.
Right. But I'm not going to bet against the possibility that there a bad
guys even now downloading the public
Boris Zbarsky:
Could maybe try to brute-force the old key until they come up with a forged
certificate that an SSL library accepts?
No, not really. It requires the possession of the certificate with the
weak key signed by a CA.
The whole point is that all the weak
keys come from a
Eddy Nigg (StartCom Ltd.) wrote:
Oh, that would technically not be possible I guess. Searching for such
keys dynamically could take hours per key, hence previously created
keys are used. They would need to be hosted somewhere and compared to.
That's why Mozilla would know about which public
Gervase Markham wrote:
- Do nothing
Once Firefox 3 is released, many people will upgrade. This means they
will be using soft-fail OCSP, and so will detect attempts to use revoked
keys.
As far as I can see, there is no way around having at least an optional
extension that allows to check
Gervase Markham:
Eddy Nigg (StartCom Ltd.) wrote:
Oh, that would technically not be possible I guess. Searching for such
keys dynamically could take hours per key, hence previously created
keys are used. They would need to be hosted somewhere and compared to.
That's why Mozilla would
Eddy Nigg (StartCom Ltd.) schrieb:
Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
The current lists of chksslkey that cover the vast majority of the weak
keys take 13 MByte -- no problem for most PCs.
bye, ju
Eddy Nigg (StartCom Ltd.) wrote:
Locally stored where exactly? Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
Doesn't sound feasible to me, hence I thought you were talking about
some kind of lookup service.
Read, the bug, Eddy! :-)
bsterne wrote:
http://people.mozilla.com/~bsterne/site-security-policy
This is an interesting proposal. Here are some thoughts:
- Are we concerned about the bandwidth used by the additional headers,
or are the days of worrying about a few bytes overhead per request long
past?
- I am concerned
Gervase Markham:
Eddy Nigg (StartCom Ltd.) wrote:
Locally stored where exactly? Do you have an idea how big such a list
which would cover just the most commonly used key sizes would be?
Doesn't sound feasible to me, hence I thought you were talking about
some kind of lookup service.
- Do you plan to permit these policies to also be placed in meta
http-equiv= tags? There are both pros and cons to this, of course.
Might it be a valuable idea to support a similar reference mechanism
to the way that the P3P compact policy is supported?
:: The location of the policy reference
10 matches
Mail list logo
