Re: Charter Update

Here is an update to the document that I posted earlier.  I think that it 
addresses all of the comments.

Russ

S/MIME Mail Security (smime)

Chair:
     Russ Housley <rhousley <at> rsasecurity.com>

Security Area Director:
     Jeffrey Schiller <jis <at> mit.edu>
     Marcus Leech <mleech <at> nortel.ca>

Mailing Lists:
     General Discussion: ietf-smime <at> imc.org
     To Subscribe:       ietf-smime-request <at> imc.org
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed  
Standards that comprise the S/MIME version 3 specification.   
Current efforts update and build upon these base specifications.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any 

Why KEM?, RE: Charter Update

Re: Why KEM?, RE: Charter Update

RE: Why KEM?, RE: Charter Update

RE: Protecting fields via message/rfc822 and merging issues

Hi Blake,

  See embedded comments below.

> > b) Discarding the outer 822 message and looking only at the
> > inner fields works provided that the inner message is
> > complete.  However, it does not work if only a partial
> > list of fields is included in the inner message.  Also,
> > since we negate the usefulness of the outer message in
> > all cases, we strongly encourage that it be a blank
> > "dummy" message.  This would effectively require the
> > application to do security processing even to display
> > the originator, subject line, etc. -- fields normally
> > shown in a mailbox view.  Blake also correctly pointed
> > out that this would squash useful headers like "trace"
> > (i.e., Received:...) and things added by list exploders.
> 
> [bcr] Right, and I think this also includes header security 
> policies (not necessarily cryptography, but generic 
> rewriting) applied by the organization such as rewritten 
> address lines for host name hiding or adding disclosed 
> recipients.  I think this is where we start running into a 
> problem, and where we're in danger of failing.

  I don't see this as so big a problem with (c).  All you need to do to make sure that you don't override the outer
fields is to ensure that recipients aren't originating those fields in the inner wrapper.  I could think of
a number of ways to implement that.  In fact, it sounds like an excellent market discriminator.  

> > d) Include the signal in a CMS attribute - In a signed-only 
> > or signed-and-encrypted message, the attribute should 
> > probably be in the inner signedAttrs.  For encrypted-only 
> > messages, it would have to go in the unprotectedAttrs, 
> > but this is not optimal since it shares the disadvantages 
> > of (a).  If this is the way forward, we have to have the 
> > subsequent discussion of whether to use an existing or 
> > new attribute.
> > 
> >   Obviously, my belief is that (d) is the only one that 
> > works.  However, I'm not happy with how it works in the 
> > encrypted-only case.  I'm also somewhat sensitive to 
> > "attribute bloat".  I therefore earnestly hope somebody 
> > else sees something that I've missed.
> 
> [bcr] I think that the biggest problem I'm having is that 
> we're trying to mix authenticated / unauthenticated / 
> encrypted / unencrypted headers together and try to do the 
> right thing in an automated fashion.  As much as as we might 
> like to define this, I think the only option might be to take 
> the coward's way out and explain that the presentation and 
> merging of the headers are the problem of the client, and 
> that it's not possible to automatically mix them.  The 
> realization that I'm coming to is that there is no utility in 
> merging the headers, and we shouldn't even attempt it, and we 
> should document that the client needs to potentially make 
> decisions about how much to trust the internal headers vs. 
> the external headers, and it is their responsibility to 
> demonstrate the separation.

  I take the point I think you're making that there might be numerous GOOD ways of doing this depending on your
assumptions, and that there might therefore not be a BEST way.  If a product is capable of showing you both
and indicating what is authenticated or encrypted and what isn't, that might be best.

> [bcr] My thinking right now is along the lines of the 
> following, and I could very well be missing some important 
> issues:
> 
> 1. Use message/rfc822 with a full set of headers for the 
> inner protected content.  This is backward compatible, and 
> it's entirely possible that existing clients might even 
> process this correctly.
> 
> 2. Define placebo values for any outer message required 
> fields.

  I didn't figure we needed to do this, but it's more important in the scenario you suggest.  For "Date:" I would
