Subject: Draft cutoff next Friday
From: Russ Housley <[email-masked]>
To: [email-masked]
Date: Fri, 31 Jul 1998 16:55:20 -0400

We have one week to go. We have a few open issues, and I would like to see
them resolved in the next few days.  This way, we can have a complete set
of documents (CMS, MSG, CERT, and ESS) for the meeting.  Can the issues be
resolved by Tuesday or Wednesday? Let's try.

Russ

Date: Thu, 30 Jul 1998 16:10:33 -0400
To: EKR <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: SignatureAlgorithmIdentifiers
Cc: [email-masked]
Sender: [email-masked]

Eric:

I just realized that I had not reponded to this message on the list.

I can accept the single rsaEncryption OID with the digest as a parameter.

Russ

At 07:23 AM 7/13/98 -0700, EKR wrote:
>Russ Housley <[email-masked]> writes:
>
>> Eric & Blake:
>> 
>> I prefer the single OID approach; however, I do understand the backward
>> compatibility concern.  Certificates use a single OID to specify the hash
>> (a.k.a. digest) and signature algorithm.  I would prefer a solution that
>> was parallel.  This admits the possibility of a common routine for all
>> signature verification.
>>
>> I think that we all agree that id-dsa-with-sha-1 should be used for DSA and
>> SHA-1.  So, lets put that ncontrovercial one aside.
>> 
>> I propose that sha-1WithRSAEncryption be used with RSA and SHA-1.  This
>> combination is not deployed in any product that I am aware of, so there is
>> not an issue with backward compatability.  PKIX Part 1 uses
>> sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 
>> 
>> For the reasons already stated, I would like to see implementations support
>> md2WithRSAEncryption and md5WithRSAEncryption.  However, rsaEncryption is
>> already used in many implementations.  So, for RSA with MD2 and MD5 mandate
>> (a MUST) the processing of rsaEncryption and allow (a SHOULD) the
>> processing of md2WithRSAEncryption and md5WithRSAEncryption.
>Russ, 
>
>Maybe I missed a prior message where you spelled out your
>reasoning more fully, but the first paragraph above implies that you
>believe that the single OID solution is a convenience to
>implementors. It's not. Since they now have to program to support two
>representations, not one. As long as rsaEncryption is allowed
>(mandated by backward compatibility) this will be true.
>
>Lest you get the idea that I'm just avoiding work, let e state that I
>don't like the single OID solution on protocol grounds.  a bad
>design. It proliferates identifiers unnecessarily, which seems
>tasteless, and it makes combinations excessively difficult (in the
>limit you need a lookup table to map OIDs to digest-signature
>combinations). This information (the digest algorithm) is perfectly
>well represented in the digestAlgorithm field. There's no need to
>recapitulate it here.
>
>Even if you believe this was a design mistake in PKCS-7, this change
>doesn't really patch it. The signature validation algorithm
>(and generation, FWIW) will have to be different for 
>PKCS-7 and X.509, because the PKCS-7 algorithm has to take
>(and process) digestAlgorithm as the input in the rsaEncryption
>case. Moreover, as I indicated earler, this change brings up the 
>unpleasant question (which I believe would have to be answered
>in the protocol document) of what to do when the digestAlgorithm
>and the digest in the signatureAlgorithm don't match.
>
>-Ekr
>
>-- 
>[Eric Rescorla                             Terisa Systems, Inc.]
>		"Put it in the top slot."
> 

Date: Wed, 29 Jul 1998 09:44:36 -0400
To: [email-masked]
From: [email-masked] (John Pawling)
Subject: Re: Question on adding an eSSSecurity Label
Sender: [email-masked]

Bill,

>Is this true even if a signerInfo does not have any signed attributes?

Yes.  In your example below, if the first SignerInfo does not have any
signedAttrs, then none of the other SignerInfos are allowed to include an
eSSSecurityLabel attribute.

In general, an additional signer can never change the data covered by the
signature of each existing SignerInfo, because the additional signer does
not possess the original signer's private digital signature key required to
re-calulate the original signer's signature of the data covered by the
signature of the existing SignerInfo.

================================
John Pawling, [email-masked]                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================

At 02:11 PM 7/29/98 +0100, William Ottaway wrote:
>Hi,
>
>In section 3.1.1 of ESS-06 it states :-
>
>"If any of the SignerInfos included in a SignedData object include an
>eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData
>object MUST include an eSSSecurityLabel attribute and the value of each
>MUST be identical."
>
>Is this true even if a signerInfo does not have any signed attributes?
>
>For example, if the first SignerInfo does not have any signedAttrs and a
>second SignerInfo is added which contains an eSSSecurityLabel, the first
>SignerInfo must have an eSSSecurityLabel added, and therefore a contentType
>and messageDigest atrribute, and the signature recalculated.
>
>Bill
>
>
>_____________________________________________________________________
>William Ottaway,             Tel: +44 (0)1684 894079
>DERA Malvern,                Fax: +44 (0)1684 896113
>St. Andrews Road,            email: [email-masked]
>Malvern,
>Worcs, WR14 3PS
>UK
>
>

Date: Wed, 29 Jul 1998 14:11:33 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Question on adding an eSSSecurity Label
Sender: [email-masked]

Hi,

In section 3.1.1 of ESS-06 it states :-

"If any of the SignerInfos included in a SignedData object include an
eSSSecurityLabel attribute, then all of the SignerInfos in that SignedData
object MUST include an eSSSecurityLabel attribute and the value of each
MUST be identical."

Is this true even if a signerInfo does not have any signed attributes?

For example, if the first SignerInfo does not have any signedAttrs and a
second SignerInfo is added which contains an eSSSecurityLabel, the first
SignerInfo must have an eSSSecurityLabel added, and therefore a contentType
and messageDigest atrribute, and the signature recalculated.

Bill

_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

Date: Fri, 24 Jul 1998 15:48:56 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: CMS Section 12, take 3
Sender: [email-masked]

Paul,

Sec 12.1, to be consistent with Sec 11.2, the last sentence should read "In
addition, digest values may be located in the Message Digest signed
attribute".

Sec 12.2, as per Sec 12.1, I suggest you had the following at the end
"Signature values are located in the SignerInfo signature field.  In
addition, Signature values may be located in the Countersignature unsigned
attribute".

Sec 12.3.3.1, sentence should read "Distribution of the key material used
to encrypt ..."

Sec 12.6, the last sentence should read "MAC algorithms appear in the
AuthenticatedData macAlgorithm field".

Sec 12.6, as per Sec 12.1, I suggest you had the following at the end "MAC
values are located in the AuthenticatedData mac field".

Francois Rousseau

Date: Wed, 22 Jul 1998 13:55:46 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Patents and draft-ietf-smime-x942-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Paul:

I have not gotten a patent statement from you.  We need it as soon as
possible.

Can you tell us what portion of the specification is covered by the patent
or pending patent?

Russ

Date: Thu, 23 Jul 1998 14:26:08 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked]
Subject: Re: CMS Section 12, take 3
Sender: [email-masked]

Paul,

I browsed through your E-mail before shortly leaving my office for a
business trip and then holidays (In case of a subsequent E-mail, don't
be surprised if you get no quick response).

> 12  Supported Algorithms

> This section lists the algorithms that must be implemented.
> Additional algorithms that may be implemented are also included.
 
> 12.1  Digest Algorithms
 
(...)

> CMS implementations must include SHA-1. CMS implementations may include MD5.

> 12.2  Signature Algorithms
 
> CMS implementations must include DSA.  CMS implementations may include RSA.

(...)

> 12.2.1  DSA
 
> The DSA signature algorithm is defined in FIPS Pub 186 [FIPS 186]. The
> algorithm identifier for DSA is:
 
>     id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
>         us(840) x9-57 (10040) x9cm(4) 3 }

Now here is my concern. We have the OID above to specify SHA-1 with DSA.
This is fine.

If I want to specify a signature algorithm such as SHA-1 with RSA but
also MD5 with RSA, it is unclear to me how this can be unambiguously
specified, since the section 12.2.2 quoted below only specifies "RSA".

> 12.2.2  RSA

> The RSA signature algorithm is defined in RFC 2313 as modified below. The
> algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

> The AlgorithmIdentifier parameters field must be present and must contain
> an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
> a parameters field that contains null, as well as an absent parameters
> field.

> This specification modifies RFC 2313 to include SHA-1 as an additional
> digest algorithm. Section 10.1.2 of RFC 2313 is modified to list SHA-1
> in the bullet item about digestAlgorithm. The following OID is added to
> the list in section 10.1.2 of RFC 2313:

>    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
>         secsig(3) algorithm(2) 26}

Would you be able to clarify the topic and then the text ?

Thanks,

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: CMS Section 12, take 3
Date: Wed, 22 Jul 1998 13:22:47 -0700
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01BDB5AE.81FE88E0
Content-Type: text/plain;
	charset="iso-8859-1"

Section 12.3.2.1 - Please omit the fact that RFC 2321 is being modified from
this section.  We are not modifying the what that the encryption algorithm
in 2313 is done, one the signing algorithm.

Section 12.4 Paragraph 3.  Please remove "probably easily" from the last
sentence.  We are now making a statment of fact not a question of how.  Also
remove the words "may be" and substitue "is" in the preceeding sentence.

Section 12.4 key wrap bullet 6.  Please change the last sentence to "The IV
must be encoded using the fixed value."

Section 12.4 Key unwrap - Add a new sentence to the end of bullet 1.  "(If
the IV is encoded as part of the parameters, it is an error if the IV is not
the fixed value.)"

Last note -  I have people who are complaining that the DSA and HMAC-SHA1
functions are taking no rather than NULL parameters.  Can you give me the
appropriate references so that I can hit someone over the head with them.
(Either you for being wrong or them for wanting what is wrong.)  Thanks --

Jim Schaad

------_=_NextPart_001_01BDB5AE.81FE88E0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2232.0">
<TITLE>RE: CMS Section 12, take 3</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>Section 12.3.2.1 - Please omit the fact that RFC 2321 =
is being modified from this section.&nbsp; We are not modifying the =
what that the encryption algorithm in 2313 is done, one the signing =
algorithm.</FONT></P>

<P><FONT SIZE=3D2>Section 12.4 Paragraph 3.&nbsp; Please remove =
&quot;probably easily&quot; from the last sentence.&nbsp; We are now =
making a statment of fact not a question of how.&nbsp; Also remove the =
words &quot;may be&quot; and substitue &quot;is&quot; in the preceeding =
sentence.</FONT></P>

<P><FONT SIZE=3D2>Section 12.4 key wrap bullet 6.&nbsp; Please change =
the last sentence to &quot;The IV must be encoded using the fixed =
value.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Section 12.4 Key unwrap - Add a new sentence to the =
end of bullet 1.&nbsp; &quot;(If the IV is encoded as part of the =
parameters, it is an error if the IV is not the fixed =
value.)&quot;</FONT></P>
<BR>

<P><FONT SIZE=3D2>Last note -&nbsp; I have people who are complaining =
that the DSA and HMAC-SHA1 functions are taking no rather than NULL =
parameters.&nbsp; Can you give me the appropriate references so that I =
can hit someone over the head with them.&nbsp; (Either you for being =
wrong or them for wanting what is wrong.)&nbsp; Thanks --</FONT></P>
<BR>

<P><FONT SIZE=3D2>Jim Schaad</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01BDB5AE.81FE88E0--

Date: Wed, 22 Jul 1998 09:43:31 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: CMS Section 12, take 3
Sender: [email-masked]

We're trying to reach closure on this, so please look at it as soon as you can an comment.

--Paul Hoffman, Director
--Internet Mail Consortium

12  Supported Algorithms

This section lists the algorithms that must be implemented.
Additional algorithms that may be implemented are also included.

12.1  Digest Algorithms

CMS implementations must include SHA-1. CMS implementations may include MD5.

Digest algorithm identifiers are used in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, and the DigestedData
digestAlgorithm field.

Digest values are located in the DigestedData digest field. In addition,
digest values are located in the Message Digest authenticated attribute.

12.1.1  SHA-1

The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 180-1]. The
algorithm identifier for SHA-1 is:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

The AlgorithmIdentifier parameters field must be present and must contain
an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
a parameters field that contains null, as well as an absent parameters
field.

12.1.2  MD5

The MD5 digest algorithm is defined in RFC 1321. The algorithm
identifier for MD5 is:

    md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) digestAlgorithm(2) 5}

The AlgorithmIdentifier parameters field must be present and must contain
an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
a parameters field that contains null, as well as an absent parameters
field.

12.2  Signature Algorithms

CMS implementations must include DSA.  CMS implementations may include RSA.

Signature algorithm identifiers are used in the SignerInfo
signatureAlgorithm field.

12.2.1  DSA

The DSA signature algorithm is defined in FIPS Pub 186 [FIPS 186]. The
algorithm identifier for DSA is:

    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
        us(840) x9-57 (10040) x9cm(4) 3 }

The AlgorithmIdentifier parameter field must not be present.

12.2.2  RSA

The RSA signature algorithm is defined in RFC 2313 as modified below. The
algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameters field must be present and must contain
an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
a parameters field that contains null, as well as an absent parameters
field.

This specification modifies RFC 2313 to include SHA-1 as an additional
digest algorithm. Section 10.1.2 of RFC 2313 is modified to list SHA-1
in the bullet item about digestAlgorithm. The following OID is added to
the list in section 10.1.2 of RFC 2313:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

12.3  Key Encryption Algorithms

CMS implementations must include Static Diffie-Hellman with tripleDES.  CMS
implementations may include RSA. CMS implementations may include
Static Diffie-Hellman with RC2.

Key encryption algorithms are used in the KeyTransRecipientInfo
keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
keyEncryptionAlgorithm field, and in the MailListRecipientInfo
keyEncryptionAlgorithm field. These are all part of the RecipientInfo
type, which is part of the EnvelopedData type.

12.3.1 Key Agreement Key Encryption Algorithms Used in
KeyAgreeRecipientInfo

12.3.1.1  Static Diffie-Hellman with tripleDES

Static Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman
Key Agreement Method, currently draft-ietf-smime-x942). The algorithm
identifier for static Diffie-Hellman with tripleDES is

    id-smime-cms-dh-with-tripleDES ::= { TBD }

The AlgorithmIdentifier parameters field must be present and must contain
an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
a parameters field that contains null, as well as an absent parameters
field.

12.3.1.2  Static Diffie-Hellman with RC2

Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman Key
Agreement Method, currently draft-ietf-smime-x942). The algorithm
identifier for static Diffie-Hellman with RC2 is

    id-smime-cms-dh-with-rC2 ::= { TBD }

For the effective-key-bits (key size) greater than 32 and less than
256, the algorithm parameters are encoded as:

    id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1.

12.3.2 Key Transport Key Encryption Algorithms Used in
KeyTransRecipientInfo

12.3.2.1  RSA

The RSA encryption algorithm is defined in RFC 2313 as modified below. The
algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameters field must be present and must contain
an ASN.1 NULL. Implementations should accept this AlgorithmIdentifier with
a parameters field that contains null, as well as an absent parameters
field.

This specification modifies RFC 2313 to include SHA-1 as an additional
digest algorithm. Section 10.1.2 of RFC 2313 is modified to list SHA-1
in the bullet item about digestAlgorithm. The following OID is added to
the list in section 10.1.2 of RFC 2313:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

12.3.3 Mail List Key Encryption Algorithms Used in MailListRecipientInfo

Mail list key encryption is defined in this section.  The key material used
to encrypt the message encryption key is distributed by an independent
mechanism.  Two different mail list key encryption algorithms are defined by
this draft.  CMS implementations must include mail list key encryption with
tripleDES if mail list key encryption is implemented.  CMS implementations may
also implement mail list key encryption with RC2.

12.3.3.1  Mail List Key Encryption with tripleDES

Mail list key encryption with triple DES has the algorithm identifier

    id-smime-cms-mlk-with-tripleDES ::= {TBD}

The AlgorithmIdentifier parameter field must be encoded as ASN.1 NULL.
Distribution of the key material used to encryption the message encryption
key is out of the scope of this document.

12.3.3.2 Mail List Key Encryption with RC2

Mail list key encryption with RC2 has the algorithm identifier

    id-smime-cms-mlk-with-rC2 ::= {TBD}

For the effective-key-bits (key size) greater than 32 and less than 256, the
algorithm parameters are encoded as:

    id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0) is
a negative number in ASN.1.

12.4 Key Wrapping Algorithm

Key Transport algorithms allow for the content-encryption key to be directly
encrypted.  Key agreement and mail list key exchange algorithms encrypt the
content-encryption key with a second (possibly different) block encryption
algorithm.  This section describes how the content-encryption key is
formatted and encrypted.

The bits used for the key-encryption key are generated by the key agreement
algorithm or are distributed as the mail list key. When obtaining the bits
of the key-encryption key the minimal number of bits needed to form the
key-encryption key must be used.  As an example only the first 40 bits of
key material would be used when using RC2/40-bit as a key-encryption
algorithm even though one may use more as RC2 starts by compressing the
input bits down to the algorithm size.

The block size of the key-encryption algorithm can be determined from the
CMS KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of
the content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
exception here; the same identifier is used for both 2-key and 3-key Triple
DES.  This is probably easily handled by always wrapping three keys, even
if the first and third keys match.

The key checksum algorithm is:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant octet to least significant octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         8 zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

The key wrap algorithm is:

1.  Modify the content-encryption key to meet any restrictions on the key.
An example of this would be modifying parity bits for DES and tripleDES
keys.
2.  Compute a 16-bit key checksum value on the content-encryption key as
described above.
3.  Generate a 4-octet random salt value.
4.  Concatenate the salt, content-encryption key, and key checksum value.
5.  Randomly generate the number of pad octets necessary to make the result
a multiple of block size of the key-encryption algorithm (the Triple-DES
algorithm block size is 8 bytes), then append them to the result.

{{{I am going to assume that this was suppose to be a random padding.}}}

6.  Encrypt the result with the key-encryption algorithm key.  Use an IV
with each octet equal to 'A5' hexadecimal. (Some key-encryption algorithms
encode the IV as part of the parameters.  The IV must still be the constant
octet string.)

The key unwrap algorithm is:

1.  Decrypt the wrapped ciphertext using the key-encryption key. Use an IV
with each octet equal to 'A5' hexadecimal.
2.  Decompose the result into the content-encryption key and key checksum
values
3.  Compute a 16-bit key checksum value on the content-encryption key as
described above.
4.  If computed key checksum value does not match the decrypted key checksum
value, then there is an error.
5.  If there are restrictions on keys, then check if the content encryption
key meets these restrictions.  An example of this would be to check the
parity bits for DES and tripleDES keys.  If any restriction is incorrect
then there is an error.

12.5  Content Encryption Algorithms

CMS implementations must include Triple-DES in CBC mode.  CMS
implementations may include DES in CBC mode and RC2 in CBC mode.

Content encryption algorithms appear in the EncryptedContentInfo
contentEncryptionAlgorithm field, which is part of the EnvelopedData type
and the EncryptedData type.

12.5.1  Triple-DES CBC

The Triple-DES algorithm is described in [3DES]. The algorithm identifier
for Triple-DES is:

    DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
        rsadsi(113549) encryptionAlgorithm(3) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter ::= IV
    IV ::= OCTET STRING -- 8 octets.

12.5.2  DES CBC

The DES algorithm in CBC mode is described in [DES]. The algorithm
identifier for DES in CBC mode is:

    DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter ::= IV
    IV ::= OCTET STRING -- 8 octets.

12.5.3  RC2 CBC

The RC2 algorithm is described in RFC 2268. The algorithm identifier for
RC2 in CBC mode is:

    RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) encryptionAlgorithm(3) 2}

For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:

    RC2-CBC parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1.

12.6  Message Authentication Code Algorithms

No MAC algorithms are mandatory.  CMS implementations may include DES
MAC and HMAC.

MAC algorithms appear in the AuthenticatedData mac field.

12.6.1  DES MAC

The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
algorithm identifier for DES MAC is:

    DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 10 }

The AlgorithmIdentifier parameter field is required. It is an INTEGER, and
carries the length in bits of the MAC, constrained to multiples of eight
from 16 to 64.

12.6.2  HMAC-SHA1

The HMAC-SHA1 algorithm is described in RFC 2104. The algorithm identifier for
HMAC-SHA1 is:

    HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) 8 1 2}

The AlgorithmIdentifier parameter field must not be present.

{{{References added}}}

3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To DES". IEEE
Spectrum, v. 16, n. 7, pp40-41. July 1979.

DES  American National Standards Institute. ANSI X3.106, "American National
Standard for Information Systems- Data Link Encryption". 1983.

FIPS 113  National Institute of Standards and Technology. FIPS Pub 113:
Computer Data Authentication. May 1985.

FIPS 180-1  National Institute of Standards and Technology. FIPS Pub 180-1: 
Secure Hash Standard.  April 1995.

FIPS 186  National Institute of Standards and Technology. FIPS Pub 186:
Digital Signature Standard.  May 1994.

RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.

RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message Authentication.
February 1997.

RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
March 1998.

X9.42  ANSI X9.42-199x.  Public Key Cryptography for The Financial Services
Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
(Working Draft).  December 1997.

Date: Mon, 20 Jul 1998 12:32:46 -0700
To: "Jim Schaad (Exchange)" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Section 12, take 2
Sender: [email-masked]

At 08:04 PM 7/17/98 -0700, Jim Schaad (Exchange) wrote:
>OK -- here is the text I would prefer
>
>12.4 Key Wrapping Algorithm

OK, everybody. No one has commented on this; does that mean it's perfect
and I can put it in round 3?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Section 12, take 2
Date: Fri, 17 Jul 1998 20:04:58 -0700
Sender: [email-masked]

OK -- here is the text I would prefer

12.4 Key Wrapping Algorithm

Key Transport algorithms allow for the content-encryption key to be directly
encrypted.  Key agreement and mail list key exchange algorithms encrypt the
content-encryption key with a second (possibly different) block encryption
algorithm.  This section describes how the content-encryption key is
formatted and encrypted.

The bits used for the key-encryption key are generated by the key agreement
algorithm or are distributed as the mail list key. When obtaining the bits
of the key-encryption key the minimal number of bits needed to form the
key-encryption key must be used.  As an example only the first 40 bits of
key material would be used when using RC2/40-bit as a key-encryption
algorithm even though one may use more as RC2 starts by compressing the
input bits down to the algorithm size.

The block size of the key-encryption algorithm can be determined from the
CMS
KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
exception here; the same identifier is used for both 2-key and 3-key Triple
DES.  This is probably easily handled by always wrapping three keys, even if
the first and third keys match.

The key checksum algorithm is:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant octet to least significant octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         8 zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

The key wrap algorithm is:

1.  Modify the content-encryption key to meet any restrictions on the key.
An example of this would be modifying parity bits for DES and tripleDES
keys.
2.  Compute a 16-bit key checksum value on the content-encryption key as
described above.
3.  Generate a 4-octet random salt value.
4.  Concatenate the salt, content-encryption key, and key checksum value.
5.  Randomly generate the number of pad octets necessary to make the result
a multiple of block size of the key-encryption algorithm (the Triple-DES
algorithm block size is 8 bytes), then append them to the result. [JLS - I
am going to assume that this was suppose to be a random padding.]
6.  Encrypt the result with the key-encryption algorithm key.  Use an IV
with each octet equal to 'A5' hexadecimal. (Some key-encryption algorithms
encode the IV as part of the parameters.  The IV must still be the constant
octet string.)

The key unwrap algorithm is:

1.  Decrypt the wrapped ciphertext using the key-encryption key. Use an IV
with each octet equal to 'A5' hexadecimal.
2.  Decompose the result into the content-encryption key and key checksum
values
3.  Compute a 16-bit key checksum value on the content-encryption key as
described above.
4.  If computed key checksum value does not match the decrypted key checksum
value, then there is an error.
5.  If there are restrictions on keys, then check if the content encryption
key meets these restrictions.  An example of this would be to check the
parity bits for DES and tripleDES keys.  If any restriction is incorrect
then there is an error.

Date: Fri, 17 Jul 1998 18:16:20 -0700
To: "Blake Ramsdell" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Information on PKCS #1 vulnerability and update
Sender: [email-masked]

>To the MSG or the CMS draft?  It seems that PKCS #1 usage is defined in
>CMS, not MSG.

My thought was MSG because CMS might be used for online transactions, so
the wording would have to be very different. On further reflection, I think
we need to say something in both. MSG has a shorter "it's hard to get the
problem to happen in S/MIME unless there is an autoresponder who is very
verbose", and CMS has that plus information about online apps that use the
format as well.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Section 12, take 2
Date: Fri, 17 Jul 1998 15:02:38 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Friday, July 17, 1998 11:02 AM
> To: Jim Schaad (Exchange); Ietf-Smime (E-mail)
> Subject: RE: Section 12, take 2
> 
> This organization makes good sense to me. Do the other folks 
> reading the
> CMS spec agree?

Makes sense to me.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Blake Ramsdell" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: RE: Information on PKCS #1 vulnerability and update
Date: Fri, 17 Jul 1998 15:01:49 -0700
Sender: [email-masked]

(John Linn removed as a recipient -- nothing personal, John.)

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Friday, July 17, 1998 12:29 PM
> To: Linn, John; [email-masked]'
> Subject: Re: Information on PKCS #1 vulnerability and update
> 
> Note that it is very likely that S/MIME v3 will continue to 
> refer to RFC
> 2313. It is not expected that the new PKCS #7 v2 document 
> will be an RFC
> any time soon (although RSADSI has indicated a desire to 
> submit it as an
> RFC after it is finished). Thus, I think adding a note about this
> now-well-known problem in the MSG draft would be a Very Good Thing.

To the MSG or the CMS draft?  It seems that PKCS #1 usage is defined in
CMS, not MSG.

Blake

Date: Fri, 17 Jul 1998 12:29:19 -0700
To: "Linn, John" <[email-masked]>, "[email-masked]'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Information on PKCS #1 vulnerability and update
Sender: [email-masked]

At 03:10 PM 7/17/98 -0400, Linn, John wrote:
>As a result, the attack
>appears appreciably less feasible to perpetrate for store-and-forward S/MIME
>environments than for directly-interactive protocols (e.g., SSL, for which
>the vulnerability was first identified).  If S/MIME messaging constructs are
>applied as an intermediate layer within an interactive request-response
>communications environment, exploitation within such a context could become
>more feasible.

This is well worth mentioning in the Security section of the MSG draft, I
believe.

Note that it is very likely that S/MIME v3 will continue to refer to RFC
2313. It is not expected that the new PKCS #7 v2 document will be an RFC
any time soon (although RSADSI has indicated a desire to submit it as an
RFC after it is finished). Thus, I think adding a note about this
now-well-known problem in the MSG draft would be a Very Good Thing.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Linn, John" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Information on PKCS #1 vulnerability and update
Date: Fri, 17 Jul 1998 15:10:52 -0400
Sender: [email-masked]

To communicate and clarify some information relevant to PKCS #1 and, more
particularly, to its usage within S/MIME: 

A revised draft version of PKCS #1, targeted to become V2.0, is now
available for review on http://www.rsa.com/rsalabs/pubs/PKCS/, responding to
a recently-discovered vulnerability to adaptive chosen ciphertext attacks
and recommending use of OAEP padding when PKCS #1 RSA encryption is applied
for secrecy purposes. Comments are solicited to [email-masked], and
those received by Friday, 14 August will be considered in the final version.
The draft is available now in MS-Word .doc and Adobe Acrobat .pdf format;
preparation of an ASCII version is currently in progress.  

Exploitation of the identified vulnerability, revealing the result of a
particular RSA decryption, requires access to an oracle which will respond
to a large number (e.g., hundreds of thousands) of ciphertexts, which are
constructed adaptively in response to previously-received replies providing
information on the results of attempted decryptions. As a result, the attack
appears appreciably less feasible to perpetrate for store-and-forward S/MIME
environments than for directly-interactive protocols (e.g., SSL, for which
the vulnerability was first identified).  If S/MIME messaging constructs are
applied as an intermediate layer within an interactive request-response
communications environment, exploitation within such a context could become
more feasible.

--John Linn, RSA Laboratories 

Date: Fri, 17 Jul 1998 11:01:33 -0700
To: "Jim Schaad (Exchange)" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Section 12, take 2
Sender: [email-masked]

At 08:38 PM 7/16/98 -0700, Jim Schaad (Exchange) wrote:
>1.  Key Encryption Algorithms should be divided into three different
>sections:
>
>12.3.1 Key Agreement Key Encryption Algorithms
>	used in KeyAgreeRecipientInfo.
>	Sub-sections are Static Diffie-Hellman with tripleDES and Static
>Diffie-Hellman with RC2
>
>12.3.2 Key Transport Key Encryption Algorithms
>	Used in KeyTransRecipientInfo
>	Sub-section would be RSA
>
>12.3.3 Mail List Key Encryption Algorithms
>	Used in MailListRecipientInfo
>	Sub-Sections are Mail List tripleDES and Mail List RC2

This organization makes good sense to me. Do the other folks reading the
CMS spec agree?

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "Ietf-Smime (E-mail)" <[email-masked]>
Subject: RE: Section 12, take 2
Date: Thu, 16 Jul 1998 20:38:14 -0700
Sender: [email-masked]

This was suppose to have gone to the list not just Paul.

I have had some more time to think on item #1 below and here are my updated
comments:

1.  Key Encryption Algorithms should be divided into three different
sections:

12.3.1 Key Agreement Key Encryption Algorithms
	used in KeyAgreeRecipientInfo.
	Sub-sections are Static Diffie-Hellman with tripleDES and Static
