Greetings again. Well, it appears we're making progress, and even though we
didn't become an IETF Working Group, we have also had some downward bogging.
In an effort to finish up, I'd like to close the following issues from the
open issue list. These issues have been in the document for at least two
cycles with little or no disucssion. This is a "speak now or forever hold
you peace" alert that they won't be on the open issues list for the next
round. Again, comment is welcome, but relative silence will be taken as
"none of us care".
- Make the micalg parameter required, not optional.
[Comment: this is probably a bit controversial, so it is still an
unresolved issue. Please speak up about this if you are an implementor and
you have a good reason to make micalgs required.]
- Need reference to allowed values for the micalg parameter in 22.214.171.124.
Need to list text values for the micalg parameter of multipart/signed.
RFC 1848 lists only "RSA-MD2" and "RSA-MD5", not "SHA-1".
[Comment: I'm going to name these 'pkcs7-sha1' and 'pkcs7-md5' to reflect
the fact that they are related to the format of the PKCS#7 data.]
- What to do if sending to multiple people with different known
capabilities? What if sending to a group, some of whom have
known capabilities, others with unknown?
[Comment: we're going to punt on this. It's up to the implementation, and
isn't a protocol issue. And it's really, really hard.]
- Do we need better heuristics for determining the encryption
capabilities of a recipient? What about guessing based on
[Comment: the SMIMECapabilities has covered this with much more precision
than a "heuristic", so we'll keep the spec as it is, with no heuristics.]
Add signedData SMIMEcapability and note about following it.
[Comment: Well, we need to do this if we're going to make SMIMECapabilities
useful. This will be added in the next round.]
- In section 126.96.36.199, we need to look at whether the SHOULDs should
[Comment: the author's group is split and waffling on this, so we'll leave
them as SHOULDs.]
Use of the S/MIME trademark.
[Comment: RSA is happy to let us use the S/MIME trademark on the current
Look at the use of PKCS-7 "data" format.
[Comment: This slipped in here without good cause. It is being fixed in
PKCS #7 version 2, which is of no concern to this spec.]
--Paul E. Hoffman, Director
--Internet Mail Consortium