Identity-Based Encryption Architecture and Supporting Data Structures
RFC 5408

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

(Sam Hartman) Discuss

Discuss (2008-03-11 for -** No value found for 'p.get_dochistory.rev' **)
I support Chris, Lisa and Cullen's discusses.

How does a key server know whether a user is authorized to use a
particular identity address?  One solution is to do as Chris suggests
and to use 2821 addresses.  Another solution might be to require that
the PKG is built into the internal email infrastructure somehow and
can determine whether a given email address would be delivered to a
given mail box  and require the same authentication for that mailbox.

I find the use of application/octet-stream and the use of xhtml
completely inappropriate in sections 3 and 4.

According to the protocol public parameters are needed to decrypt the
message.  How does this work when you try to decrypt a historic
message?  What if the public parameters have changed?  (Note that this
document requires both senders and recipients to fetch public
parameters) How does this interact with the requirement in section 3
that public parameters not be used outside their validity time?


How is interoperability achieved if implementations "MAY REQUIRE"
certain extensions to function?  Shouldn't we require that
implementations have a mode that works with no extensions?




How do you know what district to use for a given email address?  How
do you know where to find the parameters?  How do you authenticate
that a given public parameters server is allowed to speak for a given
district?

(Tim Polk) (was No Record, Discuss, Yes) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Ross Callon) No Objection

(Lisa Dusseault) (was Abstain, Discuss) No Objection

Comment (2008-11-07)
No email
send info
My DISCUSS previously pointed out problems with the lack of clear requirements for HTTP.  Because no mention is made of a requirement to support all of HTTP, and individual features aren't mentioned, it is likely that the first implementations will dictate the subset of interoperable features.  E.g. if the first implementations use redirects, then redirects will become an interoperable HTTP feature in this application; if the first implementations do not, then redirects will be unusable.

Since this is now Informational, I am not holding the document for this concern.

(Lars Eggert) (was Discuss) No Objection

(Russ Housley) (was Discuss) No Objection

(Cullen Jennings) (was Discuss, No Record, Discuss) No Objection

(Chris Newman) (was Discuss) No Objection

Comment (2008-11-05)
No email
send info
I support Lisa's discuss.

(Jon Peterson) No Objection

(Dan Romascanu) No Objection

(Mark Townsley) No Objection

(David Ward) No Objection

Magnus Westerlund No Objection