Re: [keyassure] Objective: Restrictive versus Supplementary Models

Yoav Nir <ynir@checkpoint.com> Thu, 31 March 2011 12:59 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 3DB863A6B13 for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 05:59:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.55
X-Spam-Level:
X-Spam-Status: No, score=-10.55 tagged_above=-999 required=5 tests=[AWL=0.049, 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 mOtJC8qhhD8Y for <keyassure@core3.amsl.com>; Thu, 31 Mar 2011 05:59:43 -0700 (PDT)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id F0D1F28C14A for <keyassure@ietf.org>; Thu, 31 Mar 2011 05:59:42 -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 p2VD1LGS005926; Thu, 31 Mar 2011 15:01:21 +0200
X-CheckPoint: {4D947A8E-18-1B221DC2-FFFF}
Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 31 Mar 2011 15:01:20 +0200
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 31 Mar 2011 15:01:20 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: Michael Richardson <mcr@sandelman.ca>
Date: Thu, 31 Mar 2011 15:01:19 +0200
Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models
Thread-Index: Acvvo7qeNsIwLu4IRxSz9iwEVvanxw==
Message-ID: <8FA34510-B4BA-4DD2-B1D3-49D7100D7F62@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> <14529.1301575096@marajade.sandelman.ca>
In-Reply-To: <14529.1301575096@marajade.sandelman.ca>
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: Thu, 31 Mar 2011 12:59:44 -0000

On Mar 31, 2011, at 2:38 PM, Michael Richardson wrote:

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

It's not strictly speaking "intent". It's more of an attribute. Either "this certificate of mine, you can use your regular validation techniques" or "this certificate of mine, just make sure you get this one."

Yoav