Thanks for taking the time to comment -- please find my responses inline,
marked with [bcr]. Sorry about the somewhat confusing formatting -- some
mail clients are better at doing quoting than others.
----- Original Message -----
From: Piers Chivers
To: ietf-smime(_at_)imc(_dot_)org
Sent: Wednesday, March 20, 2002 2:49 AM
Subject: Comments on RFC2633bis
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.
[bcr] I might argue that a non-mail environment is more of a CMS environment
than an S/MIME one, so most of the rules that are imposed by the S/MIME
profile need not apply. You can use CMS directly and apply whatever rules
are appropriate in your environment, which may be a better idea. The reason
why there are various restrictions on content transfer encoding are based on
the need to be compatible with the least common denominator MIME
environment. If there is consensus that having a separate S/MIME profile
for SMTP and non-SMTP environments is useful, then maybe we should discuss
it further. Another reason for the restriction was based on client support
for binary encoding, even outside of SMTP. I think this was a topic of some
controversy at one point, but certainly it might bear revisiting.
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.
[bcr] I agree, and I will try to clarify this. I think that the point is
that a receipt could be either enveloped or signed, so therefore it could be
"signed-receipt" or "enveloped-receipt". Jim or John might be able to chime
in here with some insight, since I suspect that one of them submitted the
language that's confusing to you ;).
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.
[bcr] Agreed.
Section 3.4.3.1 first sentence - is this true? Or should it be a
ContentInfo containing a signedData object?
[bcr] Same problem as above. It should 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.
[bcr] How about changing the paragraph:
To achieve signing and enveloping, any of the signed-only and
encrypted-only formats may be nested. This is allowed because the
above formats are all MIME entities, and because they all secure MIME
entities.
To read:
To achieve signing and enveloping, any of the signed-only and encrypted-only
MIME formats listed above may be nested. This is allowed because the above
formats are all MIME entities, and because they all secure MIME entities.
Is that sufficient?
Thanks again for the comments.
Blake