Diffie-Hellman with RC2

12.3.2 Key Transport Key Encryption Algorithms
	Used in KeyTransRecipientInfo
	Sub-section would be RSA

12.3.3 Mail List Key Encryption Algorithms
	Used in MailListRecipientInfo
	Sub-Sections are Mail List tripleDES and Mail List RC2

Mail list key encryption is defined in this section.  The key material used
to encrypt the message encryption key is distributed by an independent
mechinism.  Two different mail list key encryption algorithms are defined by
this draft.  CMS implementations must include mail list key encryption with
tripleDES if mail list key encrytion is implemtented.  CMS implemeations may
also implement mail list key encryption with RC2.

12.3.3.1  Mail List Key Encryption with tripleDES

Mail list key encryption with triple DES has the algorithm identifier

id-smime-cms-mlk-with-tripleDES ::= {TBD}

The AlgorithmIdentifier parameter field must be encoded as ASN.1 NULL.
Distribution of the key material used to encryption the message encryption
key is out of the scope of this document.

12.3.3.2 Mail List Key Encryption with RC2

Mail list key encryption with RC2 has the algorithm identifier

id-smime-cms-mlk-with-rC2 ::= {TBD}

For the effective-key-bits (key size) greater than 32 and less than 256, the
algorithm parameters are encoded as:

    id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0) is
a negative number in ASN.1.

jim

> -----Original Message-----
> From: Jim Schaad (Exchange) 
> Sent: Thursday, July 16, 1998 3:59 PM
> To: 'Paul Hoffman / IMC'
> Subject: RE: Section 12, take 2
> 
> 
> Comments take 2
> 
> 1.  Section 12.3 - the set of Key Encrytion Algs is not what 
> will be used for MailListReipientInfo.  This should be if the 
> form id-smime-cms-with-tripleDES.  THere is no static d-h as 
> the bulk key to do the key encryption is what is distributed 
> as the mail list key.
> 
> 2.  Section 12.5.1 Change "CBCParameter :: IV" to 
> "CBCParameter ::= IV"
> 
> 3.  Section 12.1.1  - My dev people are saying that they 
> really want to include a NULL parameter for SHA just like 
> Eric says should be done for the MD5 ones.  Where did you see 
> the docs saying omit the parameters so that I can reference 
> it to my people.  Or should we just make them all consistant.
> 
> > -----Original Message-----
> > From: Paul Hoffman / IMC [mailto:[email-masked]]
> > Sent: Wednesday, July 15, 1998 9:01 PM
> > To: [email-masked]
> > Subject: Section 12, take 2
> > 
> > 
> > Here's the second pass on CMS section 12. I think I included all
> > of the comments other than Jim's about padding, which I didn't
> > see where it would go.
> > 
> > DO NOT CODE TO THIS MESSAGE. Y'all saw how many errors
> > there were in the first draft; I expect that there are still 
> > some here.
> > Please review it carefully and post comments to the list. Won't
> > Russ be pleased when he comes back from vacation? :-)
> > 
> > 12  Supported Algorithms
> > 
> > This section lists the algorithms that must be implemented.
> > Additional algorithms that may be implemented are also included.
> > 
> > 12.1  Digest Algorithms
> > 
> > CMS implementations must include SHA-1. CMS implementations 
> > may include MD5.
> > 
> > Digest algorithm identifiers are used in the SignedData 
> > digestAlgorithms
> > field, the SignerInfo digestAlgorithm field, and the DigestedData
> > digestAlgorithm field.
> > 
> > Digest values are located in the DigestedData digest field. 
> > In addition,
> > digest values are located in the Message Digest authenticated 
> > attribute.
> > 
> > 12.1.1  SHA-1
> > 
> > The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 
> > 180-1]. The
> > algorithm identifier for SHA-1 is:
> > 
> >     sha-1 OBJECT IDENTIFIER ::= {iso(1) 
> > identified-organization(3) oiw(14)
> >         secsig(3) algorithm(2) 26}
> > 
> > The AlgorithmIdentifier parameter field is optional.  If 
> present, the
> > parameter field must contain an ASN.1 NULL.  Implementations should
> > generate SHA-1 AlgorithmIdentifiers with the parameter field 
> > containing a
> > NULL value. Implementations should accept SHA-1 
> > AlgorithmIdentifiers with
> > NULL parameters as well as absent parameters.  Note that current CMS
> > implementations encode SHA-1 both with and without the NULL 
> > attributes.
> > 
> > 12.1.2  MD5
> > 
> > The MD5 digest algorithm is defined in RFC 1321. The algorithm
> > identifier for MD5 is:
> > 
> >     md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
> >         rsadsi(113549) digestAlgorithm(2) 5}
> > 
> > The AlgorithmIdentifier parameter field is optional.  If 
> present, the
> > parameter field must contain an ASN.1 NULL.  Implementations should
> > generate MD5 AlgorithmIdentifiers with the parameter field 
> > containing a
> > NULL value. Implementations should accept MD5 
> > AlgorithmIdentifiers with
> > NULL parameters as well as absent parameters. Note that current CMS
> > implementations encode MD5 both with and without the NULL 
> attributes.
> > 
> > 12.2  Signature Algorithms
> > 
> > CMS implementations must include DSA.  CMS implementations 
> > may include RSA.
> > 
> > Signature algorithm identifiers are used in the SignerInfo
> > signatureAlgorithm field.
> > 
> > 12.2.1  DSA
> > 
> > The DSA signature algorithm is defined in FIPS Pub 186 
> [FIPS 186]. The
> > algorithm identifier for DSA is:
> > 
> >     id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
> >         us(840) x9-57 (10040) x9cm(4) 3 }
> > 
> > The AlgorithmIdentifier parameter field must not be present.
> > 
> > 12.2.2  RSA
> > 
> > The RSA signature algorithm is defined in RFC 2313 as 
> > modified below. The
> > algorithm identifier for RSA is:
> > 
> >     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) 
> member-body(2) us(840)
> >         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> > 
> > The AlgorithmIdentifier parameter field is optional.  If 
> present, the
> > parameter field must contain an ASN.1 NULL.  Implementations should
> > generate RSA AlgorithmIdentifiers with the parameter field 
> > containing a
> > NULL value. Implementations should accept RSA 
> > AlgorithmIdentifiers with
> > NULL parameters as well as absent parameters.  Note that current CMS
> > implementations encode RSA both with and without the NULL 
> attributes.
> > 
> > This specification modifies RFC 2313 to include SHA-1 as an 
> additional
> > digest algorithm. Section 10.1.2 of RFC 2313 is modified to 
> list SHA-1
> > in the bullet item about digestAlgorithm. The following OID 
> > is added to
> > the list in section 10.1.2 of RFC 2313:
> > 
> >     sha-1 OBJECT IDENTIFIER ::= {iso(1) 
> > identified-organization(3) oiw(14)
> >         secsig(3) algorithm(2) 26}
> > 
> > 12.3  Key Encryption Algorithms
> > 
> > CMS implementations must include Static Diffie-Hellman with 
> > tripleDES.  CMS
> > implementations may include RSA. CMS implementations may include
> > Static Diffie-Hellman with RC2.
> > 
> > Key encryption algorithms are used in the KeyTransRecipientInfo
> > keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
> > keyEncryptionAlgorithm field, and in the MailListRecipientInfo
> > keyEncryptionAlgorithm field. These are all part of the 
> RecipientInfo
> > type, which is part of the EnvelopedData type.
> > 
> > 12.3.1  Static Diffie-Hellman with tripleDES
> > 
> > Static Diffie-Hellman key encryption is defined in RFC TBD 
> > (Diffie-Hellman
> > Key Agreement Method, currently draft-ietf-smime-x942). The 
> algorithm
> > identifier for static Diffie-Hellman with tripleDES is
> > 
> >     id-smime-cms-dh-with-tripleDES ::= { TBD }
> > 
> > The AlgorithmIdentifier parameter field is optional.  If 
> present, the
> > parameter field must contain an ASN.1 NULL.  Implementations should
> > generate Static Diffie-Hellman AlgorithmIdentifiers with 
> the parameter
> > field containing a NULL value. Implementations should accept Static
> > Diffie-HellmanAlgorithmIdentifiers with NULL parameters as 
> > well as absent
> > parameters.
> > 
> > 12.3.2  RSA
> > 
> > The RSA encryption algorithm is defined in RFC 2313 as 
> > modified below. The
> > algorithm identifier for RSA is:
> > 
> >     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) 
> member-body(2) us(840)
> >         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> > 
> > The AlgorithmIdentifier parameter field is optional.  If 
> present, the
> > parameter field must contain an ASN.1 NULL.  Implementations should
> > generate RSA AlgorithmIdentifiers with the parameter field absent.
> > Implementations should accept RSA AlgorithmIdentifiers with 
> > NULL parameters
> > as well as absent parameters.  Note that current CMS 
> > implementations encode
> > RSA both with and without the NULL attributes.
> > 
> > This specification modifies RFC 2313 to include SHA-1 as an 
> additional
> > digest algorithm. Section 10.1.2 of RFC 2313 is modified to 
> list SHA-1
> > in the bullet item about digestAlgorithm. The following OID 
> > is added to
> > the list in section 10.1.2 of RFC 2313:
> > 
> >     sha-1 OBJECT IDENTIFIER ::= {iso(1) 
> > identified-organization(3) oiw(14)
> >         secsig(3) algorithm(2) 26}
> > 
> > 12.3.3  Static Diffie-Hellman with RC2
> > 
> > Diffie-Hellman key encryption is defined in RFC TBD 
> > (Diffie-Hellman Key
> > Agreement Method, currently draft-ietf-smime-x942). The algorithm
> > identifier for static Diffie-Hellman with RC2 is
> > 
> >     id-smime-cms-dh-with-rC2 ::= { TBD }
> > 
> > For the effective-key-bits (key size) greater than 32 and less than
> > 256, the algorithm parameters are encoded as:
> > 
> >     id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
> >         rc2ParameterVersion  INTEGER,
> >         iv                   OCTET STRING (8)}
> > 
> > For the effective-key-bits of 40, 64, and 128, the 
> rc2ParameterVersion
> > values are 160, 120, 58 respectively. It is very important to 
> > note that
> > these values are not simply the RC2 keylength. Also note that 
> > the value 160
> > must be encoded as two octets (00 A0), because encoding as 
> > one octet (A0)
> > is a negative number in ASN.1.
> > 
> > 12.4  Triple-DES Key Wrap
> > 
> > {{{Jim Schaad wanted this to be more general, and will come 
> > up with the
> > wording to make it so.}}}
> > 
> > The block size of the key-encryption algorithm can be 
> > determined from the CMS
> > KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, 
> > the size of the
> > content-encryption key can be determined from the CMS
> > ContentEncryptionAlgorithmIdentifier protocol field.  
> > Triple-DES may be an
> > exception here; the same identifier is used for both 2-key 
> > and 3-key Triple
> > DES.  This is probably easily handled by always wrapping 
> > three keys, even if
> > the first and third keys match.
> > 
> > The key checksum algorithm is:
> > 
> > 1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
> > 2.  Loop through the octets of the content-encryption key, most
> >     significant octet to least significant octet.
> >     2a.  Create a 16 bit integer, called temp, by concatenating 
> >          8 zero bits and the key octet.
> >     2b.  sum1 = sum1 + temp.
> >     2c.  sum2 = sum2 + sum1.
> > 3.  Use sum2 as the checksum value.
> > 
> > The key wrap algorithm is:
> > 
> > 1.  Adjust the parity bits on the Triple-DES keys.
> > 2.  Compute a 16-bit key checksum value on the content-encryption
> >     key as described above.
> > 3.  Generate a 4-octet random salt value.
> > 4.  Concatenate the salt, content-encryption key, and key 
> >     checksum value.
> > 5.  Generate the number of pad octets necessary to make the
> >     result a multiple of 8 bytes (the Triple-DES algorithm block
> >     size), then append them to the result.
> > 
> > {{{Is this a constant or random pad???}}}
> > 
> > 6.  Encrypt the result with the tripleDES key.  Use an IV
> >     with each octet equal to 'A5' hexadecimal.
> > 
> > The key unwrap algorithm is:
> > 
> > 1.  Decrypt the wrapped ciphertext using the key-encryption key.
> >     Use an IV with each octet equal to 'A5' hexadecimal.
> > 2.  Check the parity of the content encryption keys.  If any is 
> >     incorrect then there is an error.
> > 3.  Compute a 16-bit key checksum value on the content-encryption
> >     key as described above.
> > 4.  If computed key checksum value does not match the decrypted
> >     key checksum value, then there is an error.
> > 
> > 12.5  Content Encryption Algorithms
> > 
> > CMS implementations must include Triple-DES in CBC mode.  CMS
> > implementations may include DES in CBC mode and RC2 in CBC mode.
> > 
> > Content encryption algorithms appear in the EncryptedContentInfo
> > contentEncryptionAlgorithm field, which is part of the 
> > EnvelopedData type
> > and the EncryptedData type.
> > 
> > 12.5.1  Triple-DES CBC
> > 
> > The Triple-DES algorithm is described in [3DES]. The 
> > algorithm identifier
> > for Triple-DES is:
> > 
> >     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) 
> member-body(2) us(840) 
> >         rsadsi(113549) encryptionAlgorithm(3) 7}
> > 
> > The AlgorithmIdentifier parameter field is required and has 
> > the structure:
> > 
> >     CBCParameter :: IV
> >     IV ::= OCTET STRING -- 8 octets.
> > 
> > 12.5.2  DES CBC
> > 
> > The DES algorithm in CBC mode is described in [DES]. The algorithm
> > identifier for DES in CBC mode is:
> > 
> >     DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
> >         oiw(14) secsig(3) algorithm(2) 7}
> > 
> > The AlgorithmIdentifier parameter field is required and has 
> > the structure:
> > 
> >     CBCParameter ::= IV
> >     IV ::= OCTET STRING -- 8 octets.
> > 
> > 12.5.3  RC2 CBC
> > 
> > The RC2 algorithm is described in RFC 2268. The algorithm 
> > identifier for
> > RC2 in CBC mode is:
> > 
> >     RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
> >         rsadsi(113549) encryptionAlgorithm(3) 2}
> > 
> > For the effective-key-bits (key size) greater than 32 and less than
> > 256, the RC2-CBC algorithm parameters are encoded as:
> > 
> >     RC2-CBC parameter ::=  SEQUENCE {
> >         rc2ParameterVersion  INTEGER,
> >         iv                   OCTET STRING (8)}
> > 
> > For the effective-key-bits of 40, 64, and 128, the 
> rc2ParameterVersion
> > values are 160, 120, 58 respectively. It is very important to 
> > note that
> > these values are not simply the RC2 keylength. Also note that 
> > the value 160
> > must be encoded as two octets (00 A0), because encoding as 
> > one octet (A0)
> > is a negative number in ASN.1.
> > 
> > 12.6  Message Authentication Code Algorithms
> > 
> > No MAC algorithms are mandatory.  CMS implementations may 
> include DES
> > MAC and HMAC.
> > 
> > MAC algorithms appear in the AuthenticatedData mac field.
> > 
> > 12.6.1  DES MAC
> > 
> > The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
> > algorithm identifier for DES MAC is:
> > 
> >     DES-MAC OBJECT IDENTIFIER ::= { iso(1) 
> identified-organization(3)
> >         oiw(14) secsig(3) algorithm(2) 10 }
> > 
> > The AlgorithmIdentifier parameter field is required. It is an 
> > INTEGER, and
> > carries the length in bits of the MAC, constrained to 
> > multiples of eight
> > from 16 to 64.
> > 
> > 12.6.2  HMAC-SHA1
> > 
> > The HMAC-SHA1 algorithm is described in RFC 2104. The 
> > algorithm identifier for
> > HMAC-SHA1 is:
> > 
> >     HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) 
> identified-organization(3)
> >         dod(6) internet(1) security(5) mechanisms(5) 8 1 2}
> > 
> > The AlgorithmIdentifier parameter field must not be present.
> > 
> > 
> > {{{References added}}}
> > 
> > 3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To 
> > DES". IEEE
> > Spectrum, v. 16, n. 7, pp40-41. July 1979.
> > 
> > DES  American National Standards Institute. ANSI X3.106, 
> > "American National
> > Standard for Information Systems- Data Link Encryption". 1983.
> > 
> > FIPS 113  National Institute of Standards and Technology. 
> > FIPS Pub 113:
> > Computer Data Authentication. May 1985.
> > 
> > FIPS 180-1  National Institute of Standards and Technology. 
> > FIPS Pub 180-1: 
> > Secure Hash Standard.  April 1995.
> > 
> > FIPS 186  National Institute of Standards and Technology. 
> > FIPS Pub 186:
> > Digital Signature Standard.  May 1994.
> > 
> > RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.
> > 
> > RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message 
> > Authentication.
> > February 1997.
> > 
> > RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption 
> > Algorithm.
> > March 1998.
> > 
> > X9.42  ANSI X9.42-199x.  Public Key Cryptography for The 
> > Financial Services
> > Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
> > (Working Draft).  December 1997.
> > 
> > 
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
> > 
> 

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "EKR" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Section 12, take 2
Date: Thu, 16 Jul 1998 19:49:19 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Thursday, July 16, 1998 7:11 PM
> To: Blake Ramsdell; 'Paul Hoffman / IMC'; EKR
> Cc: [email-masked]
> Subject: RE: Section 12, take 2
> 
> I complete agree that no assumptions should be made for the Content
> Encryption routines.  This is needed for backwards compataiblity with
> existing code.

I agree with this also.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Blake Ramsdell'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, EKR <[email-masked]>
Cc: [email-masked]
Subject: RE: Section 12, take 2
Date: Thu, 16 Jul 1998 19:10:57 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Blake Ramsdell [mailto:[email-masked]]
> Sent: Thursday, July 16, 1998 6:00 PM
> To: Jim Schaad (Exchange); 'Paul Hoffman / IMC'; EKR
> Cc: [email-masked]
> Subject: RE: Section 12, take 2
> 
> 
> > -----Original Message-----
> > From: Jim Schaad (Exchange) [mailto:[email-masked]]
> > Sent: Thursday, July 16, 1998 4:47 PM
> > To: 'Paul Hoffman / IMC'; EKR
> > Cc: [email-masked]
> > Subject: RE: Section 12, take 2
> > 
> > [jls] There are two schools of thought at this point.  There was a
> > discussion at the time of V2 interop where Blake and Co were 
> > generating
> > 196-bit for RC2 keys (doing a compression step on the key 
> > material up front)
> > and we (Microsoft and Netscape) were generating n-bits of key 
> > material for
> > RC2-n.  I don't know if there ever was a decision as to the 
> reality of
> > having additional key material or not.  In this case my vote 
> > would be to use
> > the first n-bits of the D-H key agreement key to encrypt the 
> > material for
> > all algorithms as it is easier to describe and expand later 
> > if needed that
> > to say generate y-bits of key material, use as many bits as your key
> > encryption algorithm will let you.
> 
> As far as what to do for the DH RC2 usage, I don't have an opinion.
> 
> As far as the RC2 usage for a content encryption algorithm (section
> 12.5.3), I believe that it should not be assumed that the input key
> length is the same as the effective key length, and that 
> appropriate key
> expansion will need to be performed (RFC2268 section 2).  There may or
> may not be any sound cryptographic reason for using / not using
> different length keying material than effective key length, 
> and I don't
> claim to have any intelligence in this area.  It's one of those things
> that sounds like a good idea, but I don't know if there is a sound
> cryptographic reason for doing it.  We might put in a disclaimer that
> the RC2Version parameter governs the effective keylength, not 
> the length
> of the keying material itself.

I complete agree that no assumptions should be made for the Content
Encryption routines.  This is needed for backwards compataiblity with
existing code.

> 
> Blake
> --
> Blake C. Ramsdell
> Worldtalk Corporation
> For current info, check http://www.deming.com/users/blaker
> Voice +1 425 882 8861 x103  Fax +1 425 882 8060
> 

From: "Blake Ramsdell" <[email-masked]>
To: "'Jim Schaad (Exchange)'" <[email-masked]>, "'Paul Hoffman / IMC'" <[email-masked]>, "EKR" <[email-masked]>
cc: <[email-masked]>
Subject: RE: Section 12, take 2
Date: Thu, 16 Jul 1998 18:00:27 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[email-masked]]
> Sent: Thursday, July 16, 1998 4:47 PM
> To: 'Paul Hoffman / IMC'; EKR
> Cc: [email-masked]
> Subject: RE: Section 12, take 2
> 
> [jls] There are two schools of thought at this point.  There was a
> discussion at the time of V2 interop where Blake and Co were 
> generating
> 196-bit for RC2 keys (doing a compression step on the key 
> material up front)
> and we (Microsoft and Netscape) were generating n-bits of key 
> material for
> RC2-n.  I don't know if there ever was a decision as to the reality of
> having additional key material or not.  In this case my vote 
> would be to use
> the first n-bits of the D-H key agreement key to encrypt the 
> material for
> all algorithms as it is easier to describe and expand later 
> if needed that
> to say generate y-bits of key material, use as many bits as your key
> encryption algorithm will let you.

As far as what to do for the DH RC2 usage, I don't have an opinion.

As far as the RC2 usage for a content encryption algorithm (section
12.5.3), I believe that it should not be assumed that the input key
length is the same as the effective key length, and that appropriate key
expansion will need to be performed (RFC2268 section 2).  There may or
may not be any sound cryptographic reason for using / not using
different length keying material than effective key length, and I don't
claim to have any intelligence in this area.  It's one of those things
that sounds like a good idea, but I don't know if there is a sound
cryptographic reason for doing it.  We might put in a disclaimer that
the RC2Version parameter governs the effective keylength, not the length
of the keying material itself.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, EKR <[email-masked]>
Cc: [email-masked]
Subject: RE: Section 12, take 2
Date: Thu, 16 Jul 1998 16:46:53 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Thursday, July 16, 1998 11:17 AM
> To: EKR
> Cc: [email-masked]
> Subject: Re: Section 12, take 2
> 
> 
> >Paul, the parameters sections are still wrong. As I noted
> >in my previous message, all the digests and rsaEncryption
> >take a NULL parameter. The parameter is NOT optional.
> 
> For some value of optional. We're still a bit schizophrenic 
> in CMS about
> must and should language, since CMS is not really a protocol. 
> Russ chose
> not to refer to RFC 2119 because of this, I think. So when we 
> say "optional
> but implementations should emit a NULL parameter", that's 
> about as strong
> as "MUST emit a NULL parameter but should accept with no parameters".
> 
> Unless I hear differently, I'll go with Eric's stronger wording.

[jls] this is fine with me -- in fact as stated in my previous posting my
elfs don't like the fact that we are making the paraemter absent for SHA1 as
they are only setup for doing it as NULL as in the cases of MD5.

> 
> >> CMS implementations must include Static Diffie-Hellman 
> with tripleDES.  CMS
> >> implementations may include RSA. CMS implementations may include
> >> Static Diffie-Hellman with RC2.
> >What about DH with DES?
> 
> No one had asked about this. If folks want one specified, 
> please give an
> OID and any other information needed. Out of curiousity, what 
> applications
> do we expect to use DH-DES that aren't using one of the other three?
> 
> >> id-smime-cms-dh-with-tripleDES ::= { TBD }
> >We're defining our own OID here, but I don't like this 'NULL or
> >omit' stuff. We should settle on one and stick to it.
> 
> Must NULL it is.

[jls] Agreed.

> 
> >> For the effective-key-bits of 40, 64, and 128, the 
> rc2ParameterVersion
> >> values are 160, 120, 58 respectively. It is very important 
> to note that
> >> these values are not simply the RC2 keylength. Also note 
> that the value 160
> >> must be encoded as two octets (00 A0), because encoding as 
> one octet (A0)
> >> is a negative number in ASN.1.
> >What's the input key length?
> 
> That's one for the implementors. Blake, et. al.?

[jls] There are two schools of thought at this point.  There was a
discussion at the time of V2 interop where Blake and Co were generating
196-bit for RC2 keys (doing a compression step on the key material up front)
and we (Microsoft and Netscape) were generating n-bits of key material for
RC2-n.  I don't know if there ever was a decision as to the reality of
having additional key material or not.  In this case my vote would be to use
the first n-bits of the D-H key agreement key to encrypt the material for
all algorithms as it is easier to describe and expand later if needed that
to say generate y-bits of key material, use as many bits as your key
encryption algorithm will let you.

> 
> >>ContentEncryptionAlgorithmIdentifier protocol field.  
> Triple-DES may be an
> >>exception here; the same identifier is used for both 2-key 
> and 3-key Triple
> >>DES.
> >No it isn't. DES-EDE3 means 3 key 3DES.
> 
> Hmmm. Russ wrote that wording on the list many weeks ago, and 
> no one objected.
> 

THis is fine with me as worded.  All it means is that the 3-key triple DES
has two duplicate keys, this is often done today as saying 3-key triple DES
and providing only 128-bits of key material and then the extra bits are
duplicated as needed by the receiver.  (I know that this code for receiption
is in our code base and was needed for some reason.) I would leave the
wording as is.

> >>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) 
> member-body(2) us(840) 
> >>         rsadsi(113549) encryptionAlgorithm(3) 7}
> >> 
> >> The AlgorithmIdentifier parameter field is required and 
> has the structure:
> >> 
> >>     CBCParameter :: IV
> >>     IV ::= OCTET STRING -- 8 octets.
> >Surely there is a SECSIC OID?
> 
> Surely, but this is the one that we've been using in S/MIME. 
> Changing it
> now would break backwards compatibility. I don't think we need to take
> purity of OIDs that far.

Please say with the same one we used in S/MIME V2.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Thu, 16 Jul 1998 11:16:40 -0700
To: EKR <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Section 12, take 2
Cc: [email-masked]
Sender: [email-masked]

>Paul, the parameters sections are still wrong. As I noted
>in my previous message, all the digests and rsaEncryption
>take a NULL parameter. The parameter is NOT optional.

For some value of optional. We're still a bit schizophrenic in CMS about
must and should language, since CMS is not really a protocol. Russ chose
not to refer to RFC 2119 because of this, I think. So when we say "optional
but implementations should emit a NULL parameter", that's about as strong
as "MUST emit a NULL parameter but should accept with no parameters".

Unless I hear differently, I'll go with Eric's stronger wording.

>> CMS implementations must include Static Diffie-Hellman with tripleDES.  CMS
>> implementations may include RSA. CMS implementations may include
>> Static Diffie-Hellman with RC2.
>What about DH with DES?

No one had asked about this. If folks want one specified, please give an
OID and any other information needed. Out of curiousity, what applications
do we expect to use DH-DES that aren't using one of the other three?

>> id-smime-cms-dh-with-tripleDES ::= { TBD }
>We're defining our own OID here, but I don't like this 'NULL or
>omit' stuff. We should settle on one and stick to it.

Must NULL it is.

>> For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
>> values are 160, 120, 58 respectively. It is very important to note that
>> these values are not simply the RC2 keylength. Also note that the value 160
>> must be encoded as two octets (00 A0), because encoding as one octet (A0)
>> is a negative number in ASN.1.
>What's the input key length?

That's one for the implementors. Blake, et. al.?

>>ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
>>exception here; the same identifier is used for both 2-key and 3-key Triple
>>DES.
>No it isn't. DES-EDE3 means 3 key 3DES.

Hmmm. Russ wrote that wording on the list many weeks ago, and no one objected.

>>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
>>         rsadsi(113549) encryptionAlgorithm(3) 7}
>> 
>> The AlgorithmIdentifier parameter field is required and has the structure:
>> 
>>     CBCParameter :: IV
>>     IV ::= OCTET STRING -- 8 octets.
>Surely there is a SECSIC OID?

Surely, but this is the one that we've been using in S/MIME. Changing it
now would break backwards compatibility. I don't think we need to take
purity of OIDs that far.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 16 Jul 1998 11:09:06 -0700 (PDT)
From: Gene Tsudik <[email-masked]>
To: [email-masked]
Subject: ACM CCCS'98: Preliminary Program and Call for Participation
Sender: [email-masked]

			     
			     Preliminary Program

                          Fifth ACM Conference on
                    Computer and Communications Security

                          San Francisco, California
                             November 2-5, 1998
                           Sponsored by ACM SIGSAC

	For more information visit http://www.research.att.com/~reiter/ccs5

        Launched in 1993, ACM CCCS is the ACM's flagship security conference. 
        CCCS covers a wide range of topics in computer/information security
        and offers a technical as well as a tutorial program. Presentation
	topics are diverse, addressing state-of-the-art results of both 
	practical and theoretical nature (and everything in between).

================================= DAY 0 =================================== 
 
 Monday, November 2, 1998: Tutorials

                    Core Topics                  Emerging Topics

  9:00-12:30 Cryptography: Theory and   Programming Languages and Security
             Applications               Martin Abadi (DEC Systems Research
             Dan Boneh (Stanford        Center, USA) and George Necula
             University, USA)           (Carnegie Mellon University, USA)

 12:30-13:30 Lunch

 13:30-17:00 To Be Determined           Authentication Protocol Verification
                                        and Analysis Jon Millen 
					(SRI International, USA)

