Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling
RFC 3850

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

(Russ Housley) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

Comment (2004-06-09)
No email
send info
-

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) (was Discuss) No Objection

Comment (2004-06-08)
No email
send info
"BER" and "DER" are included in the list of definitions in section 1.1, but they're not used anywhere in the document that I could find.  They should probably be removed.

(David Kessens) No Objection

(Allison Mankin) No Objection

(Thomas Narten) No Objection

(Jon Peterson) No Objection

Comment (2004-06-10)
No email
send info
In Section 3 (2nd paragraph), I'm a little confused by the text that says receiving implementations MUST "recognize and accept" certificates that contain no email address. What asssurance are such certificates providing in the mail context? How are they processed? Given the importance placed on matching the subjectAltName with the From header field of an email in later paragraphs, I found the lack of procedures for this case a little odd.

(Bert Wijnen) No Objection

Comment (2004-06-10)
No email
send info
No IPR section. I assume RFC-Editor will add it.

(Alex Zinin) No Objection