Using the Elliptic Curve Cryptography (ECC) Brainpool Curves for the Internet Key Exchange Protocol Version 2 (IKEv2)
draft-merkle-ikev2-ke-brainpool-06
Yes
(Sean Turner)
No Objection
(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Pete Resnick)
(Ted Lemon)
Note: This ballot was opened for revision 03 and is now closed.
Sean Turner Former IESG member
Yes
Yes
(for -03)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -03)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(for -03)
Unknown
Benoît Claise Former IESG member
No Objection
No Objection
(for -03)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -03)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -03)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -03)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -03)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(2013-04-08 for -03)
Unknown
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 IESG member
No Objection
No Objection
(for -03)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(2013-04-09 for -03)
Unknown
+1 to Stephen's comments on Section 5 and RFC 6090.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-04-09 for -03)
Unknown
- 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 IESG member
No Objection
No Objection
(2013-04-09 for -03)
Unknown
I agree with Stephens comment on Section 5
Ted Lemon Former IESG member
(was Discuss, No Objection, Discuss)
No Objection
No Objection
(2013-04-11 for -04)
Unknown