Subject: [AAA-WG]: MIME encoding with CMS Security Application

From: Don Zick <[email-masked]>
Date: Thu, 18 Oct 2001 15:05:47 -0400

Hi Stephen and all,

>Re: [AAA-WG}: Issue 150: S/MIME precisions
>
>From: Stephen Farrell
>Date: Tue Sep 18 14:23:26 2001
>
>If we don't want to do the MIME encoding then we can omit
>it, but someone someday might build using a toolkit that
>forces the MIME en/decoding and we'll have more interop
>problems than otherwise. (I personally don't mind whether
>we omit the MIME encoding or not.)

How about we eliminate the MIME en/decoding?  I think the following is
true.  Please correct me where I'm wrong.

- it requires additional processing
- The CMS-Signed-Data AVP contains a signature for MIME encoded data,
but not the MIME encoded data itself.  This means that the receiver of a
CMS-Signed-Data AVP must be able to generate the MIME encoded data in
the exact same manner as the sender.  It might be difficult for all
implementations to perform the MIME encoding exactly the same.
Identical MIME headers must always be used with the exact same fields,
spacing, carriage returns, and line feeds.  This may be a problem if a
toolkit adds header information automatically.
- I don't think my toolkit requires it ;-)

Does anyone out there require that the MIME en/decoding be performed?

Thanks for considering this,
Don

---

From: David Frascone <[email-masked]>
Date: Thu, 18 Oct 2001 14:56:03 -0500

I see absolutely no reason to convert to 7 bit data in a binary stream.

So, vote is *against* mime encoding.

-Dave

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Oct 2001 11:09:52 +0100

> I see absolutely no reason to convert to 7 bit data in a binary stream.

I'm starting to agree. The only reason to include it is if there 
are CMS toolkits out there that insist on the MIME encoding. I 
checked with a bunch of our folks a while back and though they 
couldn't identify such a toolkit, everyone thought they remembered 
that there is one such, so I left it in.

If no-one interested in Diameter has a problem though, then
it can be removed easily enough (assuming that no Diameter
porxy/agent/server is liable to start converting EOLs, upper->
lower or other signature-breaking things).

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com