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 [melinda.sh...@nomountain.net]
Sent: Sunday, 24 March, 2019 9:46:44 PM
To: Wang Haiguang; tls@ietf.org
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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
