Re: [keyassure] Objective: Restrictive versus Supplementary Models

"Richard L. Barnes" <rbarnes@bbn.com> Wed, 30 March 2011 11:53 UTC

Return-Path: <rbarnes@bbn.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 A2BB128C11A for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.538
X-Spam-Level:
X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 lDDty+F3rx0L for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:53:16 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B1F2328C134 for <keyassure@ietf.org>; Wed, 30 Mar 2011 04:53:15 -0700 (PDT)
Received: from [128.89.255.137] (port=58399 helo=[130.129.17.55]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from <rbarnes@bbn.com>) id 1Q4tzB-000A8Z-L9; Wed, 30 Mar 2011 07:54:53 -0400
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" <rbarnes@bbn.com>
In-Reply-To: <Pine.LNX.4.64.1103300450160.25974@newtla.xelerance.com>
Date: Wed, 30 Mar 2011 13:54:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <9F44BE94-7AC3-48F4-8A42-0748CA40A29D@bbn.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <Pine.LNX.4.64.1103300450160.25974@newtla.xelerance.com>
To: Paul Wouters <paul@xelerance.com>
X-Mailer: Apple Mail (2.1082)
Cc: 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: Wed, 30 Mar 2011 11:53:16 -0000

>> 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.
> 
> 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
> keeping statistics on these (as proven recently with Comodogate)

This is isomorphic to the use of domain-issued certs, case 2 above.  If the TLS server is using a CA-issued cert, the client *should* use OCSP (or a CRL) to make sure it hasn't been revoked.  With a domain-issued cert, there's probably no place to go for OCSP.

--Richard