IBAKE: Identity-Based Authenticated Key Exchange
RFC 6539

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

(Sean Turner) Yes

(Jari Arkko) (was Discuss) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

Comment (2011-10-31 for -)
No email
send info
I am voting No Objection on the basis of the IESG note and a quick check that this draft has no routing implications.

(Gonzalo Camarillo) No Objection

(Adrian Farrel) (was Discuss) No Objection

(Stephen Farrell) No Objection

Comment (2011-11-02 for -)
No email
send info
- I agree with the proposed IESG note, but I guess we need to
figure out (with the ISE?) how to properly state that.

- another case where the IPR declaration refers to a "standard"
but this isn't going to be one.

- section 1, Public key protocols do not require "large scale" PKI,
as clearly demonstrated by the success of ssh. The statement is

- section 1, No evidence is give for the assertion that a PKG is
"simple." Personally, I doubt that and the word's not needed in
any case. Suggest s/simple// 

- section 1, Many IBE schemes have claimed that including dates
in names avoids revocation issues. However, afaik, no one has 
actually done this in the wild so this claim is also just a
bare assertion since the usability issues related to this idea
are essentially untested.

- section 2.1, IBE does not allow a public key to be calculated from
an identity. IBE requires an identity *and* a set of PKG parameters
in order to generate a public key. Truth-in-advertising would be
better here.

- Its not clear to me that two implementations of this would
interoperate. That may or may not be the case, but I guess
additional specification would be required. It would be good
to say more about what'd be needed for that.

- Its not really possible to evaluate the security claims of
this protocol as part of a 5742 review. It'd be good if a
statement to that effect were included. I'm not doubting the
security claims, but they have not been exposed to wide
spread review which would be needed were something like this
to come out of the IETF track. 

- Its hard to see how 2119 is the only normative reference

- typo: s/Privet/Private/

(Russ Housley) No Objection

(Pete Resnick) (was Discuss) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) (was Discuss) No Objection