Re: [keyassure] Objective: Restrictive versus Supplementary Models

Paul Wouters <> Fri, 01 April 2011 07:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B24A3A6BF3 for <>; Fri, 1 Apr 2011 00:12:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.593
X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fKgjJMjIRV2C for <>; Fri, 1 Apr 2011 00:12:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6A2EF3A6BD7 for <>; Fri, 1 Apr 2011 00:12:18 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id DDE47C5A0; Fri, 1 Apr 2011 03:13:55 -0400 (EDT)
Date: Fri, 1 Apr 2011 03:13:55 -0400 (EDT)
From: Paul Wouters <>
To: Yoav Nir <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <> <> <> <> <>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: "" <>
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Apr 2011 07:12:19 -0000

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"?