Skip to main content

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

Discuss


Yes

(Tim Polk)

No Objection

(Adrian Farrel)
(Dan Romascanu)
(Gonzalo Camarillo)
(Robert Sparks)
(Ron Bonica)
(Stewart Bryant)

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

Lars Eggert Discuss

Discuss (2011-02-03)
 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)
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

Yes (2011-11-12)

(Tim Polk; former steering group member) Yes

Yes ()

                            

(Adrian Farrel; former steering group member) No Objection

No Objection ()

                            

(Alexey Melnikov; former steering group member) No Objection

No Objection (2011-02-03)
The "||" convention needs to be explained early in the document.

SHA-256 needs a reference.

(Dan Romascanu; former steering group member) No Objection

No Objection ()

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection ()

                            

(Jari Arkko; former steering group member) No Objection

No Objection (2011-02-03)
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

No Objection (2011-02-02)
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

No Objection ()

                            

(Ron Bonica; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) No Objection

No Objection (2011-02-01)
  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

No Objection ()