S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)
draft-ietf-sip-smime-aes-01
Yes
(Allison Mankin)
No Objection
(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(David Kessens)
(Margaret Cullen)
(Ted Hardie)
Recuse
(Jon Peterson)
Note: This ballot was opened for revision 01 and is now closed.
Allison Mankin Former IESG member
Yes
Yes
()
Unknown
Alex Zinin Former IESG member
No Objection
No Objection
()
Unknown
Bert Wijnen Former IESG member
No Objection
No Objection
()
Unknown
Bill Fenner Former IESG member
No Objection
No Objection
()
Unknown
David Kessens Former IESG member
No Objection
No Objection
()
Unknown
Harald Alvestrand Former IESG member
No Objection
No Objection
(2004-04-14)
Unknown
Reviewed by Brian Carpenter, Gen-ART. His review, included here because I agree with him on the BCP issue: If the Security area is happy, I would vote no-ob. This just seems to be a senisble piece of clean-up. > Question for IESG: can a > document like this be BCP? It would avoid later dependency This is a good illustration of why the 3 step standards process is pointless, but IMHO this needs to be PS, logically.
Margaret Cullen Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(2004-04-09)
Unknown
Abstract: s/required minimum ciphersuite/mandatory-to-implement ciphersuite/ Section 4: s/Triples-DES/Triple-DES/ Several places: Adjust line breaks to avoid funny line break placement. Avoid: S/ <CR><LF> MIME
Scott Hollenbeck Former IESG member
No Objection
No Objection
(2004-04-09)
Unknown
Re: Question for IESG: can a document like this be BCP? In the introduction the document says "This document therefore updates the normative requirements for S/MIME in RFC3261". As an update to 3261 (a standards track document) shouldn't this itself be a standards track document, and not a BCP?
Steven Bellovin Former IESG member
No Objection
No Objection
(2004-04-13)
Unknown
It might be worth adding a sentence noting that this text from 3261:
S/MIME implementations MUST at a minimum support SHA1 as a
digital signature algorithm
is wrong since SHA1 is a hash algorithm, not a signature algorithm. In fact, that error is almost worth an RFC Erratum entry.
Ted Hardie Former IESG member
No Objection
No Objection
()
Unknown
Thomas Narten Former IESG member
No Objection
No Objection
(2004-04-15)
Unknown
> has identified AES as a algorithm that might be used for content s/a/an/ > to have comparatively low memory requirements, which make it suitable s/make/makes/
Jon Peterson Former IESG member
Recuse
Recuse
()
Unknown