================================= DAY 1 =================================== 

 Tuesday, November 3, 1998: Technical sessions

 9:00-10:00 Keynote address
            Risks and challenges in computer-communication infrastructures
            Peter G. Neumann (SRI International, USA)

 10:00-10:30			Break

 10:30-12:00		Group key management

            Communication complexity of group key distribution
            Klaus Becker (R^3 Security Engineering, Switzerland) and Uta
            Wille (IBM Zurich Research Laboratory, Switzerland)

            Key management for encrypted broadcast
            Avishai Wool (Bell Labs, USA)

            Authenticated group key agreement and related protocols
            Giuseppe Ateniese (USC Information Sciences Institute, USA),
            Michael Steiner (IBM Zurich Research Laboratory, Switzerland),
            and Gene Tsudik (USC Information Sciences Institute, USA)

 12:00-13:30			Lunch

 13:30-15:30			Anonymity

            The design, implementation and operation of an email pseudonym server
            David Mazie`res and M. Frans Kaashoek (Massachusetts Institute
            of Technology, USA)

            Panel: Anonymity on the Internet
            Moderator: Paul Syverson (Naval Research Lab, USA)

 15:30-16:00			Break

 16:00-17:00		Mobile code security
            
	    History-based access-control for mobile code
            Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of
            California, Santa Barbara, USA)

            A specification of Java loading and bytecode verification
            Allen Goldberg (Kestrel Institute, USA)

================================= DAY 2 =================================== 

 Wednesday, November 4, 1998: Technical sessions

 9:00-10:30 		 	Cryptography

            A new public key cryptosystem based on higher residues
            David Naccache (Gemplus, France) and Jacques Stern (Ecole
            Normale Superieure, France)

            An efficient non-interactive statistical zero-knowledge proof
            system for quasi-safe prime products
            Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele
            Micciancio (Massachusetts Institute of Technology, USA), and
            Tal Rabin (IBM T.J. Watson Research Center, USA)

            Communication-efficient anonymous group identification
            Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni
            Di Crescenzo (University of California, San Diego, USA)

 10:30-11:00			Break

 11:00-12:00			Invited talk

            The development of public key cryptography
            Martin Hellman

 12:00-13:30			Lunch

 13:30-15:00			Systems

            A security architecture for computational grids
            Ian Foster (Argonne National Laboratory, USA), Carl Kesselman,
            Gene Tsudik (USC Information Sciences Institute, USA), and
            Steven Tuecke (Argonne National Laboratory, USA)

            Design of a high-performance ATM firewall
            Jun Xu and Mukesh Singhal (Ohio State University, USA)

            A practical secure physical random bit generator
            Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs,
            USA) and Ari Juels (RSA Labs, USA)

 15:00-15:30			Break

 15:30-16:30			Invited talk

            Trust in cyberspace? A research roadmap
            Fred Schneider (Cornell University, USA)

================================= DAY 3 =================================== 

 Thursday, November 5, 1998: Technical sessions

 9:00-10:30 		Protocol design and analysis

            A probabilistic poly-time framework for protocol analysis
            Pat Lincoln (SRI International, USA), John Mitchell, Mark
            Mitchell (Stanford University, USA), and Andre Scedrov
            (University of Pennsylvania, USA)

            On using public-key cryptography in password protocols
            Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo
            Krawczyk (Technion, Israel)

            Cryptanalysis of Microsoft's point-to-point tunneling protocol
            Bruce Schneier (Counterpane Systems, USA)

 10:30-11:00			Break

 11:00-12:00			System monitoring

            How to prove where you are
            Eran Gabber and Avishai Wool (Bell Labs, USA)

            Temporal sequence learning and data reduction for anomaly detection
            Terran Lane and Carla E. Brodley (Purdue University, USA)

================== Worst paper award and author lampooning =================== 

 Steering committee chair: Ravi Sandhu, George Mason University
 General chair:            Li Gong, JavaSoft

 Program chair:            Mike Reiter
                           AT&T Labs, Room A269, 180 Park Avenue
                           Florham Park, NJ 07932-0971 USA
                           phone: +973-360-8349

 Awards chair:             Jacques Stern, ENS/DMI
 Publication chair:        Stuart Stubblebine, AT&T Labs
 Publicity chair:          Gene Tsudik, USC ISI

 Program committee:

 Martin Abadi, DEC SRC              David Naccache, Gemplus
 Bill Cheswick, Lucent/Bell Labs    Hilarie Orman, DARPA/ITO
 Carl Ellison, Cybercash            Avi Rubin, AT&T Labs--Research
 Ed Felten, Princeton University    Pierangela Samarati, Universita di Milano
 Paul Karger, IBM T.J. Watson       Gene Tsudik, USC ISI
 Steve Kent, BBN Corporation        Paul Van Oorschot, Entrust Technologies
 Ueli Maurer, ETH Zurich            Bennet Yee, UCSD
 Cathy Meadows, Naval Res. Lab      Moti Yung, CertCo

For more information, visit http://www.research.att.com/~reiter/ccs5

Date: Thu, 16 Jul 1998 11:08:41 -0700 (PDT)
From: Gene Tsudik <[email-masked]>
To: [email-masked]
Subject: ACM CCCS'98: Preliminary Program and Call for Participation
Sender: [email-masked]

			     
			     Preliminary Program

                          Fifth ACM Conference on
                    Computer and Communications Security

                          San Francisco, California
                             November 2-5, 1998
                           Sponsored by ACM SIGSAC

	For more information visit http://www.research.att.com/~reiter/ccs5

        Launched in 1993, ACM CCCS is the ACM's flagship security conference. 
        CCCS covers a wide range of topics in computer/information security
        and offers a technical as well as a tutorial program. Presentation
	topics are diverse, addressing state-of-the-art results of both 
	practical and theoretical nature (and everything in between).

================================= DAY 0 =================================== 
 
 Monday, November 2, 1998: Tutorials

                    Core Topics                  Emerging Topics

  9:00-12:30 Cryptography: Theory and   Programming Languages and Security
             Applications               Martin Abadi (DEC Systems Research
             Dan Boneh (Stanford        Center, USA) and George Necula
             University, USA)           (Carnegie Mellon University, USA)

 12:30-13:30 Lunch

 13:30-17:00 To Be Determined           Authentication Protocol Verification
                                        and Analysis Jon Millen 
					(SRI International, USA)

================================= DAY 1 =================================== 

 Tuesday, November 3, 1998: Technical sessions

 9:00-10:00 Keynote address
            Risks and challenges in computer-communication infrastructures
            Peter G. Neumann (SRI International, USA)

 10:00-10:30			Break

 10:30-12:00		Group key management

            Communication complexity of group key distribution
            Klaus Becker (R^3 Security Engineering, Switzerland) and Uta
            Wille (IBM Zurich Research Laboratory, Switzerland)

            Key management for encrypted broadcast
            Avishai Wool (Bell Labs, USA)

            Authenticated group key agreement and related protocols
            Giuseppe Ateniese (USC Information Sciences Institute, USA),
            Michael Steiner (IBM Zurich Research Laboratory, Switzerland),
            and Gene Tsudik (USC Information Sciences Institute, USA)

 12:00-13:30			Lunch

 13:30-15:30			Anonymity

            The design, implementation and operation of an email pseudonym server
            David Mazie`res and M. Frans Kaashoek (Massachusetts Institute
            of Technology, USA)

            Panel: Anonymity on the Internet
            Moderator: Paul Syverson (Naval Research Lab, USA)

 15:30-16:00			Break

 16:00-17:00		Mobile code security
            
	    History-based access-control for mobile code
            Guy Edjlali, Anurag Acharya, and Vipin Chaudhary (University of
            California, Santa Barbara, USA)

            A specification of Java loading and bytecode verification
            Allen Goldberg (Kestrel Institute, USA)

================================= DAY 2 =================================== 

 Wednesday, November 4, 1998: Technical sessions

 9:00-10:30 		 	Cryptography

            A new public key cryptosystem based on higher residues
            David Naccache (Gemplus, France) and Jacques Stern (Ecole
            Normale Superieure, France)

            An efficient non-interactive statistical zero-knowledge proof
            system for quasi-safe prime products
            Rosario Gennaro (IBM T.J. Watson Research Center, USA), Daniele
            Micciancio (Massachusetts Institute of Technology, USA), and
            Tal Rabin (IBM T.J. Watson Research Center, USA)

            Communication-efficient anonymous group identification
            Alfredo De Santis (Universita' di Salerno, Italy) and Giovanni
            Di Crescenzo (University of California, San Diego, USA)

 10:30-11:00			Break

 11:00-12:00			Invited talk

            The development of public key cryptography
            Martin Hellman

 12:00-13:30			Lunch

 13:30-15:00			Systems

            A security architecture for computational grids
            Ian Foster (Argonne National Laboratory, USA), Carl Kesselman,
            Gene Tsudik (USC Information Sciences Institute, USA), and
            Steven Tuecke (Argonne National Laboratory, USA)

            Design of a high-performance ATM firewall
            Jun Xu and Mukesh Singhal (Ohio State University, USA)

            A practical secure physical random bit generator
            Markus Jakobsson, Elisabeth Shriver, Bruce Hillyer (Bell Labs,
            USA) and Ari Juels (RSA Labs, USA)

 15:00-15:30			Break

 15:30-16:30			Invited talk

            Trust in cyberspace? A research roadmap
            Fred Schneider (Cornell University, USA)

================================= DAY 3 =================================== 

 Thursday, November 5, 1998: Technical sessions

 9:00-10:30 		Protocol design and analysis

            A probabilistic poly-time framework for protocol analysis
            Pat Lincoln (SRI International, USA), John Mitchell, Mark
            Mitchell (Stanford University, USA), and Andre Scedrov
            (University of Pennsylvania, USA)

            On using public-key cryptography in password protocols
            Shai Halevi (IBM T.J. Watson Research Center, USA) and Hugo
            Krawczyk (Technion, Israel)

            Cryptanalysis of Microsoft's point-to-point tunneling protocol
            Bruce Schneier (Counterpane Systems, USA)

 10:30-11:00			Break

 11:00-12:00			System monitoring

            How to prove where you are
            Eran Gabber and Avishai Wool (Bell Labs, USA)

            Temporal sequence learning and data reduction for anomaly detection
            Terran Lane and Carla E. Brodley (Purdue University, USA)

================== Worst paper award and author lampooning =================== 

 Steering committee chair: Ravi Sandhu, George Mason University
 General chair:            Li Gong, JavaSoft

 Program chair:            Mike Reiter
                           AT&T Labs, Room A269, 180 Park Avenue
                           Florham Park, NJ 07932-0971 USA
                           phone: +973-360-8349

 Awards chair:             Jacques Stern, ENS/DMI
 Publication chair:        Stuart Stubblebine, AT&T Labs
 Publicity chair:          Gene Tsudik, USC ISI

 Program committee:

 Martin Abadi, DEC SRC              David Naccache, Gemplus
 Bill Cheswick, Lucent/Bell Labs    Hilarie Orman, DARPA/ITO
 Carl Ellison, Cybercash            Avi Rubin, AT&T Labs--Research
 Ed Felten, Princeton University    Pierangela Samarati, Universita di Milano
 Paul Karger, IBM T.J. Watson       Gene Tsudik, USC ISI
 Steve Kent, BBN Corporation        Paul Van Oorschot, Entrust Technologies
 Ueli Maurer, ETH Zurich            Bennet Yee, UCSD
 Cathy Meadows, Naval Res. Lab      Moti Yung, CertCo

For more information, visit http://www.research.att.com/~reiter/ccs5

Date: Thu, 16 Jul 1998 16:19:59 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: draft-ietf-smime-domsec-00.txt
Sender: [email-masked]

Hi all,

We have just submitted a new Internet Draft entitled 'domain security 
services'. This follows our presentation at the S/MIME WG meeting in 
Washington, (December 1997), where we described our requirement for secure 
interworking between different security domains, using the S/MIME protocol.
All comments are welcome.

Bill.

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       : Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-00.txt
	Pages		: 8
	Date		: 15-Jul-98
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a messaging system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that do not have
encryption or signing capabilities at the desktop, but wish to
interoperate securely using the S/MIME protocol.

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-domsec-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-domsec-00.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-domsec-00.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.

<ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-domsec-00.txt>

_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

To: Paul Hoffman / IMC <[email-masked]>
Cc: [email-masked]
Subject: Re: Section 12, take 2
From: EKR <[email-masked]>
Date: 16 Jul 1998 07:51:10 -0700
Lines: 95
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:

> Here's the second pass on CMS section 12. I think I included all
> of the comments other than Jim's about padding, which I didn't
> see where it would go.
Paul, the parameters sections are still wrong. As I noted
in my previous message, all the digests and rsaEncryption
take a NULL parameter. The parameter is NOT optional. For 
instance, RFC2313 says:

     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 2 } md4 OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 4 } md5 OBJECT IDENTIFIER ::=
     { iso(1) member-body(2) US(840) rsadsi(113549)
         digestAlgorithm(2) 5 }

             For these object identifiers, the parameters field of the
             digestAlgorithm value should be NULL.

Implementations which omit the parameters field are broken.

> 12.3  Key Encryption Algorithms
> 
> CMS implementations must include Static Diffie-Hellman with tripleDES.  CMS
> implementations may include RSA. CMS implementations may include
> Static Diffie-Hellman with RC2.
What about DH with DES?

> 12.3.1  Static Diffie-Hellman with tripleDES
> 
> Static Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman
> Key Agreement Method, currently draft-ietf-smime-x942). The algorithm
> identifier for static Diffie-Hellman with tripleDES is
> 
>     id-smime-cms-dh-with-tripleDES ::= { TBD }
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate Static Diffie-Hellman AlgorithmIdentifiers with the parameter
> field containing a NULL value. Implementations should accept Static
> Diffie-HellmanAlgorithmIdentifiers with NULL parameters as well as absent
> parameters.
We're defining our own OID here, but I don't like this 'NULL or
omit' stuff. We should settle on one and stick to it.

> 12.3.3  Static Diffie-Hellman with RC2
> 
> Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman Key
> Agreement Method, currently draft-ietf-smime-x942). The algorithm
> identifier for static Diffie-Hellman with RC2 is
> 
>     id-smime-cms-dh-with-rC2 ::= { TBD }
> 
> For the effective-key-bits (key size) greater than 32 and less than
> 256, the algorithm parameters are encoded as:
> 
>     id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
>         rc2ParameterVersion  INTEGER,
>         iv                   OCTET STRING (8)}
> 
> For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
> values are 160, 120, 58 respectively. It is very important to note that
> these values are not simply the RC2 keylength. Also note that the value 160
> must be encoded as two octets (00 A0), because encoding as one octet (A0)
> is a negative number in ASN.1.
What's the input key length?

> 12.4  Triple-DES Key Wrap
> 
> {{{Jim Schaad wanted this to be more general, and will come up with the
> wording to make it so.}}}
Note that DES in DES isn't specified but when it is, it should be
ECB.

>ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
>exception here; the same identifier is used for both 2-key and 3-key Triple
>DES.
No it isn't. DES-EDE3 means 3 key 3DES.

> 12.5.1  Triple-DES CBC
> 
> The Triple-DES algorithm is described in [3DES]. The algorithm identifier
> for Triple-DES is:
> 
>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
>         rsadsi(113549) encryptionAlgorithm(3) 7}
> 
> The AlgorithmIdentifier parameter field is required and has the structure:
> 
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
Surely there is a SECSIC OID?

-Ekr

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-domsec-00.txt
Date: Thu, 16 Jul 1998 06:57:39 -0400
Sender: [email-masked]

--NextPart

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           : Domain Security Services using S/MIME
	Author(s)	: T. Dean, W. Ottaway
	Filename	: draft-ietf-smime-domsec-00.txt
	Pages		: 8
	Date		: 15-Jul-98
	
This document describes how the S/MIME protocol can be processed and
generated by a number of components of a messaging system, such as
message transfer agents, guards and gateways to deliver security
services. These services are collectively referred to as 'Domain
Security Services'. The mechanisms described in this document are
designed to solve a number of interoperability problems and technical
limitations that arise when different security domains wish to
communicate securely - for example when two domains use incompatible
messaging technologies such as X.400 and SMTP/MIME. This document is
also applicable to organisations and enterprises that do not have
encryption or signing capabilities at the desktop, but wish to
interoperate securely using the S/MIME protocol.

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-domsec-00.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-domsec-00.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-domsec-00.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-domsec-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-domsec-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 15 Jul 1998 21:01:26 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Section 12, take 2
Sender: [email-masked]

Here's the second pass on CMS section 12. I think I included all
of the comments other than Jim's about padding, which I didn't
see where it would go.

DO NOT CODE TO THIS MESSAGE. Y'all saw how many errors
there were in the first draft; I expect that there are still some here.
Please review it carefully and post comments to the list. Won't
Russ be pleased when he comes back from vacation? :-)

12  Supported Algorithms

This section lists the algorithms that must be implemented.
Additional algorithms that may be implemented are also included.

12.1  Digest Algorithms

CMS implementations must include SHA-1. CMS implementations may include MD5.

Digest algorithm identifiers are used in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, and the DigestedData
digestAlgorithm field.

Digest values are located in the DigestedData digest field. In addition,
digest values are located in the Message Digest authenticated attribute.

12.1.1  SHA-1

The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 180-1]. The
algorithm identifier for SHA-1 is:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate SHA-1 AlgorithmIdentifiers with the parameter field containing a
NULL value. Implementations should accept SHA-1 AlgorithmIdentifiers with
NULL parameters as well as absent parameters.  Note that current CMS
implementations encode SHA-1 both with and without the NULL attributes.

12.1.2  MD5

The MD5 digest algorithm is defined in RFC 1321. The algorithm
identifier for MD5 is:

    md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) digestAlgorithm(2) 5}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate MD5 AlgorithmIdentifiers with the parameter field containing a
NULL value. Implementations should accept MD5 AlgorithmIdentifiers with
NULL parameters as well as absent parameters. Note that current CMS
implementations encode MD5 both with and without the NULL attributes.

12.2  Signature Algorithms

CMS implementations must include DSA.  CMS implementations may include RSA.

Signature algorithm identifiers are used in the SignerInfo
signatureAlgorithm field.

12.2.1  DSA

The DSA signature algorithm is defined in FIPS Pub 186 [FIPS 186]. The
algorithm identifier for DSA is:

    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  { iso(1) member-body(2)
        us(840) x9-57 (10040) x9cm(4) 3 }

The AlgorithmIdentifier parameter field must not be present.

12.2.2  RSA

The RSA signature algorithm is defined in RFC 2313 as modified below. The
algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate RSA AlgorithmIdentifiers with the parameter field containing a
NULL value. Implementations should accept RSA AlgorithmIdentifiers with
NULL parameters as well as absent parameters.  Note that current CMS
implementations encode RSA both with and without the NULL attributes.

This specification modifies RFC 2313 to include SHA-1 as an additional
digest algorithm. Section 10.1.2 of RFC 2313 is modified to list SHA-1
in the bullet item about digestAlgorithm. The following OID is added to
the list in section 10.1.2 of RFC 2313:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

12.3  Key Encryption Algorithms

CMS implementations must include Static Diffie-Hellman with tripleDES.  CMS
implementations may include RSA. CMS implementations may include
Static Diffie-Hellman with RC2.

Key encryption algorithms are used in the KeyTransRecipientInfo
keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
keyEncryptionAlgorithm field, and in the MailListRecipientInfo
keyEncryptionAlgorithm field. These are all part of the RecipientInfo
type, which is part of the EnvelopedData type.

12.3.1  Static Diffie-Hellman with tripleDES

Static Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman
Key Agreement Method, currently draft-ietf-smime-x942). The algorithm
identifier for static Diffie-Hellman with tripleDES is

    id-smime-cms-dh-with-tripleDES ::= { TBD }

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate Static Diffie-Hellman AlgorithmIdentifiers with the parameter
field containing a NULL value. Implementations should accept Static
Diffie-HellmanAlgorithmIdentifiers with NULL parameters as well as absent
parameters.

12.3.2  RSA

The RSA encryption algorithm is defined in RFC 2313 as modified below. The
algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate RSA AlgorithmIdentifiers with the parameter field absent.
Implementations should accept RSA AlgorithmIdentifiers with NULL parameters
as well as absent parameters.  Note that current CMS implementations encode
RSA both with and without the NULL attributes.

This specification modifies RFC 2313 to include SHA-1 as an additional
digest algorithm. Section 10.1.2 of RFC 2313 is modified to list SHA-1
in the bullet item about digestAlgorithm. The following OID is added to
the list in section 10.1.2 of RFC 2313:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

12.3.3  Static Diffie-Hellman with RC2

Diffie-Hellman key encryption is defined in RFC TBD (Diffie-Hellman Key
Agreement Method, currently draft-ietf-smime-x942). The algorithm
identifier for static Diffie-Hellman with RC2 is

    id-smime-cms-dh-with-rC2 ::= { TBD }

For the effective-key-bits (key size) greater than 32 and less than
256, the algorithm parameters are encoded as:

    id-smime-cms-dh-with-rC2 parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1.

12.4  Triple-DES Key Wrap

{{{Jim Schaad wanted this to be more general, and will come up with the
wording to make it so.}}}

The block size of the key-encryption algorithm can be determined from the CMS
KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
exception here; the same identifier is used for both 2-key and 3-key Triple
DES.  This is probably easily handled by always wrapping three keys, even if
the first and third keys match.

The key checksum algorithm is:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant octet to least significant octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         8 zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

The key wrap algorithm is:

1.  Adjust the parity bits on the Triple-DES keys.
2.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
3.  Generate a 4-octet random salt value.
4.  Concatenate the salt, content-encryption key, and key 
    checksum value.
5.  Generate the number of pad octets necessary to make the
    result a multiple of 8 bytes (the Triple-DES algorithm block
    size), then append them to the result.

{{{Is this a constant or random pad???}}}

6.  Encrypt the result with the tripleDES key.  Use an IV
    with each octet equal to 'A5' hexadecimal.

The key unwrap algorithm is:

1.  Decrypt the wrapped ciphertext using the key-encryption key.
    Use an IV with each octet equal to 'A5' hexadecimal.
2.  Check the parity of the content encryption keys.  If any is 
    incorrect then there is an error.
3.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
4.  If computed key checksum value does not match the decrypted
    key checksum value, then there is an error.

12.5  Content Encryption Algorithms

CMS implementations must include Triple-DES in CBC mode.  CMS
implementations may include DES in CBC mode and RC2 in CBC mode.

Content encryption algorithms appear in the EncryptedContentInfo
contentEncryptionAlgorithm field, which is part of the EnvelopedData type
and the EncryptedData type.

12.5.1  Triple-DES CBC

The Triple-DES algorithm is described in [3DES]. The algorithm identifier
for Triple-DES is:

    DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
        rsadsi(113549) encryptionAlgorithm(3) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter :: IV
    IV ::= OCTET STRING -- 8 octets.

12.5.2  DES CBC

The DES algorithm in CBC mode is described in [DES]. The algorithm
identifier for DES in CBC mode is:

    DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter ::= IV
    IV ::= OCTET STRING -- 8 octets.

12.5.3  RC2 CBC

The RC2 algorithm is described in RFC 2268. The algorithm identifier for
RC2 in CBC mode is:

    RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) encryptionAlgorithm(3) 2}

For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:

    RC2-CBC parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1.

12.6  Message Authentication Code Algorithms

No MAC algorithms are mandatory.  CMS implementations may include DES
MAC and HMAC.

MAC algorithms appear in the AuthenticatedData mac field.

12.6.1  DES MAC

The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
algorithm identifier for DES MAC is:

    DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 10 }

The AlgorithmIdentifier parameter field is required. It is an INTEGER, and
carries the length in bits of the MAC, constrained to multiples of eight
from 16 to 64.

12.6.2  HMAC-SHA1

The HMAC-SHA1 algorithm is described in RFC 2104. The algorithm identifier for
HMAC-SHA1 is:

    HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) 8 1 2}

The AlgorithmIdentifier parameter field must not be present.

{{{References added}}}

3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To DES". IEEE
Spectrum, v. 16, n. 7, pp40-41. July 1979.

DES  American National Standards Institute. ANSI X3.106, "American National
Standard for Information Systems- Data Link Encryption". 1983.

FIPS 113  National Institute of Standards and Technology. FIPS Pub 113:
Computer Data Authentication. May 1985.

FIPS 180-1  National Institute of Standards and Technology. FIPS Pub 180-1: 
Secure Hash Standard.  April 1995.

FIPS 186  National Institute of Standards and Technology. FIPS Pub 186:
Digital Signature Standard.  May 1994.

RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.

RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message Authentication.
February 1997.

RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
March 1998.

X9.42  ANSI X9.42-199x.  Public Key Cryptography for The Financial Services
Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
(Working Draft).  December 1997.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Wed, 15 Jul 1998 17:24:24 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Jim,

I was in the US last week, then we had the Bastille day. Thus the reason
for the delay to respond.

> Denis --

> Here are the quick thoughts from your message(s)
> 
> 1.  The latest draft of the sigattr draft now has the ability to
> specifiy a set of attribute certificates to be used in the verification
> process as well as the user's signing certificate.  I sent this draft in
> today so it should showup on the list this week.

I have no been able to take a look at it yet.
 
> 2.  I'd like to get some clarifiation from you on what you consider the
> differences between a security label and a control policy module.  From
> my reading I think you consider these to be very seperate beasts but I
> would like to verify that this is a true statement.  

Yes. They are very different.

> Do you consider the following statements to be true?
 
> A.  A security label is used to define the set of readers who are
> permitted to view the contents of a signed object.

I have no problem with this.

> B.  A control policy module is a set of rules used in accepting 

more exactly "to be used by the verifier"

> a) the chain of certificates used during a signature operation 

more exactly "during a signature verification operation"

> (such as trusted roots, interpretation of non-critical extensions 
> in certificates) and 

> b) the set of authenticated attributes in a SignerInfo object 
> (such as a time, the proposed Signing Certificate attribute, 
> any proposed signature purpose attributes).

Correct.
 
> As such in my current e-mail code I am looking at allowing for
> flexability in the first (security policy) but am hard coding the
> second.

:-)

Denis

> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Monday, July 06, 1998 5:35 PM
> > To: Jim Schaad (Exchange)
> > Cc: [email-masked]
> > Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> >
> >
> > Jim,
> >
> > I took me some time to dig your E-mail too. In order to ease
> > the reading
> > I have reformatted the exchanges, placing a J (for Jim) and a D (for
> > Denis) in front of the previous exchanges.
> >
> > Reading again the E-mail I now understand what the
> > misunderstanding is.
> > It is however rather fundamental as I will attempt to explain it
> > hereafter.
> >
> > J> Denis,
> >
> > J> I somehow got lost on this message, my apologies that
> > J> I did not reply sooner.
> >
> > J> Comments mixed in below
> >
> > J> -----Original Message-----
> > J> From: Denis Pinkas [mailto:[email-masked]]
> > J> Sent: Monday, May 18, 1998 2:25 PM
> > J> To: Jim Schaad (Exchange)
> > J> Cc: [email-masked]
> > J> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> >
> >
> > D> Jim,
> >
> > D> Thank you for your detailed response. Unfortunately there are
> > D> several points I do not agree with.  :-(
> >
> > D> I am addressing the non-certificate identification issues
> > D> in this message.
> > D> These issues will be addressed separately to keep the
> > D> threads separate
> >
> > D>-----Original Message-----
> >
> > D>From: Denis Pinkas [mailto:[email-masked]]
> >
> > D>A. In section 2. Re-issue of Certificate.
> >
> > D> Either I do not see this as a problem or I do not understand
> > D> your problem.
> > D> Cross certificates can be revoked. So if the CA wishes to
> > D> re-issue a certificate it simply revokes it before and
> > D> may use different policies in the new issued certificate.
> > D> Where is the problem ?
> >
> >
> > J> I did not make myself clear here.  The attack that I was
> > J> looking at on this point had to do with a CA re-issuing
> > J> its own root certificate.
> >
> > D> There is an important issue here. This question was raised
> > D> in a recent E-mail from Francois Rousseau. Unless the security
> > D> policy to be applied for verification is itself signed,
> > D> you are open to many attacks, as the one you mention.
> >
> > I was referring to an E-mail from Francois Rousseau
> > ([email-masked])
> > from Thu, 30 Apr 1998 with the following subject : Reference to
> > Applicable Attribute Certificate(s) within the CMS.
> >
> > The sentences I was referring were at the end of his E-mail:
> >
> > " (...) This implies there are currently no mean within CMS
> > to convey to the Verifier which Attribute Certificate MUST be
> > used for each Claimant.
> >
> > Should not considerations be given within CMS to use the
> > authenticatedAttributes field under each per-signer SignerInfo
> > to specify through new CRITICAL attributes, the applicable
> > claimant's Attribute Certificate and the applicable Control policy
> > that the Verifier MUST use to validate the message?"
> >
> > ... "and the applicable Control policy that the Verifier MUST use to
> > validate the message" is the important sentence.
> >
> > The "applicable Control policy" (that I called simply
> > "security policy")
> > defines the rules to be applied for the verification of the digital
> > signatures. That security policy will indicate what are the
> > various root
> > CAs that are usable and the name constraints that are to be used for
> > each of them.
> >
> > D> So a security policy identifier (e.g. an OID) should be
> > D> part of the signature. If you have a single trust point
> > D> (which is a very specific case) then you could replace the OID
> > D> by a self-signed certificate. Under that case there will be no
> > D> ambiguity about what to use for verification. Note the IDUP,
> > D> which is an API covering non-repudiation already incorportates
> > D> this major concept.
> >
> > > I just got very lost reading the previous paragraph.
> > > I think the issues I don't understand boil down to:
> >
> > > 1.  Which message are you refering to?  The ones that I can find
> > > deal with attribute certificates and not with CA certificates.
> > > I am afraid that I don't see the connection between these issues.
> >
> > See the reference above.
> >
> > > 2.  What security policy identifier are you refering to here?
> > > If the security policy is that of the message, it is already signed
> > > in its own attribute.  If the security policy is part of the
> > > certificate, it should also be signed under the certificate
> > signature.
> >
> > I am referring a security policy that is a signed attribute, but not
> > part of the message.
> >
> > > 3.  If you are refering to the ability to verify the verification
> > > code (or at least some input data to it) then I would have to say
> > > that I think this is beyond the scope of the problems that I can
> > > even hope to address in an IETF draft as it would be very
> > > implementation dependent.
> >
> > I had not envisaged that meaning. :-)
> >
> > J> The change I would expect would be in the CPS however I will
> > J> give and example of name constraints here.  If a CA re-issues
> > J> its CA certificate and specifically constrains my certificate
> > J> out of the set of legal DNs, I may sign my message with a valid
> > J> chain (I have the original root certificate) and you may fail
> > J> the validation because you have the new root certificate.
> >
> > D> The threat you mention can be countered by the inclusion of
> > D> the security policy as an "authenticated attribute"; I would
> > D> prefer to call it a "signed attribute" :-)
> >
> > > How does the inclusion of a security policy (I assume in the
> > > SignerInfo object being verified) alter the fact that we have
> > > different root certificates and thus different input to the
> > > problem of doing the certificate validation?  Even operating
> > > under the same security policy (unless the policy itself has the
> > > roots hard coded into it) would not address this issue.
> > > I don't expect most security policies to restrict the set of roots
> > > to be used in certificate validation.
> >
> > If I use a real example, SET (Secure Electronic Transaction) does
> > restrict the set of roots to be used in certificate validation. Any
> > application should do the same. It is not the choice of the
> > verifier to
> > use the roots of its choice, but the choice of the signer. A "simple"
> > way to indicate its choice is to use a security policy OID. Now the
> > choice may or may not be acceptable to the verifier. If not, then the
> > signature is simply discarded.
> >
> > J> What I was trying to point out in the second paragraph is
> > J> that a similar problem already exists with cross-certificates.
> > J> When CA2 issues the cross certificate for CA1, it may add or
> > J> remove extensions from the CA1 certificate.  Thus it could put
> > J> in the same name constraints extension that I postulated above
> > J> on the CA root certificate re-issue.
> >
> > J> This means that my signature was valid when I sent it, as
> > J> I trusted the CA1 root directly, but you will fail the signature
> > J> validation as the name constrained imposed by CA2 on CA1 causes
> > J> my certificate to be invalid.
> >
> > We are tackling the heart of the problem here. What you would
> > like is, I
> > believe, the following: a signature that was valid when it was sent
> > should be recognized as valid at the time it is received.
> >
> > The bad news is the following : when using only the current
> > specification this is quite impossible. :-(
> >
> > The good news is the following : when using S/MIME in
> > combination with a
> > time stamp from a Time Stamping Authority, this is possible.
> >
> > The reason is fairly simple: if you want the same result, you
> > should use
> > the same input parameters to the verification process, i.e. the
> > parameters that were valid at the time of the signature. So you must
> > securely know the time of the signature, hence the reason for the time
> > stamp. If any certificate is changing, this is not a problem since you
> > will use what was valid at the time of the signature. Without a time
> > stamp you may (and will) get spurious results.
> >
> > I now see some value to consider different levels: at the level 3,
> > we could cover the case of a verification without a time stamp.
> > At a level 4, we could consider the case of a verification with
> > an additional time stamp.
> >
> > D> For the case of CAs which are "below" this is not a problem as
> > D> I mentionned it in my previous E-mail.
> >
> > D> The discussion and explanations about the need for the hash
> > D> mentioned in the discussion above should be added.
> >
> > J> I am waiting for a consensus to develop on this issue
> > J> before making this change.
> >
> > D> Well, since your paper is supposed to be a discussion
> > paper, I do not
> > D> see why we should not address the problem there. There is not yet a
> > D> consensus on the other issues.  :-)
> >
> >
> > D> C. In the Open Issues section. The inclusion for a complete
> > D> chain of certificates would have some advantages (I do not claim
> > D> it is necessary in all the cases). It allows the signer to specify
> > D> its own belief for the verification process. If the verifier wants
> > D> to use a different chain, this is fine for him, but then under his
> > D> own risk.
> >
> > D> The "rollover" argument is not a problem since anyway it is
> > D> important to capture all the certificates that were valid
> > D> at the time the signature was created, but this is a minor detail.
> >
> > In fact, I know believe that this is major argument !
> >
> > J> I agree that this might be a useful extension to have, but
> > J> I would argue that this is not the correct attribute to place
> > J> that information in. This attribute will change the validity of
> > J> the signature based on the match or non-match of the specified
> > J> certificate to the certificate used in the signature validation
> > J> process.
> >
> > But this is a way to get stable and non ambiguous results.
> >
> > D> It only changes the validity of the signature based on which
> > D> security policy you are using.
> >
> > D> Finally I could not understand the issue expressed in the
> > D> last paragraph of "B. Open Issues". A different wording
> > D> might be necessary.
> >
> > J> I will attempt to express the issue again in new wording
> > J> and hope that I do better this time.
> >
> > J> From a pure cryptographic (i.e. mathematical sense) a
> > J> signature is created by using a private key and verified by
> > J> using a public key. In this world there is no such thing as
> > J> a certificate and one does not worry about how the public key
> > J> is obtained.
> >
> > D> Correct.
> >
> > J> In the next level of abstraction up, a certificate comes
> > J> into being.
> >
> > D> More generally I would say a way to relate the public key to
> > D> the identity of the signer. For this a certificate may or may
> > D> not be used.
> >
> > J> All a certificate provides from a mathematical sense is a way
> > J> of providing a public key in a cryptographically secure manner.
> > J> In this sense it does not matter what certificate one uses to find
> > J> the public key to verify a signature as long as one finds some
> > J> certificate with the correct public key.
> >
> > D> I respectfully disagree with you on this issue. I would
> > take again my
> > D> favorite example with a CA from the Barracuda Banana Republic. This
> > CA
> > D> for 1.000 $ may be willing to issue me a certificate with the same
> > D> public key value like yours (without performing POP, ie. Proof op
> > D> Private key possession). If that CA appears to be in your
> > trust tree,
> > D> then you may be fooled. So it does matter that the signer indicates
> > D> which certificate shall be used for verification. It is not *any*.
> >
> > > You are correct in one sense and incorrect in another.  You
> > are quite
> > > correct that I will be fooled into believing that you did the
> > > signature since the public keys are the same.  From a pure
> > > mathematical standpoint there is no way for me to know which
> > > certificate is correct.  It is from the addition of a protocol that
> > > I understand some certificates are trusted and others are
> > not trusted.
> > > There is no mathematical basis to make this determination.
> >
> > When the reference of the certificate to be used is a signed
> > attribute
> > placed by the signer, there is no ambiguity.
> >
> > J> This means that if I have two certificates, both containing
> > J> the same public key, it does not matter which of these
> > certificates
> > J> you use in validating the signature as both are equally viable
> > J> from a mathematical sense.
> >
> > D> No. it does matter instead. As I do not agree on your
> > second level, I
> > D> also respectfully disagree with the next level.
> >
> > > How is the signature different on a mathematics level?
> >
> > The verification process is not purely mathematical. You MUST also
> > verify that the certificate that you use for the verification is
> > the one indicated in the signed attributes.
> >
> > > As you say I will verify using the phony signature.
> > > The step you want to place is added in the next level.
> >
> > J> The final level of abstraction that I add is the level of
> > J> protocol of signing.  At this level I care about which of the
> > J> different certificates I use in the validation process as
> > J> certificates carry different information about the signer and
> > J> the ways in which signing may occur.
> >
> > J> This information is carried as extension on the certificate and
> > J> these need to be validated as part of the process of validating
> > J> the original signature.
> >
> > Which extension(s) are you refering to ?
> >
> > J> Those people who don't go all the way to the final protocol
> > J> level we are providing don't like what this draft does, so far
> > J> I have found two sets of people who tend to stop at level 2 and
> > J> not go to level 3.
> >
> > J> The PGP community and those people who come out of that community
> > J> live at level two. I believe that this is because they don't have
> > J> the authoritative CA to do the binding and add additional protocol
> > J> information.
> >
> > Reading again your previous exchanges, I am confused about your
> > sentence "have the authoritative CA to do the binding and add
> > additional protocol information".
> >
> >
> > J> They tend to be individuals who make statements only
> > J> about identity and it does not matter what identity you use as
> > J> they mean the same person (as the private key must be the same).
> >
> > J> The second set is represented by Dave Solo who state that
> > J> everything which needs to be an important part of the signature
> > J> ought to be in the document being signed and the extra information
> > J> provided by the certificate extensions is of less importance that
> > J> what is in the document.
> >
> > Maybe I am close to Dave Solo, but in a third set. :-)
> >
> > I would state that everything which needs to be an important part
> > of the signature ought to be in the signed attributes in addition
> > to the document being signed. This includes the security policy
> > to be used by the verifier and an unambiguous reference to the
> > certificate of the signer to be used by the verifier. The extra
> > information provided by the certificate extensions cannot overide
> > the previous signed attributes.
> >
> > Denis
> >
> >
> > --
> >       Denis Pinkas     Bull S.A.          mailto:[email-masked]
> >       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
> >       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> >

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Wed, 15 Jul 1998 15:43:15 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: S-MIME / IETF <[email-masked]>
Subject: Comments on CMS-06
Sender: [email-masked]

Without waiting for a last call for CMS-06, here are my comments:

On page 10, the text says “ The input to the signature validation
process includes the result of the message digest calculation process
and the signer’s public key”. This is not sufficient in order to give
the same and relaible result between two different implementations. The
knowledge of the certificate of the signer as well as the time of the
signature are both important. If there is an ambiguity on one or the
other component then the end-result can be different.

1) About the CertUid of the signer

Unless the unambiguous identifier of the certificate of the signer is
part of the signed attributes, attacks are possible. This is a weakness
of the original PKS-7 document that should be corrected. 

This has already be advertised on the PKIX list and explained during the
last meeting in LA. This relates to the POP (Proof of Private key
possession) issue. In other words, using the certificate identifier from
the signer as an additional signed attribute is the only way to make
sure, and at the time the verification is performed, that the user
really has possession of the signing private key, whether or not the CA
has done POP correctly. This protects again a malicious CA that would
"forget" to make POP.

This discussion also relates about the way to uniquely identify a
certificate. From previous E-mail exchanges it has been demonstrated
that in some cases the hash of the issuer public key was a way to
discriminate between synonymous issuer names. Thus the syntax of the
certificate identifier should be extended to optionally support a hash
of the issuer key. 

2) About the signature time

Unless the time is securely known (using a time stamp over the CMS
message), the time should be considered to be the time at which the
signer makes the verification. This means that different results may be
obtained since the signer’s certificate may have been revoked since the
signature was produced (see the recent E-mails exchanges on the mailing
list).

In order to care for these cases, the following text is proposed as an
addition after the first sentence of the section 5.6:

 “ The signer’s public key can be known in advance from the context. In
that case it is directly used. When this is not the case, it has to be
obtained from the information present in the message. The CertUid
present in the signed certificate shall be used for that purpose. 

In order to make sure that the identified certificate is valid, e.g.
using CRLs and ARLs, it is important to know the status of the
certificate at the time the signature was performed. When that time
cannot be reliably known, then, by default, the current time shall be
used. It should be noticed that this can lead to different results
depending upon the time the validation is performed. When that time is
reliably known, e.g. using a time stamp over the CMS message, then that
time shall be used. It should be noticed that leads to the same result
whatever the time the validation is performed.” 

The section 11 should be extended to add the "CertUid" as a "usefull"
attribute.

At the last meeting in LA, I explained during the S/MIME session why it
is important to allow for the presence of a CertUid as a signed
attribute. Refer to the slides that I presented. This section should be
expanded to allow that attribute to be included here, otherwise there
would be serious security problems. 

Proposed text:

11.X  Certificate Unique Identifier

   The Certificate-Unique-Identifier attribute type specifies 
   unambiguously the certificate to be used for verifying the 
   signature, when it is not known otherwise from the context. 

   A Certificate-Unique-Identifier attribute must have a single 
   attribute value.

   The following object identifier identifies the 
   Certificate-Unique-Identifier attribute:

      id-certUid OBJECT IDENTIFIER ::= { iso(1) member-body(2)
          XXXX }

   Certificate-Unique-Identifier attribute values have ASN.1 type 
   CertUid:

      CertUid ::= CertId

      CertId ::= SEQUENCE {
          issuerAndSerialNumber    IssuerAndSerialNumber,
          hashIssuerPublicKey      HashIssuerPublicKey  OPTIONAL}

   The IssuerAndSerialNumber type identifies a certificate, and 
   thereby an entity and a public key, by the name of the certificate
   issuer and an issuer-specific certificate serial number.

   The hashIssuerPublicKey allows to discriminate between two CAs 
   that would have the same issuer name. Should that situation happen,
   then the two CAs would have different public keys. The hash of the
   public keys would thus be different.

      HashIssuerPublicKey ::= SEQUENCE {
            hashOid                 ObjectIdentifier,
            hashedIssuerPublicKey   OCTET STRING}

On page 5, there is a sentence stating: “The signer’s certificate may be
included in the SignedData certificates field”. It is not clear why the
whole certificate should be included. The CertUid (or CertID) would be
sufficient. If the full certificate is needed it does not need to be
part of the signed attributes (note that it is not part of the list of
“useful attributes” described in the section 11).

Finally. At this time, the specification mandates for the use of DNs for
issuers. This question is being debated in the PKIX group. It would
seems more appropriate to write this specification in a way that would
be independent from the final resolution on this topic. In other ways,
the document should avoid to say whether a DN or an alternate name is
being used for the issuer.

Denis

-- 
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "Ietf-Smime (E-mail)" <[email-masked]>
Subject: Section 12 comments (Padding for DSS signatures)
Date: Tue, 14 Jul 1998 16:31:00 -0700
Sender: [email-masked]

The following represents some discussions that went on a long time ago.  The
reasons for needing the padding are still valid for us.  SHould this go into
the new section 12 for the CMS draft or else where?

-----Original Message-----
From: John Pawling [mailto:[email-masked]] 
Sent: Thursday, October 09, 1997 5:20 AM
To: Phil Hallin; Jim Schaad (Exchange)
Cc: [email-masked]
Subject: RE: FW: Comments on PKCS #7, version 1.6: Digest-encryption
process for DSA

Phil,

I agree with your recommendation to allow the signer the flexibility to
include the extra padding, but that the padding is not a mandatory
requirement.  I agree with you that the padding will not cause ASN.1
decoding problems since the padded values are ignored by the decoder.  

Please note that bytes can be added to the R and S values in addition to
leading zeroes being deleted.  Recommend that you set your maximum
Dsa-Sig-Value size to include the worst case scenario in which both the
R
and S values each have a zero octet prepended (i.e. 129 bytes each).

==============================================================
John Pawling                               (301) 953-3600
J.G. Van Dyke & Associates, Inc.           (410) 880-6095
141 National Business Pkwy, Suite 210      FAX: (301) 953-2901
Annapolis Junction, MD  20701              [email-masked]

At 06:26 PM 10/8/97 -0700, Phil Hallin wrote:
>
>	The EncryptedDigest is an OCTET STRING. For DSS, the initial
>bytes of the OCTET STRING contain the ASN.1 sequence of the R and S
>unsigned integers. The length of the sequence is dependent on the
>unsigned integers having or not having leading 0's that are removed for
>DER encoding. I also believe, that  DSS resigning of the same content
>with the same private key results in different R and S values. This
also
>leads to different lengths for the sequence.
>
>	In our PKCS #7 streaming code, if the PKCS #7 is definite length
>encoded, we need to make an initial pass to calculate the overall
length
>of the message. When doing the length calculation, we skip the hash
>step. On the second pass, we update the outer sequence lengths with the
>correct lengths and hash the content. When we get to the signer info,
we
>do the DSS signature and update the EncryptedDigest. Since R and S are
>encoded as unsigned integers, they can have leading 0's that will be
>stripped off. This will change the length of the sequence. If we don't
>allow padding, then, it will also change the length of EncryptedDigest.
>However, if we allow padding, then, we can set the length of the
>EncryptedDigest to the maximum length the sequence of unsigned integers
>can have to contain the DSS R and S components.
>
>	The verify code, simply decodes the initial bytes of the OCTET
>STRING. The verifier simply skips the padding. I have seen similar
>padding in certificate extension values. We ASN.1 decode the initial
>bytes of the extension and ignore the trailing, padding bytes.
>
>	In summary, I  want to allow the signer the flexibility to
>include the extra padding. I used it when doing Definite Length
>streaming of DSS SignedData messages. However, the padding is not
>required.
>
>> -----Original Message-----
>> From:	[email-masked] [SMTP:[email-masked]]
>> Sent:	Wednesday, October 08, 1997 4:22 PM
>> To:	Jim Schaad (Exchange)
>> Cc:	Russ Housley (E-mail); [email-masked]
>> Subject:	Re: FW: Comments on PKCS #7, version 1.6:
>> Digest-encryption process for DSA
>> 
>> Jim,
>> 
>> The process that you describe in your message is exactly what we are
>> planning to implement except for a couple of minor changes:
>> 
>> 1) To comply with PKIX I, we are planning on using the X9.57 OID 
>>         as follows: id-dsa-with-sha-1 {1 2 840 10040 4 3}. 
>>    We are planning on using the NIST OID for SHA1 as follows:
>>     id-sha1 (iso(1) identified-organization(3) oiw(14) secsig(3)
>> algorithm(2) 26}.
>> 
>> 2) We are planning to correctly implement the R and S values as
>> unsigned
>> ASN.1 INTEGERs.  The attachment explains our planned strategy.  This
>> strategy could result in octets being omitted or prepended to the R
>> and S
>> values.  I disagree with your plan to pad the ASN.1 encoded
>> EncryptedDigest
>> so that it is always the same length.  It seems that this just adds
>> more
>> compexity to an already complex process.  I believe that we should
>> just
>> transfer the ASN.1 encoded EncryptedDigest without padding it.
>> 
>> Please note that Russ Housley will be writing an Appendix to PKCS #7
>> that
>> describes the use of SHA1 and DSA with PKCS #7 v1.5.
>> 
>> 
>> ATTACHMENT:
>> 
>> ASN.1 Encoding/Decoding unsigned INTEGERs:
>> 
>> All SHA1/DSA related crypto values (i.e. P, Q, G, R, S, Y) need to be
>> unsigned numbers.  
>> 
>> The following strategy is planned for ASN.1 encoding r, s, p, q, g
and
>> y
>> INTEGER values:
>> 
>> IF the crypto token generates an r, s, p, q, g or y value in which
the
>> first
>> 9 bits are all set to 0, THEN the encoding software deletes the first
>> octet
>> from the octets to be encoded.  This rule is applied repeatedly to
the
>> remaining octets until the first 9 bits are not all set to 0.
>> 
>> IF the crypto token generates an r, s, p, q, g or y value in which
the
>> most
>> significant bit (MSB) is set to 1, THEN the software prepends a
single
>> octet
>> in which every bit is set to 0 to the octets to be encoded.
>> 
>> The following strategy is planned for ASN.1 decoding r, s, p, q, g
and
>> y
>> INTEGER values:
>> 
>> 1) IF the encoded value is "missing" octets (i.e. there are fewer
than
>> the
>> expected number of octets) THEN the decoding software ensures that
the
>> MSB
>> is 0 and, if so, prepends the appropriate number of octets in which
>> every
>> bit is set to 0 to the decoded value to obtain the value to be
>> supplied to
>> the crypto token.  If the MSB of the value encoded in the certificate
>> is set
>> to 1, then an error condition is reported.
>>  
>> 2) IF the encoded value includes an "extra" octet (i.e. the length of
>> the
>> decoded value is one greater that what is expected) THEN the decoding
>> software ensures that every bit in the initial octet is set to 0 and,
>> if so,
>> deletes the initial octet from the decoded value to obtain the value
>> to be
>> supplied to the crypto token.  If the "extra" octet contains a bit
set
>> to 1,
>> then an error condition is reported.
>> 
>> Example 1:
>> 
>> Encoding: The CA software uses the crypto token to generate a 128
byte
>> Y
>> value that begins with "FF0B".  The encoding rules are applied.
>> Because the MSB is set to 1, then the software prepends a single
octet
>> in
>> which every bit is set to 0 to the octets to be encoded.  In this
>> case, a
>> 129 byte Y value is encoded in the DSAPublicKey ASN.1 INTEGER
>> beginning 
>> with "00FF0B....."
>> 
>> Decoding: The certificate-using software discovers that a 129 byte Y
>> value
>> beginning with "00FF0B...." is encoded in the certificate.  Because
>> the
>> cryto token demands a 128 byte Y value, the decoding software ensures
>> that
>> every bit in
>> the initial octet is set to 0 and deletes the initial octet from the
>> decoded
>> value to obtain the value to be supplied to the crypto token to
obtain
>> a
>> 128 byte value beginning with "FF0B.....".
>> 
>> 
>> Example 2:
>> 
>> Encoding: The CA software uses the crypto token to generate a 128
byte
>> Y
>> value that begins with "007FFF". The encoding rules are applied.
>> Because the first 9 bits are all set to 0, then the leading octet is
>> not
>> included in the encoding of the Y value.  The encoding rules are
>> applied to the remaining octets.  The first nine bits are neither all
>> set to
>> 0 nor is the MSB set to 1, so the rules are satisfied.  In this case,
>> a 127
>> byte Y value is encoded in the DSAPublicKey ASN.1 INTEGER as
>> "7FFF....."
>> 
>> Decoding: The certificate using software discovers that a 127 byte Y
>> value
>> ("7FFF....") is encoded in the certificate.  Because the crypto token
>> demands a 128 byte Y value, then the decoding software ensures that
>> the MSB
>> is 0 and prepends an octet consisting of all zeroes (i.e. 00) to the
>> decoded
>> value to obtain "007FFF".
>> 
>> 
>> Example 3:
>> 
>> Encoding: The CA software uses the crypto token to generate a 128
byte
>> Y
>> value that begins with "00007FFF".  The encoding rules are applied.
>> Because the first 9 bits are all set to 0, then the leading octet is
>> deleted
>> from the octets to be encoded in the Y value.  The rules are
>> applied to the remaining octets.  Because the first 9 bits are all
set
>> to 0,
>> then the leading octet is deleted from the octets to be encoded in
the
>> Y
>> value.  The encoding rules are applied to the remaining octets.
>> The first nine bits are neither all set to 0 nor is the MSB set to 1,
>> so the
>> rules are satisfied.  In this case, a 126 byte Y value is encoded in
>> the
>> DSAPublicKey ASN.1 INTEGER as "7FFF....."
>> 
>> Decoding: The certificate using software discovers that a 126 byte Y
>> value
>> ("7FFF....") is encoded in the certificate.  Because the crypto token
>> demands a 128 byte Y value, then the decoding software ensures that
>> the MSB
>> is 0 and prepends two octets consisting of all zeroes (i.e. 0000) to
>> the
>> decoded value to obtain "00007FFF".
>> 
>> 
>> END OF ATTACHMENT
>> 
>> 
>> At 12:24 PM 10/8/97 -0700, Jim Schaad (Exchange) wrote:
>> >Some of our people have implemented this.  How close is this going
to
>> >match to what you are spec-ing for S/MIME V3?
>> >
>> >jim schaad
>> >
>> >> -----Original Message-----
>> >> From:	Phil Hallin 
>> >> Sent:	Wednesday, October 08, 1997 11:18 AM
>> >> To:	Jim Schaad (Exchange)
>> >> Subject:	FW: Comments on PKCS #7, version 1.6: Digest-encryption
>> >> process for DSA
>> >> 
>> >> 
>> >> 
>> >> -----Original Message-----
>> >> From:	Phil Hallin 
>> >> Sent:	Wednesday, June 18, 1997 1:58 PM
>> >> To:	[email-masked]'
>> >> Cc:	Keith Vogel; [email-masked]'; [email-masked]'; Craig
>> Sinclair;
>> >> Sanjay Menon
>> >> Subject:	Comments on PKCS #7, version 1.6: Digest-encryption
>> >> process for DSA
>> >> 
>> >> The document, Extensions and Revisions to PKCS #7, alluded to
>> >> deficiencies in the Digest-encryption process that should be
>> >> considered in version 2.0. I believe this deficiency needs to be
>> >> addressed sooner in 1.6 and possibly in 1.5 to allow DSA
>> signatures.
>> >> 
>> >> The digest-encryption process defined in version 1.5 isn't
>> compatible
>> >> with the signature format in DSA signed X.509 certificates used
for
>> >> Java and recommended in the <draft-ietf-pkix-ipki-part1-04.txt>.
>> >> 
>> >> To be compatible with the DSA X.509 signatures I propose the
>> following
>> >> for the PKCS#7 SignedData Digest-encryption process used for DSA
>> >> signature keys.
>> >> 
>> >> When signing, DSA generates two values. These values are commonly
>> >> referred to as r and s. To easily transfer these two values as one
>> >> signature, they shall be ASN.1 encoded using the following ASN.1
>> >> structure:
>> >> Dsa-Sig-Value ::= SEQUENCE {
>> >>    r       INTEGER,
>> >>    s      INTEGER }
>> >> 
>> >> When a PKCS #7 SignerInfo has a digestEncryptionAlgorithm
>> indicating
>> >> the use of a DSA signature key, for instance, {iso(1)
>> >> identified-organization(3) oiw(14) secsig(3) algorithm(2) 12} and
a
>> >> digestAlgorithm indicating the use of sha1, then, the SignerInfo's
>> >> EncryptedDigest should contain the DER encoding of the above
>> >> Dsa-Sig-Value and not the encryption with the signer's private key
>> of
>> >> the BER encoding of the DigestInfo as defined in Section 9.4 of
the
>> >> PKCS#7 document.
>> >> 
>> >> The input to the DSA signature process is the same message digest
>> that
>> >> is input for the DigestInfo.
>> >> 
>> >> The DSA signature process proposed here for PKCS#7 is identical to
>> the
>> >> DSA signature process used for signing DSS X.509 certificates.
>> >> 
>> >> One additional refinement on the octets in the EncryptedDigest for
>> >> DSA. Since the Dsa-Sig-Value is encoded as a sequence of unsigned
>> >> integers, the length can vary depending if the unsigned integers
>> >> having leading 0's. To allow the EncryptedDigest to have the same
>> >> length for different signatures, the EncryptedDigest can be padded
>> >> with trailing 0's after the ASN.1 encoding of the Dsa-Sig-Value
>> >> sequence.
>> >> 
>> >> Since S/MIME is using PKCS #7 version 1.5, I would also recommend
>> that
>> >> the above DSA signature would also be allowed in version 1.5.
>> >> 
>> >> 
>> >
>

From: "Blake Ramsdell" <[email-masked]>
To: "'EKR'" <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
cc: <[email-masked]>
Subject: NULL AlgorithmIdentifier parameters (was RE: Proposed Section 12 for CMS draft)
Date: Tue, 14 Jul 1998 13:00:09 -0700
Sender: [email-masked]

> -----Original Message-----
> From: EKR [mailto:[email-masked]]
> Sent: Tuesday, July 14, 1998 10:06 AM
> To: Paul Hoffman / IMC
> Cc: [email-masked]
> Subject: Re: Proposed Section 12 for CMS draft
> 
>           For these object identifiers, the parameters field
>           of the digestAlgorithm value should be NULL.

Thank you for actually citing references that support your position.

There has been very loud and opinionated debate (publicly and privately)
about whether or not to omit the parameters or encode them as ASN.1
NULL.  I have explained that current practice is to encode them as NULL,
but this has been a very hard fight for whatever reason, ending at the
current language.

I understand that this is an extremely trivial point (bordering on
insanely trivial).  The simple fact is that the specifications for the
various algorithms specify that the algorithms should be encoded as
ASN.1 NULL, and current practice follows the specifications.

Part of the original debate surrounded the fact that one version of
X9.57 encoded the SHA-1 algorithms as absent.  Personally, I think
that's X9.57's problem, not mine.

My opinion is to encode the parameters as ASN.1 NULL as the Creators of
those OIDs intended.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

To: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Proposed Section 12 for CMS draft
Cc: [email-masked]
From: EKR <[email-masked]>
Date: 14 Jul 1998 10:05:40 -0700
Lines: 278
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:
> 12.1.1  SHA-1
> 
> The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 180-1]. The
> algorithm identifier for SHA-1 is:
> 
>     sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
>         secsig(3) algorithm(2) 26}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate SHA-1 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept SHA-1 AlgorithmIdentifiers with NULL
> parameters as well as absent parameters.  Note that current CMS
> implementations encode SHA-1 both with and without the NULL attributes.
I believe this is wrong. Here's the relevant section from the
latest copy of the OIW OIDs that I have:
          7.1.6   SHA1

          This algorithm  is the NIST  Secure Hash  Algorithm [??].   It is
          based on  concepts  similar to  those used  in MD4  and MD5,  and
          outputs a 160-bit digest.

               sha1 ALGORITHM 
               PARAMETER NULL
               ::= {algorithm 26}

