Skip to main content

Identity-Based Encryption Architecture and Supporting Data Structures
RFC 5408

Discuss


Yes

(Tim Polk)

No Objection

Lars Eggert
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)
(Ross Callon)
(Russ Housley)

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

Lars Eggert
(was Discuss) No Objection
Sam Hartman Former IESG member
Discuss
Discuss [Treat as non-blocking comment] (2008-03-11) Unknown
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 Former IESG member
(was No Record, Discuss, Yes) Yes
Yes () Unknown

                            
Chris Newman Former IESG member
(was Discuss) No Objection
No Objection (2008-11-05) Unknown
I support Lisa's discuss.
Cullen Jennings Former IESG member
(was Discuss, No Record, Discuss) No Objection
No Objection (2008-11-03) Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
(was Abstain, Discuss) No Objection
No Objection (2008-11-07) Unknown
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.
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss) No Objection
No Objection () Unknown