Document: draft-martin-ibcs-04.txt Reviewer: David L. Black Review Date: 03 July 2007 IESG Telechat date: 05 July 2007 Summary: This draft is basically ready for publication as an Informational RFC, but has nits that should be fixed before publication. Comments: The -04 version of this draft is much improved over the -03 version, and has addressed most of the concerns raised in the GenART review of the -03 version. In particular, the serious lack of hash agility and the related lack of support for the 256-bit level of security have both been corrected in the -04 version, there is now a discussion of use of IBE at the front of the draft, and the security considerations section has been significantly improved. Many thanks to the authors for dealing with these issues. The IPR disclosure was in fact filed at the time of the previous review, but the IETF IPR search tool fails to find it. This review has been cc:'d to IETF-ACTION in order to correct this failure. I've cc:'d the smime WG chairs to ensure that they are aware of the contents of this disclosure - https://datatracker.ietf.org/ipr/821/ . The security considerations section does not explicitly address the stream-cipher-like behavior of encryption/decryption noted in the previous GenART review. This is ok because this security concern has been addressed by other means in the -04 version; the plaintext is now required to be a random session key in Sections 5.4 and 6.4. If the crucial value that effectively initializes the stream cipher (l in Section 5.4, s in Section 6.4), is ever reused, an adversary learns only the XOR of two random session keys, which should be of no value to the adversary for truly random session keys. I still have one concern - there is no discussion of rekeying an individual user. In order to rekey a user whose private keying material has been compromised without changing the master IBE secret, the user's identity has to change. The draft defines identity in Section 2.2 as: Identity - An identity an arbitrary string, usually a human- readable unambiguous designator of a system user, possibly augmented with a time stamp and other attributes. The "possibly augmented ... " wording may be describing a feature that is crucial to enabling a user to be rekeyed without changing her name (e.g., given name, email address). Some discussion of rekeying of users without changing the master IBE secret should be included in the security considerations section, as it appears to have relevance to the choice of structure of identities used with these algorithms. Nit: the parameter space for V in Sections 5.4.1 and 5.5.1 should be "{0, ... , 255}^hashlen" instead of "{0, ... , 255}^20" . Nit: I don't see the point of the [KERLAW] reference to an 1883 paper in French. The added [BF] citations in the -04 version are sufficient for the request in the previous review that a reference be cited to support the statements of belief about strength of these cryptographic techniques.