Re: [keyassure] Musing on design based on proposed use cases

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 30 March 2011 12:45 UTC

Return-Path: <rbarnes@bbn.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5317F28C12F for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:45:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.545
X-Spam-Level:
X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eW+ZJCZ9sI5A for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:45:26 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id C3E0528C14E for <keyassure@ietf.org>; Wed, 30 Mar 2011 05:45:25 -0700 (PDT)
Received: from [128.89.255.137] (port=58514 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q4und-000AuN-Mt; Wed, 30 Mar 2011 08:47:01 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <AANLkTikyt=mHRLjXQ64903knEkUKwO0fKjqoSPy2anXQ@mail.gmail.com>
Date: Wed, 30 Mar 2011 14:46:55 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <D1BAB282-629B-44F3-8869-6AB685F2CCCE@bbn.com>
References: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com> <AANLkTikyt=mHRLjXQ64903knEkUKwO0fKjqoSPy2anXQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
X-Mailer: Apple Mail (2.1082)
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Musing on design based on proposed use cases
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 12:45:27 -0000

>> So the proposed validation algorithm would have roughly the following form:
>> A. Given a set of DANE records and a cert chain...
>> B. Verify that all DANE certs with the "critical" flag set are present in the cert chain
> 
> This seems problematic. Say what I'm trying to do is cert lock and I
> have multiple servers,
> each with its own cert. If I list all the certs, this will obvious break.

Fair enough.  Could also be "Verify that at least one DANE CA cert with the "critical" flag set is present in the cert chain".  Assuming that you never want to specify more than one cert in the chain (I don't see why you would).

--Richard