Re: [TLS] TLS 1.3 wishlist

Henry Story <henry.story@bblfish.net> Sat, 07 December 2013 10:16 UTC

Return-Path: <henry.story@bblfish.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D501C1AE043 for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 02:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 udhX0SxUcN8J for <tls@ietfa.amsl.com>; Sat, 7 Dec 2013 02:16:07 -0800 (PST)
Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id B91211AD72A for <tls@ietf.org>; Sat, 7 Dec 2013 02:16:06 -0800 (PST)
Received: by mail-wg0-f43.google.com with SMTP id k14so1649901wgh.22 for <tls@ietf.org>; Sat, 07 Dec 2013 02:16:02 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=KxZhhNnkMLS2ybsgwJNSJ0nNXnCAxeJcR2n+MCh/My4=; b=kvCnTxB/lQZOyBXIvcqsegvf9jfGB4zMFKQgnLi+gN+RGuMa2/NlNA79oiEw2VJQVX feDgp6uJqoaHHA4OymahkaK1pJyxFqo4aLWKR5Xe8lKnXY6Rkent+DOvs6tVpQE9uV9u vOkCcoNk09ld9RF5zvPf7/yGkTeOTJ/0npcHF8tS/ejMf9z0vutN9KFiJeGmiGNjhO8U u2Nhf4ficpJ72JIOEm7VtBxeglKwROAERPZZcIU+m0q0vk1Yzd2IjTaelAik0p2+wWpM cxzp0E3J2s3cqIyisE9NNFebl1Z13al3EZYdPtGgzlsnxwdx6MUSzx0whclNXE9cJrXW m+jQ==
X-Gm-Message-State: ALoCoQlmY9Km/aC3GfAhzP+VBxxi07MHEnYr4V2WxwLNCH5hIzrzPJw6P+c3tq97vhToZrbgGJo6
X-Received: by 10.180.101.41 with SMTP id fd9mr6404417wib.14.1386411362120; Sat, 07 Dec 2013 02:16:02 -0800 (PST)
Received: from bblfish.home (AAubervilliers-652-1-119-108.w83-200.abo.wanadoo.fr. [83.200.86.108]) by mx.google.com with ESMTPSA id nb16sm4184806wic.0.2013.12.07.02.15.59 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 07 Dec 2013 02:15:59 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Henry Story <henry.story@bblfish.net>
In-Reply-To: <5239F4C9.5090805@pobox.com>
Date: Sat, 7 Dec 2013 11:15:56 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <01CA3CC6-C3C4-4412-80F8-E7101BA5C209@bblfish.net>
References: <5239F4C9.5090805@pobox.com>
To: Michael D'Errico <mike-list@pobox.com>
X-Mailer: Apple Mail (2.1822)
Cc: TLS Mailing List <tls@ietf.org>, public-webid WebID Group <public-webid@w3.org>
Subject: Re: [TLS] TLS 1.3 wishlist
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 07 Dec 2013 10:16:08 -0000

On 18 Sep 2013, at 20:45, Michael D'Errico <mike-list@pobox.com> wrote:

> A "wish list" for an upcoming new version of TLS is available
> online (I found it via a message on Twitter):
> 
> https://www.ietf.org/proceedings/87/slides/slides-87-tls-5.pdf
> 
> Is it appropriate to discuss this now, prior to rechartering?

Hi,

  One thing that would be nice would be some way of having more flexibility
for the server to request a client certificate. In TLS 1.2 it seems
the only way to do this is to use the certificate_authorities
list. 

  With WebID over TLS [1] a server may in fact be satisfied if the 
Client certificate contains a WebID in the Subject Alternative Name.
But this then leaves the question open as to how the server can transmit
to the client it's ability to accept such certificates.

The only solution currently available that I know of 
would be to create a CA with DN such as

   CN=WebID, O={}

that every WebID enabled certificate would claim it is signed by (somewhere
in the certificte chain)

Then this could be passed by the server in the certificate_authorities
list as specified in http://tools.ietf.org/html/rfc5246#section-7.4.6


Some people are worried that this would require CAs to resign their root
CAs with a WebID certificate in case they wanted to release WebID 
certificates.

Is there a better way to do this currently? Could there be a better 
way to do it?


Henry


[1] https://dvcs.w3.org/hg/WebID/raw-file/tip/spec/index.html


Social Web Architect
http://bblfish.net/