[TLS] draft-rescorla-tls-subcerts-01

Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 21 April 2017 08:37 UTC

Return-Path: <hannes.tschofenig@gmx.net>
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 C8394129420 for <tls@ietfa.amsl.com>; Fri, 21 Apr 2017 01:37:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1kVrPs-lmaF for <tls@ietfa.amsl.com>; Fri, 21 Apr 2017 01:37:27 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4243129AF7 for <tls@ietf.org>; Fri, 21 Apr 2017 01:37:26 -0700 (PDT)
Received: from [192.168.91.191] ([195.149.223.176]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LrZOj-1c0LVO1MNB-013RM2 for <tls@ietf.org>; Fri, 21 Apr 2017 10:37:23 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
To: "<tls@ietf.org>" <tls@ietf.org>
Message-ID: <bea3cb60-fdfc-950f-f628-90eb87ed42ef@gmx.net>
Date: Fri, 21 Apr 2017 10:37:21 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="fixtobeic9LXj5qokmBqQjpd8lMHLwfou"
X-Provags-ID: V03:K0:UqqL7aCK9Oh1dt+s3efWhjg95JqVCQX1aifNqXWyh+bsmeXGnz1 GgIaVqYK4DsFVOmbArCkkGU7mRNMskqKCmF18oaSRCuAOmjLeyGGuCLwD7PMfd8Q/4JSrWj XOQpSnbwJogwWgnQfMCcO8Jvr25iUWUuYYtNTlSpSPmPSdu06ZtZbRWHx+XUQ94B9cZ18D1 /mc61AABQHojjIvl9BJ5g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:2xa7FF0ARqw=:NvRDFDTfKhYhm44060Eh/n nT6VptDxSwNL6zvbwX6UMlQxwt3sEaj3eFsWAbnxZQOVFdoiMXW1lo2Wt4M34As5aRTGo6s77 XBcXsV1aCx7jE+W52qiS2cGFkzGuEKsbugufyJYh84ZXG/vk6kvSjFr6MxKYXxHTMQ0Uk+bG/ 6n4rKraCqtkAIH0f/o57LA7VIlCs3YUsoa4rPBDdK5MRY3pMSdHzcqHlOyUM2PztGShgNtZ87 JvuY0aoqv6/Cl9Re515DEGz+UulYnWlKWBsr+Nox+74fZmHaomCWRh7kSls0RKCPlFAcjtobo a+86WRNzn4NkB4XPTa8/4rtEwCfv0sCuIinGxoHnMQyzWZs3k1rpHRhVH9cOyKpBn8P0gf4rS Z8dFclsfGpVgXHDznuux45yCYyK/+ZNyFrle2KyEiU8czSlpPFor5Und5NSwLGQeiR4sSen63 4w/vuFcoMWfv+R4hsRIFJzQu0bAvveQB8f3VxR9/9Ycg7rp6MxKbFvnxk2VaYaUmaJ+ZbPeQo 95pr9ojkHgeJP8p4wCXXUrZTvIeCn0hSZ8TMsH7ZSuKIrHdk1d1sfVNav2qJmrekIg9qgINjh XJOj5iE21FKCBIkbyEXPRj4BeZ6A94FWKdYuAwVtwK7XvQAOoEyucs+DLMBz2PDKqRRqXb58V 2LtJ6vfHlBx/oHhfzNx4ZXk71A1vyD1R1CMS0x9qDDOTLbI77n0rXw6jduRdwcAy7xcCoyup1 6tBSGlD6T2V6FM23g2Z7r2o/XCOyFDtC/wWJyU5xabBuPFBeOKiDIlV4TxM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pE-vFia9rPK7qrUs9Z76IYmpeqM>
Subject: [TLS] draft-rescorla-tls-subcerts-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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, 21 Apr 2017 08:37:29 -0000

I read through draft-rescorla-tls-subcerts-01 and I ran into some basic
questions.

I have been wondering why the TLS server operator obtains an end-entity
certificate from a CA (which cannot be used to sign further
certificates) instead of running an intermediate CA him-/herself
instead. This would work without requiring any changes to the client
side. The proposed solution, although technically feasible, will
unfortunately take a long time to deploy since it requires cooperation
from clients, servers, and also from CAs.

What is also not clear to my why some of the certificate management
protocols, which provide the necessary level of automation, cannot be
used with CAs to request short-lived certificates.

Ciao
Hannes