IETF Logo Mail Archive

Re: [keyassure] Objective: Restrictive versus Supplementary Models

Paul Wouters <paul@xelerance.com> Fri, 01 April 2011 07:27 UTC

Return-Path: <paul@xelerance.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 6815C3A6BEC for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 00:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Level:
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599]
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 nDE9-YcJMJCP for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 00:27:31 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 96F9E3A6BD7 for <keyassure@ietf.org>; Fri, 1 Apr 2011 00:27:31 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 2E9A6C5A0; Fri, 1 Apr 2011 03:29:11 -0400 (EDT)
Date: Fri, 01 Apr 2011 03:29:10 -0400
From: Paul Wouters <paul@xelerance.com>
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.com>
Message-ID: <alpine.LFD.1.10.1104010324570.18318@newtla.xelerance.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com> <m3pqp8fvoz.fsf@jhcloos.com> <F1AC4325-EA91-4570-A423-F14B178B3965@bbn.com> <alpine.LFD.1.10.1103310340560.4460@newtla.xelerance.com> <A473B403-50A7-4A8D-973B-64142F1ECE5A@bbn.com> <7629D2C2-16DC-4ED8-B1AE-14900891448B@checkpoint.com> <alpine.LFD.1.10.1104010311400.18318@newtla.xelerance.com> <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
Cc: "keyassure@ietf.org" <keyassure@ietf.org>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
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: Fri, 01 Apr 2011 07:27:32 -0000

On Fri, 1 Apr 2011, Yoav Nir wrote:

>>> So I think the requirements document should describe EKR's use cases, and require that the TLSA record be able to differentiate between records that are appropriate for the two use cases.
>>
>> Are you really suggesting some kind of indicator that says "you can ignore the cruft from the cert that is bogus
>> that I vouched for via the RRSIG"?
>
> Stated like this, it conveys policy. I just want it to say that this is the cert I'm going to use, and I can't vouch for anything there besides the public key.

The obvious answer here is to make it explicit that you are only vouching for the public key... by only putting
the public key in the DANE record to sign.

1) You're not signing items you want the client to ignore
2) You're not signing for information that contradicts itself (RRSIG/TTL vs Expiry or RRlabel vs Subject*)

Paul

v2.23.0 | Report a Bug | By Email