> 12.1.2  MD5
> 
> The MD5 digest algorithm is defined in RFC 1321. The algorithm
> identifier for MD5 is:
> 
>     md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) digestAlgorithm(2) 5}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate MD5 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept MD5 AlgorithmIdentifiers with NULL parameters
> as well as absent parameters. Note that current CMS implementations encode
> MD5 both with and without the NULL attributes.
I believe that that's wrong. Here's the relevant section from pkcs-1:
md2 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 2 }
md4 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 4 }
md5 OBJECT IDENTIFIER ::=
  { iso(1) member-body(2) US(840) rsadsi(113549)
      digestAlgorithm(2) 5 }

          For these object identifiers, the parameters field
          of the digestAlgorithm value should be NULL.

> 12.2  Signature Algorithms
> 
> CMS implementations must include DSA.  CMS implementations may include RSA.
> 
> Signature algorithm identifiers are used in the SignerInfo
> signatureAlgorithm field.
> 
> 12.2.1  DSA
> 
> The DSA signature algorithm is defined in RFC TBD (Diffie-Hellman Key
> Agreement Method, currently draft-ietf-smime-x942). The algorithm
This doesn't seem right.
                              ^^^^^^^^^^^^^^^^^^^^^^

> identifier for DSA is:
> 
>     id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) x9-57(10040)
>         x9cm(4) 1}
This is the wrong OID. It should be dsa-with-sha-1, no?

> The id-dsa algorithm syntax includes an optional sequence of parameters.
> These parameters are commonly referred to as p, q, and g. If the DSA
> algorithm parameters are present, they are included using the following
> ASN.1 structure:
> 
>     Dss-Parms  ::=  SEQUENCE  {
> 	p             INTEGER,
> 	q             INTEGER,
> 	g             INTEGER  }
> 
> If the parameters are omitted, the parameters component must be omitted
> entirely, so the AlgorithmIdentifier in this case is a SEQUENCE of only one
> component, the OBJECT IDENTIFIER id-dsa.
id-dsa-with-sha-1 takes NULL parameters.

p,q,g, should be specified with the user's key, which will
have the OID id-dsa in the certificate.

> 12.2.2  RSA
> 
> The RSA signature algorithm is defined in RFC 2313. The algorithm
> identifier for RSA is:
> 
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with NULL parameters
> as well as absent parameters.  Note that current CMS implementations encode
> RSA both with and without the NULL attributes.
Again, they're wrong. PKCS-1 says:
rsaEncryption OBJECT IDENTIFIER ::= { pkcs-1 1 }

The rsaEncryption object identifier is intended to be used
in the algorithm field of a value of type
AlgorithmIdentifier. The parameters field of that type,
which has the algorithm-specific syntax ANY DEFINED BY
algorithm, would have ASN.1 type NULL for this algorithm.

> 12.3  Key Encryption Algorithms
> 
> CMS implementations must include X9.42 Static Diffie-Hellman.  CMS
> implementations may include RSA.
> 
> Key encryption algorithms are used in the KeyTransRecipientInfo
> keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
> keyEncryptionAlgorithm field, and in the MailListRecipientInfo
> keyEncryptionAlgorithm field. These are all part of the RecipientInfo
> type, which is part of the EnvelopedData type.
> 
> 12.3.1  X9.42 Static Diffie-Hellman with desCBC
> 
> Diffie-Hellman key encryption is defined in X9.42 [X9.42]. The algorithm
Here's where the reference to my draft should go.

> identifier for static Diffie-Hellman is
> 
>     id-smime-cms-x942-with-desCBC ::= { TBD }
This shouldn't be desCBC, since desCBC isn't being used. It's more like
id-smime-cms-x942-with-des3Wrap

I agree with Jim's previous comments. You should be able to
wrap DES in DES, RC2 in RC2, etc. These should be specified
in THIS document.

> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should accept
> static Diffie-Hellman AlgorithmIdentifiers with NULL parameters as well as
> absent parameters. Implementations should generate static Diffie-Hellman
> AlgorithmIdentifiers with the parameter field absent.
We should choose NULL or omitted.

> 12.3.2  RSA
> 
> The RSA encryption algorithm is defined in RFC 2313 [RFC 2313]. The
> algorithm identifier for RSA is:
> 
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with NULL parameters
> as well as absent parameters.  Note that current CMS implementations encode
> RSA both with and without the NULL attributes.
See previous comments about PKCS-1.

> 12.4  Triple-DES Key Wrap
> 
> The block size of the key-encryption algorithm can be determined from the CMS
> KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of the
> content-encryption key can be determined from the CMS
> ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
> exception here; the same identifier is used for both 2-key and 3-key Triple
> DES.  This is probably easily handled by always wrapping three keys, even if
> the first and third keys match.
> 
> The key checksum algorithm is:
> 
> 1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
> 2.  Loop through the octets of the content-encryption key, most
>     significant octet to least significant octet.
>     2a.  Create a 16 bit integer, called temp, by concatenating 
>          8 zero bits and the key octet.
>     2b.  sum1 = sum1 + temp.
>     2c.  sum2 = sum2 + sum1.
> 3.  Use sum2 as the checksum value.
> 
> The key wrap algorithm is:
> 
> 1.  Adjust the parity bits on the Triple-DES keys.
> 2.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 3.  Generate a 4-octet random salt value.
> 4.  Concatenate the salt, content-encryption key, and key 
>     checksum value.
> 5.  Generate the number of pad octets necessary to make the
>     result a multiple of 8 bytes (the Triple-DES algorithm block
>     size), then append them to the result.
> 6.  Encrypt the result with the key-encryption key.  Use an IV
>     with each octet equal to 'A5' hexadecimal.
> 
> The key unwrap algorithm is:
> 
> 1.  Decrypt the wrapped ciphertext using the key-encryption key.
>     Use an IV with each octet equal to 'A5' hexadecimal.
> 2.  Check the parity of the Triple-DES keys.  If any is 
>     incorrect then there is an error.
> 3.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 4.  If computed key checksum value does not match the decrypted
>     key checksum value, then there is an error.
> 
> 12.5  Content Encryption Algorithms
> 
> CMS implementations must include Triple-DES in CBC mode.  CMS
> implementations may include DES in CBC mode and RC2 in CBC mode.
> 
> Content encryption algorithms appear in the EncryptedContentInfo
> contentEncryptionAlgorithm field, which is part of the EnvelopedData type
> and the EncryptedData type.
> 
> 12.5.1  Triple-DES CBC
> 
> The Triple-DES algorithm is described in [3DES]. The algorithm identifier
> for Triple-DES is:
> 
>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
>         rsadsi(113549) encryptionAlgorithm(3) 7}
> 
> The AlgorithmIdentifier parameter field is required and has the structure:
> 
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
> 
> 12.5.2  DES CBC
> 
> The DES algorithm in CBC mode is described in [DES]. The algorithm
> identifier for DES in CBC mode is:
> 
>     DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
>         oiw(14) secsig(3) algorithm(2) 7}
> 
> The AlgorithmIdentifier parameter field is required and has the structure:
> 
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
> 
> 12.5.3  RC2 CBC
> 
> The RC2 algorithm is described in RFC 2268. The algorithm identifier for
> RC2 in CBC mode is:
> 
>     RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) encryptionAlgorithm(3) 2}
> 
> For the effective-key-bits (key size) greater than 32 and less than
> 256, the RC2-CBC algorithm parameters are encoded as:
> 
>     RC2-CBC parameter ::=  SEQUENCE {
>         rc2ParameterVersion  INTEGER,
>         iv                   OCTET STRING (8)}
> 
> For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
> values are 160, 120, 58 respectively. It is very important to note that
> these values are not simply the RC2 keylength. Also note that the value 160
> must be encoded as two octets (00 A0), because encoding as one octet (A0)
> is a negative number in ASN.1.
We need to come down on how long the RC2 keylength is. Stephen
Henson claims that it's commonly set to be the same as the 
effective length, but my experience is that it's set to a fixed
64 bits. Blake?

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

To: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Proposed Section 12 for CMS draft
Cc: [email-masked]
From: EKR <[email-masked]>
Date: 14 Jul 1998 09:58:09 -0700
Lines: 25
Sender: [email-masked]

Paul Hoffman / IMC <[email-masked]> writes:

> At 09:58 PM 7/13/98 -0700, Jim Schaad (Exchange) wrote:
> >1.  Section 12.2.1 - The DSA section is referering to our D-H draft.  I
> >expect it should be refering to a FIPS standard.
> 
> I thought the whole idea of our D-H draft was so we didn't have to rely on
> the FIPS draft, which is still a draft and not finished. Did I get
> something wrong here?
You're confusing DSA with DH. DSA _is_ a FIPS, not a draft. DH (X9.42)
is a draft.

> >2.  Section 12.2.1 - Should include a statement to the effect that if the
> >parameters are omitted they are inherited from the signing certificate. (I
> >may be wrong on this statement.)
> 
> Opinions from the rest of the crowd on this?
Yes. I'll comment on this in my comments on your draft
(as opposed to my comments on Jim's comments).

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Tue, 14 Jul 1998 08:40:32 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: Proposed Section 12 for CMS draft
Sender: [email-masked]

At 09:58 PM 7/13/98 -0700, Jim Schaad (Exchange) wrote:
>1.  Section 12.2.1 - The DSA section is referering to our D-H draft.  I
>expect it should be refering to a FIPS standard.

I thought the whole idea of our D-H draft was so we didn't have to rely on
the FIPS draft, which is still a draft and not finished. Did I get
something wrong here?

>2.  Section 12.2.1 - Should include a statement to the effect that if the
>parameters are omitted they are inherited from the signing certificate. (I
>may be wrong on this statement.)

Opinions from the rest of the crowd on this?

>3.  Section 12.3 - Must include our varient of D-H --- see our D-H draft.
>Don't reference X9.42 Static D-H.

Ah, whoops. I guess I got mixed up about where our D-H was.

>4.  Section 12.3.1 - I don't like the inclusion of des in this OID.  I need
>to be able to operation in a completely exportable manner and I want the RFC
>to support this in an OPTIONAL mode.  Additionally this should refer(?) to
>our D-H draft rathern than X9.42.

Russ stated a preference about not doing parameters on OIDs, just making
the OID what it was supposed to be fully. I tend to agree with him, in that
we have had lots of history of people getting the parameters wrong.
OID+parameter seems unnecessary if we have OIDs for any of the desired
parameters, yes?

>5.  Section 12.4 -- I though that I had talked Russ into providing something
>which contained other than 3-DES key wrapping as an optional.

Yes, but this section describes what is used in the spec, with is only
tripleDES. If I generalize this and say "for tripleDES, this is xyz", there
is more of a chance someone will get it wrong. If you use this for
something other than tripleDES, you have to say what the values used in it
are, so you're going to have to write a doc anyways. I'm happy to make it
more general if you specify what other algs you want values for, and give
the values.

>6.  Section 12.3.1 and section 12.4 -- It does not make sense that the Key
>Agreement OID uses the word des, but the wrapping is actually done with
>3-DES.

I think I agree. Others?

>7.  Section 12.4 -- Need a statement on step 5 if the pad octects are
>constant or random.  I assume that they are random bits.

Others?

>8.  Section 12.4 -- Step 6.  "Encrypt the result with the Triple-DES keys.
>..."

OK.

>9.  Section 12.4 -- Unwrap - Step #2 does not make sense.  Suggest "Check
>the parity of the resulting content encryption key.  If any is incorrect
>then there is an error."  The encryption key may be RC2-40 and therefore not
>have parity bits.

Well, we're only describing tripleDES here. I will certainly make this
change if I generalize the section.

>10.  Section 12.5.1 and Section 12.5.2 -- "CBCParameter ::= IV" -- missing
>'='

Good catch.

>11.  Section 12.6.2 - HMAC-SHA1 does not contain a paragraph describing the
>parameters.  I don't remember there being any paraemters.

Can someone familiar with this let me know definitively whether or not
there are parameters?

--Paul Hoffman, Director
--Internet Mail Consortium

To: "Jim Schaad (Exchange)" <[email-masked]>
Cc: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: Re: Proposed Section 12 for CMS draft
From: EKR <[email-masked]>
Date: 14 Jul 1998 06:56:07 -0700
Lines: 26
Sender: [email-masked]

"Jim Schaad (Exchange)" <[email-masked]> writes:
> 4.  Section 12.3.1 - I don't like the inclusion of des in this OID.  I need
> to be able to operation in a completely exportable manner and I want the RFC
> to support this in an OPTIONAL mode.  Additionally this should refer(?) to
> our D-H draft rathern than X9.42.
Right. The thing to realize here is that there are two adjustable
parameters:
(1) the key agreement algorithm
(2) the key encryption algorithm

So, they either have to be carried as a single OID or they 
have to be carried as an AlgId with the OID specifying
the key agrement algorithm and the parameter specifying
the key encryption algorithm. I prefer the latter, but if
we're going to do the former, we'll need( (at least)
3 different OIDs:
dh-with-des (note, NOT CBC, since we're not wrapping with CBC)
dh-with-3des
dh-with-rc2

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Tue, 14 Jul 1998 12:35:12 +0100
From: Dr Stephen Henson <[email-masked]>
Organization: Dr S N Henson
To: "[email-masked]" <[email-masked]>
Subject: CMS: RecipientInfo syntax.
Sender: [email-masked]

This was mentioned a while ago and is more a cosmetic change than
anything: it may have been too late to be included in the latest CMS
draft. I suggested (and a few agreed) that RecipientInfo should have the
form:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [0] KeyAgreeRecipientInfo,
  mlri [1] MailListRecipientInfo  }

As opposed to its current form:

RecipientInfo ::= CHOICE {
  ktri KeyTransRecipientInfo,
  kari [1] KeyAgreeRecipientInfo,
  mlri [2] MailListRecipientInfo  }

this is just following the general rule that the lowest tag values
necessary should be used.

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: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, [email-masked]
Subject: RE: Proposed Section 12 for CMS draft
Date: Mon, 13 Jul 1998 21:58:36 -0700
Sender: [email-masked]

Next think you know Blake will want to take a vacation.

Comments:

1.  Section 12.2.1 - The DSA section is referering to our D-H draft.  I
expect it should be refering to a FIPS standard.

2.  Section 12.2.1 - Should include a statement to the effect that if the
parameters are omitted they are inherited from the signing certificate. (I
may be wrong on this statement.)

3.  Section 12.3 - Must include our varient of D-H --- see our D-H draft.
Don't reference X9.42 Static D-H.

4.  Section 12.3.1 - I don't like the inclusion of des in this OID.  I need
to be able to operation in a completely exportable manner and I want the RFC
to support this in an OPTIONAL mode.  Additionally this should refer(?) to
our D-H draft rathern than X9.42.

5.  Section 12.4 -- I though that I had talked Russ into providing something
which contained other than 3-DES key wrapping as an optional.

6.  Section 12.3.1 and section 12.4 -- It does not make sense that the Key
Agreement OID uses the word des, but the wrapping is actually done with
3-DES.

7.  Section 12.4 -- Need a statement on step 5 if the pad octects are
constant or random.  I assume that they are random bits.

8.  Section 12.4 -- Step 6.  "Encrypt the result with the Triple-DES keys.
..."

9.  Section 12.4 -- Unwrap - Step #2 does not make sense.  Suggest "Check
the parity of the resulting content encryption key.  If any is incorrect
then there is an error."  The encryption key may be RC2-40 and therefore not
have parity bits.

10.  Section 12.5.1 and Section 12.5.2 -- "CBCParameter ::= IV" -- missing
'='

11.  Section 12.6.2 - HMAC-SHA1 does not contain a paragraph describing the
parameters.  I don't remember there being any paraemters.

> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[email-masked]]
> Sent: Monday, July 13, 1998 8:08 PM
> To: [email-masked]
> Subject: Proposed Section 12 for CMS draft
> 
> 
> Greetings again. Russ decided that summer was for vacations, 
> so he's gone 
> this week. Because we want to get everything ready for last call ASAP 
> (modulo stupid patent issues), he asked Blake and I to try to 
> clean up the 
> last big empty part of the CMS draft, which is section 12. 
> Below is my 
> suggested cut at it. Please read it over carefully and 
> comment, since there 
> are likely to be things that are wrong with it. If we can do 
> significant 
> bashing this week, Russ said he'd rev the draft as soon as he is back.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 12  Supported Algorithms
> 
> This section lists the algorithms that must be implemented.
> Additional algorithms that may be implemented are also included.
> 
> 12.1  Digest Algorithms
> 
> CMS implementations must include SHA-1. CMS implementations 
> may include MD5.
> 
> Digest algorithm identifiers are used in the SignedData 
> digestAlgorithms
> field, the SignerInfo digestAlgorithm field, and the DigestedData
> digestAlgorithm field.
> 
> Digest values are located in the DigestedData digest field. 
> In addition,
> digest values are located in the Message Digest authenticated 
> attribute.
> 
> 12.1.1  SHA-1
> 
> The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 
> 180-1]. The
> algorithm identifier for SHA-1 is:
> 
>     sha-1 OBJECT IDENTIFIER ::= {iso(1) 
> identified-organization(3) oiw(14)
>         secsig(3) algorithm(2) 26}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate SHA-1 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept SHA-1 AlgorithmIdentifiers with NULL
> parameters as well as absent parameters.  Note that current CMS
> implementations encode SHA-1 both with and without the NULL 
> attributes.
> 
> 12.1.2  MD5
> 
> The MD5 digest algorithm is defined in RFC 1321. The algorithm
> identifier for MD5 is:
> 
>     md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) digestAlgorithm(2) 5}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate MD5 AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept MD5 AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters. Note that current CMS 
> implementations encode
> MD5 both with and without the NULL attributes.
> 
> 12.2  Signature Algorithms
> 
> CMS implementations must include DSA.  CMS implementations 
> may include RSA.
> 
> Signature algorithm identifiers are used in the SignerInfo
> signatureAlgorithm field.
> 
> 12.2.1  DSA
> 
> The DSA signature algorithm is defined in RFC TBD (Diffie-Hellman Key
> Agreement Method, currently draft-ietf-smime-x942). The algorithm
> identifier for DSA is:
> 
>     id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) 
> us(840) x9-57(10040)
>         x9cm(4) 1}
> 
> The id-dsa algorithm syntax includes an optional sequence of 
> parameters.
> These parameters are commonly referred to as p, q, and g. If the DSA
> algorithm parameters are present, they are included using the 
> following
> ASN.1 structure:
> 
>     Dss-Parms  ::=  SEQUENCE  {
> 	p             INTEGER,
> 	q             INTEGER,
> 	g             INTEGER  }
> 
> If the parameters are omitted, the parameters component must 
> be omitted
> entirely, so the AlgorithmIdentifier in this case is a 
> SEQUENCE of only one
> component, the OBJECT IDENTIFIER id-dsa.
> 
> 12.2.2  RSA
> 
> The RSA signature algorithm is defined in RFC 2313. The algorithm
> identifier for RSA is:
> 
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters.  Note that current CMS 
> implementations encode
> RSA both with and without the NULL attributes.
> 
> 12.3  Key Encryption Algorithms
> 
> CMS implementations must include X9.42 Static Diffie-Hellman.  CMS
> implementations may include RSA.
> 
> Key encryption algorithms are used in the KeyTransRecipientInfo
> keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
> keyEncryptionAlgorithm field, and in the MailListRecipientInfo
> keyEncryptionAlgorithm field. These are all part of the RecipientInfo
> type, which is part of the EnvelopedData type.
> 
> 12.3.1  X9.42 Static Diffie-Hellman with desCBC
> 
> Diffie-Hellman key encryption is defined in X9.42 [X9.42]. 
> The algorithm
> identifier for static Diffie-Hellman is
> 
>     id-smime-cms-x942-with-desCBC ::= { TBD }
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations 
> should accept
> static Diffie-Hellman AlgorithmIdentifiers with NULL 
> parameters as well as
> absent parameters. Implementations should generate static 
> Diffie-Hellman
> AlgorithmIdentifiers with the parameter field absent.
> 
> 12.3.2  RSA
> 
> The RSA encryption algorithm is defined in RFC 2313 [RFC 2313]. The
> algorithm identifier for RSA is:
> 
>     rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) pkcs(1) pkcs-1(1) 1}
> 
> The AlgorithmIdentifier parameter field is optional.  If present, the
> parameter field must contain an ASN.1 NULL.  Implementations should
> generate RSA AlgorithmIdentifiers with the parameter field absent.
> Implementations should accept RSA AlgorithmIdentifiers with 
> NULL parameters
> as well as absent parameters.  Note that current CMS 
> implementations encode
> RSA both with and without the NULL attributes.
> 
> 12.4  Triple-DES Key Wrap
> 
> The block size of the key-encryption algorithm can be 
> determined from the CMS
> KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, 
> the size of the
> content-encryption key can be determined from the CMS
> ContentEncryptionAlgorithmIdentifier protocol field.  
> Triple-DES may be an
> exception here; the same identifier is used for both 2-key 
> and 3-key Triple
> DES.  This is probably easily handled by always wrapping 
> three keys, even if
> the first and third keys match.
> 
> The key checksum algorithm is:
> 
> 1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
> 2.  Loop through the octets of the content-encryption key, most
>     significant octet to least significant octet.
>     2a.  Create a 16 bit integer, called temp, by concatenating 
>          8 zero bits and the key octet.
>     2b.  sum1 = sum1 + temp.
>     2c.  sum2 = sum2 + sum1.
> 3.  Use sum2 as the checksum value.
> 
> The key wrap algorithm is:
> 
> 1.  Adjust the parity bits on the Triple-DES keys.
> 2.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 3.  Generate a 4-octet random salt value.
> 4.  Concatenate the salt, content-encryption key, and key 
>     checksum value.
> 5.  Generate the number of pad octets necessary to make the
>     result a multiple of 8 bytes (the Triple-DES algorithm block
>     size), then append them to the result.
> 6.  Encrypt the result with the key-encryption key.  Use an IV
>     with each octet equal to 'A5' hexadecimal.
> 
> The key unwrap algorithm is:
> 
> 1.  Decrypt the wrapped ciphertext using the key-encryption key.
>     Use an IV with each octet equal to 'A5' hexadecimal.
> 2.  Check the parity of the Triple-DES keys.  If any is 
>     incorrect then there is an error.
> 3.  Compute a 16-bit key checksum value on the content-encryption
>     key as described above.
> 4.  If computed key checksum value does not match the decrypted
>     key checksum value, then there is an error.
> 
> 12.5  Content Encryption Algorithms
> 
> CMS implementations must include Triple-DES in CBC mode.  CMS
> implementations may include DES in CBC mode and RC2 in CBC mode.
> 
> Content encryption algorithms appear in the EncryptedContentInfo
> contentEncryptionAlgorithm field, which is part of the 
> EnvelopedData type
> and the EncryptedData type.
> 
> 12.5.1  Triple-DES CBC
> 
> The Triple-DES algorithm is described in [3DES]. The 
> algorithm identifier
> for Triple-DES is:
> 
>     DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
>         rsadsi(113549) encryptionAlgorithm(3) 7}
> 
> The AlgorithmIdentifier parameter field is required and has 
> the structure:
> 
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
> 
> 12.5.2  DES CBC
> 
> The DES algorithm in CBC mode is described in [DES]. The algorithm
> identifier for DES in CBC mode is:
> 
>     DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
>         oiw(14) secsig(3) algorithm(2) 7}
> 
> The AlgorithmIdentifier parameter field is required and has 
> the structure:
> 
>     CBCParameter :: IV
>     IV ::= OCTET STRING -- 8 octets.
> 
> 12.5.3  RC2 CBC
> 
> The RC2 algorithm is described in RFC 2268. The algorithm 
> identifier for
> RC2 in CBC mode is:
> 
>     RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
>         rsadsi(113549) encryptionAlgorithm(3) 2}
> 
> For the effective-key-bits (key size) greater than 32 and less than
> 256, the RC2-CBC algorithm parameters are encoded as:
> 
>     RC2-CBC parameter ::=  SEQUENCE {
>         rc2ParameterVersion  INTEGER,
>         iv                   OCTET STRING (8)}
> 
> For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
> values are 160, 120, 58 respectively. It is very important to 
> note that
> these values are not simply the RC2 keylength. Also note that 
> the value 160
> must be encoded as two octets (00 A0), because encoding as 
> one octet (A0)
> is a negative number in ASN.1.
> 
> 12.6  Message Authentication Code Algorithms
> 
> No MAC algorithms are mandatory.  CMS implementations may include DES
> MAC and HMAC.
> 
> MAC algorithms appear in the AuthenticatedData mac field.
> 
> 12.6.1  DES MAC
> 
> The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
> algorithm identifier for DES MAC is:
> 
>     DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>         oiw(14) secsig(3) algorithm(2) 10 }
> 
> The AlgorithmIdentifier parameter field is required. It is an 
> INTEGER, and
> carries the length in bits of the MAC, constrained to 
> multiples of eight
> from 16 to 64.
> 
> 12.6.2  HMAC-SHA1
> 
> The HMAC-SHA1 algorithm is described in RFC 2104. The 
> algorithm identifier for
> HMAC-SHA1 is:
> 
>     HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
>         dod(6) internet(1) security(5) mechanisms(5) 8 1 2}
> 
> {{{References added}}}
> 
> 3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To 
> DES". IEEE
> Spectrum, v. 16, n. 7, pp40-41. July 1979.
> 
> DES  American National Standards Institute. ANSI X3.106, 
> "American National
> Standard for Information Systems- Data Link Encryption". 1983.
> 
> FIPS 113  National Institute of Standards and Technology. 
> FIPS Pub 113:
> Computer Data Authentication. May 1985.
> 
> FIPS 180-1  National Institute of Standards and Technology. 
> FIPS Pub 180-1: 
> Secure Hash Standard.  April 1995.
> 
> FIPS 186  National Institute of Standards and Technology. 
> FIPS Pub 186:
> Digital Signature Standard.  May 1994.
> 
> RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.
> 
> RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message 
> Authentication.
> February 1997.
> 
> RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption 
> Algorithm.
> March 1998.
> 
> X9.42  ANSI X9.42-199x.  Public Key Cryptography for The 
> Financial Services
> Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
> (Working Draft).  December 1997.
> 
> 

Date: Mon, 13 Jul 1998 20:07:44 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Proposed Section 12 for CMS draft
Sender: [email-masked]

Greetings again. Russ decided that summer was for vacations, so he's gone 
this week. Because we want to get everything ready for last call ASAP 
(modulo stupid patent issues), he asked Blake and I to try to clean up the 
last big empty part of the CMS draft, which is section 12. Below is my 
suggested cut at it. Please read it over carefully and comment, since there 
are likely to be things that are wrong with it. If we can do significant 
bashing this week, Russ said he'd rev the draft as soon as he is back.

--Paul Hoffman, Director
--Internet Mail Consortium

12  Supported Algorithms

This section lists the algorithms that must be implemented.
Additional algorithms that may be implemented are also included.

12.1  Digest Algorithms

CMS implementations must include SHA-1. CMS implementations may include MD5.

Digest algorithm identifiers are used in the SignedData digestAlgorithms
field, the SignerInfo digestAlgorithm field, and the DigestedData
digestAlgorithm field.

Digest values are located in the DigestedData digest field. In addition,
digest values are located in the Message Digest authenticated attribute.

12.1.1  SHA-1

The SHA-1 digest algorithm is defined in FIPS Pub 180-1 [FIPS 180-1]. The
algorithm identifier for SHA-1 is:

    sha-1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3) oiw(14)
        secsig(3) algorithm(2) 26}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate SHA-1 AlgorithmIdentifiers with the parameter field absent.
Implementations should accept SHA-1 AlgorithmIdentifiers with NULL
parameters as well as absent parameters.  Note that current CMS
implementations encode SHA-1 both with and without the NULL attributes.

12.1.2  MD5

The MD5 digest algorithm is defined in RFC 1321. The algorithm
identifier for MD5 is:

    md5 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) digestAlgorithm(2) 5}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate MD5 AlgorithmIdentifiers with the parameter field absent.
Implementations should accept MD5 AlgorithmIdentifiers with NULL parameters
as well as absent parameters. Note that current CMS implementations encode
MD5 both with and without the NULL attributes.

12.2  Signature Algorithms

CMS implementations must include DSA.  CMS implementations may include RSA.

Signature algorithm identifiers are used in the SignerInfo
signatureAlgorithm field.

12.2.1  DSA

The DSA signature algorithm is defined in RFC TBD (Diffie-Hellman Key
Agreement Method, currently draft-ietf-smime-x942). The algorithm
identifier for DSA is:

    id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) x9-57(10040)
        x9cm(4) 1}

The id-dsa algorithm syntax includes an optional sequence of parameters.
These parameters are commonly referred to as p, q, and g. If the DSA
algorithm parameters are present, they are included using the following
ASN.1 structure:

    Dss-Parms  ::=  SEQUENCE  {
	p             INTEGER,
	q             INTEGER,
	g             INTEGER  }

If the parameters are omitted, the parameters component must be omitted
entirely, so the AlgorithmIdentifier in this case is a SEQUENCE of only one
component, the OBJECT IDENTIFIER id-dsa.

12.2.2  RSA

The RSA signature algorithm is defined in RFC 2313. The algorithm
identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate RSA AlgorithmIdentifiers with the parameter field absent.
Implementations should accept RSA AlgorithmIdentifiers with NULL parameters
as well as absent parameters.  Note that current CMS implementations encode
RSA both with and without the NULL attributes.

12.3  Key Encryption Algorithms

CMS implementations must include X9.42 Static Diffie-Hellman.  CMS
implementations may include RSA.

