Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC

Martin Rex <mrex@sap.com> Mon, 04 October 2010 19:58 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 944C83A7083; Mon, 4 Oct 2010 12:58:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.85
X-Spam-Level:
X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 tqjTg1hJd7Jc; Mon, 4 Oct 2010 12:58:53 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 69C1D3A6E7D; Mon, 4 Oct 2010 12:58:52 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id o94Jxi9v021616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2010 21:59:45 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201010041959.o94JxhHB019126@fs4113.wdf.sap.corp>
To: stephen.farrell@cs.tcd.ie (Stephen Farrell)
Date: Mon, 4 Oct 2010 21:59:43 +0200 (MEST)
In-Reply-To: <4CA9FB2F.4000300@cs.tcd.ie> from "Stephen Farrell" at Oct 4, 10 05:05:03 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: dnsop@ietf.org, saag@ietf.org, pkix@ietf.org, tls@ietf.org
Subject: Re: [TLS] [pkix] Cert Enumeration and Key Assurance With DNSSEC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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 19:58:54 -0000

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.  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.  

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.  


-Martin