Subject: [AAA-WG]: Issue 150: S/MIME precisions

From: Pat Calhoun <[email-masked]>
Date: Thu, 30 Aug 2001 10:46:33 -0700

All,

Both Steven Farrell and I believe that it isn't necessary to get into a
tutorial of CMS and S/MIME, and specifically how they interact.  Given
that an implementor will need to understand the intricacies of S/MIME
and CMS to implement this application, we both feel that this isn't
necessary.

I would, of course, welcome your comments,

PatC

---

From: Miguel Ángel Monjas Llorente <[email-masked]>
Date: Fri, 31 Aug 2001 09:33:22 +0200

> and CMS to implement this application, we both feel that this isn't

Hi Pat,

of course that adding an S/MIME and CMS introduction would be
unnecessary. Some precisions either:

- While there's a specific mention of MIME encoding of AVPs in 6.1
(CMS-Signed-Data AVP):

  This means that where a set of AVPs is protected using CMS, the set
  MUST first be encoded according to MIME encoding rules specified
below.

and in the same paragraph (though talking about encryption + signing):

  The resulting CMS object MUST then be MIME encoded producing an
  application/pkcs7-mime MIME type which is then used as the content
  of the EnvelopedData. 

there's no explicit mention of MIME enconding in 6.2
(CMS-Encrypted-Data AVP). My oppinion is that such explicit mention to
MIME should be included in 6.2 (at least if MIME enconding is
necessary).

BTW, where are the MIME encoding rules specified "below"?

- The second quote is very low-level, in the sense that even the MIME
type is mentioned (I've got no problem with that). Not being a S/MIME
expert, I'd help a such specific indication about the way of including
several EnvelopedData in one CMS-Encrypted-Data (even off-line). I've
been browsing S/MIME spec and ESS draft and I haven't found any
indication of such procedure (maybe a deeper reading would help, but
I'd be grateful with some clue).

Regards

  // M.A.