On Thu, 2010-09-16 at 03:08 +0200, Martin Rex wrote: > What confuses me is that 4.6.1 + 4.6.2 + 4.6.3 would allow a server, > which originally offered an inadequate server certificate which the > user manually confirmed, to unconditionally and silently bypass > the users manual confirmation with appropriately looking server cert > from any arbitrary trust anchor. This doesn't seem right.
I disagree. The user's confirmation was to accept the certificate, not to use it exclusively. I have taken advantage of this behavior on https://mattmccutchen.net . > The option of memorizing a server certificate for future reconnects > would significantly improve the security. Once a client caches > a server cert that is manually confirmed by the user, this could > protect a user on future reconnects to the same server from > an attacker that succeeds subverting a trusted CA. Even from > full compromise of all CAs by that attacker. The certificate exception mechanism serves the limited purpose of making it possible for users to connect to servers with unverifiable certificates, without which they would be unable to get work done in some cases. It looks like you're trying to replace the public-CA trust model, which is a much more ambitious goal, and it's not clear that your suggested change to the exception mechanism is anything near an appropriate or comprehensive solution. Let's have that discussion elsewhere and let the server-id-check draft proceed with its original scope. -- Matt _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
