Subject: [keyassure] Another comment from the mic

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 10:57:38 +0200

As I said at the mic, the vast majority of the certificate warnings
you see on the network
are not because of attacks, but rather are due to:

- Self-signed certs
- Certificates from legitimate CAs which are uncompromised but invalid
for some technical
   reason (expired certs, trivial name mismatches, etc.)

One of the purposes of my "permissive" case-2 model in my previous
email is to allow those
self-signed certificate servers to have verifiable credentials.
However, anything we do that
has the consequence that certificates which should verify don't for
mostly-irrelevant technical
reasons (e.g., certs which are validated by DANE but are expired or
have the wrong keyusage
bits) will defeat this purpose to some extent. Perhaps that's worth
doing in service of the correctness
of the validation chain, but it does need to be considered.

-Ekr

---

From: Stephen Kent <[email-masked]>
Date: Wed, 30 Mar 2011 07:16:15 -0400

>of the validation chain, but it does need to be considered.

I fully agree with the goal of avoiding error messages that confuse a 
user, especially ones that make it hard to tell the difference 
between a sloppy
admin and an attacker.  But, it may be hard to tell the difference in some
cases :-). Maybe we can reduce the incidence of bad self-signed certs 
by providing better tools to generate these certs, and including 
defaults to
make it easy to avoid the typical errors.

Steve

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 Mar 2011 13:53:51 +0200

On Wed, Mar 30, 2011 at 1:16 PM, Stephen Kent <[email-masked]> wrote:
> I fully agree with the goal of avoiding error messages that confuse a user,
> especially ones that make it hard to tell the difference between a sloppy
> cases :-). Maybe we can reduce the incidence of bad self-signed certs by
> providing better tools to generate these certs, and including defaults to

This seems like a very worthy goal.

-Ekr