Re: [keyassure] Another comment from the mic

Stephen Kent <> Wed, 30 March 2011 11:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFFFA28C0DB for <>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.555
X-Spam-Status: No, score=-102.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K-DQAt-XY2uQ for <>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 088B228C0F9 for <>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
Received: from ([]:58034 helo=[]) by with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <>) id 1Q4tmM-000A36-Ep; Wed, 30 Mar 2011 07:41:38 -0400
Mime-Version: 1.0
Message-Id: <p06240802c9b8c0e530e6@[]>
In-Reply-To: <>
References: <>
Date: Wed, 30 Mar 2011 07:16:15 -0400
To: Eric Rescorla <>
From: Stephen Kent <>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Subject: Re: [keyassure] Another comment from the mic
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Mar 2011 11:40:01 -0000

At 10:57 AM +0200 3/30/11, Eric Rescorla wrote:
>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.

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.