[TLS] Generalising DN's to SAN and IAN in TLS1.3?
Henry Story <henry.story@bblfish.net> Tue, 08 March 2016 08:24 UTC
Return-Path: <henry.story@bblfish.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 557B412D547
for <tls@ietfa.amsl.com>; Tue, 8 Mar 2016 00:24:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
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=bblfish-net.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 055_67nGNvbY for <tls@ietfa.amsl.com>;
Tue, 8 Mar 2016 00:24:04 -0800 (PST)
Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com
[IPv6:2a00:1450:400c:c09::230])
(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 A680812D546
for <tls@ietf.org>; Tue, 8 Mar 2016 00:24:03 -0800 (PST)
Received: by mail-wm0-x230.google.com with SMTP id p65so16932273wmp.0
for <tls@ietf.org>; Tue, 08 Mar 2016 00:24:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=bblfish-net.20150623.gappssmtp.com; s=20150623;
h=from:content-transfer-encoding:subject:message-id:date:to
:mime-version; bh=FOQ5+LdqOT9+su4qneDSIBMD1t7fAFDXRbXTZVhCZRY=;
b=YtCLRvWfyNy6WdE/GXjY2Nkrs3JKMtKWnp7XfsE34lD4cyegguomXU5+pKYYPKrark
N8c+ljIYDj6K9vxl6cigZOpZyUgWure6BSpZLtGc6o74IBBi1Vxbk/VS6Euwg3zBMIdR
5yOoH9l8EGQerjKSsV5HWutQxcoKF582nZP3IqGPOsIpPYBgE7mJeFKrtRCQY5B3kFly
l9F/3nCXunWsqXqxZhlJ1DogkNFNpVYLMYP6bCrPZaost6oGNLpCS181xor0iWl0B8h7
yEdP8Jl/ZwXwG7YnOow+5VwFN9cr5f7ih7w+uDkxcYW8/h7CV6M20f095fvV6+CDePYR
ePIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:from:content-transfer-encoding:subject
:message-id:date:to:mime-version;
bh=FOQ5+LdqOT9+su4qneDSIBMD1t7fAFDXRbXTZVhCZRY=;
b=SXTz7B4pS1POHhCC1ljwsYyD735qq75yGwuOd5gwFQbsp3vILM8qucNJiVWkcO0qPW
mzTHhgF1eU1shPXrgqmkbGzwqFGju/gdy2743aW57wqMud8OJS8LlLyuMeA2XVU/iDI1
eF8Btm5wxEeawNM4A54j9f6GCDujet8lASV08sn7OjZZ3lQq7yNxx7dzTdY39DXNjH0E
ILgLExhWTBi5kwAcxtqtbVqpjQ+zFuftzjd47QWO79xh9ZXghxukN4cFUXqCPL0W76CY
WytiAMEVXG8VbEr84z5askMRT2o9C5tpogCPgUgBBLVUNX3oiBMCjNHQ4Xl+5QBZDE/U
CPsQ==
X-Gm-Message-State: AD7BkJLK7rFTp/e++++z5x3v5L7nRYU4VwlcAMT1Gl3S1nzNW1BWyDEyvwtZGdQITfkV+Q==
X-Received: by 10.28.176.133 with SMTP id z127mr18207150wme.66.1457425442140;
Tue, 08 Mar 2016 00:24:02 -0800 (PST)
Received: from [192.168.0.2] (cpc2-popl3-2-0-cust563.13-2.cable.virginm.net.
[86.21.242.52])
by smtp.gmail.com with ESMTPSA id e4sm2138532wma.10.2016.03.08.00.24.00
for <tls@ietf.org>
(version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128);
Tue, 08 Mar 2016 00:24:01 -0800 (PST)
From: Henry Story <henry.story@bblfish.net>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <BEA18B4D-DCE0-4EF3-806D-30662DB2E288@bblfish.net>
Date: Tue, 8 Mar 2016 08:22:19 +0000
To: "<tls@ietf.org>" <tls@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
X-Mailer: Apple Mail (2.3112)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BpgkUv3lQY9JpODefvF2in3AgxA>
Subject: [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:24:06 -0000
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] Generalising DN's to SAN and IAN in TLS1.3? Henry Story
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Eric Rescorla
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Henry Story
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Henry Story
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Andrei Popov