I think that the point Russ was making is "can you handle nesting of CMS
objects" not "can you handle nesting of MIME wrapped CMS objects". In our
case, we can only do MIME wrapped CMS objects, but we can handle binary
encoding of those objects.
Blake
-----Original Message-----
From: Aram Perez [mailto:aperez(_at_)syndata(_dot_)com]
Sent: Tuesday, March 07, 2000 6:30 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Triple Wrapping Survey
Hi Russ,
I agree that S/MIMEv3 should minimize Base64 encoding when possible. As I
understand MIME, all implementations should handle binary as this is the
default unless otherwise specified.
Regards,
Aram Perez
-----Original Message-----
From: Russ Housley [mailto:housley(_at_)spyrus(_dot_)com]
Sent: Monday, March 06, 2000 7:21 PM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Triple Wrapping Survey
I have a few questions for implementors. First some background, then the
questions.
The use of S/MIMEv3 Triple Wrapping leads to the incorporation of four MIME
encodings. If each of these encodings uses Base64, then the overhead is
huge. I am interested in ways to reduce the overhead, hopefully without
hurting IMAP usability.
1. Can your implementation handle
MIME( SignedData (EnvelopedData (SignedData ( MIME ))) ?
The outer SignedData has the OID for EnvelopedData in the content type, not
id-data.
The EnvelopedData has the OID for SignedData in the content type, not
id-data.
The inner Signed Data has the id-data OID in the content type.
2. Can your implementation handle MIME without Base64 encoding? I am
interested in using "binary" instead of Base64 to reduce the overhead.
Russ