Key encryption algorithms are used in the KeyTransRecipientInfo
keyEncryptionAlgorithm field, in the KeyAgreeRecipientInfo
keyEncryptionAlgorithm field, and in the MailListRecipientInfo
keyEncryptionAlgorithm field. These are all part of the RecipientInfo
type, which is part of the EnvelopedData type.

12.3.1  X9.42 Static Diffie-Hellman with desCBC

Diffie-Hellman key encryption is defined in X9.42 [X9.42]. The algorithm
identifier for static Diffie-Hellman is

    id-smime-cms-x942-with-desCBC ::= { TBD }

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should accept
static Diffie-Hellman AlgorithmIdentifiers with NULL parameters as well as
absent parameters. Implementations should generate static Diffie-Hellman
AlgorithmIdentifiers with the parameter field absent.

12.3.2  RSA

The RSA encryption algorithm is defined in RFC 2313 [RFC 2313]. The
algorithm identifier for RSA is:

    rsaEncryption OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) pkcs(1) pkcs-1(1) 1}

The AlgorithmIdentifier parameter field is optional.  If present, the
parameter field must contain an ASN.1 NULL.  Implementations should
generate RSA AlgorithmIdentifiers with the parameter field absent.
Implementations should accept RSA AlgorithmIdentifiers with NULL parameters
as well as absent parameters.  Note that current CMS implementations encode
RSA both with and without the NULL attributes.

12.4  Triple-DES Key Wrap

The block size of the key-encryption algorithm can be determined from the CMS
KeyEncryptionAlgorithmIdentifier protocol field.  Likewise, the size of the
content-encryption key can be determined from the CMS
ContentEncryptionAlgorithmIdentifier protocol field.  Triple-DES may be an
exception here; the same identifier is used for both 2-key and 3-key Triple
DES.  This is probably easily handled by always wrapping three keys, even if
the first and third keys match.

The key checksum algorithm is:

1.  Initialize two 16 bit integers, sum1 and sum2, to zero.
2.  Loop through the octets of the content-encryption key, most
    significant octet to least significant octet.
    2a.  Create a 16 bit integer, called temp, by concatenating 
         8 zero bits and the key octet.
    2b.  sum1 = sum1 + temp.
    2c.  sum2 = sum2 + sum1.
3.  Use sum2 as the checksum value.

The key wrap algorithm is:

1.  Adjust the parity bits on the Triple-DES keys.
2.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
3.  Generate a 4-octet random salt value.
4.  Concatenate the salt, content-encryption key, and key 
    checksum value.
5.  Generate the number of pad octets necessary to make the
    result a multiple of 8 bytes (the Triple-DES algorithm block
    size), then append them to the result.
6.  Encrypt the result with the key-encryption key.  Use an IV
    with each octet equal to 'A5' hexadecimal.

The key unwrap algorithm is:

1.  Decrypt the wrapped ciphertext using the key-encryption key.
    Use an IV with each octet equal to 'A5' hexadecimal.
2.  Check the parity of the Triple-DES keys.  If any is 
    incorrect then there is an error.
3.  Compute a 16-bit key checksum value on the content-encryption
    key as described above.
4.  If computed key checksum value does not match the decrypted
    key checksum value, then there is an error.

12.5  Content Encryption Algorithms

CMS implementations must include Triple-DES in CBC mode.  CMS
implementations may include DES in CBC mode and RC2 in CBC mode.

Content encryption algorithms appear in the EncryptedContentInfo
contentEncryptionAlgorithm field, which is part of the EnvelopedData type
and the EncryptedData type.

12.5.1  Triple-DES CBC

The Triple-DES algorithm is described in [3DES]. The algorithm identifier
for Triple-DES is:

    DES-EDE3-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) 
        rsadsi(113549) encryptionAlgorithm(3) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter :: IV
    IV ::= OCTET STRING -- 8 octets.

12.5.2  DES CBC

The DES algorithm in CBC mode is described in [DES]. The algorithm
identifier for DES in CBC mode is:

    DES-CBC OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 7}

The AlgorithmIdentifier parameter field is required and has the structure:

    CBCParameter :: IV
    IV ::= OCTET STRING -- 8 octets.

12.5.3  RC2 CBC

The RC2 algorithm is described in RFC 2268. The algorithm identifier for
RC2 in CBC mode is:

    RC2-CBC OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
        rsadsi(113549) encryptionAlgorithm(3) 2}

For the effective-key-bits (key size) greater than 32 and less than
256, the RC2-CBC algorithm parameters are encoded as:

    RC2-CBC parameter ::=  SEQUENCE {
        rc2ParameterVersion  INTEGER,
        iv                   OCTET STRING (8)}

For the effective-key-bits of 40, 64, and 128, the rc2ParameterVersion
values are 160, 120, 58 respectively. It is very important to note that
these values are not simply the RC2 keylength. Also note that the value 160
must be encoded as two octets (00 A0), because encoding as one octet (A0)
is a negative number in ASN.1.

12.6  Message Authentication Code Algorithms

No MAC algorithms are mandatory.  CMS implementations may include DES
MAC and HMAC.

MAC algorithms appear in the AuthenticatedData mac field.

12.6.1  DES MAC

The DES MAC algorithm is described in FIPS Pub 113 [FIPS-113]. The
algorithm identifier for DES MAC is:

    DES-MAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
        oiw(14) secsig(3) algorithm(2) 10 }

The AlgorithmIdentifier parameter field is required. It is an INTEGER, and
carries the length in bits of the MAC, constrained to multiples of eight
from 16 to 64.

12.6.2  HMAC-SHA1

The HMAC-SHA1 algorithm is described in RFC 2104. The algorithm identifier for
HMAC-SHA1 is:

    HMAC-SHA1 OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
        dod(6) internet(1) security(5) mechanisms(5) 8 1 2}

{{{References added}}}

3DES  W. Tuchman. "Hellman Presents No Shortcut Solutions To DES". IEEE
Spectrum, v. 16, n. 7, pp40-41. July 1979.

DES  American National Standards Institute. ANSI X3.106, "American National
Standard for Information Systems- Data Link Encryption". 1983.

FIPS 113  National Institute of Standards and Technology. FIPS Pub 113:
Computer Data Authentication. May 1985.

FIPS 180-1  National Institute of Standards and Technology. FIPS Pub 180-1: 
Secure Hash Standard.  April 1995.

FIPS 186  National Institute of Standards and Technology. FIPS Pub 186:
Digital Signature Standard.  May 1994.

RFC 1321  Rivest, R.  The MD5 Message Digest Algorithm.  April 1992.

RFC 2104  Krawczyk, H.  HMAC: Keyed-Hashing for Message Authentication.
February 1997.

RFC 2268  Rivest, R. A Description of the RC2 (r) Encryption Algorithm.
March 1998.

X9.42  ANSI X9.42-199x.  Public Key Cryptography for The Financial Services
Industry: Agreement of Symmetric Algorithm Keys Using Diffie-Hellman
(Working Draft).  December 1997.

To: Russ Housley <[email-masked]>
Cc: [email-masked]
Subject: Re: SignatureAlgorithmIdentifiers
From: EKR <[email-masked]>
Date: 13 Jul 1998 07:23:33 -0700
Lines: 56
Sender: [email-masked]

Russ Housley <[email-masked]> writes:

> Eric & Blake:
> 
> I prefer the single OID approach; however, I do understand the backward
> compatibility concern.  Certificates use a single OID to specify the hash
> (a.k.a. digest) and signature algorithm.  I would prefer a solution that
> was parallel.  This admits the possibility of a common routine for all
> signature verification.
>
> I think that we all agree that id-dsa-with-sha-1 should be used for DSA and
> SHA-1.  So, lets put that ncontrovercial one aside.
> 
> I propose that sha-1WithRSAEncryption be used with RSA and SHA-1.  This
> combination is not deployed in any product that I am aware of, so there is
> not an issue with backward compatability.  PKIX Part 1 uses
> sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 
> 
> For the reasons already stated, I would like to see implementations support
> md2WithRSAEncryption and md5WithRSAEncryption.  However, rsaEncryption is
> already used in many implementations.  So, for RSA with MD2 and MD5 mandate
> (a MUST) the processing of rsaEncryption and allow (a SHOULD) the
> processing of md2WithRSAEncryption and md5WithRSAEncryption.
Russ, 

Maybe I missed a prior message where you spelled out your
reasoning more fully, but the first paragraph above implies that you
believe that the single OID solution is a convenience to
implementors. It's not. Since they now have to program to support two
representations, not one. As long as rsaEncryption is allowed
(mandated by backward compatibility) this will be true.

Lest you get the idea that I'm just avoiding work, let e state that I
don't like the single OID solution on protocol grounds.  a bad
design. It proliferates identifiers unnecessarily, which seems
tasteless, and it makes combinations excessively difficult (in the
limit you need a lookup table to map OIDs to digest-signature
combinations). This information (the digest algorithm) is perfectly
well represented in the digestAlgorithm field. There's no need to
recapitulate it here.

Even if you believe this was a design mistake in PKCS-7, this change
doesn't really patch it. The signature validation algorithm
(and generation, FWIW) will have to be different for 
PKCS-7 and X.509, because the PKCS-7 algorithm has to take
(and process) digestAlgorithm as the input in the rsaEncryption
case. Moreover, as I indicated earler, this change brings up the 
unpleasant question (which I believe would have to be answered
in the protocol document) of what to do when the digestAlgorithm
and the digest in the signatureAlgorithm don't match.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

To: "Blake Ramsdell" <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: Re: SignatureAlgorithmIdentifiers
From: EKR <[email-masked]>
Date: 12 Jul 1998 17:46:57 -0700
Lines: 35
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:

