Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated

Wang Haiguang <> Thu, 27 December 2018 08:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3794F128D09 for <>; Thu, 27 Dec 2018 00:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JE90c9vSZXcs for <>; Thu, 27 Dec 2018 00:10:04 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 826A11200D7 for <>; Thu, 27 Dec 2018 00:10:04 -0800 (PST)
Received: from (unknown []) by Forcepoint Email with ESMTP id 25DC9C8FDFF19 for <>; Thu, 27 Dec 2018 08:10:00 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 27 Dec 2018 08:10:00 +0000
Received: from ([]) by ([]) with mapi id 14.03.0415.000; Thu, 27 Dec 2018 16:09:53 +0800
From: Wang Haiguang <>
To: "" <>
CC: "" <>
Thread-Topic: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated
Thread-Index: AdSc+ToMK5SgJR+fTtWsM2NRX2mmLP//3EsA//5YoiA=
Date: Thu, 27 Dec 2018 08:09:52 +0000
Message-ID: <>
References: <> <20181226145106.GA6893@LK-Perkele-VII>
In-Reply-To: <20181226145106.GA6893@LK-Perkele-VII>
Accept-Language: en-SG, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated
X-Mailman-Version: 2.1.29
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: Thu, 27 Dec 2018 08:10:10 -0000

Dear Ilari,

Thanks very much for the suggestion.  We need some time to discuss and will reply back to the mailing list as soon as possible. 

Happy new year!


-----Original Message-----
From: [] 
Sent: Wednesday, December 26, 2018 10:51 PM
To: Wang Haiguang <>
Subject: Re: [TLS] A new draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)" has been updated

On Wed, Dec 26, 2018 at 09:00:08AM +0000, Wang Haiguang wrote:
> Hello, everyone
> We have just updated the internet draft for "Using Identity as Raw Public Key in Transport Layer Security (TLS)". 
> In this draft, we propose to use the Identity as raw public key, which further simplifies authentication and identity management of large scale IoT devices. 
> The updating are mainly in the IANA consideration part. 
> We have some IANA related issues that need expert from this group to help:
> 1) TLS protocol require OID to identify an signature algorithm used in authentication and key exchange. 
>      However, the identity-based signature algorithm (ECCSI) specified by IETF in RFC 6507 does not have an OID yet. 
>      We have written to IANA for consideration but do not get it yet. 

Also, Huawei seems to have an OID arc...

> 2) TLS cipher suites and a  few TLS registries need to be updated also, by adding in the relative names for ECCSI: 
>      * TLS  cipher suites

This registry seems to be specification required.

>      * TLS TLS KeyExchangeAlgorithm Registry

From what I can tell, there is no such registry. The key exchange algorithms seem to be specified in the RFCs themselves.

>      * TLS ClientCertificateType Registry

Specification required range exists.

>      * TLS SignatureAlgorithm Registry

Note that SignatureAlgorithm registry has all entries reserved, it does not have unassigned codepoints. Instead, request SignatureScheme assignment, and specify if it is valid for TLS 1.2 or not. From the above registry requests, I would guess it is meant to be valid in TLS 1.2.

> Although the draft is still personal draft , some telecom customer 
> want to use TLS+ECCSI in their network for IoT  device authentication.
> Therefore, is it possible for IANA to assign value for above TLS 
> registries and OID for ECCSI since ECCSI is specified by IETF?
> Please give us some suggestion on the OID and TLS registries updating issues.
> Below is the link to our recently uploaded draft. 
> h-ibc-03.txt

Some other comments:

- Why is this seemi~ngly only specified for TLS 1.2? I am not seeing any
  obstacles to porting this to TLS 1.3 in fairly straightforward
  manner. The only problematic aspects I see are:
  - Using SignatureAlgorithm, but I do not think that would work in
    TLS 1.2 either (use SignatureScheme instead).
  - The weird preference signaling for client signature via
  For TLS 1.3, new ciphersuites, key exchange algorithms and client
  certificate types would be unnecressary (the last two do not even
  exist in TLS 1.3, with first the standard algorithms should work).
- Section 2 references RFC 2119 and not RFC 8174 (I have seen complaints
  about this).
- Section 2 seems to be missing "NOT RECOMMENDED" (or if the list is
  supposed to be minimal, "RECOMMENDED" does not seem to be used
  anywhere (this is actually an errata on RFC 2119).
- Section 3 has "SubjectECCSIPublicKeyInfo" in figure 1 title. I
  suppose that should be "subjectPublicKeyInfo"?
- Section 3 has mechanism to fetch the parameters from URL. Those
  parameters should be strongly checksummed (e.g., SHA-256). Also, the
  risks of fetching information from URL as part of handshake (probing,
  pointing at some large file, etc...) should be considered.
- Section 4 references RFC 4492. Use RFC 8422 instead.
- Section 4 defines AES-CBC cihpersuites. No new ciphersuites using
  AES-CBC are to be defined. Use AES-GCM and/or Chacha20-Poly1305
  instead. The usual hash algorithms are SHA-384 for AES-256-GCM and
  SHA-256 for AES-128-GCM and Chacha20-Poly1305.
- Section 5 has "ANSI.1 structure for CertificateRequest" I presume
  that should be "TLS 1.2 structure for CertificateRequest". 
- Section 5: Since eccsi_sign in ClientCertificateType is actual
  codepoint, but no value is known, it presumably should be
- Section 5: I do not think SignatureAlgorithm can be obtained.
  One should use SignatureScheme instead. And if it is indeed
  fixed to SHA-256, it should be specified as "eccsi_sha256(TBD2)"
  or something like that. And then specify TLS 1.2 to use whatever
  HashAlgorithm and SignatureAlgorithm that SignatureScheme gets read
- Section 6 has example url of "". I presume that
  should be something like "http://pkgx.example/1.pkg" or thereabouts.
- Section 6.2: Negotiatating client preference for signature types
  using ciphersuites looks very odd. If server used X.509, but
  supported both ECDSA and ECSSI for client, it would pick ECDSA
  ciphersuite and include both ECDSA and ECSSI in CertificateRequest,
  and then the client would pick. Alternatively the server could
  include only ECSSI in CertificateRequest if it demanded ECSSI from
  the client (the ciphersuite could still be ECDSA one).
- Section 8 has obsolete registration policy information. None of
  the registeries are "standards action" anymore, all the existing
  ones are "specification required". One should also duplicate all
  requested codepoints in this section.