Elliptic Curve-Based Certificateless Signatures for Identity-Based Encryption (ECCSI)
RFC 6507

Note: This ballot was opened for revision 01 and is now closed.

(Lars Eggert) Discuss

Discuss (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
 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?

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Tim Polk) Yes

(Sean Turner) (was No Objection, Discuss) Yes

Comment (2011-11-12)
No email
send info

(Jari Arkko) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) (was Discuss, No Objection) No Objection

Comment (2011-02-02)
No email
send info
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].

(Adrian Farrel) No Objection

(Russ Housley) No Objection

Comment (2011-02-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  Please consider the comments from the Gen-ART Review by Francis Dupont
  on 13-JAN-2011.  You can found the review at:


(Alexey Melnikov) No Objection

Comment (2011-02-03 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
The "||" convention needs to be explained early in the document.

SHA-256 needs a reference.

(Dan Romascanu) No Objection

(Robert Sparks) No Objection