> > -----Original Message-----
> > From: Russ Housley [mailto:[email-masked]]
> > Sent: Friday, July 10, 1998 5:51 AM
> > To: [email-masked]
> > Subject: Re: SignatureAlgorithmIdentifiers
> > 
> > I propose that sha-1WithRSAEncryption be used with RSA and 
> > SHA-1.  This
> > combination is not deployed in any product that I am aware 
> > of, so there is
> > not an issue with backward compatability.  PKIX Part 1 uses
> > sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 
> 
> Several products use sha-1 as a digest algorithm identifier and
> rsaEncryption as a digest encryption / protection algorithm identifier
> (Worldtalk WorldSecure Client, Microsoft Outlook Express, Netscape
> Messenger are three -- I have messages for other vendors also, but these
> are the important ones.  Well, I think they're important).
> 
> So the bottom line seems to be:
> 
> If we use the same OIDs used in PKIX for certificate signatures, it
> makes it easier for implementors, but it could affect backwards
> compatibility.
It doesn't make it easier for this implementor. Since I already have
to support the old format, at least for MD5, this makes life more
complicated rather than less.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Sat, 11 Jul 1998 10:22:31 +0900 (JST)
To: [email-masked]
From: [email-masked] (Your Home Town)
Comments: Authenticated sender is <[email-masked]>
Reply-to: [email-masked]
Subject: Your Home Town Provides Everything You Need
Sender: [email-masked]

YOUR HOME TOWN 
WILL DO 100% OF THE WORK FOR YOU

WE OFFER:
You the chance to own your own Home Based Business.

WE OFFER:
To build your Home Based Business for you.

WE OFFER
You financial independence.

WE OFFER:
You life saving and life changing products.

WE OFFER:
You the easiest way we know to, improve your Health, your
Wealth and your Happiness.

For more information Call:

Our toll free 24 hr message center  at 888-771-9338

Our toll free 24 hr recorded message at 888-771-9340.

our research showed you would be interested in this.
If this is not true <a ahref="mailto:[email-masked]">Click Here</a> and enter remove in the subject.
Thank You.

Reference # 1007109

From: "Paul Lambert" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Fri, 10 Jul 1998 17:59:24 -0700
Subject: Re: Patents and draft-ietf-smime-x942-00.txt
Sender: [email-masked]

Russ,

>I would like to know if any of the patents aply to the subset of X9.42
that
>we has specified to sue with S/MIME.

Yes.

>If they do, then we need to work on a patent statement ...

Ok.

Paul

Russ Housley <[email-masked]> on 07/10/98 05:55:30 AM

To:   Paul Lambert/Certicom
cc:   [email-masked], [email-masked], [email-masked],
      [email-masked]
Subject:  Re: Patents and draft-ietf-smime-x942-00.txt

Paul:

I would like to know if any of the patents aply to the subset of X9.42 that
we has specified to sue with S/MIME.  If they do, then we need to work on a
patent statement or select a different key management approach that does
not infringe on the patent (or pending patent).

Russ

At 02:43 PM 7/9/98 -0700, Paul Lambert wrote:
>Russ,
>
>>Does anyone, especially anyone from Certicom, have any additional
>>information on this topic?
>
>Yes, the IEEE patent statement is an accurate description of Certicom's
>currently issued and pending patents applicable to IEEE 1363.  Some of the
>pending patents apply to X9.42.
>
>
>Regards,
>
>Paul A. Lambert
>
>VP of Product Management
>Certicom Corp.
>San Mateo California
>(650) 312-7996
>
>
>
>
>
>
>Russ Housley <[email-masked]> on 07/09/98 02:05:52 PM
>
>To:   [email-masked]
>cc:   [email-masked], [email-masked], [email-masked] (bcc: Paul
>      Lambert/Certicom)
>Subject:  Re: Patents and draft-ietf-smime-x942-00.txt
>
>
>
>All:
>
>At the recent IEEE P1363 meeting a letter from Certicom was circulated
that
>claimed patent protection on a number of techniques in the P1363 standard.
>X9.42 and P1363 are very highly aligned in the area of Diffie-Hellman.
One
>of these techniques is Public Key Validation, which is described in
Section
>2.1.5 of draft-ietf-smime-x942-00.txt.
>
>A copy of the letter can be found at:
>
>http://grouper.ieee.org/groups/1363/letters/Certicom.txt
>
>Does anyone, especially anyone from Certicom, have any additional
>information on this topic?
>
>Russ
>
>
>>> From:  [email-masked]
>>> Sent:  Friday, June 19, 1998 3:52 PM
>>> To:    [email-masked]
>>> Cc:    [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked]
>>> Subject:    Patents and draft-ietf-smime-x942-00.txt
>>>
>>> All:
>>>
>>> The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
>>> variants fron the ANSI X9.42 Draft Standad. This vairant of
>Diffie-Hellman
>>> seems to be clear of IBM's pending patent.
>>>
>>> At this point, I waould like all S/MIME WG members to determine if
there
>>> are any other potential patents (pending or otherwise) that might
impact
>>> the use of the Diffie-Hellman variant specified in
>>> draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and
>this
>>> query is to avoid any rude surprises.
>>>
>>> Please forward this note to anyone who might offer assistance in the
>quick
>>> resolution of this matter.
>>>
>>> Russ
>>> S/MIME WG Chair
>

Date: Fri, 10 Jul 1998 15:44:10 -0700
To: <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: SignatureAlgorithmIdentifiers
Sender: [email-masked]

At 02:39 PM 7/10/98 -0700, Blake Ramsdell wrote:
>If we use the same OIDs used in PKIX for certificate signatures, it
>makes it easier for implementors, but it could affect backwards
>compatibility.

"could affect" means "break". I'm completely against changing this OID if
it causes messages from v3 clients to not be readable by v2 clients just so
we have nicer-looking OIDs. I think we should leave this alone, and when we
add the DSA alg (which I'm working on), the OID will be DSA-with-SHA-1.

--Paul Hoffman, Director
--Internet Mail Consortium

From: "Blake Ramsdell" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: SignatureAlgorithmIdentifiers
Date: Fri, 10 Jul 1998 14:39:01 -0700
Sender: [email-masked]

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, July 10, 1998 5:51 AM
> To: [email-masked]
> Subject: Re: SignatureAlgorithmIdentifiers
> 
> I propose that sha-1WithRSAEncryption be used with RSA and 
> SHA-1.  This
> combination is not deployed in any product that I am aware 
> of, so there is
> not an issue with backward compatability.  PKIX Part 1 uses
> sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 

Several products use sha-1 as a digest algorithm identifier and
rsaEncryption as a digest encryption / protection algorithm identifier
(Worldtalk WorldSecure Client, Microsoft Outlook Express, Netscape
Messenger are three -- I have messages for other vendors also, but these
are the important ones.  Well, I think they're important).

So the bottom line seems to be:

If we use the same OIDs used in PKIX for certificate signatures, it
makes it easier for implementors, but it could affect backwards
compatibility.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Fri, 10 Jul 1998 08:55:30 -0400
To: "Paul Lambert" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Patents and draft-ietf-smime-x942-00.txt
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Paul:

I would like to know if any of the patents aply to the subset of X9.42 that
we has specified to sue with S/MIME.  If they do, then we need to work on a
patent statement or select a different key management approach that does
not infringe on the patent (or pending patent).

Russ

At 02:43 PM 7/9/98 -0700, Paul Lambert wrote:
>Russ,
>
>>Does anyone, especially anyone from Certicom, have any additional
>>information on this topic?
>
>Yes, the IEEE patent statement is an accurate description of Certicom's
>currently issued and pending patents applicable to IEEE 1363.  Some of the
>pending patents apply to X9.42.
>
>
>Regards,
>
>Paul A. Lambert
>
>VP of Product Management
>Certicom Corp.
>San Mateo California
>(650) 312-7996
>
>
>
>
>
>
>Russ Housley <[email-masked]> on 07/09/98 02:05:52 PM
>
>To:   [email-masked]
>cc:   [email-masked], [email-masked], [email-masked] (bcc: Paul
>      Lambert/Certicom)
>Subject:  Re: Patents and draft-ietf-smime-x942-00.txt
>
>
>
>All:
>
>At the recent IEEE P1363 meeting a letter from Certicom was circulated that
>claimed patent protection on a number of techniques in the P1363 standard.
>X9.42 and P1363 are very highly aligned in the area of Diffie-Hellman.  One
>of these techniques is Public Key Validation, which is described in Section
>2.1.5 of draft-ietf-smime-x942-00.txt.
>
>A copy of the letter can be found at:
>
>http://grouper.ieee.org/groups/1363/letters/Certicom.txt
>
>Does anyone, especially anyone from Certicom, have any additional
>information on this topic?
>
>Russ
>
>
>>> From:  [email-masked]
>>> Sent:  Friday, June 19, 1998 3:52 PM
>>> To:    [email-masked]
>>> Cc:    [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked];
>>> [email-masked]; [email-masked]; [email-masked]
>>> Subject:    Patents and draft-ietf-smime-x942-00.txt
>>>
>>> All:
>>>
>>> The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
>>> variants fron the ANSI X9.42 Draft Standad. This vairant of
>Diffie-Hellman
>>> seems to be clear of IBM's pending patent.
>>>
>>> At this point, I waould like all S/MIME WG members to determine if there
>>> are any other potential patents (pending or otherwise) that might impact
>>> the use of the Diffie-Hellman variant specified in
>>> draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and
>this
>>> query is to avoid any rude surprises.
>>>
>>> Please forward this note to anyone who might offer assistance in the
>quick
>>> resolution of this matter.
>>>
>>> Russ
>>> S/MIME WG Chair
> 

Date: Fri, 10 Jul 1998 08:51:06 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: SignatureAlgorithmIdentifiers
Sender: [email-masked]

Eric & Blake:

I prefer the single OID approach; however, I do understand the backward
compatibility concern.  Certificates use a single OID to specify the hash
(a.k.a. digest) and signature algorithm.  I would prefer a solution that
was parallel.  This admits the possibility of a common routine for all
signature verification.

I think that we all agree that id-dsa-with-sha-1 should be used for DSA and
SHA-1.  So, lets put that ncontrovercial one aside.

I propose that sha-1WithRSAEncryption be used with RSA and SHA-1.  This
combination is not deployed in any product that I am aware of, so there is
not an issue with backward compatability.  PKIX Part 1 uses
sha-1WithRSAEncryption for certificate signatures with RSA and SHA-1. 

For the reasons already stated, I would like to see implementations support
md2WithRSAEncryption and md5WithRSAEncryption.  However, rsaEncryption is
already used in many implementations.  So, for RSA with MD2 and MD5 mandate
(a MUST) the processing of rsaEncryption and allow (a SHOULD) the
processing of md2WithRSAEncryption and md5WithRSAEncryption.

Russ

Blake said:
>> OK, now for something controversial (well, maybe it isn't).  Object
>> identifiers.
>> 
>> There is currently a field in the SignerInfo structure called
>> signatureAlgorithm which is of type SignatureAlgorithmIdentifier.  This
>> was called digestEncryptionAlgorithm and was of type
>> DigestEncryptionAlgorithmIdentifier in PKCS #7 v1.5 (RFC 2315).  It was
>> renamed because DSA is not technically an encryption of a digest which
>> was implied by the old name.  In any case, in S/MIME v2 which used PKCS
>> #7 v1.5, this field always contained the OID "rsaEncryption" defined
>> under PKCS #1.
>> 
>> It has been suggested through various non-list channels that the
>> semantics of this field be changed to be the complete signature
>> algorithm.  That is, the OID that combines the digest algorithm with the
>> method by which the digest is protected.  For instance,
>> md2WithRSAEncryption, md5WithRSAEncryption, sha-1WithRSAEncryption, and
>> id-dsa-with-sha1 instead of the currently specified values of
>> rsaEncryption and id-dsa.

Then, Eric said:
>I agree that dsa should be id-dsa-with-sha-1 for security reasons.
>
>I do not, however, agree that we should use fooWithRSAEncryption.
>It doesn't provide any obvious benefit that I can see, and
>(as noted) has negative backwards compatibility consequences.
>Moroever, it leaves open the question of what to do if the
>OID in the SignatureAlgorithm doesn't match the OID in the
>digestAlgorithm field.

To: "Blake Ramsdell" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: SignatureAlgorithmIdentifiers
From: EKR <[email-masked]>
Date: 09 Jul 1998 21:16:14 -0700
Lines: 51
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:
> > I agree that dsa should be id-dsa-with-sha-1 for security reasons.
> 
> What are the security reasons?  I may not have been paying attention in
> class again, so sorry if this is review.
Any system which uses DSA MUST choose one and only one 
message digest to be used with DSA. Otherwise, imagine
that the attacker has compromised digest A but not 
digest B. He takes a message signed with digest B 
such that B(M)=dB and replaces it with a message M'
such that A(M')=dA=dB=B(M). He also (of course) relabels
the message as using digest A. He's now constructed a
message with a valid signature and content of his choosing.
This attack cannot be mounted against RSA because 
the digest algorithm is part of the signature.

> The idea was that in PKCS #7 v1.5, there was "the thing that you use to
> digest the content [the digest algorithm]" and "the thing that you use
> to unprotect the protected digest value so that you can compare it to
> the thing you got with the thing that you used to digest the content
> [which used to be called the digest encryption algorithm, but is now
> called the signature algorithm, but which possibly should be called the
> digest protection algorithm]".  id-dsa-with-sha1 seems to refer to the
> combination of these two types of algorithms, similar to
> md5WithRSAEncryption.
Yes, I agree. The problem is that the digest algorthm cannot be
independently chosen from the digest protection algorithm when
DSA is used. It can when RSA is used.

> > I do not, however, agree that we should use fooWithRSAEncryption.
> > It doesn't provide any obvious benefit that I can see, and
> > (as noted) has negative backwards compatibility consequences.
> > Moroever, it leaves open the question of what to do if the
> > OID in the SignatureAlgorithm doesn't match the OID in the
> > digestAlgorithm field.
> 
> A message signed with an RSA certificate and digested using the SHA-1
> digest algorithm in current practice has rsaEncryption in the
> signatureAlgorithm, and the digestAlgorithm contains sha-1, so I think
> we are already in a situation that they don't match. 
But they're not supposed to match, so that's fine. If we change,
then you should have digestAlgorithm=SHA-1 and signatureAlgorithm=
SHAw/RSA but what if signatureAlgorithm=MD5w/RSA. How should
you behave if you receive such a message? I'd ratheer skirt
this problem entirely.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

From: "Blake Ramsdell" <[email-masked]>
To: "'EKR'" <[email-masked]>
cc: "[email-masked]'" <[email-masked]>
Subject: RE: SignatureAlgorithmIdentifiers
Date: Thu, 9 Jul 1998 16:34:39 -0700
Sender: [email-masked]

> -----Original Message-----
> From: EKR [mailto:[email-masked]]
> Sent: Thursday, July 09, 1998 3:56 PM
> To: Blake Ramsdell
> Cc: [email-masked]'
> Subject: Re: SignatureAlgorithmIdentifiers
> 
> I agree that dsa should be id-dsa-with-sha-1 for security reasons.

What are the security reasons?  I may not have been paying attention in
class again, so sorry if this is review.

The idea was that in PKCS #7 v1.5, there was "the thing that you use to
digest the content [the digest algorithm]" and "the thing that you use
to unprotect the protected digest value so that you can compare it to
the thing you got with the thing that you used to digest the content
[which used to be called the digest encryption algorithm, but is now
called the signature algorithm, but which possibly should be called the
digest protection algorithm]".  id-dsa-with-sha1 seems to refer to the
combination of these two types of algorithms, similar to
md5WithRSAEncryption.

This wording is not very good, and I will probably explain it better
about five messages from now.

> I do not, however, agree that we should use fooWithRSAEncryption.
> It doesn't provide any obvious benefit that I can see, and
> (as noted) has negative backwards compatibility consequences.
> Moroever, it leaves open the question of what to do if the
> OID in the SignatureAlgorithm doesn't match the OID in the
> digestAlgorithm field.

A message signed with an RSA certificate and digested using the SHA-1
digest algorithm in current practice has rsaEncryption in the
signatureAlgorithm, and the digestAlgorithm contains sha-1, so I think
we are already in a situation that they don't match.  I do agree,
however, that it does not seem to provide any obvious benefit to use the
fooWithRSAEncryption in the signatureAlgorithm field.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

To: "Blake Ramsdell" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: SignatureAlgorithmIdentifiers
From: EKR <[email-masked]>
Date: 09 Jul 1998 15:56:12 -0700
Lines: 35
Sender: [email-masked]

"Blake Ramsdell" <[email-masked]> writes:

> OK, now for something controversial (well, maybe it isn't).  Object
> identifiers.
> 
> There is currently a field in the SignerInfo structure called
> signatureAlgorithm which is of type SignatureAlgorithmIdentifier.  This
> was called digestEncryptionAlgorithm and was of type
> DigestEncryptionAlgorithmIdentifier in PKCS #7 v1.5 (RFC 2315).  It was
> renamed because DSA is not technically an encryption of a digest which
> was implied by the old name.  In any case, in S/MIME v2 which used PKCS
> #7 v1.5, this field always contained the OID "rsaEncryption" defined
> under PKCS #1.
> 
> It has been suggested through various non-list channels that the
> semantics of this field be changed to be the complete signature
> algorithm.  That is, the OID that combines the digest algorithm with the
> method by which the digest is protected.  For instance,
> md2WithRSAEncryption, md5WithRSAEncryption, sha-1WithRSAEncryption, and
> id-dsa-with-sha1 instead of the currently specified values of
> rsaEncryption and id-dsa.
I agree that dsa should be id-dsa-with-sha-1 for security reasons.

I do not, however, agree that we should use fooWithRSAEncryption.
It doesn't provide any obvious benefit that I can see, and
(as noted) has negative backwards compatibility consequences.
Moroever, it leaves open the question of what to do if the
OID in the SignatureAlgorithm doesn't match the OID in the
digestAlgorithm field.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

From: "Paul Lambert" <[email-masked]>
To: Russ Housley <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Date: Thu, 9 Jul 1998 14:43:25 -0700
Subject: Re: Patents and draft-ietf-smime-x942-00.txt
Sender: [email-masked]

Russ,

>Does anyone, especially anyone from Certicom, have any additional
>information on this topic?

Yes, the IEEE patent statement is an accurate description of Certicom's
currently issued and pending patents applicable to IEEE 1363.  Some of the
pending patents apply to X9.42.

Regards,

Paul A. Lambert

VP of Product Management
Certicom Corp.
San Mateo California
(650) 312-7996

Russ Housley <[email-masked]> on 07/09/98 02:05:52 PM

To:   [email-masked]
cc:   [email-masked], [email-masked], [email-masked] (bcc: Paul
      Lambert/Certicom)
Subject:  Re: Patents and draft-ietf-smime-x942-00.txt

All:

At the recent IEEE P1363 meeting a letter from Certicom was circulated that
claimed patent protection on a number of techniques in the P1363 standard.
X9.42 and P1363 are very highly aligned in the area of Diffie-Hellman.  One
of these techniques is Public Key Validation, which is described in Section
2.1.5 of draft-ietf-smime-x942-00.txt.

A copy of the letter can be found at:

http://grouper.ieee.org/groups/1363/letters/Certicom.txt

Does anyone, especially anyone from Certicom, have any additional
information on this topic?

Russ

>> From:  [email-masked]
>> Sent:  Friday, June 19, 1998 3:52 PM
>> To:    [email-masked]
>> Cc:    [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Subject:    Patents and draft-ietf-smime-x942-00.txt
>>
>> All:
>>
>> The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
>> variants fron the ANSI X9.42 Draft Standad. This vairant of
Diffie-Hellman
>> seems to be clear of IBM's pending patent.
>>
>> At this point, I waould like all S/MIME WG members to determine if there
>> are any other potential patents (pending or otherwise) that might impact
>> the use of the Diffie-Hellman variant specified in
>> draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and
this
>> query is to avoid any rude surprises.
>>
>> Please forward this note to anyone who might offer assistance in the
quick
>> resolution of this matter.
>>
>> Russ
>> S/MIME WG Chair

From: "Blake Ramsdell" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: SignatureAlgorithmIdentifiers
Date: Thu, 9 Jul 1998 14:38:01 -0700
Sender: [email-masked]

OK, now for something controversial (well, maybe it isn't).  Object
identifiers.

There is currently a field in the SignerInfo structure called
signatureAlgorithm which is of type SignatureAlgorithmIdentifier.  This
was called digestEncryptionAlgorithm and was of type
DigestEncryptionAlgorithmIdentifier in PKCS #7 v1.5 (RFC 2315).  It was
renamed because DSA is not technically an encryption of a digest which
was implied by the old name.  In any case, in S/MIME v2 which used PKCS
#7 v1.5, this field always contained the OID "rsaEncryption" defined
under PKCS #1.

It has been suggested through various non-list channels that the
semantics of this field be changed to be the complete signature
algorithm.  That is, the OID that combines the digest algorithm with the
method by which the digest is protected.  For instance,
md2WithRSAEncryption, md5WithRSAEncryption, sha-1WithRSAEncryption, and
id-dsa-with-sha1 instead of the currently specified values of
rsaEncryption and id-dsa.

I have one concern about this -- backwards compatibility.  I'm a baby
about this, and I know for a fact that some S/MIME v2 agents will freak
out if they spot md5WithRSAEncryption or sha-1WithRSAEncryption in the
digestEncryptionAlgorithm field of the SignerInfo.

If people think that this change is a good idea, then how should we word
it?

First cut:

Sending agents SHOULD use md2WithRSAEncryption, md5WithRSAEncryption,
sha-1WithRSAEncryption when signing with any of those algorithm
combinations.  Sending agents SHOULD not use rsaEncryption except when
compatibility with v2 is required.  Sending agents MUST use
id-dsa-with-sha1 since there are no backwards compatibility issues.
Receiving agents MUST accept these as well as the (deprecated)
rsaEncryption.

I think it gets a bit messy, and any suggestions are welcome.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

Date: Thu, 09 Jul 1998 17:05:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Patents and draft-ietf-smime-x942-00.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

All:

At the recent IEEE P1363 meeting a letter from Certicom was circulated that
claimed patent protection on a number of techniques in the P1363 standard.
X9.42 and P1363 are very highly aligned in the area of Diffie-Hellman.  One
of these techniques is Public Key Validation, which is described in Section
2.1.5 of draft-ietf-smime-x942-00.txt.

A copy of the letter can be found at:

http://grouper.ieee.org/groups/1363/letters/Certicom.txt

Does anyone, especially anyone from Certicom, have any additional
information on this topic?

Russ

>> From: 	[email-masked]
>> Sent: 	Friday, June 19, 1998 3:52 PM
>> To: 	[email-masked]
>> Cc: 	[email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked];
>> [email-masked]; [email-masked]; [email-masked]
>> Subject: 	Patents and draft-ietf-smime-x942-00.txt
>> 
>> All:
>> 
>> The Internet-Draft draft-ietf-smime-x942-00.txt specified on of the
>> variants fron the ANSI X9.42 Draft Standad. This vairant of Diffie-Hellman
>> seems to be clear of IBM's pending patent.
>> 
>> At this point, I waould like all S/MIME WG members to determine if there
>> are any other potential patents (pending or otherwise) that might impact
>> the use of the Diffie-Hellman variant specified in
>> draft-ietf-smime-x942-00.txt.  At this point I am unaware of any, and this
>> query is to avoid any rude surprises.
>> 
>> Please forward this note to anyone who might offer assistance in the quick
>> resolution of this matter.
>> 
>> Russ
>> S/MIME WG Chair 

From: "Blake Ramsdell" <[email-masked]>
To: "'EKR'" <[email-masked]>, "Russ Housley" <[email-masked]>
cc: <[email-masked]>, "ietf-smime" <[email-masked]>
Subject: RE: Signing a SignedData object with RSA
Date: Wed, 8 Jul 1998 14:53:28 -0700
Sender: [email-masked]

> -----Original Message-----
> From: EKR [mailto:[email-masked]]
> Sent: Wednesday, July 08, 1998 7:39 AM
> To: Russ Housley
> Cc: [email-masked]; ietf-smime
> Subject: Re: Signing a SignedData object with RSA
> 
> Russ Housley <[email-masked]> writes:
> > >- the signatureAlgorithm of the SignerInfo is to be a 
> proper signature
> > >algorithm, like sha1WithRSASignature
> > 
> > Correct.
> Actually, no. At least not if we want to maintain compatibility
> with PKCS-7. Remember that in PKCS-7, this field was known as
> digestEncryptionAlgorithm. It's just rsaEncryption. 

This is correct.  This is what current S/MIME practice is, for exactly
the reason that Eric points out.

For further clarification, the OID is the one defined under PKCS #1
rsaEncryption, not the other five or six that you might find lying about
in other places.

I presume that this will all be covered when we start shoring up section
12 of CMS.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice +1 425 882 8861 x103  Fax +1 425 882 8060

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "'Francois Rousseau'" <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-smime-sigattr-01.txt
Date: Wed, 8 Jul 1998 12:02:59 -0700 
Sender: [email-masked]

This is what I get for not completely understanding attribute
certificates yet.  I will make the change from IssuerAndSerialNumber to
using a GeneralName on the issuer.

jim

> -----Original Message-----
> From: Francois Rousseau [mailto:[email-masked]]
> Sent: Wednesday, July 08, 1998 7:29 AM
> To: Jim Schaad (Exchange)
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-smime-sigattr-01.txt
> 
> 
> Jim,
> 
> I fully support the added ability to refer to Attribute 
> Certificates in the
> revised Signing Certificate Attribute. However, for the 
> CertID type at Sec
> 5, you used the IssuerAndSerialNumber type, which is defined 
> in Sec 10.2.4
> of CMS as:
> 
> IssuerAndSerialNumber ::= SEQUENCE {
> 	issuer		Name,
> 	serialNumber	CertificateSerialNumber }
> 
> The IssuerAndSerialNumber type is adequate to identify a public key
> certificate by the DN of the certificate issuer and an issuer-specific
> certificate serial number. However, it will not be adequate 
> for Attribute
> Certificates since they use the GeneralNames type to identify the
> certificate issuer instead on the Name type. As suggested in 
> my previous
> message on 29 May 1998, instead of the IssuerAndSerialNumber type, I
> suggest that you use the following:
> 
> IssuerSerial ::= SEQUENCE {
> 	issuer		GeneralNames,
> 	serialNumber	CertificateSerialNumber }
> 
> Where fields of the IssuerSerial type would have the 
> following meanings:
> 
> 	The issuer is the name of the Authority that created 
> the certificate.
> 
> 	The serialNumber is the serial number that uniquely 
> identifies the
> certificate.
> 
> The issuer field can be used to identify the issuer of an attribute
> certificate or a public key certificates since one of the possible
> alternative under the GeneralNames type is the Name type. 
> Note that Sec
> 4.2.1.7 of PKIX Part 1 provides more details on the GeneralNames type.
> 
> In addition, CMS distinguishes between signed/unsigned 
> attributes, which
> are only used in the SignerInfo object, and 
> authenticated/unauthenticated
> attributes, which are only used in the AuthenticatedData 
> object. Because of
> this, I suggest that the second sentence of Sec 1 should read:
> 
> "This draft addresses this issue by creating a new attribute 
> to be placed
> in the SignedAttributes section of a SignerInfo object."
> 
> In the same vein I suggest that the first four sentences of the last
> paragraph of Sec 6 should read:
> 
> "If present, the SigningCertificate attribute MUST be a 
> signed attribute;
> it MUST NOT be an unsigned, an authenticated or an unauthenticated
> attribute.  CMS defines SignedAttributes as a SET SIZE (1..MAX) OF
> Attribute.  A SignerInfo MUST NOT include multiple instances of the
> SigningCertificate attribute.  CMS defines the ASN.1 syntax 
> for Attribute
> to include attrValues SET OF AttributeValue."
> 
> Francois Rousseau
> 

To: Russ Housley <[email-masked]>
Cc: [email-masked], ietf-smime <[email-masked]>
Subject: Re: Signing a SignedData object with RSA
From: EKR <[email-masked]>
Date: 08 Jul 1998 07:38:40 -0700
Lines: 61
Sender: [email-masked]

Russ Housley <[email-masked]> writes:
> >- the signatureAlgorithm of the SignerInfo is to be a proper signature
> >algorithm, like sha1WithRSASignature
> 
> Correct.
Actually, no. At least not if we want to maintain compatibility
with PKCS-7. Remember that in PKCS-7, this field was known as
digestEncryptionAlgorithm. It's just rsaEncryption. 

If you reference note 2 of section 9.4, this becomes clear:

     2.   The input to the encryption process typically will
          have 30 or fewer octets. If
          digestEncryptionAlgorithm is PKCS #1's
          rsaEncryption, then this means that the input can
          be encrypted in a single block as long as the
          length of the RSA modulus is at least 328 bits,
          which is reasonable and consistent with security
          recommendations.

Also, see S 9.5
9.5 Compatibility with Privacy-Enhanced Mail

Compatibility with the MIC-ONLY and MIC-CLEAR process types
in PEM occurs when the content type of the ContentInfo value
being signed is data, there are no authenticated attributes,
the message-digest algorithm is md2 or md5, and the digest-
encryption algorithm is PKCS #1's rsaEncryption. Under all
those conditions, the encrypted message digest produced here
matches the one produced in PEM because:

     1.   The value input to the message-digest algorithm in
          PEM is the same as in this standard when there are
          no authenticated attributes. MD2 and MD5 in PEM
          are the same as md2 and md5.
          
     2.   The value encrypted with the signer's private key
          in PEM (as specified in RFC 1423) is the same as
          in this standard when there are no authenticated
          attributes. RSA private-key encryption in PEM is
          the same as PKCS #1's rsaEncryption.
          
The other parts of the signed-data content type
(certificates, CRLs, algorithm identifiers, etc.) are easily
translated to and from their corresponding PEM components.

This is also what my implementation does. Does anyone else
do it differently?

This 
Two comments:
1. This is the right thing to do. That's why the digestAlgorithm
field is present.
2. DSA must of course be DSA-with-SHA-1.

-Ekr

-- 
[Eric Rescorla                             Terisa Systems, Inc.]
		"Put it in the top slot."

Date: Wed, 08 Jul 1998 10:29:18 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-sigattr-01.txt
Cc: [email-masked]
Sender: [email-masked]

Jim,

I fully support the added ability to refer to Attribute Certificates in the
revised Signing Certificate Attribute. However, for the CertID type at Sec
5, you used the IssuerAndSerialNumber type, which is defined in Sec 10.2.4
of CMS as:

IssuerAndSerialNumber ::= SEQUENCE {
	issuer		Name,
	serialNumber	CertificateSerialNumber }

The IssuerAndSerialNumber type is adequate to identify a public key
certificate by the DN of the certificate issuer and an issuer-specific
certificate serial number. However, it will not be adequate for Attribute
Certificates since they use the GeneralNames type to identify the
certificate issuer instead on the Name type. As suggested in my previous
message on 29 May 1998, instead of the IssuerAndSerialNumber type, I
suggest that you use the following:

IssuerSerial ::= SEQUENCE {
	issuer		GeneralNames,
	serialNumber	CertificateSerialNumber }

Where fields of the IssuerSerial type would have the following meanings:

	The issuer is the name of the Authority that created the certificate.

	The serialNumber is the serial number that uniquely identifies the
certificate.

The issuer field can be used to identify the issuer of an attribute
certificate or a public key certificates since one of the possible
alternative under the GeneralNames type is the Name type. Note that Sec
4.2.1.7 of PKIX Part 1 provides more details on the GeneralNames type.

In addition, CMS distinguishes between signed/unsigned attributes, which
are only used in the SignerInfo object, and authenticated/unauthenticated
attributes, which are only used in the AuthenticatedData object. Because of
this, I suggest that the second sentence of Sec 1 should read:

"This draft addresses this issue by creating a new attribute to be placed
in the SignedAttributes section of a SignerInfo object."

In the same vein I suggest that the first four sentences of the last
paragraph of Sec 6 should read:

"If present, the SigningCertificate attribute MUST be a signed attribute;
it MUST NOT be an unsigned, an authenticated or an unauthenticated
attribute.  CMS defines SignedAttributes as a SET SIZE (1..MAX) OF
Attribute.  A SignerInfo MUST NOT include multiple instances of the
SigningCertificate attribute.  CMS defines the ASN.1 syntax for Attribute
to include attrValues SET OF AttributeValue."

Francois Rousseau

Date: Wed, 08 Jul 1998 09:51:58 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Signing a SignedData object with RSA
Cc: ietf-smime <[email-masked]>
Sender: [email-masked]

Anette 

>Since neither the CMS spec nor PKCS#7 states this explicitly, I'd very
>much appreciate to have the following confirmed - or corrected: 

Section 12 will provide thin information.

>When signing a SignedData object with RSA keys: 
>- the signature is to be formed according to PKCS#1, and this is just
>the value of the signature OCTET STRING in the SignerInfo object

Correct.

>- the signatureAlgorithm of the SignerInfo is to be a proper signature
>algorithm, like sha1WithRSASignature

Correct.

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-certdist-01.txt
Date: Wed, 08 Jul 1998 08:47:48 -0400
Sender: [email-masked]

--NextPart

A Revised 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		: Certificate Distribution Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-certdist-01.txt
	Pages		: 8
	Date		: 07-Jul-98
	
This document provides a method of publishing certificates with  secondary support information such as the SMimeCapabilities attribute (containing bulk algorithm support) in a way that is both authenticated and bound to a given certificate.

Internet-Drafts are available by anonymous FTP.  Login wih the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-certdist-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-smime-certdist-01.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: ds.internic.net
	
	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-certdist-01.txt".
	
NOTE:	The mail server at ds.internic.net 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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-certdist-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-certdist-01.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-sigattr-01.txt
Date: Wed, 08 Jul 1998 08:44:42 -0400
Sender: [email-masked]

--NextPart

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		: Signing Certificate Attribute Specification
	Author(s)	: J. Schaad
	Filename	: draft-ietf-smime-sigattr-01.txt
	Pages		: 7
	Date		: 07-Jul-98
	
A set of attacks on SignedData objects have been identified relating to the fact that the certificate to be used when verifying the signature in a SignerInfo is not cryptographically bound into the signature. This leads to a set of attacks where the certificate used to verify the signature is altered leading to possible incorrect results. This document describes these attacks and provides ways to deal with some of the attacks.

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-sigattr-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-sigattr-01.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-sigattr-01.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-sigattr-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-sigattr-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 08 Jul 1998 13:58:39 +0200
From: Anette Byskov <[email-masked]>
Reply-To: [email-masked]
Organization: Cryptomathic
To: ietf-smime <[email-masked]>
Subject: Signing a SignedData object with RSA
Sender: [email-masked]

Since neither the CMS spec nor PKCS#7 states this explicitly, I'd very
much appreciate to have the following confirmed - or corrected: 

When signing a SignedData object with RSA keys: 
- the signature is to be formed according to PKCS#1, and this is just
the value of the signature OCTET STRING in the SignerInfo object
- the signatureAlgorithm of the SignerInfo is to be a proper signature
algorithm, like sha1WithRSASignature (or is it just rsaEncryption as the
digestAlgorithm holds the Sha1 OID?)

Best regards,
Anette Byskov
------------------------------------------------------------
Anette Byskov                          Cryptomathic A/S
Tel:    +45 86 13 90 20                Klostergade 28
Direct: +45 86 13 90 21 - 113          DK-8000 Aarhus C
Fax:    +45 86 20 29 75                Denmark
Web:    http://www.cryptomathic.dk/
                           - new dimensions in data security
------------------------------------------------------------

From: [email-masked]
To: IETF-Announce: ;
Cc: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-06.txt
Date: Tue, 07 Jul 1998 10:51:39 -0400
Sender: [email-masked]

--NextPart

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-06.txt
	Pages		: 41
	Date		: 06-Jul-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-06.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-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "Jim Schaad (Exchange)" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Tue, 7 Jul 1998 12:38:55 -0700 
Sender: [email-masked]

Denis -- 
Here are the quick thoughts from your message(s)

1.  The latest draft of the sigattr draft now has the ability to
specifiy a set of attribute certificates to be used in the verification
process as well as the user's signing certificate.  I sent this draft in
today so it should showup on the list this week.

2.  I'd like to get some clarifiation from you on what you consider the
differences between a security label and a control policy module.  From
my reading I think you consider these to be very seperate beasts but I
would like to verify that this is a true statement.  Do you consider the
following statements to be true?

A.  A security label is used to define the set of readers who are
permitted to view the contents of a signed object.
B.  A control policy module is a set of rules used in accepting a) the
chain of certificates used during a signature operation (such as trusted
roots, interpretation of non-critical extensions in certificates) and b)
the set of authenticated attributes in a SignerInfo object (such as a
time, the proposed Signing Certificate attribute, any proposed signature
purpose attributes).

As such in my current e-mail code I am looking at allowing for
flexability in the first (security policy) but am hard coding the
second.

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, July 06, 1998 5:35 PM
> To: Jim Schaad (Exchange)
> Cc: [email-masked]
> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> 
> 
> Jim,
> 
> I took me some time to dig your E-mail too. In order to ease 
> the reading
> I have reformatted the exchanges, placing a J (for Jim) and a D (for
> Denis) in front of the previous exchanges.
> 
> Reading again the E-mail I now understand what the 
> misunderstanding is.
> It is however rather fundamental as I will attempt to explain it
> hereafter.
> 
> J> Denis,
> 
> J> I somehow got lost on this message, my apologies that 
> J> I did not reply sooner.
> 
> J> Comments mixed in below
> 
> J> -----Original Message-----
> J> From: Denis Pinkas [mailto:[email-masked]]
> J> Sent: Monday, May 18, 1998 2:25 PM
> J> To: Jim Schaad (Exchange)
> J> Cc: [email-masked]
> J> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> 
> 
> D> Jim,
> 
> D> Thank you for your detailed response. Unfortunately there are 
> D> several points I do not agree with.  :-(
> 
> D> I am addressing the non-certificate identification issues 
> D> in this message.
> D> These issues will be addressed separately to keep the 
> D> threads separate
> 
> D>-----Original Message-----
> 
> D>From: Denis Pinkas [mailto:[email-masked]]
> 
> D>A. In section 2. Re-issue of Certificate.
> 
> D> Either I do not see this as a problem or I do not understand 
> D> your problem.
> D> Cross certificates can be revoked. So if the CA wishes to 
> D> re-issue a certificate it simply revokes it before and 
> D> may use different policies in the new issued certificate. 
> D> Where is the problem ?
> 
> 
> J> I did not make myself clear here.  The attack that I was 
> J> looking at on this point had to do with a CA re-issuing 
> J> its own root certificate.
> 
> D> There is an important issue here. This question was raised 
> D> in a recent E-mail from Francois Rousseau. Unless the security 
> D> policy to be applied for verification is itself signed, 
> D> you are open to many attacks, as the one you mention. 
> 
> I was referring to an E-mail from Francois Rousseau 
> ([email-masked])
> from Thu, 30 Apr 1998 with the following subject : Reference to
> Applicable Attribute Certificate(s) within the CMS.
> 
> The sentences I was referring were at the end of his E-mail:
> 
> " (...) This implies there are currently no mean within CMS 
> to convey to the Verifier which Attribute Certificate MUST be 
> used for each Claimant.
> 
> Should not considerations be given within CMS to use the
> authenticatedAttributes field under each per-signer SignerInfo 
> to specify through new CRITICAL attributes, the applicable 
> claimant's Attribute Certificate and the applicable Control policy 
> that the Verifier MUST use to validate the message?"
> 
> ... "and the applicable Control policy that the Verifier MUST use to
> validate the message" is the important sentence.
> 
> The "applicable Control policy" (that I called simply 
> "security policy")
> defines the rules to be applied for the verification of the digital
> signatures. That security policy will indicate what are the 
> various root
> CAs that are usable and the name constraints that are to be used for
> each of them.
> 
> D> So a security policy identifier (e.g. an OID) should be
> D> part of the signature. If you have a single trust point 
> D> (which is a very specific case) then you could replace the OID 
> D> by a self-signed certificate. Under that case there will be no 
> D> ambiguity about what to use for verification. Note the IDUP, 
> D> which is an API covering non-repudiation already incorportates 
> D> this major concept.
> 
> > I just got very lost reading the previous paragraph.  
> > I think the issues I don't understand boil down to:
> 
> > 1.  Which message are you refering to?  The ones that I can find 
> > deal with attribute certificates and not with CA certificates.  
> > I am afraid that I don't see the connection between these issues.
> 
> See the reference above.
> 
> > 2.  What security policy identifier are you refering to here?  
> > If the security policy is that of the message, it is already signed
> > in its own attribute.  If the security policy is part of the 
> > certificate, it should also be signed under the certificate 
> signature.
> 
> I am referring a security policy that is a signed attribute, but not
> part of the message. 
> 
> > 3.  If you are refering to the ability to verify the verification 
> > code (or at least some input data to it) then I would have to say 
> > that I think this is beyond the scope of the problems that I can 
> > even hope to address in an IETF draft as it would be very 
> > implementation dependent.
> 
> I had not envisaged that meaning. :-)
> 
> J> The change I would expect would be in the CPS however I will 
> J> give and example of name constraints here.  If a CA re-issues 
> J> its CA certificate and specifically constrains my certificate 
> J> out of the set of legal DNs, I may sign my message with a valid 
> J> chain (I have the original root certificate) and you may fail 
> J> the validation because you have the new root certificate.
> 
> D> The threat you mention can be countered by the inclusion of 
> D> the security policy as an "authenticated attribute"; I would 
> D> prefer to call it a "signed attribute" :-)
> 
> > How does the inclusion of a security policy (I assume in the 
> > SignerInfo object being verified) alter the fact that we have 
> > different root certificates and thus different input to the 
> > problem of doing the certificate validation?  Even operating 
> > under the same security policy (unless the policy itself has the 
> > roots hard coded into it) would not address this issue.  
> > I don't expect most security policies to restrict the set of roots 
> > to be used in certificate validation.
> 
> If I use a real example, SET (Secure Electronic Transaction) does
> restrict the set of roots to be used in certificate validation. Any
> application should do the same. It is not the choice of the 
> verifier to
> use the roots of its choice, but the choice of the signer. A "simple"
> way to indicate its choice is to use a security policy OID. Now the
> choice may or may not be acceptable to the verifier. If not, then the
> signature is simply discarded.
> 
> J> What I was trying to point out in the second paragraph is 
> J> that a similar problem already exists with cross-certificates.
> J> When CA2 issues the cross certificate for CA1, it may add or 
> J> remove extensions from the CA1 certificate.  Thus it could put 
> J> in the same name constraints extension that I postulated above 
> J> on the CA root certificate re-issue.  
> 
> J> This means that my signature was valid when I sent it, as 
> J> I trusted the CA1 root directly, but you will fail the signature 
> J> validation as the name constrained imposed by CA2 on CA1 causes 
> J> my certificate to be invalid.
> 
> We are tackling the heart of the problem here. What you would 
> like is, I
> believe, the following: a signature that was valid when it was sent
> should be recognized as valid at the time it is received. 
> 
> The bad news is the following : when using only the current
> specification this is quite impossible. :-(
> 
> The good news is the following : when using S/MIME in 
> combination with a
> time stamp from a Time Stamping Authority, this is possible.
> 
> The reason is fairly simple: if you want the same result, you 
> should use
> the same input parameters to the verification process, i.e. the
> parameters that were valid at the time of the signature. So you must
> securely know the time of the signature, hence the reason for the time
> stamp. If any certificate is changing, this is not a problem since you
> will use what was valid at the time of the signature. Without a time
> stamp you may (and will) get spurious results.
> 
> I now see some value to consider different levels: at the level 3, 
> we could cover the case of a verification without a time stamp.
> At a level 4, we could consider the case of a verification with 
> an additional time stamp.
> 
> D> For the case of CAs which are "below" this is not a problem as 
> D> I mentionned it in my previous E-mail.
> 
> D> The discussion and explanations about the need for the hash
> D> mentioned in the discussion above should be added.
> 
> J> I am waiting for a consensus to develop on this issue 
> J> before making this change.
> 
> D> Well, since your paper is supposed to be a discussion 
> paper, I do not
> D> see why we should not address the problem there. There is not yet a
> D> consensus on the other issues.  :-)
> 
> 
> D> C. In the Open Issues section. The inclusion for a complete
> D> chain of certificates would have some advantages (I do not claim
> D> it is necessary in all the cases). It allows the signer to specify
> D> its own belief for the verification process. If the verifier wants 
> D> to use a different chain, this is fine for him, but then under his 
> D> own risk.
> 
> D> The "rollover" argument is not a problem since anyway it is
> D> important to capture all the certificates that were valid 
> D> at the time the signature was created, but this is a minor detail.
> 
> In fact, I know believe that this is major argument !
> 
> J> I agree that this might be a useful extension to have, but 
> J> I would argue that this is not the correct attribute to place 
> J> that information in. This attribute will change the validity of 
> J> the signature based on the match or non-match of the specified
> J> certificate to the certificate used in the signature validation 
> J> process.
> 
> But this is a way to get stable and non ambiguous results.
> 
> D> It only changes the validity of the signature based on which 
> D> security policy you are using.
> 
> D> Finally I could not understand the issue expressed in the
> D> last paragraph of "B. Open Issues". A different wording 
> D> might be necessary.
> 
> J> I will attempt to express the issue again in new wording 
> J> and hope that I do better this time.
> 
> J> From a pure cryptographic (i.e. mathematical sense) a 
> J> signature is created by using a private key and verified by 
> J> using a public key. In this world there is no such thing as 
> J> a certificate and one does not worry about how the public key 
> J> is obtained.
> 
> D> Correct.
> 
> J> In the next level of abstraction up, a certificate comes 
> J> into being.  
> 
> D> More generally I would say a way to relate the public key to 
> D> the identity of the signer. For this a certificate may or may 
> D> not be used.
> 
> J> All a certificate provides from a mathematical sense is a way 
> J> of providing a public key in a cryptographically secure manner.
> J> In this sense it does not matter what certificate one uses to find
> J> the public key to verify a signature as long as one finds some
> J> certificate with the correct public key.
> 
> D> I respectfully disagree with you on this issue. I would 
> take again my
> D> favorite example with a CA from the Barracuda Banana Republic. This
> CA
> D> for 1.000 $ may be willing to issue me a certificate with the same
> D> public key value like yours (without performing POP, ie. Proof op
> D> Private key possession). If that CA appears to be in your 
> trust tree,
> D> then you may be fooled. So it does matter that the signer indicates
> D> which certificate shall be used for verification. It is not *any*.
> 
> > You are correct in one sense and incorrect in another.  You 
> are quite
> > correct that I will be fooled into believing that you did the 
> > signature since the public keys are the same.  From a pure 
> > mathematical standpoint there is no way for me to know which 
> > certificate is correct.  It is from the addition of a protocol that 
> > I understand some certificates are trusted and others are 
> not trusted.
> > There is no mathematical basis to make this determination.
> 
> When the reference of the certificate to be used is a signed 
> attribute 
> placed by the signer, there is no ambiguity. 
> 
> J> This means that if I have two certificates, both containing 
> J> the same public key, it does not matter which of these 
> certificates 
> J> you use in validating the signature as both are equally viable 
> J> from a mathematical sense.
> 
> D> No. it does matter instead. As I do not agree on your 
> second level, I
> D> also respectfully disagree with the next level.
> 
> > How is the signature different on a mathematics level?  
> 
> The verification process is not purely mathematical. You MUST also 
> verify that the certificate that you use for the verification is 
> the one indicated in the signed attributes.
> 
> > As you say I will verify using the phony signature.  
> > The step you want to place is added in the next level.
> 
> J> The final level of abstraction that I add is the level of 
> J> protocol of signing.  At this level I care about which of the 
> J> different certificates I use in the validation process as 
> J> certificates carry different information about the signer and 
> J> the ways in which signing may occur.  
> 
> J> This information is carried as extension on the certificate and 
> J> these need to be validated as part of the process of validating 
> J> the original signature.
> 
> Which extension(s) are you refering to ? 
> 
> J> Those people who don't go all the way to the final protocol 
> J> level we are providing don't like what this draft does, so far 
> J> I have found two sets of people who tend to stop at level 2 and 
> J> not go to level 3.  
> 
> J> The PGP community and those people who come out of that community 
> J> live at level two. I believe that this is because they don't have 
> J> the authoritative CA to do the binding and add additional protocol
> J> information.  
> 
> Reading again your previous exchanges, I am confused about your 
> sentence "have the authoritative CA to do the binding and add 
> additional protocol information". 
> 
> 
> J> They tend to be individuals who make statements only 
> J> about identity and it does not matter what identity you use as 
> J> they mean the same person (as the private key must be the same).
> 
> J> The second set is represented by Dave Solo who state that
> J> everything which needs to be an important part of the signature 
> J> ought to be in the document being signed and the extra information 
> J> provided by the certificate extensions is of less importance that 
> J> what is in the document.
> 
> Maybe I am close to Dave Solo, but in a third set. :-)
> 
> I would state that everything which needs to be an important part 
> of the signature ought to be in the signed attributes in addition 
> to the document being signed. This includes the security policy 
> to be used by the verifier and an unambiguous reference to the 
> certificate of the signer to be used by the verifier. The extra 
> information provided by the certificate extensions cannot overide 
> the previous signed attributes.
> 
> Denis
> 
> 
> --
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
> 

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-06.txt
Date: Tue, 07 Jul 1998 10:51:39 -0400
Sender: [email-masked]

--NextPart

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-06.txt
	Pages		: 41
	Date		: 06-Jul-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-06.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-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 07 Jul 1998 08:36:52 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-smime-cms-06.txt
Sender: [email-masked]

S/MIME WG members:

This version includes "fixes" for all of the problems that were raised with
draft-ietf-smime-cms-05.txt.  I hope that these "fixes" do not raise new
issues.  The biggest change is the support for key agreement (e.g.,
Diffie-Hellman) when the originator uses an ephemeral public key without
certified public key.

Sestion 12 remains a place holder.  I hope to complete section 12 prior to
the IETF meeting in August.

Russ

>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-06.txt
>	Pages		: 41
>	Date		: 02-Jul-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/>.

Date: Tue, 07 Jul 1998 08:08:47 -0400
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: S/MIME WG Meeting at 42nd IETF-CHICAGO, IL
Sender: [email-masked]

S/MIME WG Memebers:

The S/MIME WG will meet on Wednesday, 26 August 1998 from 9:00 to 11:30.

Please send me requests for time on the agenda ASAP.

Russ

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-smime-cms-06.txt
Date: Mon, 06 Jul 1998 14:06:50 -0400
Sender: [email-masked]

--NextPart

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-06.txt
	Pages		: 41
	Date		: 02-Jul-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-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-06.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-06.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.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-cms-06.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-cms-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 06 Jul 1998 17:34:34 -0700
From: Denis Pinkas <[email-masked]>
Reply-To: [email-masked]
Organization: Bull
To: "Jim Schaad (Exchange)" <[email-masked]>
CC: [email-masked]
Subject: Re: SigningCertificate and IssuerAndSerialNumber.
Sender: [email-masked]

Jim,

I took me some time to dig your E-mail too. In order to ease the reading
I have reformatted the exchanges, placing a J (for Jim) and a D (for
Denis) in front of the previous exchanges.

Reading again the E-mail I now understand what the misunderstanding is.
It is however rather fundamental as I will attempt to explain it
hereafter.

J> Denis,

J> I somehow got lost on this message, my apologies that 
J> I did not reply sooner.

J> Comments mixed in below

J> -----Original Message-----
J> From: Denis Pinkas [mailto:[email-masked]]
J> Sent: Monday, May 18, 1998 2:25 PM
J> To: Jim Schaad (Exchange)
J> Cc: [email-masked]
J> Subject: Re: SigningCertificate and IssuerAndSerialNumber.

D> Jim,

D> Thank you for your detailed response. Unfortunately there are 
D> several points I do not agree with.  :-(

D> I am addressing the non-certificate identification issues 
D> in this message.
D> These issues will be addressed separately to keep the 
D> threads separate

D>-----Original Message-----

D>From: Denis Pinkas [mailto:[email-masked]]

D>A. In section 2. Re-issue of Certificate.

D> Either I do not see this as a problem or I do not understand 
D> your problem.
D> Cross certificates can be revoked. So if the CA wishes to 
D> re-issue a certificate it simply revokes it before and 
D> may use different policies in the new issued certificate. 
D> Where is the problem ?

J> I did not make myself clear here.  The attack that I was 
J> looking at on this point had to do with a CA re-issuing 
J> its own root certificate.

D> There is an important issue here. This question was raised 
D> in a recent E-mail from Francois Rousseau. Unless the security 
D> policy to be applied for verification is itself signed, 
D> you are open to many attacks, as the one you mention. 

I was referring to an E-mail from Francois Rousseau ([email-masked])
from Thu, 30 Apr 1998 with the following subject : Reference to
Applicable Attribute Certificate(s) within the CMS.

The sentences I was referring were at the end of his E-mail:

" (...) This implies there are currently no mean within CMS 
to convey to the Verifier which Attribute Certificate MUST be 
used for each Claimant.

Should not considerations be given within CMS to use the
authenticatedAttributes field under each per-signer SignerInfo 
to specify through new CRITICAL attributes, the applicable 
claimant's Attribute Certificate and the applicable Control policy 
that the Verifier MUST use to validate the message?"

... "and the applicable Control policy that the Verifier MUST use to
validate the message" is the important sentence.

The "applicable Control policy" (that I called simply "security policy")
defines the rules to be applied for the verification of the digital
signatures. That security policy will indicate what are the various root
CAs that are usable and the name constraints that are to be used for
each of them.

D> So a security policy identifier (e.g. an OID) should be
D> part of the signature. If you have a single trust point 
D> (which is a very specific case) then you could replace the OID 
D> by a self-signed certificate. Under that case there will be no 
D> ambiguity about what to use for verification. Note the IDUP, 
D> which is an API covering non-repudiation already incorportates 
D> this major concept.

> I just got very lost reading the previous paragraph.  
> I think the issues I don't understand boil down to:

> 1.  Which message are you refering to?  The ones that I can find 
> deal with attribute certificates and not with CA certificates.  
> I am afraid that I don't see the connection between these issues.

See the reference above.

> 2.  What security policy identifier are you refering to here?  
> If the security policy is that of the message, it is already signed
> in its own attribute.  If the security policy is part of the 
> certificate, it should also be signed under the certificate signature.

I am referring a security policy that is a signed attribute, but not
part of the message. 

> 3.  If you are refering to the ability to verify the verification 
> code (or at least some input data to it) then I would have to say 
> that I think this is beyond the scope of the problems that I can 
> even hope to address in an IETF draft as it would be very 
> implementation dependent.

I had not envisaged that meaning. :-)

J> The change I would expect would be in the CPS however I will 
J> give and example of name constraints here.  If a CA re-issues 
J> its CA certificate and specifically constrains my certificate 
J> out of the set of legal DNs, I may sign my message with a valid 
J> chain (I have the original root certificate) and you may fail 
J> the validation because you have the new root certificate.

D> The threat you mention can be countered by the inclusion of 
D> the security policy as an "authenticated attribute"; I would 
D> prefer to call it a "signed attribute" :-)

> How does the inclusion of a security policy (I assume in the 
> SignerInfo object being verified) alter the fact that we have 
> different root certificates and thus different input to the 
> problem of doing the certificate validation?  Even operating 
> under the same security policy (unless the policy itself has the 
> roots hard coded into it) would not address this issue.  
> I don't expect most security policies to restrict the set of roots 
> to be used in certificate validation.

If I use a real example, SET (Secure Electronic Transaction) does
restrict the set of roots to be used in certificate validation. Any
application should do the same. It is not the choice of the verifier to
use the roots of its choice, but the choice of the signer. A "simple"
way to indicate its choice is to use a security policy OID. Now the
choice may or may not be acceptable to the verifier. If not, then the
signature is simply discarded.

J> What I was trying to point out in the second paragraph is 
J> that a similar problem already exists with cross-certificates.
J> When CA2 issues the cross certificate for CA1, it may add or 
J> remove extensions from the CA1 certificate.  Thus it could put 
J> in the same name constraints extension that I postulated above 
J> on the CA root certificate re-issue.  

J> This means that my signature was valid when I sent it, as 
J> I trusted the CA1 root directly, but you will fail the signature 
J> validation as the name constrained imposed by CA2 on CA1 causes 
J> my certificate to be invalid.

We are tackling the heart of the problem here. What you would like is, I
believe, the following: a signature that was valid when it was sent
should be recognized as valid at the time it is received. 

The bad news is the following : when using only the current
specification this is quite impossible. :-(

The good news is the following : when using S/MIME in combination with a
time stamp from a Time Stamping Authority, this is possible.

The reason is fairly simple: if you want the same result, you should use
the same input parameters to the verification process, i.e. the
parameters that were valid at the time of the signature. So you must
securely know the time of the signature, hence the reason for the time
stamp. If any certificate is changing, this is not a problem since you
will use what was valid at the time of the signature. Without a time
stamp you may (and will) get spurious results.

I now see some value to consider different levels: at the level 3, 
we could cover the case of a verification without a time stamp.
At a level 4, we could consider the case of a verification with 
an additional time stamp.

D> For the case of CAs which are "below" this is not a problem as 
D> I mentionned it in my previous E-mail.

D> The discussion and explanations about the need for the hash
D> mentioned in the discussion above should be added.

J> I am waiting for a consensus to develop on this issue 
J> before making this change.

D> Well, since your paper is supposed to be a discussion paper, I do not
D> see why we should not address the problem there. There is not yet a
D> consensus on the other issues.  :-)

D> C. In the Open Issues section. The inclusion for a complete
D> chain of certificates would have some advantages (I do not claim
D> it is necessary in all the cases). It allows the signer to specify
D> its own belief for the verification process. If the verifier wants 
D> to use a different chain, this is fine for him, but then under his 
D> own risk.

D> The "rollover" argument is not a problem since anyway it is
D> important to capture all the certificates that were valid 
D> at the time the signature was created, but this is a minor detail.

In fact, I know believe that this is major argument !

J> I agree that this might be a useful extension to have, but 
J> I would argue that this is not the correct attribute to place 
J> that information in. This attribute will change the validity of 
J> the signature based on the match or non-match of the specified
J> certificate to the certificate used in the signature validation 
J> process.

But this is a way to get stable and non ambiguous results.

D> It only changes the validity of the signature based on which 
D> security policy you are using.

D> Finally I could not understand the issue expressed in the
D> last paragraph of "B. Open Issues". A different wording 
D> might be necessary.

J> I will attempt to express the issue again in new wording 
J> and hope that I do better this time.

J> From a pure cryptographic (i.e. mathematical sense) a 
J> signature is created by using a private key and verified by 
J> using a public key. In this world there is no such thing as 
J> a certificate and one does not worry about how the public key 
J> is obtained.

D> Correct.

J> In the next level of abstraction up, a certificate comes 
J> into being.  

D> More generally I would say a way to relate the public key to 
D> the identity of the signer. For this a certificate may or may 
D> not be used.

J> All a certificate provides from a mathematical sense is a way 
J> of providing a public key in a cryptographically secure manner.
J> In this sense it does not matter what certificate one uses to find
J> the public key to verify a signature as long as one finds some
J> certificate with the correct public key.

D> I respectfully disagree with you on this issue. I would take again my
D> favorite example with a CA from the Barracuda Banana Republic. This
CA
D> for 1.000 $ may be willing to issue me a certificate with the same
D> public key value like yours (without performing POP, ie. Proof op
D> Private key possession). If that CA appears to be in your trust tree,
D> then you may be fooled. So it does matter that the signer indicates
D> which certificate shall be used for verification. It is not *any*.

> You are correct in one sense and incorrect in another.  You are quite
> correct that I will be fooled into believing that you did the 
> signature since the public keys are the same.  From a pure 
> mathematical standpoint there is no way for me to know which 
> certificate is correct.  It is from the addition of a protocol that 
> I understand some certificates are trusted and others are not trusted.
> There is no mathematical basis to make this determination.

When the reference of the certificate to be used is a signed attribute 
placed by the signer, there is no ambiguity. 

J> This means that if I have two certificates, both containing 
J> the same public key, it does not matter which of these certificates 
J> you use in validating the signature as both are equally viable 
J> from a mathematical sense.

D> No. it does matter instead. As I do not agree on your second level, I
D> also respectfully disagree with the next level.

> How is the signature different on a mathematics level?  

The verification process is not purely mathematical. You MUST also 
verify that the certificate that you use for the verification is 
the one indicated in the signed attributes.

> As you say I will verify using the phony signature.  
> The step you want to place is added in the next level.

J> The final level of abstraction that I add is the level of 
J> protocol of signing.  At this level I care about which of the 
J> different certificates I use in the validation process as 
J> certificates carry different information about the signer and 
J> the ways in which signing may occur.  

J> This information is carried as extension on the certificate and 
J> these need to be validated as part of the process of validating 
J> the original signature.

Which extension(s) are you refering to ? 

J> Those people who don't go all the way to the final protocol 
J> level we are providing don't like what this draft does, so far 
J> I have found two sets of people who tend to stop at level 2 and 
J> not go to level 3.  

J> The PGP community and those people who come out of that community 
J> live at level two. I believe that this is because they don't have 
J> the authoritative CA to do the binding and add additional protocol
J> information.  

Reading again your previous exchanges, I am confused about your 
sentence "have the authoritative CA to do the binding and add 
additional protocol information". 

J> They tend to be individuals who make statements only 
J> about identity and it does not matter what identity you use as 
J> they mean the same person (as the private key must be the same).

J> The second set is represented by Dave Solo who state that
J> everything which needs to be an important part of the signature 
J> ought to be in the document being signed and the extra information 
J> provided by the certificate extensions is of less importance that 
J> what is in the document.

Maybe I am close to Dave Solo, but in a third set. :-)

I would state that everything which needs to be an important part 
of the signature ought to be in the signed attributes in addition 
to the document being signed. This includes the security policy 
to be used by the verifier and an unambiguous reference to the 
certificate of the signer to be used by the verifier. The extra 
information provided by the certificate extensions cannot overide 
the previous signed attributes.

Denis

--
      Denis Pinkas     Bull S.A.          mailto:[email-masked]
      Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
      78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21

Date: Mon, 06 Jul 1998 11:20:58 -0400
To: [email-masked]
From: Francois Rousseau <[email-masked]>
Subject: Re: New version of CMS available
Sender: [email-masked]

Russ,

Sec 6, Sec 6.2 and Sec 6.4 should indicate if the different key management
techniques can be used in combination for the various recipients and/or a
single recipient of an encrypted content. Reading Sec 6, it does not seem
to preclude either approach.

Sec 6.1, both the OriginatorInfo "certs" field and the SignedData
"certificates" field from Sec 5.1 are defined as a "CertificateSet" type,
which is defined at Sec 10.2.3 as a set of "CertificateChoices" type
allowing PKCS #6 extended certificates, X.509 certificates and X.509
attribute certificates. Although attribute certificates can be present in
the "certificates" field if the value of the SignedData "version" field is
set to 3, attribute certificates are not mentioned in the definition of the
OriginatorInfo "certs" field at Sec 6.1. Does this mean that the
"EnvelopedData" and the "AuthenticatedData" content types can NOT contain
attribute certificates in their OriginatorInfo "certs" field?

Sec 6.1, under the definition of the "contentEncryptionAlgorithm" field, I
suggest that the last sentence should read "The same algorithm and
content-encryption key are used for all recipients".

Sec 10.2.1 defines the "CertificateRevocationLists" type that appears under
the "crls" field of the "SignedData", the "EnvelopedData" and the
"AuthenticatedData" content types, as a set of "CertificateList", which the
definition is imported from X.509. In addition to the Certificate
Revocation List (CRL) attribute type, which is mentioned throughout the CMS
document, three other attribute types using the syntax of CertificateList
are also defined in X.509 (i.e. Authority Revocation List (ARL), Delta
Revocation List and Attribute Certificate Revocation List), however they
are not mentioned in CMS. Are these other attribute types not also allowed
in the "crls" field of CMS? Note that PKIX Part 1 currently only mentions
the CRL and Delta CRL attribute types. I suggest that an enlarged
definition of CRL be added at Sec 10.2.1 to cover all types.

Francois Rousseau

From: Tom Kung <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>
Cc: [email-masked]
Subject: RE: New version of CMS available
Date: Fri, 3 Jul 1998 14:06:35 -0400 
Sender: [email-masked]

Goodays,

There appears to be two definitions for RecipientIdentifier in CMS06:

 RecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     subjectKeyIdentifier [0] SubjectKeyIdentifier }

AND

 RecipientIdentifier ::= CHOICE {
     issuerAndSerialNumber IssuerAndSerialNumber,
     rKeyId [0] IMPLICIT RecipientKeyIdentifier }

Tom.
> ----------
> From: 	Paul Hoffman / IMC[SMTP:[email-masked]]
> Sent: 	Friday, July 03, 1998 11:37 AM
> To: 	[email-masked]
> Subject: 	New version of CMS available
> 
> Draft -06 of CMS is now in the official drafts archives and can also be
> found at <http://www.imc.org/draft-ietf-smime-cms>.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 

Date: Fri, 03 Jul 1998 08:37:36 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: New version of CMS available
Sender: [email-masked]

Draft -06 of CMS is now in the official drafts archives and can also be
found at <http://www.imc.org/draft-ietf-smime-cms>.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 02 Jul 1998 18:19:03 +0100
From: Dr Stephen Henson <[email-masked]>
Reply-To: [email-masked]
Organization: Dr S N Henson
To: Russ Housley <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Subject: Re: CMS: key wrapping standard.
Sender: [email-masked]

Russ Housley wrote:
> 
> Steve:
> 
> The structure of the PKCS#1 key block used to encrypt a content-encryption
> key in a recipient public key offers some integrity protection.  Other
> techniques have been defined that offer even more integrity.
> 
> The recipient of such a block has some assurance that the unwrapped key is
> the one used by the originator.  Thus, it is unlikely that the recipient
> will spend time decrypting the message content if an attacker altered the
> wrapped content-encryption key.
> 

Can you be more specific about the integrity checks for the key
transport case? 

I may well be missing something here but isn't it possible for an
attacker to just pick a random key (a bogus content encryption key),
encrypt that using the recipients public key and PKCS#1 rules?

This would then appear to be a similar attack to the DH one you are
trying to prevent. The recipient decrypts the block: it decrypts fine
and then uses the bogus content encryption key only to find a problem
when the message decrypts as garbage.

This may require that the attacker know the recipients public key: so I
suppose in that sense it is a little harder than the DH one.
Alternatively they can just copy the relevant sections of the structure
from another message to the same recipient.

My only real concern with the proposal was that it may indeed stop one
attack but there so many other trivial attacks that I can't see the
point. The essentially anonymous nature of such messages makes such
attacks inevitable and, compared to the alternative of implicit or
explicit signing of everything, desirable.

I have only one other objection to the wrapping method you are
suggesting: that it should be coded in ASN1 rather than raw data.

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

Date: Thu, 02 Jul 1998 09:33:55 -0700
To: William Ottaway <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

>>A countersignature can be created without the countersigner knowing the
>>original content. The recipient who is validating the countersignature has
>>no way of knowing if the signature that was countersigned is valid without
>>checking that signature as well. Thus, a recipient who can validate a
>>countersignature but cannot validate the original signature must not infer
>>that the content that was signed has not been modified, and must not infer
>>that the original signer actually had access to the content.

>Shouldn't the last sentence read "..., and must not infer that the counter
>signer actually had access to the content."? Or, are you thinking about a
>scenario where a counter signature is bound to another counter signature?

Er, yes. Your changes is what I ment.

>I still question the usefulness of a counter signature.

It allows for the countersigner to say "I saw this signature and assure the
recipient that the signature I saw was xyz." It is not meant to say anything
about what the signature was over, but that the signature arrived to the
recipient unmodified. It also allows the countersigner to toss in lots of
interesting attributes about the original signature.

--Paul Hoffman, Director
--Internet Mail Consortium

Date: Thu, 02 Jul 1998 12:14:08 +0100
To: [email-masked]
From: William Ottaway <[email-masked]>
Subject: Re: Countersignature within CMS
Cc: [email-masked]
Sender: [email-masked]

At 08:35 30/06/98 -0700, you wrote:
>At 09:41 AM 6/30/98 +0100, William Ottaway wrote:
>>I could propose a paragraph but I would like to hold off for a while. We
>>will be releasing an internet draft on domain security services using
>>S/MIME within the next couple of weeks and I want to take on board the
>>comments it will raise before addressing the Countersignature issue.
>
>Well, I would rather not delay the S/MIME work, so I'll propose one. Anyone
>should feel free to comment on this.
>
>A countersignature can be created without the countersigner knowing the
>original content. The recipient who is validating the countersignature has
>no way of knowing if the signature that was countersigned is valid without
>checking that signature as well. Thus, a recipient who can validate a
>countersignature but cannot validate the original signature must not infer
>that the content that was signed has not been modified, and must not infer
>that the original signer actually had access to the content.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium

Paul,

Thankyou for your contribution to this thread.

Shouldn't the last sentence read "..., and must not infer that the counter
signer actually had access to the content."? Or, are you thinking about a
scenario where a counter signature is bound to another counter signature?

If the former then your text is acceptable in that it clearly states to the
reader the implications of using a counter signature. If the latter then I
don't accept the proposed text because the last sentence is confusing.

I still question the usefulness of a counter signature. If a counter
signature is used then the recipient must be able to verify the originators
signature. In the less than ideal world I see there being disjoint PKIs
where it would be very common for a recipient not to be able to verify the
originators signature, but may be able to verify a counter signing
signature. If the recipient knew that the counter signer had already
verified the signature it is signing then the recipient would be in a
position to accept the message. 

I hope that this scenario will be resolved in a manner acceptable to this
working group within our internet draft on domain security services using
S/MIME, to be released shortly.

For the time being I am willing to accept the additional paragraph, as long
as the last sentence is changed as stated above. But there may be some
repercussions when our draft is released.

Bill.  
_____________________________________________________________________
William Ottaway,             Tel: +44 (0)1684 894079
DERA Malvern,                Fax: +44 (0)1684 896113
St. Andrews Road,            email: [email-masked]
Malvern,
Worcs, WR14 3PS
UK

From: "Jim Schaad (Exchange)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: [email-masked]
Subject: RE: SigningCertificate and IssuerAndSerialNumber.
Date: Wed, 1 Jul 1998 12:01:50 -0700 
Sender: [email-masked]

Denis,
I somehow got lost on this message, my apologies that I did not reply
sooner.

Comments mixed in below

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Monday, May 18, 1998 2:25 PM
> To: Jim Schaad (Exchange)
> Cc: [email-masked]
> Subject: Re: SigningCertificate and IssuerAndSerialNumber.
> 
> 
> Jim,
> 
> Thank you for your detailed response. Unfortunately there are several
> points I do not agree with.  :-(
> 
> > I am addressing the non-certificate identification issues 
> in this message.
> > These issues will be addressed separately to keep the 
> threads separate
> > 
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[email-masked]]
> > >
> > > A. In section 2. Re-issue of Certificate.
> > >
> > > Either I do not see this as a problem or I do not understand your
> > > problem.
> > > Cross certificates can be revoked. So if the CA wishes to 
> re-issue a
> > > certificate it simply revokes it before and may use 
> different policies
> > > in the new issued certificate. Where is the problem ?
> > >
> > 
> > I did not make myself clear here.  The attack that I was 
> looking at on this
> > point had to do with a CA re-issuing its own root certificate.  
> 
> There is an important issue here. This question was raised in a recent
> E-mail from Francois Rousseau. Unless the security policy to 
> be applied
> for verification is itself signed, you are open to many 
> attacks, as the
> one you mention. So a security policy identifier (e.g. an 
> OID) should be
> part of the signature. If you have a single trust point 
> (which is a very
> specific case) then you could replace the OID by a self-signed
> certificate. Under that case there will be no ambiguity about what to
> use for verification. Note the IDUP, which is an API covering
> non-repudiation already incorportates this major concept.

I just got very lost reading the previous paragraph.  I think the issues I
don't understand boil down to:
1.  Which message are you refering to?  The ones that I can find deal with
attribute certificates and not with CA certificates.  I am afraid that I
don't see the connection between these issues.

2.  What security policy identifier are you refering to here?  If the
security policy is that of the message, it is already signed in its own
attribute.  If the security policy is part of the certificate, it should
also be signed under the certificate signature.

3.  If you are refering to the ability to verify the verification code (or
atleast some input data to it) then I would have to say that I think this is
beyond the scope of the problems that I can even hope to address in an IETF
draft as it would be very implementation dependent.

> 
> > The change I
> > would expect would be in the CPS however I will give and 
> example of name
> > constraints here.  If a CA re-issues its CA certificate and 
> specifically
> > constrains my certificate out of the set of legal DNs, I 
> may sign my message
> > with a valid chain (I have the original root certificate) 
> and you may fail
> > the validation because you have the new root certificate.
> 
> The threat you mention can be countered by the inclusion of 
> the security
> policy as an "authenticated attribute"; I would prefer to call it a
> "signed attribute" :-)