suggest 1/1/1970 (zero in UNIX, I think).  I guess I don't have a value to suggest for "From:".  The
difficulty is that you need to have a minimally conformant address.  Anybody out there have a suggestion?

> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps we can describe a default rule similar
to the option (c) I described, hanging under a SHOULD.  That way, if there was a good reason to do something
different it's okay.

Best regards,
Chris

RE: Protecting fields via message/rfc822 and merging issues

Suggestion for "From:" field below,

-----Original Message-----
From: owner-ietf-smime <at> mail.imc.org
[mailto:owner-ietf-smime <at> mail.imc.org] On Behalf Of Bonatti, Chris
Sent: mercredi 1 mai 2002 20:15
To: Blake Ramsdell
Cc: IETF SMIME WG
Subject: RE: Protecting fields via message/rfc822 and merging issues

Hi Blake,

  See embedded comments below.

> > b) Discarding the outer 822 message and looking only at the inner 
> > fields works provided that the inner message is complete.  However, 
> > it does not work if only a partial list of fields is included in the

> > inner message.  Also, since we negate the usefulness of the outer 
> > message in all cases, we strongly encourage that it be a blank
> > "dummy" message.  This would effectively require the
> > application to do security processing even to display
> > the originator, subject line, etc. -- fields normally
> > shown in a mailbox view.  Blake also correctly pointed
> > out that this would squash useful headers like "trace"
> > (i.e., Received:...) and things added by list exploders.
> 
> [bcr] Right, and I think this also includes header security
> policies (not necessarily cryptography, but generic 
> rewriting) applied by the organization such as rewritten 
> address lines for host name hiding or adding disclosed 
> recipients.  I think this is where we start running into a 
> problem, and where we're in danger of failing.

  I don't see this as so big a problem with (c).  All you need to do to
make sure that you don't override the outer fields is to ensure that
recipients aren't originating those fields in the inner wrapper.  I
could think of a number of ways to implement that.  In fact, it sounds
like an excellent market discriminator.  

> > d) Include the signal in a CMS attribute - In a signed-only
> > or signed-and-encrypted message, the attribute should 
> > probably be in the inner signedAttrs.  For encrypted-only 
> > messages, it would have to go in the unprotectedAttrs, 
> > but this is not optimal since it shares the disadvantages 
> > of (a).  If this is the way forward, we have to have the 
> > subsequent discussion of whether to use an existing or 
> > new attribute.
> > 
> >   Obviously, my belief is that (d) is the only one that
> > works.  However, I'm not happy with how it works in the 
> > encrypted-only case.  I'm also somewhat sensitive to 
> > "attribute bloat".  I therefore earnestly hope somebody 
> > else sees something that I've missed.
> 
> [bcr] I think that the biggest problem I'm having is that
> we're trying to mix authenticated / unauthenticated / 
> encrypted / unencrypted headers together and try to do the 
> right thing in an automated fashion.  As much as as we might 
> like to define this, I think the only option might be to take 
> the coward's way out and explain that the presentation and 
> merging of the headers are the problem of the client, and 
> that it's not possible to automatically mix them.  The 
> realization that I'm coming to is that there is no utility in 
> merging the headers, and we shouldn't even attempt it, and we 
> should document that the client needs to potentially make 
> decisions about how much to trust the internal headers vs. 
> the external headers, and it is their responsibility to 
> demonstrate the separation.

  I take the point I think you're making that there might be numerous
GOOD ways of doing this depending on your assumptions, and that there
might therefore not be a BEST way.  If a product is capable of showing
you both and indicating what is authenticated or encrypted and what
isn't, that might be best.

