Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
Note: This ballot was opened for revision 01 and is now closed.
Lars Eggert Discuss
DISCUSS: This is from the sec-dir review: > 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. Do we need an IESG note on this document? It seems like an IETF last call doesn't really help much if we don't have the expertise in the community. Why is this being published via the IETF stream?
It is the job of the *AD* to check conformance to idnits for AD-sponsored documents... INTRODUCTION, paragraph 10: > Copyright Notice Boilerplate is outdated for a -00 doc that was submitted Jun 2010. INTRODUCTION, paragraph 15: > Table of Contents The document seems to lack an IANA Considerations section.
(Sean Turner; former steering group member) (was No Objection, Discuss) Yes
(Tim Polk; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Alexey Melnikov; former steering group member) No Objection
The "||" convention needs to be explained early in the document. SHA-256 needs a reference.
(Dan Romascanu; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
Ari Keränen's review noted the following: 2. Architecture Before verification of any Signatures, members of the user community are supplied with the KPAK. The supply of the KPAK MUST be authenticated by the KMS and this authentication MUST be verified by each member of the user community. What must the members exactly verify? That the KPAK was authenticated by the KMS? Every member does this separately? In the description of the algorithms in this document, it is assumed that there is one KPA, First instance of KPA; needs to be expanded. Or should that be KMS?Ss
(Ralph Droms; former steering group member) (was Discuss, No Objection) No Objection
A minor suggestion - it would help avoid confusion through interpretation of different textual descriptions in section 3 to take out the informal description of integer representation as an octet string and use just the pointer to [P1363]. The informal use of octet string might also be cleaned up a little to clarify that they are all indicating the use of the representation in [P1363].
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
Please consider the comments from the Gen-ART Review by Francis Dupont on 13-JAN-2011. You can found the review at: http://www.softarmor.com/rai/temp-gen-art/ draft-groves-eccsi-00-dupont.txt
(Stewart Bryant; former steering group member) No Objection