[TLS] OtherCerts & pinning (Was: Re: [pkix] Cert Enumeration and Key Assurance With DNSSEC)

Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 04 October 2010 22:25 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id EFF2F3A6EB9; Mon, 4 Oct 2010 15:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.858
X-Spam-Status: No, score=-102.858 tagged_above=-999 required=5 tests=[AWL=-0.259, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id E8djnLUAFPTS; Mon, 4 Oct 2010 15:25:55 -0700 (PDT)
Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id ACE893A6CB0; Mon, 4 Oct 2010 15:25:54 -0700 (PDT)
Received: from localhost (localhost []) by hermes.scss.tcd.ie (Postfix) with ESMTP id E2E733E4102; Mon, 4 Oct 2010 23:26:48 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1286231207; bh=gaPyQi9Rgbk5a1 5f9EpAZl4AEt8FIc2MCh2tcEHjYkU=; b=wHDG1GtYYjo2SU9DY0aNRzUN9/2phu 2OZbwaIpwtERElSZfLnVoZPrfSlmx4aN6ZFP0W/rXxd61oNEhM+DMyANYPXYaLiO 5xhgEUAkMB6Fb20A4tj1qeFUhbTLGq3tiFkBXwqKY4pIVbRu/tRmhlcdBrzWWpf7 o53zoNQy95Kk2eE6gwh6bUSzO/6s04zpQ7m5Es6MnAWhHGhVarSbB0edVTqGezjC DO1sy2AA30Lx+j09gCvue31XTR4bG7mkacQROMV2NyiqiHcqUGRFXMkMQHnP9dU0 D5KeFPwZUdsy5unIvxHbBc8Z56dzjK6h+1TSgg4/jBSolR8bR6bxaF5A==
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from scss.tcd.ie ([]) by localhost (scss.tcd.ie []) (amavisd-new, port 10027) with ESMTP id t0Zu88u39cxS; Mon, 4 Oct 2010 23:26:47 +0100 (IST)
Received: from [] (dsl-102-234.cust.imagine.ie []) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id A77E33E40F6; Mon, 4 Oct 2010 23:26:46 +0100 (IST)
Message-ID: <4CAA54A5.9050602@cs.tcd.ie>
Date: Mon, 04 Oct 2010 23:26:45 +0100
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100915 Lightning/1.0b1 Thunderbird/3.0.8
MIME-Version: 1.0
To: mrex@sap.com
References: <201010041959.o94JxhHB019126@fs4113.wdf.sap.corp>
In-Reply-To: <201010041959.o94JxhHB019126@fs4113.wdf.sap.corp>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: pkix <pkix@ietf.org>, tls@ietf.org
Subject: [TLS] OtherCerts & pinning (Was: Re: [pkix] Cert Enumeration and Key Assurance With DNSSEC)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Oct 2010 22:25:57 -0000

(Just bringing the cc down to TLS & PKIX.)

On 04/10/10 20:59, Martin Rex wrote:
> Stephen Farrell wrote:
>> On 04/10/10 15:37, Martin Rex wrote:
>>> One thing that needs to be addressed/solved is the key/cert rollover
>>> for any TLS-Server, so that it is possible to list more than one
>>> server cert as "valid" for a Server through DNS, at least for the
>>> time of the transition/rollover.
>> Maybe a side-issue here, but this came up in the W3C WSC work and
>> I wrote up an idea for that (not based on DNS) which is RFC 5697. [1]
>> No idea if anyone is using or would use it, though I did have a student
>> implement it, so it *could* work. (Note: that's an experimental-track
>> RFC, as it ought be:-)
>> S.
>> [1] http://tools.ietf.org/html/rfc5697
> I do _not_ like the OtherCertificates extension.  

I'm all upset:-)

> If some client would
> honour this for a "pinned" cert, it would allow an arbitrary CA under
> any of the trusted roots to completely subvert the clients motivation
> of pinning the cert.

Right. Just like today. OtherCerts wasn't aimed at tackling rogue
CAs. Could be that a solution exists that can handle rogue CAs as
well as allowing clients to track pinning across certs. If so, I'd
be glad to see it written up.

> A sensible approach would require a certificate extension in the
> new cert which provides a proof from the original certificate holder
> (i.e. signed with the private key of the old cert), that the new
> cert (the public key and at least some of the certificat attributes,
> such as subject name, all subjectAltNames, BasicConstraints, keyUsage,
> ExtendedKeyUsage, maybe more) are a valid replacement for the original
> server cert.


> Key continuity without the consent of the original key holder looks
> dangerous to me.  

I suspect it'd get too complicated if all 3 parties (CA, TLS server
and client) have to be involved, and PKIX doesn't have a history
of successfully getting more complicated EE/CA protocols deployed.
But if it worked, I'd be for trying it.