> [bcr] My thinking right now is along the lines of the
> following, and I could very well be missing some important 
> issues:
> 
> 1. Use message/rfc822 with a full set of headers for the
> inner protected content.  This is backward compatible, and 
> it's entirely possible that existing clients might even 
> process this correctly.
> 
> 2. Define placebo values for any outer message required
> fields.

  I didn't figure we needed to do this, but it's more important in the
scenario you suggest.  For "Date:" I would suggest 1/1/1970 (zero in
UNIX, I think).  I guess I don't have a value to suggest for "From:".
The difficulty is that you need to have a minimally conformant address.
Anybody out there have a suggestion?

--------------------- From: John Doe?

> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps
we can describe a default rule similar to the option (c) I described,
hanging under a SHOULD.  That way, if there was a good reason to do
something different it's okay.

Best regards,
Chris

rfc2633bis and multipart/encrypted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847 way of 
_encrypting_ mime entities, but describes mp/signed as _preferred_.

In message <ilu66752z6b.fsf <at> dhcp128.extundo.com>, Simon Josefsson wrote back 
in December:
> While we are on the topic of MIME and encryption -- does anyone know
> the history behind S/MIME not using multipart/encrypted of RFC 1847
> for encrypted data?  This decision causes some pain when implementing
> a client that supports both PGP and CMS; S/MIME encryption becomes a
> special case.  Multipart/encrypted doesn't seem to have been discussed
> here, judging by the mail archives at least.

There was no reply.

The only references I could find about mp/encrypted and rfc1847 were some 
comments about gateways breaking rfc1847, which is probably what the 
respective comments in the final rfc reflect.

But given the rules for determining whether a given message is an S/MIME 
message, anything that could conceivably be done to a mp/encrypted at 
gateways would downgrade to the "filename extension" rule of S/MIME message 
detection.

Thus, I don't see a reason to not use mp/encrypted - esp. as mp/signed is the 
preferred mode for signing.

Can someone enlighten me?

If there are no reasons against it, I'd propose to include it as the preferred 
method of encrypting and define a new mimetype app/pkcs7-encrypted.

It will degrade gracefully since old MUAs should treat unknown multipart 
subtypes as mp/mixed and by the file-extension rule, the app/octet-stream 
with filename *.p7m will be recognized as part of a S/MIME message.

Marc

- -- 
Marc Mutz <mutz <at> kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
MEmwcc1Np37bsO8hTutUTSY=
=iZh1
-----END PGP SIGNATURE-----

Re: rfc2633bis and multipart/encrypted

Marc Mutz <mutz <at> kde.org> quotes:

>While we are on the topic of MIME and encryption -- does anyone know
>the history behind S/MIME not using multipart/encrypted of RFC 1847
>for encrypted data?

Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent were a
bigger hammer, so S/MIME won.

(Having said that, multipart/encrypted is pretty clunky (signed data is a
 different issue).  OTOH given the perpetual-motion-machine nature of debates
 over this in 1995-1996, it's arguable that any decision would have been
 regarded as bad by some subset of people).

Peter.

Re: rfc2633bis and multipart/encrypted

Marc:

I recall a discussion about maintaining backward compatibility with S/MIME v2.

Russ

