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.