Re: [TLS] draft-rescorla-tls-subcerts

Peter Gutmann <> Fri, 08 July 2016 03:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8616B12D093 for <>; Thu, 7 Jul 2016 20:29:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.626
X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zqswUDYXXB_4 for <>; Thu, 7 Jul 2016 20:29:01 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3646912B03C for <>; Thu, 7 Jul 2016 20:29:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1467948541; x=1499484541; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=v22JDF6VjCTRRvyiqoU1y8YUpmZ30zxdRqSwocDfQvo=; b=Nq3hTZVot77JODMIlMaqDsySE0/nq7G3WAWaG+SPyEz6qT39LKMRshl7 RkEiqgaMih0kZZ3BCDN0KYUbRRmYQqRrEmzjY2Ha7RyKCNbb4yWSvqcLs iZRYEh1uNsCfLCRIQVod9N0m98mRBKpBm1nvhx9uPQdiaSeEP3MxG5YdZ Fv+UdLn//x10DI3XScxFo7B3ScVejA/5kbMS6dUncDyUNO3J4iZ7kD6hg MsWE4A2yjVtIVg9knHiMWlducOJlMyg5QlLq3DJ2rXtwecOS76Gly70D9 Z4PkBkvA8j8Ha9bRI/CVqzCwjn/I0cfpX9fbFtn1q106V2HoadEogGkrT w==;
X-IronPort-AV: E=Sophos;i="5.28,327,1464609600"; d="scan'208";a="95637560"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 08 Jul 2016 15:28:58 +1200
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Fri, 8 Jul 2016 15:28:58 +1200
From: Peter Gutmann <>
To: Eric Rescorla <>, "" <>
Thread-Topic: [TLS] draft-rescorla-tls-subcerts
Thread-Index: AQHR2IXg2E2zYiv3ukOGpCbMgJc8F6AN4CtN
Date: Fri, 08 Jul 2016 03:28:57 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [TLS] draft-rescorla-tls-subcerts
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 08 Jul 2016 03:29:06 -0000

Eric Rescorla <> writes:

>We've talked several times about designing some sort of TLS delegation
>mechanism. A few of us got together and put together some initial thoughts
>about the options at:

That's going to be a tricky one.  The PKIX standing committee has always
rigidly (and in some cases I'd say rabidly) opposed anything that would allow
end users to bypass CAs (in one case the WG chair killed a proposal for
delegated certs with the comment "we don't want to turn X.509 into PGP").
Admittedly PKIX is now defunct, but there are still enough PKIX members in the
IETF that it could be tricky getting anything done.

Another issue is how you're going to do it.  You really need to have an EE
able to use a standard cert to issue short-term certs for high-exposure
environments, so only the high-risk key needs to be online.  One of the
proposals for this (which I have a link to, since I wrote it in this case)

This talks about all of the issues involved.

The alternative is to use a cert to sign "credentials", whatever form that may
take.  That's going to get ugly since you're now introducing something that's
in effect a certificate, but isn't called a certificate (yes, you can whittle
it down a bit, but eventually you'll want to add more features, and end up
reinventing certs). 

I would go for delegated certs, since 99% of the work is already done for you
(formats, data types, how to process them, code to handle them, etc).