At 03:36 PM 5/3/2002 +0200, Marc Mutz wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi!
>
>I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847 
>way of
>_encrypting_ mime entities, but describes mp/signed as _preferred_.
>
>In message <ilu66752z6b.fsf <at> dhcp128.extundo.com>, Simon Josefsson wrote back
>in December:
> > While we are on the topic of MIME and encryption -- does anyone know
> > the history behind S/MIME not using multipart/encrypted of RFC 1847
> > for encrypted data?  This decision causes some pain when implementing
> > a client that supports both PGP and CMS; S/MIME encryption becomes a
> > special case.  Multipart/encrypted doesn't seem to have been discussed
> > here, judging by the mail archives at least.
>
>There was no reply.
>
>The only references I could find about mp/encrypted and rfc1847 were some
>comments about gateways breaking rfc1847, which is probably what the
>respective comments in the final rfc reflect.
>
>But given the rules for determining whether a given message is an S/MIME
>message, anything that could conceivably be done to a mp/encrypted at
>gateways would downgrade to the "filename extension" rule of S/MIME message
>detection.
>
>Thus, I don't see a reason to not use mp/encrypted - esp. as mp/signed is the
>preferred mode for signing.
>
>Can someone enlighten me?
>
>If there are no reasons against it, I'd propose to include it as the 
>preferred
>method of encrypting and define a new mimetype app/pkcs7-encrypted.
>
>It will degrade gracefully since old MUAs should treat unknown multipart
>subtypes as mp/mixed and by the file-extension rule, the app/octet-stream
>with filename *.p7m will be recognized as part of a S/MIME message.
>
>Marc
>
>- --
>Marc Mutz <mutz <at> kde.org>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
>MEmwcc1Np37bsO8hTutUTSY=
>=iZh1
>-----END PGP SIGNATURE-----

Re: rfc2633bis and multipart/encrypted

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maybe I should introduce myself first:
I'm a KMail (kmail.kde.org) developer and responsible for the next-generation 
message handling code that will creep into KMail over the next months.
As such, I'm partly remotely, partly directly involved in the Aegypten Project 
of the German government (www.gnupg.org/aegypten), which aims to bring S/MIME 
support to the well-known OpenPGP imlementation GnuPG, and incorporate 
support into OSS mail clients, chiefly KMail and mutt.

On Friday 03 May 2002 16:15, Peter Gutmann wrote:
> Marc Mutz <mutz <at> kde.org> quotes:
> >While we are on the topic of MIME and encryption -- does anyone know
> >the history behind S/MIME not using multipart/encrypted of RFC 1847
> >for encrypted data?
>
> Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
> worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent were
> a bigger hammer, so S/MIME won.

The few arguments for using an application subtype for encrypted/signed data 
and CRLs are handwaving at best.
Now we implementors are stuck with a - let's say - suboptimal solution and the 
clean solution is disallowed by not even mentioning it in the RFC.

What are arguments against including
multipart/encrypted; protocol="application/pkcs7-encrypted"
with a "MAY create / SHOULD understand" in the successor of RFC 2633?

This would at least open the door for adoption in the future.
Then S/MIMEv2 -> S/MIMEv3 transition seems to have had some potentially much 
more grave disruptions than introducing mp/encrypted.

> (Having said that, multipart/encrypted is pretty clunky (signed data is a
>  different issue). 

- From an implementor's POV, multipart/encrypted is by no means "clunky". Yes, 
it adds an outer and an inner body part of hot air around the interesting 
stuff, but the headers of the "hot air" body parts are what counts. They 
contain the information used by the MUA to dispatch the content to the right 
backend crypto engine. What's more, it allows MUAs to guess (rightly so) that 
what comes back from the crypto engine is only another mime entity (something 
that needs further processing by the MUA itself), while that isn't at all 
clear when using application/pkcs7-mime. There, the MUA doesn't even know 
whether it's an CRL, a signed document, an encrypted document or simply 
CMS-wrapped data without cryptography.  (Without particular knowledge of 
S/MIME, that is.)

I understand that some (to me obscure) gatewaying and backwards compat issues, 
paired with politics, have prevented the inclusion of an elegant solution. 
app/pgp has been deprecated - and successfully so. Time to try the same with 
app/pkcs7-mime, I'd say.

> OTOH given the perpetual-motion-machine nature of
> debates over this in 1995-1996, it's arguable that any decision would have
> been regarded as bad by some subset of people).

Back at politics, then... 

Marc

- -- 
Marc Mutz <mutz <at> kde.org>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80sFJ3oWD+L2/6DgRAifHAKCiuoPG4tIoErrapAH26P5sRBRiIQCfUS3r
R++N3nYDzvGfdHUXlPD+l+A=
=ZZbO
-----END PGP SIGNATURE-----