Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-merkle-ikev2-ke-brainpool-06

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

(Sean Turner; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Barry Leiba; former steering group member) No Objection

(Benoît Claise; former steering group member) No Objection

(Brian Haberman; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

(Joel Jaeggli; former steering group member) No Objection

(Martin Stiemerling; former steering group member) No Objection

Just two nits:

Section 5., paragraph 1:

>    Although, the authors have no knowledge about any intellectual
>    property rights which cover the general usage of the ECP groups
>    defined herein, implementations based on these domain parameters may

  replace 'may' by 'could'.


Section 5., paragraph 2:

>    require use of inventions covered by patent rights.  In particular,
>    techniques for an efficient arithmetic based on the special
>    parameters of the twisted curves as explained in Section 2.1 may be
>    covered by patents.

  replace 'may' by 'could'.

(Pete Resnick; former steering group member) No Objection

(Richard Barnes; former steering group member) No Objection

+1 to Stephen's comments on Section 5 and RFC 6090.

(Stephen Farrell; former steering group member) (was Discuss) No Objection

- I don't really like how this document has a section (5) that
says "there may be patents" but yet there are no IPR declarations
for this and hence no concrete information. The authors did
explain that they put this in because they worry that the
ideas referenced seem like the kind of thing that'd be
patented but that they don't know of any such patents.
I can understand that but this seems to me to just add 
to the IPR FUD around ECC and would be better deleted 
I think.

- Section 5 also refers to 2.1 but I think you mean 2.2?

- Don't you need once of RFC 6090 or SEC1 to be normative since
you're using the FieldElement-to-OctetString conversion function
from one of them? I'd much prefer 6090 be normative.

(Stewart Bryant; former steering group member) No Objection

I agree with Stephens comment on Section 5

(Ted Lemon; former steering group member) (was Discuss, No Objection, Discuss) No Objection