Subject: I-D ACTION:draft-ietf-smime-cms-07.txt

From: [email-masked]
Date: Mon, 26 Oct 1998 10:22:18 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the S/MIME Mail Security Working Group of the IETF.

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-07.txt
	Pages		: 52
	Date		: 23-Oct-98
	
   This document describes the Cryptographic Message Syntax.  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary messages.
 
   The Cryptographic Message Syntax is derived from PKCS #7 version 1.5
   [RFC 2315].  Wherever possible, backward compatibility is preserved;
   however, changes were necessary to accommodate attribute certificate
   transfer and key agreement techniques for key management.
 
   This draft is being discussed on the 'ietf-smime' mailing list.  To
   join the list, send a message to <[email-masked]> with
   the single word 'subscribe' in the body of the message.  Also, there
   is a Web site for the mailing list at <http://www.imc.org/ietf-
   smime/>.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cms-07.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-07.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-07.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 1998 17:06:03 -0500

S/MIME WG Memebers:

CMS is now read for Working Group Last Call.  The X9.42 draft is not
complete, but it should be posted near the end of the week.  Last Call will
close two weeks after the X9.42 draft is posted.

Russ
S/MIME WG Chair

>   is a Web site for the mailing list at <http://www.imc.org/ietf->   smime/>.
>
>Content-Type: text/plain
>Content-ID:	<[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-smime-cms-07.txt
>
><ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-07.txt>

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 27 Oct 1998 02:32:48 +0000

Russ,

A few comments.

As I understand the ES DH description there are two separate OIDs:
id-alg-ESDHwithRC2 and id-alg-ESDHwith3DES. This specifies both the key
transport and the symmetric encryption algorithms. What if someone wants
to use a different symmetric algorithm? Do they need to register an
id-alg-ESDHwithXXX OID and does everyone need to change their code to
support it? If history is anything to go by this will result in lots of
incompatible id-alg-ESDHwithXXX OIDs used by different applications.

Is there some specific reason why we can't do the same as with RSA? That
is have an id-alg-ESDH OID and then a separate symmetric algorithm OID.
That way if someone wants to support some other algorithm with a
registered OID they can already do it in a compatible way.

In 12.6:

>    The key-encryption key is generated by the key agreement algorithm or
>    distributed as a mail list key.  With key agreement, the minimum
>    number of bits needed to form the key-encryption key must be used.
>    As an example, only the first 40 bits of Diffie-Hellman generated
>    keying material are used for a RC2/40 key-encryption key.

This appears to be the "RC2 key length X/8" option. This adds the
restriction that X/8 must always be used in mixed DH+RSA messages though
just RSA need not be restricted to X/8. Or am I misinterpreting this?

Steve.
-- 
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant. 
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: [email-masked]
PGP key: via homepage.

---

From: EKR <[email-masked]>
Date: 26 Oct 1998 18:57:55 -0800

> just RSA need not be restricted to X/8. Or am I misinterpreting this?
You're right about this. Russ, I thought the plan here was to
use the Fixed-128 option.

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Oct 1998 22:23:38 -0500

>incompatible id-alg-ESDHwithXXX OIDs used by different applications.

Yes, an new OID is needed for each ESDHwithXXX.  We could have assigned one
OID with a parameter of the symmetric algorithm, but then the structure is
not quite right since the symmetric algorithm OID might require IVs or some
other parameter.

>registered OID they can already do it in a compatible way.

With RSA, the symmetric algorithm OID is inside the encrypted structure.
With E-S D-H we would have to put the symmetric algorithm OID as a
parameter to the ESDH OID.

>just RSA need not be restricted to X/8. Or am I misinterpreting this?

You're right about this. Based on Eric's message, I will change it to use
the Fixed-128 option.

Russ

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 27 Oct 1998 12:46:34 +0000

> not quite right since the symmetric algorithm OID might require IVs or some

OK let me see if I've got this right. The message encryption key and
parameters (e.g. IV) come from the ContentEncryptionAlgorithmIdentifier
field.

The key encryption key algorithm and key transport algorithm is
determined implicitly from the keyEncryptionAlgorithm (which is now a
"key transport algorithm and key encryption algorithm") and the IV is
'A5' as mentioned in 12.6.2 (6).

This implies that the content encryption algorithm can be anything but
the key encryption algorithm can only be RC2 or triple DES unless and
until more OIDs are registered. 

Although 3DES is mandatory for S/MIME I suspect someone is going to want
to use DES, Blowfish, Idea or maybe RC5 and would not want to implement
another symmetric algorithm just for the key wrap. Considering the
change in US crypto laws there may be good reasons why someone would
want to use DES for 56 bits to avoid possible patent problems with 56
bit RC2. IMHO we should at least provide some syntax where this can be
done without necessitating OID registration and the possible chaos of
multiple OIDs.

I agree that just using an AlgorithmIdentifier for the KEK algorithm is
not strictly speaking correct because the IV will be included but 'A5'
will be used for the IV. However this appears to be allowed for in
12.6.1:

>    Some key-encryption algorithm identifiers include an IV as part of
>    the parameters.  The IV must still be the constant above.

Adding support for arbitrary key wrapping algorithms could be done in
two ways. One as you mention is to include the KEK algorithm in the
KeyEncryptionAlgorithmIdentifier parameters. The other is to change
KeyTransRecipientInfo to read:

   KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyTransportAlgorithm KeyTransportAlgorithmIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey }

