Housley, Russ | 1 May 17:00 2002

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 
(Continue reading)

Mike Just | 1 May 19:14 2002

Why KEM?, RE: Charter Update

It's not clear to me that there is consensus on this path (unfortunately, there seemed to be no reaction on either side to this email) as reflected in the latest version of the Charter.

I'd like to re-iterate Robert's concerns (from his e-mail of 04/19/2002) and ask the fundamental question: Why are we even considering KEM when we already have a sufficient solution with OAEP?

Mike

-----Original Message-----
From: Housley, Russ [mailto:rhousley <at> rsasecurity.com]
Sent: Wednesday, April 24, 2002 5:14 PM
To: ietf-smime <at> imc.org
Subject: RE: Charter Update



Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should be in separate,
independent documents.  This would allow AES to be used with any of the key
management techniques?

Russ

Housley, Russ | 1 May 19:21 2002

Re: Why KEM?, RE: Charter Update

Mike:

I think that I did respond to Robert's question.  At IETF 53, I gave a presentation on this subject.  You can see the slides at http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html.

Russ


At 01:14 PM 5/1/2002 -0400, Mike Just wrote:

It's not clear to me that there is consensus on this path (unfortunately, there seemed to be no reaction on either side to this email) as reflected in the latest version of the Charter.

I'd like to re-iterate Robert's concerns (from his e-mail of 04/19/2002) and ask the fundamental question: Why are we even considering KEM when we already have a sufficient solution with OAEP?

Mike

-----Original Message-----
From: Housley, Russ [mailto:rhousley <at> rsasecurity.com]
Sent: Wednesday, April 24, 2002 5:14 PM
To: ietf-smime <at> imc.org
Subject: RE: Charter Update


Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should be in separate,
independent documents.  This would allow AES to be used with any of the key
management techniques?

Russ
Mike Just | 1 May 19:33 2002

RE: Why KEM?, RE: Charter Update

Thanks Russ.  I did manage to look at your slides when you first posted them to the list on April 17th.  I found them very helpful.   However, I think Robert has raised some good points (based on the issues claimed in your slides) that question the motivation for even considering a move to KEM.  I've attached his email below for your convenience.  I think we have chosen a very good direction already with OAEP and am not convinced that we need to change this. 
 
Mike
 
 
 
---- Robert's email of 04/19/2002 ---
-----Original Message-----
From: Robert Zuccherato [mailto:robert.zuccherato <at> entrust.com]
Sent: Friday, April 19, 2002 10:46 AM
To: 'Housley, Russ'; ietf-smime <at> imc.org
Subject: RE: Charter Update

Russ;

Having not attended the Minneapolis meeting I must say that I was very surprised by your recommendation to drop OAEP as the MUST implement key transport mechanism with AES in favour of KEM.  It wasn't all that long ago that you were attempting to get everyone (S/MIME, TLS, X9.44) to agree on requiring OAEP with AES as a method of transitioning to OAEP from PKCS#1 v1.5.  Partly as a result of that effort, implementations of OAEP have started to appear (e.g. OpenSSL) and transitions to OAEP can actually now start to occur.  If we are going to introduce a new MUST algorithm, and thus additional uncertainty about what to use and how to transition, we really should have a good reason.

In your presentation you say that KEM has better security proofs.  That may be, however, OAEP is still secure.  No actual weaknesses in it have been found.  On RSA's website there is a description of recent results on OAEP that says "... it makes little sense replacing OAEP with a "more secure" encoding method, because if a CCA2 adversary is able to break RSAEP-OAEP, then she will be able to break RSAEP equipped with any encoding method (if maybe slightly less efficiently)."  (http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.html)  Thus, there is no need to introduce KEM for security reasons.

Your presentation also lists some standards that already include KEM.  However, all of the ones that are listed except TLS also specify OAEP (ANSI X9.44, IEEE P1363, ISO/IEC 18033-2, PKCS#1, S/MIME).  TLS, while it specifies a variant of KEM, doesn't actually use anything that is compatible with the KEM that S/MIME (and the other groups listed) would be using.  I would also like to point out that XML Encryption has OAEP as a required key transport method.  At this point it does seem like OAEP is starting to get adopted by other groups and thus introducing KEM now seems to be counterproductive.

It is true that with OAEP the message length is bounded.  However, for our requirements here, is that really an issue? 

For these reasons I think we should reconsider your proposal to use RSA-KEM instead of RSA-OAEP in draft-ietf-smime-aes-alg.


Robert Zuccherato
Entrust, Inc.

--------------------------------------------
 
 
-----Original Message-----
From: Housley, Russ [mailto:rhousley <at> rsasecurity.com]
Sent: Wednesday, May 01, 2002 1:22 PM
To: Mike Just
Cc: ietf-smime <at> imc.org
Subject: Re: Why KEM?, RE: Charter Update

Mike:

I think that I did respond to Robert's question.  At IETF 53, I gave a presentation on this subject.  You can see the slides at http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html.

Russ


At 01:14 PM 5/1/2002 -0400, Mike Just wrote:

It's not clear to me that there is consensus on this path (unfortunately, there seemed to be no reaction on either side to this email) as reflected in the latest version of the Charter.

I'd like to re-iterate Robert's concerns (from his e-mail of 04/19/2002) and ask the fundamental question: Why are we even considering KEM when we already have a sufficient solution with OAEP?

Mike

-----Original Message-----
From: Housley, Russ [mailto:rhousley <at> rsasecurity.com]
Sent: Wednesday, April 24, 2002 5:14 PM
To: ietf-smime <at> imc.org
Subject: RE: Charter Update


Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should be in separate,
independent documents.  This would allow AES to be used with any of the key
management techniques?

Russ
Bonatti, Chris | 1 May 20:14 2002

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

Omer Hasret | 2 May 10:04 2002
Picon

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

Marc Mutz | 3 May 15:36 2002
Picon

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

Peter Gutmann | 3 May 16:15 2002
Picon
Picon
Picon

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.

Housley, Russ | 3 May 16:18 2002

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

Marc Mutz | 3 May 18:56 2002
Picon

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


Gmane