Re: [TLS] TLS 1.3 certificate delegation?

Andy Lutomirski <luto@amacapital.net> Thu, 07 November 2013 20:15 UTC

Return-Path: <luto@amacapital.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 0BC6421E809D for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 12:15:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.696
X-Spam-Level:
X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 TeK-0vnXCQEG for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 12:15:38 -0800 (PST)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CDBD21E8096 for <tls@ietf.org>; Thu, 7 Nov 2013 12:15:38 -0800 (PST)
Received: by mail-vb0-f44.google.com with SMTP id 11so745457vbe.31 for <tls@ietf.org>; Thu, 07 Nov 2013 12:15:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=EFySXiZX7/hFqrQDQCZ7F/6Lwzaqi0i80Dw3AB/hlRw=; b=Hj3BQwSilBn8tt0SmgOvrooNRIb6iXBJk/6zHEzdsNUjhD/AlZQ26OVP3ZZI36IWBM KTG7kWDRNfc6EM9RbVfnMePhW1xBCy1COYlwi5CHd5CrneOAtJegOUuXhFhr6lthscuV ujPcCiOnBm9CkxZWbaYrKs+UpeoiNebFzgLi7CmSJfOAM1fA2C+KvG5H1OBE/abjFR6g Ecoe05aZxcUmpx0nm5kbZaOvFOZNB7aKspZgQEgoFM3PUon5VE7KDNLzMxLn5joa/x4r t2L6LWKLlpX0A13sFpvMNUH5MSI0WxJglnuNaqqjew1wH4OE2a9SCtz5Du+lQiDoWnhK Tq6w==
X-Gm-Message-State: ALoCoQnlcYCk+n5AdZN7UjgIEduj0rofWO2QUR1D81mPV6xwA8Pc1K8PxyBSHvp7nIQX+RB8LMZ0
X-Received: by 10.52.27.243 with SMTP id w19mr6617541vdg.3.1383855330972; Thu, 07 Nov 2013 12:15:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.8.18 with HTTP; Thu, 7 Nov 2013 12:15:10 -0800 (PST)
In-Reply-To: <CEA1320D.8065%carl@redhoundsoftware.com>
References: <527BEF5E.8070704@amacapital.net> <CEA1320D.8065%carl@redhoundsoftware.com>
From: Andy Lutomirski <luto@amacapital.net>
Date: Thu, 07 Nov 2013 12:15:10 -0800
Message-ID: <CALCETrUGfMqVzW3PgKJuLoRpGYuOsSH2SzaXV0DxRdAxhUimmw@mail.gmail.com>
To: Carl Wallace <carl@redhoundsoftware.com>
Content-Type: text/plain; charset="ISO-8859-1"
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: Thu, 07 Nov 2013 20:15:48 -0000

On Thu, Nov 7, 2013 at 12:08 PM, Carl Wallace <carl@redhoundsoftware.com> wrote:
>
> 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.

Interesting -- I'd never noticed that.

That being said, proxy certificates are essentially useless unless all
clients support them.  In the absence of mandatory support or a client
extension indicating acceptance of proxy certificates, they won't be
used.

--Andy