So that for example for triple DES KeyEncryptionAlgorithmIdentifier
would be id-alg-ESDH and KeyEncryptionAlgorithmIdentifier would be
des-ede3-cbc the IV present being ignored for the key wrap and 'A5' used
instead (or maybe even forcing the IV parameter to be 'A5' and returning
and error if it is not).

A similar thing could be done with the mailing list wrapping algorithms.

This would have the advantage that any wrapping algorithms could be
handled automatically (if the algorithm was supported) rather than
having to add algorithm specific code for each wrapping OID.

Steve.

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 27 Oct 1998 16:52:39 +0000

Ooops I messed up my response and got key agreement and transport
transposed sorry. Hopefully it should have read...

> 'A5' as mentioned in 12.6.2 (6).

I meant key agreement algorithm... 

>      encryptedKey EncryptedKey }

Likewise this proposal should read:

      KeyAgreeRecipientInfo ::= SEQUENCE {
        version CMSVersion,  -- always set to 3
        originator [0] EXPLICIT OriginatorIdentifierOrKey,
        ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
	keyArgeeAlgorithmIdentifier KeyAgreeAlgorithmIdentifier,
        keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
        recipientEncryptedKeys RecipientEncryptedKeys }

Steve.

---

From: Russ Housley <[email-masked]>
Date: Tue, 27 Oct 1998 18:31:53 -0500

I think I understand Steve's point.  What do others think about this topic?

Russ

---

From: Magnus Nyström <[email-masked]>
Date: Wed, 28 Oct 1998 09:16:30 -0500 (Eastern Standard Time)

Stephen Henson's first approach is similar to the approach taken in the
new version (2.0) of PKCS#5, where the same problem previously existed -
pbe algorithms where (unnecessarily) tied to particular encryption
algorithms (e.g pbeWithMD5AndDES-CBC). My personal opinion is that Stephen
Hensons proposal is to be preferred, due to it's dynamic nature.

/Magnus
------------------------------------------------------------
Magnus Nyström            Email: [email-masked]
RSA Laboratories          Phone: (781) 687-7000
20 Crosby Drive           Fax:   (781) 687-7213
Bedford, MA 01730  USA

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 29 Oct 1998 01:42:49 +0000

> Hensons proposal is to be preferred, due to it's dynamic nature.

It was because of what happened with PKCS#5 and its variants and
extensions (PFX, PKCS#12 and vendor specific hacks and horrors) that I
made the suggestion.

Steve.