Re: [keyassure] Objective: Restrictive versus Supplementary Models

Yoav Nir <> Wed, 30 March 2011 09:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5DEC13A697A for <>; Wed, 30 Mar 2011 02:13:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.545
X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zKF52zJl8Ynr for <>; Wed, 30 Mar 2011 02:13:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 245BF3A6875 for <>; Wed, 30 Mar 2011 02:13:46 -0700 (PDT)
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p2U9FOA9027704; Wed, 30 Mar 2011 11:15:24 +0200
X-CheckPoint: {4D92F420-F-1B221DC2-FFFF}
Received: from ([]) by ([]) with mapi; Wed, 30 Mar 2011 11:15:24 +0200
From: Yoav Nir <>
To: Eric Rescorla <>
Date: Wed, 30 Mar 2011 11:15:23 +0200
Thread-Topic: [keyassure] Objective: Restrictive versus Supplementary Models
Thread-Index: AcvuuwBcEyTzZ+JoQ9yLPapZRJKGaQ==
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 30 Mar 2011 09:13:48 -0000

On Mar 30, 2011, at 10:48 AM, Eric Rescorla wrote:

> To follow up on my comments at the microphone, there are two potential
> objectives for
> technology of this type:
> 1. Protecting against CA mis-issue (as in CA/cert lock).
> 2. Allowing TLS to work without getting a certificate from one of the
> established trust
> anchors.

I think the current draft is mostly focused on the second objective. Unless we declare #2 to be a non-goal, a (web) client cannot do the regular PKIX validation of the certificate.

More specifically, with a type-2 certificate (CA cert in the record) you anyway have to validate the EE certificate using regular PKIX procedure, except that you replace the trust anchor store with the CA certificate in the DNS record. This makes sense for the 2nd objective, but not for the first (you could put the Verisign root certificate in the DNS record, but then you're protected from mis-issue only by the other CAs). So with a type #2 record, you get both objectives

With a type-1 certificate (EE cert in the record) you get objective #1, but how is a client to know whether it is intended to just compare bits or also to validate the certificate? As long as objective #2 is not a non-goal, the client can't rely on such a record containing a certificate that can be validated. Maybe we need three types of records: CA certificate, untrusted EE certificate, and PKIX EE certificate. In that case, I don't the what advantage an "untrusted EE certificate" has over bare keys. So maybe it should be: CA certificate, PKIX certificate (that needs to be validated) and bare keys.