I agree with EKR. It's another type of PKI, in the sense that there's some infrastructure you have to trust, in addition to or instead of your own key pair. Some, myself included, would prefer facing the kinds of attacks that are possible with the traditional PKI, rather than those that IBC enables.
Regards, Uri Sent from my iPhone > On Mar 24, 2019, at 08:17, Wang Haiguang <wang.haiguang.shield...@huawei.com> > wrote: > > 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-boun...@ietf.org] on behalf of Melinda Shore > [melinda.sh...@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 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
