IETF Logo Mail Archive

Re: [TLS] Commentary on the client authentication presentation slides

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 24 July 2015 06:42 UTC

Return-Path: <Andrei.Popov@microsoft.com>
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 7F98F1A8AEE for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 23:42:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 P4qgk7A24muv for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 23:42:37 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0765.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::765]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5AD21B2F65 for <tls@ietf.org>; Thu, 23 Jul 2015 23:42:35 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 24 Jul 2015 06:42:19 +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.0225.018; Fri, 24 Jul 2015 06:42:19 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Thread-Topic: [TLS] Commentary on the client authentication presentation slides
Thread-Index: AQHQwvXiSxNxWYXIoUOvWC1ZP+t1vJ3qDNvQgAAiSACAAAH3wA==
Date: Fri, 24 Jul 2015 06:42:19 +0000
Message-ID: <BLUPR03MB139614A88DC6895B3CBCEA908C810@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <20150720141036.GA32204@LK-Perkele-VII> <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com> <20150724063236.GA8759@LK-Perkele-VII>
In-Reply-To: <20150724063236.GA8759@LK-Perkele-VII>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: elisanet.fi; dkim=none (message not signed) header.d=none;
x-originating-ip: [90.181.160.186]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:y0ZSuQ+24mZb/9AkDLyY7B7TN0RPdnfZkTBwQ0yeX2fD5RiZuAxxheTFVIoGQiMV0h8pm5aQRLUcifajegRf2Q4rAetaFCgfsMGp5xFiPSfzCkIOJY08xhbvt66l1gPxsbgWD/qwNn2FMkI2GWwMlw==; 24:G9mEWV+fTuKFxP1PCfzISWyOtMhjmsw92SIsyAHfkMaQEaHynBXMGYyKV+C35ENmbwyweunZ/nqPUXgz4O/DVdaGI7mNCxaL4rtpEI2828w=; 20:UDmep9kYRqY0QKO5u49Kdq+WdPboYdvK3DkCi+OZAq9jULBT4wVTL/6ijTgNbBTuDXTilntjdyNnH42juHnm3A==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396;
blupr03mb1396: X-MS-Exchange-Organization-RulesExecuted
x-microsoft-antispam-prvs: <BLUPR03MB1396E8A7E3C704551ADCE41C8C810@BLUPR03MB1396.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396;
x-forefront-prvs: 0647963F84
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(13464003)(19580405001)(46102003)(2950100001)(76576001)(87936001)(110136002)(2656002)(5001960100002)(40100003)(74316001)(2900100001)(50986999)(86362001)(122556002)(19580395003)(92566002)(10090500001)(33656002)(62966003)(5002640100001)(54356999)(77156002)(77096005)(106116001)(76176999)(5003600100002)(99286002)(102836002)(189998001)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2015 06:42:19.6130 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SiGjekFg4UhNqnuPN8ve-SdvEzA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
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: <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: Fri, 24 Jul 2015 06:42:38 -0000

Sound good to me; if the group agrees to remove certificate_types, I'll make this change in the PR.

-----Original Message-----
From: Ilari Liusvaara [mailto:ilari.liusvaara@elisanet.fi] 
Sent: Friday, July 24, 2015 8:33 AM
To: Andrei Popov
Cc: tls@ietf.org
Subject: Re: [TLS] Commentary on the client authentication presentation slides

On Fri, Jul 24, 2015 at 05:01:37AM +0000, Andrei Popov wrote:
> 
> > - The certificate_types field in CertificateRequest is pretty much  
> > useless, since all supported algorithms are of signature type.
> If the signature_algorithms extension officially becomes MTI, then 
> perhaps we can discus getting rid of certificate_types in the 
> CertificateRequest. Except we may want to use this field when we 
> introduce new certificate types (e.g. something like IEEE1609 certs).

Don't confuse signature_algorithms extension and supported_signature_algorithms field of CertificateRequest. Those two carry similar tasks in opposite directions, except that ssa is REQUIRED with signature certs.

There are seemingly no defaults for SSA, so it has to be non-empty for signature certs to work at all.

And all present types of TLS 1.3 key exchange can only use signature certs.

As for IEEE1609 certs, those are negotiated via certificate format negotiation, which is entierely separate mechanism (described in RFC 7250), not involving CertificateRequest message at all.


-Ilari

v2.23.0 | Report a Bug | By Email