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

Hi, Melinda

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. 

When we use the existing raw public as specified in the TLS 1.3, somebody has to decide the lifetime of a raw public key also.   

Wtih IBC, re-keying is needed when a private key is expired. Similarly, when a raw public (as in TLS 1.3) expires, the binding list has to be updated by re-keying the raw public key at server side.  

Haiguang 
________________________________________
From: TLS [tls-bounces@ietf.org] on behalf of Melinda Shore [melinda.shore@nomountain.net]
Sent: Saturday, 23 March, 2019 5:12:20 PM
To: tls@ietf.org
Subject: Re: [TLS] draft-wang-tls-raw-public-key-with-ibc-10

On 3/22/19 7:28 AM, Wang Haiguang wrote:
> [HG] Regarding the revocation, we did not mention it in the draft, but
> we have
>
> considered it in the design. In practice, an
>
> expiring time can be included in the identity for the IBC system.
>
> In fact, in RFC 6507 page 7-8, authors have mentioned that expiration
> time may be included
>
> in the identity. That’s the reason we have not discussed the revocation
> issue in our draft.  If experts in this
>
> group think we should address this issue, we can provide more
> information and details in the next draft.
>

I generally agree with EKR's comments but I do think this is a
particular problem that needs to be addressed.  The security of a
mechanism like this depends on the ability to revoke compromised keys.
Your draft does not, in fact, include a key lifetime in the identifier
(and note that the timestamp is a MAY in RFC 6507).  If you decide to
include one it will probably need to be notably short in order to
provide any robustness against key compromises, which means that
rekeying and provisioning are going to be a practical problem that
may not be in scope for the draft but which will need to be addressed
in implementation and deployment.

I'm unenthusiastic about this draft but to the extent that there's a
hope to progress it, revocation really must be dealt with.

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