Frank Hecker wrote:
Sigh, that is _so_ brain-dead.
It is! But it's the CA's problem, surely? MF can only
go so far in mollycoddling the CAs, and at some point,
it becomes an abusive relationship, which I would
suspect was an issue in that sad story. But very
illustrative of real world problems, thanks Nelson.
I don't think it's a good idea to include policy language that one is
not likely to enforce should it come to that, especially for a problem
that may or may not actually occur.
I agree with that. If a "certain well-known CA" decides to
play silly buggers with the customers, then it's between
the CA and the customers ... and the CA should suffer in the
market place. The right thing to do is to surface the info
and let the CA decide whether its reputation is worth
trashing in this way, or whether the exigency is severe
enough that it's the right option, IMO.
If a "certain well-known CA" did that, then it should be
named, and become well-named for who it is, not obscured
nor protected by MF. Maybe it had a good reason to do
that - nobody can really judge on their behalf - but likewise
it is not up to MF to hide the problems from users.
At the very least, MF should know in advance which CAs will similarly
not
permit distribution of replacement root CA certs apart from software
distributions. It would also be advisable for MF to keep track of
upcoming root CA expirations and plan releases for them.
I do agree that we need a plan for this. My proposal is not to revise
the actual 1.0 policy to address this, but to first look at the actual
situation (in terms of CA cert expiry dates and relevant CA copyright
language) and see how serious this problem actually is today. At the
same time we can consider ways to push out root cert list updates.
(Things like the Firefox update mechanism are obvious candidates, but
then we have to address the whole signed XPI issue.)
(This sounds like an implementation detail, rather than a
policy detail?)
As an implementation detail, one could run a script to
just mail the CAs 2m and 1m before expiry, like the domains
people do. Or, alternatively, just mail out the release
planning dates to CAs saying "make sure your certs are
up to date for those dates."
Another way of doing this is to put the info in the release
notes. That is, when the rootlist is manufactured, it spits
out the certs list with expiry dates. Then, all the users
get told it is an expired cert, and it isn't MF's fault that
the CA hasn't kept up to date. Plus the release notes
can be promulgated on the web page for CAs, which
would be useful info for the various user communities
to browse.
Just some ideas...
iang
--
News and views on what matters in finance+crypto:
http://financialcryptography.com/
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto
