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

Eric Rescorla <> Tue, 08 March 2016 08:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F97112D560 for <>; Tue, 8 Mar 2016 00:30:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gbUcVNDFZffD for <>; Tue, 8 Mar 2016 00:30:47 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A2FF812D54C for <>; Tue, 8 Mar 2016 00:30:47 -0800 (PST)
Received: by with SMTP id h129so6325536ywb.1 for <>; Tue, 08 Mar 2016 00:30:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with SMTP id d200mr13536459ywb.115.1457425846905; Tue, 08 Mar 2016 00:30:46 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 8 Mar 2016 00:30:07 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Tue, 8 Mar 2016 00:30:07 -0800
Message-ID: <>
To: Henry Story <>
Content-Type: multipart/alternative; boundary=001a114bbc96e45c1e052d8565ac
Archived-At: <>
Cc: "<>" <>
Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.

What more do you think you need?


On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <>

> 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]
> [2]
> [3]
> _______________________________________________
> TLS mailing list