[keyassure] Another comment from the mic

Eric Rescorla <ekr@rtfm.com> Wed, 30 March 2011 08:56 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 78BEE28C111 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 01:56:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.941
X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 9rUeYo312ljR for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 01:55:59 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com []) by core3.amsl.com (Postfix) with ESMTP id C0AB128C0F0 for <keyassure@ietf.org>; Wed, 30 Mar 2011 01:55:59 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1184868iwn.31 for <keyassure@ietf.org>; Wed, 30 Mar 2011 01:57:38 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id ho7mr963237icc.171.1301475458514; Wed, 30 Mar 2011 01:57:38 -0700 (PDT)
Received: by with HTTP; Wed, 30 Mar 2011 01:57:38 -0700 (PDT)
Date: Wed, 30 Mar 2011 10:57:38 +0200
Message-ID: <AANLkTinLzQLW6pPOPewFtsnf28DdQc_wVRq0wWkdr-s4@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: keyassure@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [keyassure] Another comment from the mic
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 08:56:00 -0000

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.