Identity-Based Encryption Architecture and Supporting Data Structures
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
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
I support Lisa's discuss.