Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3?
Andrei Popov <Andrei.Popov@microsoft.com> Wed, 16 March 2016 17:02 UTC
Return-Path: <Andrei.Popov@microsoft.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 7733A12DA1A for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 10:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.013
X-Spam-Level:
X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com
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 2cSdQxoAmY8A for <tls@ietfa.amsl.com>; Wed, 16 Mar 2016 10:02:19 -0700 (PDT)
Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0145.outbound.protection.outlook.com [207.46.100.145]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336AF12DA00 for <tls@ietf.org>; Wed, 16 Mar 2016 10:02:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=EdnHURPv1xLlZx7/mwX6sevup5H3AzFCiY3jcgrkUDU=; b=h3ZH9dr+887jdvgC/BthFn7yO6mrMiDfOI2BsF+Sc51QHbPmOFPr9aiwz5toHedjU72Lk5M9bYvDvUNqPBdC3omPeCIwu4PuUjs2Xa+BSoLFD5JqiqaGTL7//MbrK1INws81JKitjL2BFMFS55iqSrdfQ/VCbBUm5apJMMbTgH4=
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.434.16; Wed, 16 Mar 2016 17:02:15 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0434.016; Wed, 16 Mar 2016 17:02:16 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Henry Story <henry.story@bblfish.net>, Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [TLS] Generalising DN's to SAN and IAN in TLS1.3?
Thread-Index: AQHReRPpyna+fmf6VEO5ENmKma0iPJ9PN0iAgAzNgACAAFFmUA==
Date: Wed, 16 Mar 2016 17:02:15 +0000
Message-ID: <BLUPR03MB1396523ABE524DE9528EAB318C8A0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <BEA18B4D-DCE0-4EF3-806D-30662DB2E288@bblfish.net> <CABcZeBOGjD0Po2j2wK3+5wMw=SUHp-C=JQCyYAL4c3Z0ojkCdA@mail.gmail.com> <3E4912F8-55D6-45E9-AD52-7081ADC3306C@bblfish.net>
In-Reply-To: <3E4912F8-55D6-45E9-AD52-7081ADC3306C@bblfish.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: bblfish.net; dkim=none (message not signed) header.d=none;bblfish.net; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2001:4898:80e8:7::1d2]
x-ms-office365-filtering-correlation-id: 666dc3da-847c-4e20-1183-08d34dbcba17
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:ma0jP9HBxB2w2YQrfY4mrR4GXhsY8mK8RkTXEPGDrgtJ4HTVTfgJkxTMg0/+7aJMWCO8cY1k37GYf2C4Qn743Fmx+9uDwqQ+VSEc+zaSN1YwCPO+PU9Th4qm2XENeQHSsRtat03+2Zbjw58NOiAruQ==; 24:io7XWZY1hqJ+vAgf6m1owCkUqMV98eT3MoQfltx/roNWqTt3O+o/pe1Q/89jszc5pB8+WqrC5uCaaMUMI0yY8N8yDrzKGrOG2ZojOXLDzRw=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394;
x-microsoft-antispam-prvs: <BLUPR03MB1394B0BD09F92D271E1E49FB8C8A0@BLUPR03MB1394.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394;
x-forefront-prvs: 08831F51DC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(19625215002)(2950100001)(106116001)(2906002)(50986999)(790700001)(54356999)(5001770100001)(76176999)(5008740100001)(102836003)(586003)(33656002)(6116002)(2900100001)(122556002)(92566002)(76576001)(16236675004)(1220700001)(10090500001)(189998001)(19609705001)(19617315012)(3280700002)(1096002)(86362001)(5004730100002)(77096005)(87936001)(5002640100001)(5005710100001)(19580405001)(10400500002)(19300405004)(15975445007)(3660700001)(81166005)(99286002)(74316001)(5003600100002)(10290500002)(4326007)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BLUPR03MB1396523ABE524DE9528EAB318C8A0BLUPR03MB1396namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Mar 2016 17:02:15.8024 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/98LWDEcf1Q7AoI-Ub1EDa3bSVHI>
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: Wed, 16 Mar 2016 17:02:23 -0000
Hi Henry, Extension_data field can be zero-length: opaque extension_data<0..2^16-1>; The TLS 1.3 draft specifies matching rules for two extensions: KU and EKU and then says: "Separate specifications may define matching rules for other certificate extensions." Which means that you should be able to specify matching rules e.g. for SAN or IAN where zero-length extension_data is interpreted as a wildcard. Getting TLS/PKI implementations to implement this new specification is a different matter, of course. Cheers, Andrei From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Henry Story Sent: Wednesday, March 16, 2016 5:01 AM To: Eric Rescorla <ekr@rtfm.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] Generalising DN's to SAN and IAN in TLS1.3? On 8 Mar 2016, at 09:30, Eric Rescorla <ekr@rtfm.com<mailto:ekr@rtfm.com>> wrote: CertificateRequest already allows you to pass an arbitrary number of extensions by OID. http://tlswg.github.io/tls13-spec/#certificate-request<https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2ftlswg.github.io%2ftls13-spec%2f%23certificate-request&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c33df174362e14a4ecbff08d34d929747%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=FzrdfaiUYUyTdLlsZCwbUh%2bUIlkC2hkn1P5ddVvlzFo%3d> What more do you think you need? Perhaps what would be needed in addition would be wildcard support. Eg, it would be useful to say: Give me certificates that contain an extension without specifying the value of the extension. Eg: give me a certificate that contains a SAN or IAN, I don't care what value of those are. Is that allowed? I don't see anything regarding it when reading that section. But I may be missing something. -Ekr On Tue, Mar 8, 2016 at 12:22 AM, Henry Story <henry.story@bblfish.net<mailto: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<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-thomson-http2-client-certs-01&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c33df174362e14a4ecbff08d34d929747%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=d4LzRaMT9DseDT9yUzMfmieb6t8R%2bBFiNGq3FzkudoA%3d> [2] https://www.w3.org/2005/Incubator/webid/spec/identity/#overview<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2005%2fIncubator%2fwebid%2fspec%2fidentity%2f%23overview&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c33df174362e14a4ecbff08d34d929747%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=aP7%2bh%2fT5QobK9NBUk4uek52c8aCRSJUhDJYmjtxomYA%3d> [3] https://www.w3.org/2005/Incubator/webid/spec/tls/<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.w3.org%2f2005%2fIncubator%2fwebid%2fspec%2ftls%2f&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c33df174362e14a4ecbff08d34d929747%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=zs43f%2f2stuCfS5N5SBL3FAm3y4EVxFCd7GwOLyiNse8%3d> _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c33df174362e14a4ecbff08d34d929747%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=52jCoXe9vX7LjRyzR34OgzCZqSqpjNjOfDNvcG3CkqA%3d>
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Eric Rescorla
- [TLS] Generalising DN's to SAN and IAN in TLS1.3? 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… Henry Story
- Re: [TLS] Generalising DN's to SAN and IAN in TLS… Andrei Popov