How does the inclusion of a security policy (I assume in the SignerInfo
object being verified) alter the fact that we have different root
certificates and thus different input to the problem of doing the
certificate validation?  Even operating under the same security policy
(unless the policy itself has the roots hard coded into it) would not
address this issue.  I don't expect most security policies to restrict the
set of roots to be used in certificate validation.
> 
> > What I was trying to point out in the second paragraph is 
> that a similar
> > problem already exists with cross-certificates.  When CA2 
> issues the cross
> > certificate for CA1, it may add or remove extensions from the CA1
> > certificate.  Thus it could put in the same name 
> constraints extension that
> > I postulated above on the CA root certificate re-issue.  
> This means that my
> > signature was valid when I sent it, as I trusted the CA1 
> root directly, but
> > you will fail the signature validation as the name 
> constrained imposed by
> > CA2 on CA1 causes my certificate to be invalid.
> 
> For the case of CAs which are "below" this is not a problem as I
> mentionned it in my previous E-mail.
> 
> > > B. The discussion and explanations about the need for the hash
> > > mentioned in the discussion above should be added.
> > 
> > I am waiting for a consensus to develop on this issue 
> before making this
> > change.
> 
> Well, since your paper is supposed to be a discussion paper, I do not
> see why we should not address the problem there. There is not yet a
> consensus on the other issues.  :-)
> 
> 
> > > C. In the Open Issues section. The inclusion for a 
> complete chain of
> > > certificates would have some advantages (I do not claim it is
> > > necessary
> > > in all the cases). It allows the signer to specify its 
> own belief for
> > > the verification process. If the verifier wants to use a different
> > > chain, this is fine for him, but then under his own risk.
> > >
> > > The "rollover" argument is not a problem since anyway it is
> > > important to
> > > capture all the certificates that were valid at the time 
> the signature
> > > was created, but this is a minor detail.
> > 
> > I agree that this might be a useful extension to have, but 
> I would argue
> > that this is not the correct attribute to place that 
> information in.  This
> > attribute will change the validity of the signature based 
> on the match or
> > non-match of the specified certificate to the certificate 
> used in the
> > signature validation process.
> 
> It only changes the validity of the signature based on which security
> policy you are using.
> 
> > > Finally I could not understand the issue expressed in the
> > > last paragraph
> > > of "B. Open Issues". A different wording might be necessary.
> > 
> > I will attempt to express the issue again in new wording 
> and hope that I do
> > better this time.
> > 
> > From a pure cryptographic (i.e. mathematical sense) a 
> signature is created
> > by using a private key and verified by using a public key.  
> In this world
> > there is no such thing as a certificate and one does not 
> worry about how the
> > public key is obtained.
> 
> Correct.
> 
> > In the next level of abstraction up, a certificate comes 
> into being.  
> 
> More generally I would say a way to relate the public key to the
> identity of the signer. For this a certificate may or mot not be used.
> 
> > All a
> > certificate provides from a mathematical sense is a way of 
> providing a
> > public key in a cryptographically secure manner.  In this 
> sense it does not
> > matter what certificate one uses to find the public key to verify a
> > signature as long as one finds some certificate with the 
> correct public key.
> 
> I respectfully disagree with you on this issue. I would take again my
> favorite example with a CA from the Barracuda Banana Republic. This CA
> for 1.000 $ may be willing to issue me a certificate with the same
> public key value like yours (without performing POP, ie. Proof op
> Private key possession). If that CA appears to be in your trust tree,
> then you may be fooled. So it does matter that the signer indicates
> which certificate sahll be used for verification. It is not *any*.

You are correct in one sense and incorrect in another.  You are quite
correct that I will be fooled into believing that you did the signature
since the public keys are the same.  From a pure mathematical standpoint
there is no way for me to know which certificate is correct.  It is from the
addition of a protocol that I understand some certificates are trusted and
others are not trusted.  There is no mathematical basis to make this
determination.

> 
> > This means that if I have two certificates, both containing 
> the same public
> > key, it does not matter which of these certificates you use 
> in validating
> > the signature as both are equally viable from a mathematical sense.
> 
> No. it does matter instead. As I do not agree on your second level, I
> also respectfully disagree with the next level.

How is the signature different on a mathematics level?  As you say I will
verify using the phony signature.  The step you want to place is added in
the next level.

> 
> > The final level of abstraction that I add is the level of 
> protocol of
> > signing.  At this level I care about which of the different 
> certificates I
> > use in the validation process as certificates carry 
> different information
> > about the signer and the ways in which signing may occur.  
> This information
> > is carried as extension on the certificate and these need 
> to be validated as
> > part of the process of validating the original signature.
> > 
> > Those people who don't go all the way to the final protocol 
> level we are
> > providing don't like what this draft does, so far I have 
> found two sets of
> > people who tend to stop at level 2 and not go to level 3.  
> The PGP community
> > and those people who come out of that community live at 
> level two.  I
> > believe that this is because they don't have the 
> authoritative CA to do the
> > binding and add additional protocol information.  They tend to be
> > individuals who make statements only about identity and it 
> does not matter
> > what identity you use as they mean the same person (as the 
> private key must
> > be the same).  The second set is represented by Dave Solo 
> who state that
> > everything which needs to be an important part of the 
> signature ought to be
> > in the document being signed and the extra information 
> provided by the
> > certificate extensions is of less importance that what is 
> in the document.
> 
> > Jim
> 
> Denis
> 
> -- 
>       Denis Pinkas     Bull S.A.          mailto:[email-masked]
>       Rue Jean Jaures  B.P. 68            Phone : 33 - 1 30 80 34 87
>       78340 Les Clayes sous Bois. FRANCE   Fax  : 33 - 1 30 80 33 21
>