I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document defines an identity-based encryption algorithm, using elliptic-curve crypto, based in part on the design of ECDSA. In the system described, each participant has a well-known identifier and a public/private key pair generated by a central keying authority, which itself has a well-known public key. Each participant's public key is a function of that participant's identifer, the keying authority's well-known public key, and a long-term "validation token" which is initially provided the keying authority, and then transmitted by that participant along with each of its signatures. This system shares the usual security considerations of any public key cryptosystem, of ECC in general, and of ECDSA in particular; the security considerations section seems to do a reasonable job of calling these out. Recommendations are made for selecting an appropriate group size based on the desired symmetric-equivalent strength, but no information is given as to the derivation of this advice. I suggest a reference to RFC3766, or perhaps some more recent document which pays particular attention to ECC algorithms. Naturally, the security of the system depends on secure delivery of the agreed-upon group parameters, the keying authority's public key, and the generated keying material to each participant. This document calls out the need for suitable protection, but considers protocols or mechanisms for delivering this data to be out of scope. No explicit mechanism is provided for revocation or expiration of keys. However, identifiers are free-form, and could easily be extended to include timestamps, as discussed in the security considerations section. This is one of the most serious concerns I have with any identity-based crypto scheme, and I'm glad to see it called out and addressed. This document is unusual for the IETF, in that it defines a new cryptographic algorithm, which we normally don't do. While there is no particular reason not to publish it here, I would be wary of using this algorithm in any IETF protocol until it has seen extensive review by the cryptographic community. It looks to me like it should work, but I am not a cryptographer and may well have missed an obvious flaw. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf