IETF Logo Mail Archive

Re: [TLS] TLS 1.3 certificate delegation?

"Salz, Rich" <rsalz@akamai.com> Fri, 08 November 2013 16:45 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2288811E8189 for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 08:45:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koGiObE3ZT5g for <tls@ietfa.amsl.com>; Fri, 8 Nov 2013 08:45:50 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9F611E80E6 for <tls@ietf.org>; Fri, 8 Nov 2013 08:45:34 -0800 (PST)
Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 928734810F; Fri, 8 Nov 2013 16:45:20 +0000 (GMT)
Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 86A2E4810D; Fri, 8 Nov 2013 16:45:20 +0000 (GMT)
Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 6D74547BE0; Fri, 8 Nov 2013 16:45:20 +0000 (GMT)
Received: from USMBX1.msg.corp.akamai.com ([169.254.1.206]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 8 Nov 2013 11:45:19 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Andy Lutomirski <luto@amacapital.net>
Date: Fri, 08 Nov 2013 11:45:18 -0500
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
Thread-Index: Ac7coM+SnuUVj2jGRa2zRJ9igrLhkwAAB39g
Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF57F@USMBX1.msg.corp.akamai.com>
References: <527CF707.2070000@secunet.com> <r422Ps-1075i-7D1B8241D4174A8BAEFBF63DCD3FADA9@Williams-MacBook-Pro.local> <2A0EFB9C05D0164E98F19BB0AF3708C711DA7CF541@USMBX1.msg.corp.akamai.com> <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>
In-Reply-To: <CALCETrUBc+2urjCEGvpXQczu920X7knzYUW+dGd6vTAU1MQaGg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS 1.3 certificate delegation?
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Fri, 08 Nov 2013 16:45:58 -0000

> Rather than presenting a proxy certificate, the server could present a standard (valid according to PKIX / TLS 1.2 rules) certificate and *separately* present a chain of public keys, ... None of this needs to be in X.509 format.

I'm curious what this new and different but similar structure would be like.   And whether the intended use of this stuff justifies the complexity and creation of all this new stuff, or breaking PKIX compatibility.

I think one way to not break with PKIX is to define a new extendedKeyUsage attribute that says "can sign short-term SSL cert chains"

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

v2.23.0 | Report a Bug | By Email