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

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 24 July 2015 06:32 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
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 2302C1B2F68 for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 23:32:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 YnOm7UoWTLP3 for <tls@ietfa.amsl.com>; Thu, 23 Jul 2015 23:32:40 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00DD61A92F6 for <tls@ietf.org>; Thu, 23 Jul 2015 23:32:39 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id DE3A71A26DE; Fri, 24 Jul 2015 09:32:36 +0300 (EEST)
Date: Fri, 24 Jul 2015 09:32:36 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Message-ID: <20150724063236.GA8759@LK-Perkele-VII>
References: <20150720141036.GA32204@LK-Perkele-VII> <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/JY780vSD_XvRhQYErPMFzLpXzPg>
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:32:42 -0000

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