I have taken an initial look at this draft [0]. Comments follow. First the motivation for this technique appears rather weak. Primarily, you argue that a PKI is complicated to implement and this is simpler. However, there are a number of factors to consider.
First, I believe the design you have selected is too simple to work outside of toy scenarios. Specifically, it doesn't seem to account for any form of revocation. How do you handle the case where someone's keys are compromised? There are a number of ways to handle this inside the context of an IBC system (time-based PKG parameters, have the identities have a timestamp built into them, etc.), but you don't specify these, and they add complexity. In a similar vein, another thing that adds complexity is having a certificate hierarchy rather than a single CA. If you are willing to have a single-level hierarchy then life is much simpler. With an IBC system, one typically either foregoes this or uses HIBC. Are these systems HIBC capable? In addition, the innherent escrow capability that you describe in Section 7 is a way in which IBC systems are materially worse than PKI systems in a way we don't know how to ameliorate (as opposed to CT). For these reasons, I don't think this WG should adopt this work, though the process allows you to have a code point without adoption. TECHNICAL COMMENTS I don't understand why you are sending the PKG parameters over the wire. Either the parameters are already known to the relying party, in which case they are unnecessary or they are not in which case they cannot be trusted. It seems like a hash of them would be sufficient. And of course this doesn't mesh well with multiple generations of PKG parameters (see above) unless you have signed parameters, but now you have a mini PKI. You need to specify the format of "ServerID". Is it a domain name? Something else? -Ekr [0] Note that it's much harder to review documents in PDF. Please send text in future. On Thu, Mar 21, 2019 at 12:33 AM Wang Haiguang < wang.haiguang.shield...@huawei.com> wrote: > Hello, everyone. > > Attached is an updated version to our personal draft on > draft-wang-tls-raw-public-key-with-ibc-10. > > The target of the draft is to use identity as raw public key over TLS. > Idenitty-based signature (IBS) algorithms are used for peer/server > authentication. > > The draft has been updated from time to time and this is the 10th version. > > The main change in this version is we have extended the draft to support > three other IBS algorithms, i.e. the ISO-IBS1, ISO-IBS2 and > ISO-Chinese-IBS. > Data structures for these three algorithms are has been defined. > > This version has not been submitted to the IETF data trackers yet. We will > submit it once it is reopen. > > It is appreciate if expert in this mailing list can provide comments and > help us to improve the draft. > > Best regards. > > Haiguang > > > _______________________________________________ > 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
