On 30/12/08 06:30, Ben Bucksch wrote:
If we decide that a CA does not operate properly,.but we don't want to
cause problems for users, another option would be to shorten the expiry
date of the relevant root certs to one year or less.
Technically, that should be possible. The cert is public anyways. The
current certs are probably self-signed, but I don't know if that's
necessary for NSS to function - I don't think it's inherently necessary,
so NSS could be changed to allow the roots to be not self-signed (but
instead signed by e.g. a Mozilla Foundation cert). What's important is
the trust that the cert gains by being included in the root cert store
shipping with Mozilla.
This would mean that users could continue to browse normally, including
SSL verification. Website owners would have one year (or less) time to
get certs from another CA, which does proper verifications. We restore
proper functioning of the system within one year (or less).
And we have a real threat to CAs.
This is interesting thinking. Technically, I would agree that the
vector for controlling the roots is in adding new features to the root
list software to control it in different ways (and ignore the settings
in the self-signed cert). Adding / changing the "trust" bits is the
same as setting a "mozo-expiry".
I would ask what the wider administrative effects are here?
Is Mozo taking on the task of monitoring its roots to such a dynamic
extent, and to deal with what might lead to an aggressive competitive
environment? E.g., if the current pressure succeeds in causing a change
to one CA, will other CAs be also challenged in the future?
Currently the administration is styled as entry, then low maintenance.
If there is a need to monitor and review all the CAs on a yearly basis,
and this group wants this, that might involve a lot more work, and I
don't think anyone wants that?
iang
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
