[keyassure] Musing on design based on proposed use cases

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 30 March 2011 12:38 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 8ADBF3A67FC for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:38:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.542
X-Spam-Level:
X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 RfdxWuBh62rj for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:38:55 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 5A3EC3A67D4 for <keyassure@ietf.org>; Wed, 30 Mar 2011 05:38:55 -0700 (PDT)
Received: from [128.89.255.137] (port=58496 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 1Q4uhN-000AqB-Tx for keyassure@ietf.org; Wed, 30 Mar 2011 08:40:34 -0400
From: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Wed, 30 Mar 2011 14:40:28 +0200
Message-Id: <1DDD3940-D481-44E8-B505-05F24E7B46AA@bbn.com>
To: keyassure@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
Subject: [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:38:56 -0000

So I think the use cases EKR described are clear enough to design to -- and they're not satisfied by the current design.  ISTM that there will probably be a need for a couple of flags to distinguish the two semantics:
1. "critical": MUST require that this cert be present in the chain
2. "trusted":  MUST use this cert as a TA
3. "exclusive": Trusted + MUST NOT use any other TAs.

The latter two come with a caveat: Clearly, the relying party can choose to ignore the DANE TAs, so the flag would be a recommendation from the domain owner to the relying party.  (There are clearly interactions between the flags, e.g., no "exclusive" without "trusted"; see table at the bottom.  There are also potential interactions between records w.r.t. the "exclusive" flag.)

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
C. [TBD-Consensus] If there is a "critical" EE cert, accept/reject based on exact match
E. If any DANE record is flagged "exclusive", remove all TAs from the local TA store 
D. Add all DANE certs with the "trusted" flag set to the local TA store
F. Perform normal PKIX validation

Submitted for consideration...
--Richard


CTE
000 [disallowed]
001 [disallowed]
010 MUST use as a TA
011 MUST NOT use any other TAs
100 MUST be present in cert chain
101 [disallowed]
110 MUST be present and used as a TA
111 MUST be present and used as only TA