On 22/1/09 12:26, Eddy Nigg wrote:
On 01/22/2009 01:13 PM, Ian G:
Although it is good that people rose to the challenge of the debian PRNG
failure, I do not understand the position that all certs had to be
revoked. Isn't it a situation between the Subscribers, Relying Parties
and the CA concerned? That is, notification is as far as you can go?
Indeed! Mozilla is a relying party.
good point. So this means that Mozilla has agreed to the RPA?
;-) The problem with acting "as if" is that you get all the
responsibilities and none of the powers.
A weak key is compromised from the outset and upon detection (which can
be actively pursued) requires revocation of the key by the CA. This is
what most CAs have in their policies. This was what drove some CAs to
actually revoke them. Gerv and others were very helpful in pointing out
the arguments in favor of such an action.
Arguments in favour ... are nice. What about arguments against?
The system could be further protected by other means. It could be used
for client-cert work. It could be in use for a low-security usage, such
as would be acceptable for SSCs. It could be an old or deprecated site.
It could be a no-liability cert (that's an oxymoron, all certs are
no-liability, but oh well)... It could be an expiry in a month. It
could be a free cert, in which case no support is offered? It could be
an S/MIME cert for internal email, in which case who cares? There could
be penalties for revocation. The subscriber agreement could have
covered this already.
Unless you can demonstrate a clear and present danger to the end-user of
Mozilla's products, it may be hard to to establish a line here.
Theoretical weaknesses in crypto mean little, it's a business
discussion, and the threat has to be related to the business risks,
liabilities and obligations.
iang
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto