Re: [keyassure] Objective: Restrictive versus Supplementary Models

Yoav Nir <ynir@checkpoint.com> Fri, 01 April 2011 07:21 UTC

Return-Path: <ynir@checkpoint.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 0D48B3A69D3 for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 00:21:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.554
X-Spam-Level:
X-Spam-Status: No, score=-10.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 ZOuDKQPyAdta for <keyassure@core3.amsl.com>; Fri, 1 Apr 2011 00:21:09 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 6B03F3A6B03 for <keyassure@ietf.org>; Fri, 1 Apr 2011 00:21:07 -0700 (PDT)
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p317MfQV018079; Fri, 1 Apr 2011 10:22:41 +0300
X-CheckPoint: {4D958B32-2-1B221DC2-FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 1 Apr 2011 10:22:41 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: Paul Wouters <paul@xelerance.com>
Date: Fri, 1 Apr 2011 10:22:40 +0300
Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models
Thread-Index: AcvwPZZSPiOLsiexRWCPor5y2T44Pw==
Message-ID: <97668833-DC1B-4371-85F5-60ABBE8CA2F2@checkpoint.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>
In-Reply-To: <alpine.LFD.1.10.1104010311400.18318@newtla.xelerance.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:21:21 -0000

On Apr 1, 2011, at 10:13 AM, Paul Wouters wrote:

> On Thu, 31 Mar 2011, Yoav Nir wrote:
> 
>> Cert-lock (and CA-lock) are what EKR calls supplementary, while the others are the restrictive. While the sever (and domain owner) can't dictate client policy, they should be able to indicate whether the Certificate (TA or EE) that's in the TLSA record is supposed to be validatable or not. The client (relying party) may have a policy to ignore records that push a non-valid certificate, but if you're going to publish a record with a certificate that you have just issued using openssl on your laptop and expires in 1975, the TLSA record had better reflect that this certificate is just a container for a public key, not something you can chain and validate.
>> 
>> 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.