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
