Ben Bucksch wrote:
Julien Pierre wrote:
Ben Bucksch wrote:
What about the model I proposed? First cert for a person is either
CA-based or self-signed, subsequent certs *must* be authorized and
signed by the previous cert or will be treated as attack.
If the key for the first cert was compromised (fell into the wrong
hands), and that cert was self-signed, how can you possibly do
revocation on it?
Let's say I can't and that would have been my price for using a
self-signed cert. You may have pointed out a good reason to use
CA-signed certs.
Right. As it should be - this is what you
get for free. If you put down some money,
you can some infrastructure (revocation) to
provide more support.
But it doesn't change my proposal to enforce "continuity" of certs and
warn the user, if that's no longer given. I.e. the reaction of the
software to a new cert changes depending on if I already have another
cert for that correspondent or not.
Oh, scrap my previous email - I thought you
meant by continuity, not permitting servers
and browsers to change cert providers at all
(e.g., enforce).
Yes, notification of a change to certs
should be part of the browser's security
model. It's the only way that the user can
deal with the whole class of substitute-
cert attacks.
iang
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
