Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

[Wang Haiguang <[e-mail]>]

To handle the compromised key, a revocation list maintained at server side can help. This is similar to the PKI certificate. 

The binding list used by existing raw public in TLS 1.3 actually is a white list. If I have a few million devices, then the white list contains a few million records.   

On the other hand, the number of compromised keys usually should be only a small number.  So the revocation list is much shorter compare to the binding list maintain for raw public.

This is value point of using IBS as signature algorithm. 

TLS with IBS is not proposed for use with the existing browser/server kind of communication. The intention is to use IBS for IoT networks.  

________________________________________
From: Melinda Shore [[e-mail]]
Sent: Sunday, 24 March, 2019 9:46:44 PM
To: Wang Haiguang; [e-mail]
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

On 3/24/19 4:16 AM, Wang Haiguang wrote:
> We do plan to include an expire date in the identity design. The
> valid period is a decision that should be decide either by the user
> or the PKG manager.

The problem here is that you do not want to get into the
position of allowing a known compromised key to be treated
as valid for, say, a period of several years.  Even if you
replace the private key in the handset, a "compromise"
typically involves the existence of an uncontrolled instance
of the private key.  Consequently you need to either narrowly
constrain the key lifetime or provide a revocation mechanism.

Melinda


--
Software longa, hardware brevis

PGP key fingerprint  4F68 2D93 2A17 96F8 20F2
                     34C0 DFB8 9172 9A76 DB8F