Some comments on RFC2633bis:
Section 1.1 3rd para - remove all of the "also"s.
Section 3.1.2 - This section is very confusing for somebody (like myself)
who is using the spec to generate SMIME "things" in a non-mail environment.
I'm quite happy with binary transfer encoding since my SMIME things never
see SMTP environments. I would prefer to see a section headed "Transfer
Encoding considerations in SMTP or 7-bit worlds". All the transfer encoding
considerations for those environments can be listed there. Otherwise the
spec should say that _any_ transfer encoding is permitted.
Section 3.2.2 Bullet point 1. - I simply don't understand this para! I think
it should be re-written so that I can understand it!! An example is worth a
thousand pictures.
Section 3.3 Step 3 - the sentence says that the CMS object from the previous
step (envelopedData) is inserted into the MIME entity. In fact a CMS object
of ContentInfo containing the envelopedData object should be inserted. The
same comment applies to Section 3.4.2. My thanks to Russ Housley for
confirming my understanding of this.
Section 3.4.3.1 first sentence - is this true? Or should it be a
ContentInfo containing a signedData object?
Section 3.5 - it would have helped me greatly if this section had
(re-)stated that in SMIME the CMS secured stuff is always a MIME entity. I
wasn't sure if a signed then encrypted message needed to have the MIME
encoding around the inner ContentInfo/SignedData object.
Thanks,
Piers
Piers Chivers
Product Architect
Protek Network Security
+44 (0)1270 507800
www.protek.com <http://www.protek.com>