S/MIME Advanced Encryption Standard (AES) Requirement for the Session Initiation Protocol (SIP)
RFC 3853

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

(Allison Mankin) Yes

(Harald Alvestrand) No Objection

Comment (2004-04-14)
No email
send info
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.

(Steven Bellovin) No Objection

Comment (2004-04-13)
No email
send info
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.

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

(Scott Hollenbeck) No Objection

Comment (2004-04-09)
No email
send info
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?

(Russ Housley) (was Discuss) No Objection

Comment (2004-04-09)
No email
send info
  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

(David Kessens) No Objection

(Thomas Narten) No Objection

Comment (2004-04-15)
No email
send info
>    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/

(Bert Wijnen) No Objection

(Alex Zinin) No Objection

(Jon Peterson) Recuse