Subject: which is easier?

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Sep 2001 17:00:37 +0100

Folks,

I'm involved in writing up a spec [*] that uses 
EnvelopedData. I want it to be easily usable with current 
toolkits and I've a question about the MIME encodings to use.

The data is binary and the EnvelopedData are carried in a 
binary protocol so I think the only issue is what's easiest for 
folks (who don't know s/mime) to code using existing APIs.

Should I:-

1. MIME encode the data before encryption?
2. MIME encode the data after encryption?
3. both of the above
4. neither of the above

That is, should my ciphertext look like:

1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...)
2. MIME-enc(EnvelopedData-fnc(data,receipient-stuff...))
3. MIME-enc(EnvelopedData-fnc(MIME-enc(data),receipient-stuff...))
4. EnvelopedData-fnc(data,receipient-stuff...)

Answers off-list are fine (and much appreciated),
Ta,
Stephen.

[*] If you're interested its a AAA WG work item, the next version of:
http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cms-sec-02.txt

-- 
____________________________________________________________
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

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 17 Sep 2001 13:28:11 -0700

Stephen,

Since my response is going to be a generalized one, I am posting to the
list.

You don't really give me enough information in your message for me to
answer you question, so I will response by asking a set of questions and
giving what I consider to be appropriate responses for the different
answers.

First all of the tool kits separate the MIME processing from the CMS
processing so there is no need to tie them together if not needed.  

Questions:

1.  Do you expect the inner data to ever be transported independent of a
CMS wrapping?
2.  Do you feel that either a) you can assign an OID for this content or
b) the content is uniquely described else where (this can be in the
protocol as well).
3.  Do you expect the wrapped data to be transported using a system that
expects MIME content (i.e. SMTP, HTTP)?

If the answer for 1 is yes, then use MIME for the inner wrapping
otherwise use a binary content.
If the answer for 2 is yes, then assign a new OID for the binary
structure (or use id-data).  If the answer is no, use a MIME wrapper.
If the answer for 3 is yes, use MIME otherwise don't.

I expect that there may be some people who would disagree with my
response to question #2.  Specifically I am allowing for what I assume
is a non ASN.1 binary blob to be assigned an OID value and placed in the
encapsulated data.  I feel that this is appropriate and legal.  Also,
beware of some completely automated processors (such as a mail client)
which assume that id-data is the equivalent of saying MIME content.
This is not what is specified in the documents but is an assumption in
some environments.

Jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Farrell
> Sent: Monday, September 17, 2001 9:01 AM
> To: [email-masked]
> Subject: which is easier?
> 
> 
> 
> 
> Folks,
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 18 Sep 2001 13:09:38 +0100

Thanks Jim,

> processing so there is no need to tie them together if not needed.

Good.

> 1.  Do you expect the inner data to ever be transported independent of a

Yes, the inner data are Diameter AVPs (attr/vals pairs) and will often be
carried, in clear, as "normal" Diameter AVPs. There can be "proxy" things
that wrap/unwrap the AVPs.

> b) the content is uniquely described else where (this can be in the

I'd say yes, given that all the AVPs are defined in Diameter specs. However,
I'd expect to get toolkit problems with a new OID. Maybe I'm just a pessimist.

> expects MIME content (i.e. SMTP, HTTP)?

Nope.

> This is not what is specified in the documents but is an assumption in

So, given the above, am I right that you'd recommend:

1. EnvelopedData-fnc(MIME-enc(data),receipient-stuff...) 
   and use id-data as the OID.

Stephen.

PS: I also got off-list recommendations for 2 and 4 (I think:-)