IETF Logo Mail Archive

Re: [TLS] TLS 1.3 certificate delegation?

Carl Wallace <carl@redhoundsoftware.com> Thu, 07 November 2013 20:08 UTC

Return-Path: <carl@redhoundsoftware.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 E155821E8096 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 12:08:36 -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 BbZ8xTTBR-MQ for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 12:08:31 -0800 (PST)
Received: from mail-pd0-f170.google.com (mail-pd0-f170.google.com [209.85.192.170]) by ietfa.amsl.com (Postfix) with ESMTP id 988F321E8137 for <tls@ietf.org>; Thu, 7 Nov 2013 12:08:28 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id v10so1092131pde.29 for <tls@ietf.org>; Thu, 07 Nov 2013 12:08:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=cs7hrfWaImzGPQ0QeGhESvE0XjDs+xFF39d/SmzOMhs=; b=D3UCZrO+ZnRdw1uMAdsZ0V/CIVGH+tEZNzQXpeQvZ/q2R2Rb6HoL4Mzbl20AgLU5LR 0VcpwuBaxIzWnRYRSAgow8CJ+eXiE53b6SvixAgEGr1lTdO3AZVTFWHHunb3nEKsQ8oV OuFwQ8iOpPTkkGMxJLo7p5Pfusa+Tio9zyJ/Q5kFg6XgPjIuUmZQGuKs4QHWB/7yzv2B e8x4QJ59fvO4ZeDnvzVV0B75eap0E60VTRdAUR+H9gm5qvZdDxKmcqBUtRUaOLI2zcPj WMq7US76Ee96DofTBfyPi4ReZTGCJ54nS9F3g/+asV4hK0ei6+1bUVyNnMw1dutpLaln cU4Q==
X-Gm-Message-State: ALoCoQkGlCIFAVXJ3ZugM+An/s81IZVpyzBYS0sBtI0nasG1YDIHNxxRSj9H+S1+1GuH/GhyDHjQ
X-Received: by 10.68.133.198 with SMTP id pe6mr10971382pbb.10.1383854907923; Thu, 07 Nov 2013 12:08:27 -0800 (PST)
Received: from [192.168.0.131] (S01061caff7df80fa.vc.shawcable.net. [24.85.69.194]) by mx.google.com with ESMTPSA id zq10sm8555030pab.6.2013.11.07.12.08.26 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 07 Nov 2013 12:08:27 -0800 (PST)
User-Agent: Microsoft-MacOutlook/14.3.8.130913
Date: Thu, 07 Nov 2013 12:08:21 -0800
From: Carl Wallace <carl@redhoundsoftware.com>
To: Andy Lutomirski <luto@amacapital.net>, "tls@ietf.org" <tls@ietf.org>
Message-ID: <CEA1320D.8065%carl@redhoundsoftware.com>
Thread-Topic: [TLS] TLS 1.3 certificate delegation?
In-Reply-To: <527BEF5E.8070704@amacapital.net>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
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: Thu, 07 Nov 2013 20:08:37 -0000

On 11/7/13 11:51 AM, "Andy Lutomirski" <luto@amacapital.net> wrote:

>I'm not sure that this is in scope for TLS 1.3, but if it were part of
>TLS 1.3 then servers could send different certificates to clients
>depending on TLS version.
>
>Currently, if an organization wants to use a wildcard certificate, every
>web server must possess (or at least be able to use) the associated
>private key.  Similarly, if an organization wants to use short-lived
>keys, it must ask its CA to sign a large number of short-lived
>certificates.
>
>In principle, a server could present a certificate chain like this:
>
>1. trusted root
>    |
>    V
>2. intermediate CA  (owned by outside authority)
>    |
>    V
>3. non-CA (wildcard?) certificate  (owned by the server's operator)
>    |
>    V
>4. short-lived or domain-specific certificate

Proxy certificates should accomplish what you want. See RFC3820.

v2.23.0 | Report a Bug | By Email