Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?

Eric Rescorla <ekr@rtfm.com> Tue, 08 March 2016 08:30 UTC

Return-Path: <ekr@rtfm.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 4F97112D560 for <tls@ietfa.amsl.com>; Tue, 8 Mar 2016 00:30:49 -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=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbUcVNDFZffD for <tls@ietfa.amsl.com>; Tue, 8 Mar 2016 00:30:47 -0800 (PST)
Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 A2FF812D54C for <tls@ietf.org>; Tue, 8 Mar 2016 00:30:47 -0800 (PST)
Received: by mail-yw0-x233.google.com with SMTP id h129so6325536ywb.1 for <tls@ietf.org>; Tue, 08 Mar 2016 00:30:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dfAhUr9ogJWS6SX3QFZGOBXSx1okIOWpBEnRAPyeDXA=; b=d6wYokZrY6W+xy8fq7vKyG/ya7twFk8GqjkTh4Be86Gdw5XDHM9pR6BVvWZcxrpQbr VDdFsd9cvxUDXqE7jJIuWdhRHyMtvtj94Y1dzBhtOktep6FUV76LUsVetKv4OHPqGbO2 AZA6/ACqq26xWubaavB3FwIzGcjIaC+QWgBs2/L7+pd0kzKTQwIYr0gDiRZwlgeZT7ID 9onO3M2agySGHVz0iv/ZG4oGBVHJBM8ZQ3GzHd4AohrfLUgz7BC2kQOJ+aNTsrHuAnzv ybOQDNuGKdOZd8EyujFGUshkHrghrUMFewwuyuDhQ1eKF3Xz+qHnhKP4xteB7FJDsPYz QSTQ==
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; bh=dfAhUr9ogJWS6SX3QFZGOBXSx1okIOWpBEnRAPyeDXA=; b=ZVSZ6WZLfwKg75u6D3Rx4ya95J0Zu6xoqDSaUQi989j7UA+UNVHpD/TNDs/Y62jLGr x66Y4rnvIh43dpO+beSw0waiPhVTas/KN0G6J1UJHxTY/uQU2ybbVkEOrLKy4OKv1qda 0ke1OoCFrYpJYfE3UJ/dqHNmfrKYNWMldP3NFnfPN4cYl7JvG4jGhmbdK4xxUA1JFKwi JG9iOcfbAN6uPAKn9pKWjCdhNFBlQV0rNBO0jF3XsfIVveVozWlBiJkCA3QRwSWR0Sny fjiAamupkUnaiDMWwBBC2qSVrTwQuz1iaJekR/unA1LIzeh2LaTu1ZLZrtZqCsUuow+2 h6Dw==
X-Gm-Message-State: AD7BkJJ2ejW/cNiHX1iN3um3GyndmYPVQbmEJqgNpH70vDICtTR1MqWnQVR4dL9I3MLvIKHbJM6z+X1paOqorw==
X-Received: by 10.129.79.209 with SMTP id d200mr13536459ywb.115.1457425846905; Tue, 08 Mar 2016 00:30:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.13.249.5 with HTTP; Tue, 8 Mar 2016 00:30:07 -0800 (PST)
In-Reply-To: <BEA18B4D-DCE0-4EF3-806D-30662DB2E288@bblfish.net>
References: <BEA18B4D-DCE0-4EF3-806D-30662DB2E288@bblfish.net>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 8 Mar 2016 00:30:07 -0800
Message-ID: <CABcZeBOGjD0Po2j2wK3+5wMw=SUHp-C=JQCyYAL4c3Z0ojkCdA@mail.gmail.com>
To: Henry Story <henry.story@bblfish.net>
Content-Type: multipart/alternative; boundary=001a114bbc96e45c1e052d8565ac
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/O62HD-M4JZL5-Jx17jYtew7ZY_k>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?
X-BeenThere: tls@ietf.org
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." <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: Tue, 08 Mar 2016 08:30:49 -0000

CertificateRequest already allows you to pass an arbitrary number of
extensions by OID.

http://tlswg.github.io/tls13-spec/#certificate-request

What more do you think you need?

-Ekr


On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfish.net>
wrote:

> Hi,
>
>
>   I was reading with interest M. Thomson and M. Bishop's
> "Reactive Certificate-Based Client Authentication" draft RFC [1].
> In the section 2.3 "The CERTIFICATE_REQUEST Frame"
>
> [[
>       CA-Count and Certificate-Authorities:  "Certificate-Authorities" is a
>       series of distinguished names of acceptable certificate
>       authorities, represented in DER-encoded [X690] format.  These
>       distinguished names may specify a desired distinguished name for a
>       root CA or for a subordinate CA; thus, this message can be used to
>       describe known roots as well as a desired authorization space.
>       The number of such structures is given by the 16-bit "CA-Count"
>       field, which MAY be zero.  If the "CA-Count" field is zero, then
>       the client MAY send any certificate that meets the rest of the
>       selection criteria in the "CERTIFICATE_REQUEST", unless there is
>       some external arrangement to the contrary.
> ]]
>
> Would it not be possible to extend that so that one could also pass
> issuer Alternative Names, and not just DNs?
>
> Using DNs made sense when it was thought that LDAP and X500 would
> end up being the protocols for global directories. This turned out
> not to be the case. It turned out that DNs were a special case of
> what could be termed a URI (even though DNs are not in URI format).
> And many (most?) URIs can refer to agents, least but not last
> http(s) URLs (See the WebID spec [2] for a nice diagram of how this
> works conceptually and the WebID-TLS spec for one way this can be tied
> to TLS [3]).
>
> If TLS1.3 could start moving away from sole reliance on DNs this
> would open quite a lot of possibilities, including the ability to
> build institutional Webs of trust for CAs (ie trust anchors could
> list CAs by reference at one or more levels of indirection), and CAs
> could also describe themselves at their URI.
>
> Those last two paragraphs are just hints of some possibilities that
> could emerge from moving away from DNs that I can think of. Others
> members of this group will certainly find other possibilities.
>
> In any case it seems that the time for DNs is passed, and that
> one should perhaps move away from reliance on those and generalise
> this part of TLS.
>
> Henry
>
>
>
> [1] https://tools.ietf.org/html/draft-thomson-http2-client-certs-01
> [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview
> [3] https://www.w3.org/2005/Incubator/webid/spec/tls/
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>