RE: Comments on CMC-09

["Jim Schaad (Exchange)" <[e-mail]>]

Comments in line

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[e-mail]]
> Sent: Monday, November 30, 1998 4:45 PM
> To: [e-mail]
> Subject: Re: Comments on CMC-09
> 
> 
> Jim Schaad (Exchange) wrote:
> > 
> > 
> > >
> > > >15.  Section 12.6.2 - You have not modified the key wrap
> > > algorithm to allow
> > > >for arbitrary length RC2 key sources.
> > >
> > > Are you suggesting an explicit length field or something else?
> > >
> > We need to either put in an explicit length field or use a 
> known padding
> > algorithm.  I have no perference on which is used but 
> something along this
> > lines is absolutely required.
> > 
> 
> Speaking personally I'd prefer known padding. Known padding at least
> adds some consistency with the use of symmetric algorithms: 
> they all use
> the "padded" forms.
> 
> If an explicit length parameter is included the logical place 
> to put it
> is in the EncryptedContentInfo structure because its a property of the
> content encryption key. You'd probably then have to make it 
> OPTIONAL for
> v2 compatability only include it when at least one recipient used key
> agreement.

If I was to put it some place I would put it into the encrypted content to
make for minimual changes from now.

> 
> With known padding the following minor change should suffice:
> 
>    1.  Modify the content-encryption key to meet any restrictions on 
>        the key. For example, adjust the parity bits for each DES key
>        comprising a Triple-DES key.
>    2.  Compute a 16-bit key checksum value on the 
> content-encryption key
>        as described above.
>    3.  Generate a 32-bit random salt value.
>    4.  Concatenate the salt, content-encryption key, and key checksum
>        value.
>    5.  Add one block length of randomly generated pad octets. Then pad
>        the result using standard block padding as defined in section
>        6.3.
>    6.  Encrypt the result with the key-encryption algorithm 
> key.  Use an
>        IV with each octet equal to 'A5' hexadecimal.
> 
> The unwrap text is OK as it is but a comment could be added that the
> key length can be checked:
> 
>    5.  If there are restrictions on keys, then check if the
>        content-encryption key meets these restrictions.  For example,
>        check for odd parity of each octet in each DES key 
> that makes up
>        a Triple-DES key and check that the key length is correct.  If 
>        any restriction is incorrect, then there is an error.
> 
> 
This looks fine to me with the change from above.

> > 
> > >
> > > >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV
> > > present and is its
> > > >value the constant 'A5' repeated n time?  The IV was not
> > > present in the
> > > >previous versions but would appear to be present now.  We
> > > still have the IV
> > > >restriction on the key wrap algorithm however.
> > >
> > > There is no field needed to carry the IV as it is always
> > > "A5...A5".  For 3DES,
> > > the parameter is always NULL, and for RC2 the parameter is
> > > the effective key
> > > length.  Where do you see an IV?
> > 
> > OK -- I see where I got confused.  I started with the 
> second paragraph in
> > section 12.3.1 and made a leap of incorrectness into the 
> fact that the
> > KeyWrapAlgorithm was going to be rc2-cbc not 
> id-alg-RC2wrap.  I don't see
> > any clarifications that need to be added to the text, I was 
> just skimming
> > the changes too fast.
> > 
> 
> Just to add a little comment of my own since I suggested part of this.
> My primary reason for this change is to allow algorithms 
> other than RC2
> and 3DES to be used with key agreement. In the case of RC2 and 3DES a
> special algorithm identifier form is defined without the IV. In other
> cases, such as (single) DES the normal algorithm identifier would be
> used which would include an IV: but in this case it would be ignored
> and A5 used.

Yes -- this is what I kind of expected to have happen.  I would however make
an assert that the IV MUST be 'A5' and encoded as such.

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

jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA21284 for ietf-smime-bks; Mon, 30 Nov 1998 17:11:31 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA21280 for <[e-mail]>; Mon, 30 Nov 1998 17:11:30 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGCP87>; Mon, 30 Nov 1998 17:13:58 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B19@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Dr Stephen Henson'" <[e-mail]>, [e-mail]
Subject: RE: Comments on CMC-09
Date: Mon, 30 Nov 1998 17:13:56 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Comments in line

> -----Original Message-----
> From: Dr Stephen Henson [mailto:[e-mail]]
> Sent: Monday, November 30, 1998 4:45 PM
> To: [e-mail]
> Subject: Re: Comments on CMC-09
> 
> 
> Jim Schaad (Exchange) wrote:
> > 
> > 
> > >
> > > >15.  Section 12.6.2 - You have not modified the key wrap
> > > algorithm to allow
> > > >for arbitrary length RC2 key sources.
> > >
> > > Are you suggesting an explicit length field or something else?
> > >
> > We need to either put in an explicit length field or use a 
> known padding
> > algorithm.  I have no perference on which is used but 
> something along this
> > lines is absolutely required.
> > 
> 
> Speaking personally I'd prefer known padding. Known padding at least
> adds some consistency with the use of symmetric algorithms: 
> they all use
> the "padded" forms.
> 
> If an explicit length parameter is included the logical place 
> to put it
> is in the EncryptedContentInfo structure because its a property of the
> content encryption key. You'd probably then have to make it 
> OPTIONAL for
> v2 compatability only include it when at least one recipient used key
> agreement.

If I was to put it some place I would put it into the encrypted content to
make for minimual changes from now.

> 
> With known padding the following minor change should suffice:
> 
>    1.  Modify the content-encryption key to meet any restrictions on 
>        the key. For example, adjust the parity bits for each DES key
>        comprising a Triple-DES key.
>    2.  Compute a 16-bit key checksum value on the 
> content-encryption key
>        as described above.
>    3.  Generate a 32-bit random salt value.
>    4.  Concatenate the salt, content-encryption key, and key checksum
>        value.
>    5.  Add one block length of randomly generated pad octets. Then pad
>        the result using standard block padding as defined in section
>        6.3.
>    6.  Encrypt the result with the key-encryption algorithm 
> key.  Use an
>        IV with each octet equal to 'A5' hexadecimal.
> 
> The unwrap text is OK as it is but a comment could be added that the
> key length can be checked:
> 
>    5.  If there are restrictions on keys, then check if the
>        content-encryption key meets these restrictions.  For example,
>        check for odd parity of each octet in each DES key 
> that makes up
>        a Triple-DES key and check that the key length is correct.  If 
>        any restriction is incorrect, then there is an error.
> 
> 
This looks fine to me with the change from above.

> > 
> > >
> > > >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV
> > > present and is its
> > > >value the constant 'A5' repeated n time?  The IV was not
> > > present in the
> > > >previous versions but would appear to be present now.  We
> > > still have the IV
> > > >restriction on the key wrap algorithm however.
> > >
> > > There is no field needed to carry the IV as it is always
> > > "A5...A5".  For 3DES,
> > > the parameter is always NULL, and for RC2 the parameter is
> > > the effective key
> > > length.  Where do you see an IV?
> > 
> > OK -- I see where I got confused.  I started with the 
> second paragraph in
> > section 12.3.1 and made a leap of incorrectness into the 
> fact that the
> > KeyWrapAlgorithm was going to be rc2-cbc not 
> id-alg-RC2wrap.  I don't see
> > any clarifications that need to be added to the text, I was 
> just skimming
> > the changes too fast.
> > 
> 
> Just to add a little comment of my own since I suggested part of this.
> My primary reason for this change is to allow algorithms 
> other than RC2
> and 3DES to be used with key agreement. In the case of RC2 and 3DES a
> special algorithm identifier form is defined without the IV. In other
> cases, such as (single) DES the normal algorithm identifier would be
> used which would include an IV: but in this case it would be ignored
> and A5 used.

Yes -- this is what I kind of expected to have happen.  I would however make
an assert that the IV MUST be 'A5' and encoded as such.

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

jim


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA21089 for ietf-smime-bks; Mon, 30 Nov 1998 16:46:00 -0800 (PST)
Received: from post.mail.demon.net (post-22.mail.demon.net [194.217.242.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA21085 for <[e-mail]>; Mon, 30 Nov 1998 16:45:59 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.054 #1) id 0zke1a-00005X-00 for [e-mail]; Tue, 1 Dec 1998 00:50:43 +0000
Message-ID: <[e-mail]>
Date: Tue, 01 Dec 1998 00:45:29 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Comments on CMC-09
References: <2FBF98FC7852CF11912A0000000000010ECB5B0E@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jim Schaad (Exchange) wrote:
> 
> 
> >
> > >15.  Section 12.6.2 - You have not modified the key wrap
> > algorithm to allow
> > >for arbitrary length RC2 key sources.
> >
> > Are you suggesting an explicit length field or something else?
> >
> We need to either put in an explicit length field or use a known padding
> algorithm.  I have no perference on which is used but something along this
> lines is absolutely required.
> 

Speaking personally I'd prefer known padding. Known padding at least
adds some consistency with the use of symmetric algorithms: they all use
the "padded" forms.

If an explicit length parameter is included the logical place to put it
is in the EncryptedContentInfo structure because its a property of the
content encryption key. You'd probably then have to make it OPTIONAL for
v2 compatability only include it when at least one recipient used key
agreement.

With known padding the following minor change should suffice:

   1.  Modify the content-encryption key to meet any restrictions on 
       the key. For example, adjust the parity bits for each DES key
       comprising a Triple-DES key.
   2.  Compute a 16-bit key checksum value on the content-encryption key
       as described above.
   3.  Generate a 32-bit random salt value.
   4.  Concatenate the salt, content-encryption key, and key checksum
       value.
   5.  Add one block length of randomly generated pad octets. Then pad
       the result using standard block padding as defined in section
       6.3.
   6.  Encrypt the result with the key-encryption algorithm key.  Use an
       IV with each octet equal to 'A5' hexadecimal.

The unwrap text is OK as it is but a comment could be added that the
key length can be checked:

   5.  If there are restrictions on keys, then check if the
       content-encryption key meets these restrictions.  For example,
       check for odd parity of each octet in each DES key that makes up
       a Triple-DES key and check that the key length is correct.  If 
       any restriction is incorrect, then there is an error.


> 
> >
> > >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV
> > present and is its
> > >value the constant 'A5' repeated n time?  The IV was not
> > present in the
> > >previous versions but would appear to be present now.  We
> > still have the IV
> > >restriction on the key wrap algorithm however.
> >
> > There is no field needed to carry the IV as it is always
> > "A5...A5".  For 3DES,
> > the parameter is always NULL, and for RC2 the parameter is
> > the effective key
> > length.  Where do you see an IV?
> 
> OK -- I see where I got confused.  I started with the second paragraph in
> section 12.3.1 and made a leap of incorrectness into the fact that the
> KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap.  I don't see
> any clarifications that need to be added to the text, I was just skimming
> the changes too fast.
> 

Just to add a little comment of my own since I suggested part of this.
My primary reason for this change is to allow algorithms other than RC2
and 3DES to be used with key agreement. In the case of RC2 and 3DES a
special algorithm identifier form is defined without the IV. In other
cases, such as (single) DES the normal algorithm identifier would be
used which would include an IV: but in this case it would be ignored
and A5 used.

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA19486 for ietf-smime-bks; Mon, 30 Nov 1998 13:35:57 -0800 (PST)
Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA19482 for <[e-mail]>; Mon, 30 Nov 1998 13:35:56 -0800 (PST)
Received: by dfssl.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPL4VK4V>; Mon, 30 Nov 1998 13:38:38 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B0E@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on CMC-09
Date: Mon, 30 Nov 1998 13:38:21 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Wednesday, November 25, 1998 11:29 AM
> To: Jim Schaad (Exchange)
> Cc: [e-mail]
> Subject: Re: Comments on CMC-09
> 
> 
> Jim:
> 
> >4.  Section 4.0 Last Paragraph:  Please delete the last 
> sentence in this
> >paragraph.  I don't understand what is going on in this 
> paragraph.  We have
> >obously defined how to do the encapsulated content in this 
> document (such as
> >signed data in signed data), we just have not defined any 
> other base content
> >types 
> 
> Agree.  This was intended to allow arbitrary content types to 
> be encapsulated. 
> I agree that it does not belong in this section.  Does the 
> thought belong
> somewhere else?
> 
> Also, I added the Data ASN.1 definition:
> 
>   The data content type shall have ASN.1 type Data:
> 
>         Data ::= OCTET STRING
> 

I agree with the addition of the ASN.  I don't think the thought needs to be
expressed anyplace else.  Neither of the sections for encapsulated or
enveloped content have any restrictions implied or explict about the content
to be encapsulated.
> 
> >5.  Section 2.0 Paragraph 1.  Change "ContentInfo 
> encapsulates one or more
> >content types." to "ContentInfo encapsulates an identified 
> content type."
> >There is no sequence so the one or more is misleading.
> 
> I agree with your point.  How about:
> 
>    ContentInfo encapsulates a single identified content type, and
>    the identified type may provide further encapsulation.
> 

This sounds fine with me.

> 
> >6.  Section 3.0  Should we change the title on this section 
> from General
> >Syntax to Content Info?  Since we are no longer restricting 
> the exported
> >types to ContentInfo then there is no longer a single general syntax
> >anymore.
> 
> This is the title used by PKCS#7 v1.5.  My hope is to make it 
> easier for the
> reader who is concerned about backward compatibility.
> 
> What do other people think about this one?
> 
> 
> >9.  Section 9.2:  Was there a reason for removing the 
> "rather than the
> >implcit [0] .." phrase.  This exists in the process for 
> signed data and I
> >think should be here as well.
> 
> For authenticated-data, digests are only computed on the 
> content.  They are
> never computed on the attributes.  The IMPLICIT [0] stuff was 
> about the
> attribute encoding.
>

I don't follow your response.  What I am looking at is the text relating to
the creation of the authenticatedAttributes blob over which the MAC will be
computed.  This is yet another location where the ASN which is encoded and
sent is not the same as the ASN which is acutally MAC-ed.  I think this
should be very explicit like in the other cases.
 
> 
> >10.  Global -- You have some inconsitant labeling  Some 
> references are
> >bracked and some are not.  Please go through the document 
> and choose one
> >method or the other but be consistant.  (Examples are 11.0 
> uses brackets but
> >10.2.2 does not.)
> 
> I changed 10.2.2.  I did not see any others like that one.
> 

I'll send you a list.

> 
> >13.  Section 12.3.1.1 Para "keyEncryptionAlgrothm must ..." 
> I have a problem
> >with the phase a "and contain a", the first 6 or 7 time I read this I
> >assumed it was a field in the parameters rather than being 
> the parameter
> >itself.  Writing as "The algorihtm identifier parameter field for
> >id-alg-ESDH is KeyWrapAlgorihtm and must be present." avoids 
> this issue.
> 
> Okay.  How about:
> 
>    The algorihtm identifier parameter field for id-alg-ESDH
>    is KeyWrapAlgorihtm, and this parameter must be present.
>
This is just fine.
 
> 
> >14.  Section 12.3.3 Last paragarph.  What is this paragraph 
> doing here?  It
> >is talking about key agreement in the symetric key 
> -encryption section.
> 
> The output of a key agreement algorithm is a key-encryption 
> key, and this
> key-encryption key is used to encrypt the content-encryption 
> key.  The last
> paragraph is a backward pointer telling folks that the same 
> techniques are used
> regardless of the source of the key-encryption key.  I will 
> add an sentence to
> the front of this paragraph that hopefully makes this more clear.
> 
I don't understand this even with your explination.

> 
> >15.  Section 12.6.2 - You have not modified the key wrap 
> algorithm to allow
> >for arbitrary length RC2 key sources.
> 
> Are you suggesting an explicit length field or something else?
> 
We need to either put in an explicit length field or use a known padding
algorithm.  I have no perference on which is used but something along this
lines is absolutely required.

> 
> >16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV 
> present and is its
> >value the constant 'A5' repeated n time?  The IV was not 
> present in the
> >previous versions but would appear to be present now.  We 
> still have the IV
> >restriction on the key wrap algorithm however.
> 
> There is no field needed to carry the IV as it is always 
> "A5...A5".  For 3DES,
> the parameter is always NULL, and for RC2 the parameter is 
> the effective key
> length.  Where do you see an IV?

OK -- I see where I got confused.  I started with the second paragraph in
section 12.3.1 and made a leap of incorrectness into the fact that the
KeyWrapAlgorithm was going to be rc2-cbc not id-alg-RC2wrap.  I don't see
any clarifications that need to be added to the text, I was just skimming
the changes too fast.

> 
> Russ
> 
> 

jim


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA16148 for ietf-smime-bks; Mon, 30 Nov 1998 06:20:21 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA16144 for <[e-mail]>; Mon, 30 Nov 1998 06:20:20 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id JAA25157; Mon, 30 Nov 1998 09:24:28 -0500
Message-Id: <4.1.19981130090938.00978430@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 30 Nov 1998 09:25:27 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: RecipientInfo vs SignerInfo key identification
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:25 PM 11/28/98 +0000, Peter Gutmann wrote:
>>>I've noticed that RecipientInfo identifies a key with a CHOICE between
>>>IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows
>>>IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the
>>>RecipientInfo should also require it in the SignerInfo, could these be
merged
>>>to create a unified identifier type (ie they both use a RecipientInfo-style
>>>CHOICE)?
>
>>The addition of SubjectKeyIdentifier to SignerInfo was considered.  Many
>>developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
>>was more important that the shorter certificate reference.
>
>The reason I brought it up was because of the inconsistency in identifying
>certs which currently exists - depending on whether you're signing or 
>encrypting, you end up with different identifiers, and if there was some
>overwhelming reason which made SKI's necessary for RecipientInfo then I
>would have assumed that the same argument applied for SignerInfo.

No.  In general S/MIME usage, SignedData will have one SignerInfo.  With a
single signer, there is not a great motivation to reduce the size of the
certificate reference.

On the other hand, the number of recipients contained in an EnvelopedData
may be quite significant.  For this reason, RecipientInfo supports the
shorter form of certificate reference.

Further, some people argued that the key is not the only thing that is
important in verifying a signature.  Other fields in the certificate, like
policy, are important too.  If a signer has the same public key in two
certificates, then an attacker can swap the certificate carried in the
certificates field.  Since PKIX recommends a form of key identifier based
on hashing the public key, then the relying pary will probably not be able
to determine that the certificates were swapped.  Since the issuer / serial
pair specifies a certificate, not just a public key, it seems to be the
prefered method for signatures.

>In terms of the backwards-compatibility argument, it's already present
>in RecipientInfo and doesn't seem to have caused any trouble, so if it works
>fine for RecipientInfo why shouldn't it work for SignerInfo?  It can be
>handled in exactly the same manner as the RecipientInfo... any argument
>against having it in SignerInfo would also count against its use in
>RecipientInfo, but it's being used in RI already, so I'm not sure why it
>can't also be used in SI.
>
>(I'm not just arguing this point to be difficult, there's a genuine use
>for SKI's when used with things like PGP keys, at the moment this works
>just fine for RI's but doesn't work at all for SI's if they don't allow
>the same type of key identification as RI's).

Agreed, it could be added without breaking backward compatibility.  Support
for key identifiers could be added to SignerInfo, but as stated above,
there is less motivation to do so.

Again, signatures should reference a particular certificate, not just a
public key.


Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA12290 for ietf-smime-bks; Fri, 27 Nov 1998 18:21:17 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA12285 for <[e-mail]>; Fri, 27 Nov 1998 18:21:15 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA25124; Sat, 28 Nov 1998 15:25:32 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91221993214185>; Sat, 28 Nov 1998 15:25:32 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: RecipientInfo vs SignerInfo key identification
Cc: [e-mail]
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 28 Nov 1998 15:25:32 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>>I've noticed that RecipientInfo identifies a key with a CHOICE between
>>IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows
>>IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the
>>RecipientInfo should also require it in the SignerInfo, could these be merged
>>to create a unified identifier type (ie they both use a RecipientInfo-style
>>CHOICE)?

>The addition of SubjectKeyIdentifier to SignerInfo was considered.  Many
>developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
>was more important that the shorter certificate reference.

The reason I brought it up was because of the inconsistency in identifying
certs which currently exists - depending on whether you're signing or 
encrypting, you end up with different identifiers, and if there was some
overwhelming reason which made SKI's necessary for RecipientInfo then I
would have assumed that the same argument applied for SignerInfo.

In terms of the backwards-compatibility argument, it's already present
in RecipientInfo and doesn't seem to have caused any trouble, so if it works
fine for RecipientInfo why shouldn't it work for SignerInfo?  It can be
handled in exactly the same manner as the RecipientInfo... any argument
against having it in SignerInfo would also count against its use in
RecipientInfo, but it's being used in RI already, so I'm not sure why it
can't also be used in SI.

(I'm not just arguing this point to be difficult, there's a genuine use
for SKI's when used with things like PGP keys, at the moment this works
just fine for RI's but doesn't work at all for SI's if they don't allow
the same type of key identification as RI's).

Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA18881 for ietf-smime-bks; Wed, 25 Nov 1998 22:05:44 -0800 (PST)
Received: from vivaldi.ort.edu.uy (vivaldi.ort.edu.uy [164.73.96.2]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA18877 for <[e-mail]>; Wed, 25 Nov 1998 22:05:42 -0800 (PST)
From: [e-mail]
Received: from falcon-west.bestnet.org by vivaldi.ort.edu.uy with smtp (Smail3.1.28.1 #2) id m0ziqvQ-00006WC; Wed, 25 Nov 98 23:12 GRNLNDST
Message-Id: <[e-mail]>
Date: Wed, 25 Nov 98 23:12 GRNLNDST
To: <[e-mail]>
Subject: Y2K Solution.
Sender: [e-mail]
Precedence: bulk

Important millennium press announcement for the individual investor, expanding world renowned Y2K compliance solution and compliant Y2K E-trade software.

Investor opportunity awareness features.  Leading world software developer press release reported by World Currency News.

For updated information and researched references see Recent & Future Events under the heading of International Scoreboard.


http://www.worldcurrencynews.com


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15016 for ietf-smime-bks; Wed, 25 Nov 1998 13:44:10 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15012 for <[e-mail]>; Wed, 25 Nov 1998 13:44:09 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA05227; Wed, 25 Nov 1998 16:48:36 -0500
Message-Id: <4.1.19981125164134.00988c60@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 25 Nov 1998 16:43:31 -0500
To: EKR <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: More X942-03 Comments
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <"Jim Schaad's message of "Fri, 20 Nov 1998 16:28:48 -0800"> <2FBF98FC7852CF11912A0000000000010ECB5ADF@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

>> 1.  Section 2.1.2 in the paragraph on pubInfo:  There is a description that
>> appears to say CMS defined UserKeyingMaterial as a 512-bit value.  There are
>> two problems with this: a) CMS does not say anything about the length of ukm
>> and b) no justification is shown here for a length of 512-bits.  Is this a
>> magic length?
>I'm trying to remember myself. ISTR that some previous CMS version
>had 512 bits. I'm not fixated on this number by any means.
>IIRC, KEA uses 512 bits.

You are comparing apples and oranges.  KEA has a UKM value, bit it is 1024
bits long, and it is not an input to a hash function.

Again, 512 bits is the SHA-1 block size, so it is the maximum entropy that
can be inserted in this manner.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15011 for ietf-smime-bks; Wed, 25 Nov 1998 13:44:09 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA15006 for <[e-mail]>; Wed, 25 Nov 1998 13:44:08 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id QAA05217; Wed, 25 Nov 1998 16:48:27 -0500
Message-Id: <4.1.19981125163918.00989960@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 25 Nov 1998 16:41:11 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: More X942-03 Comments
Cc: "'EKR'" <[e-mail]>, [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5ADF@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>1.  Section 2.1.2 in the paragraph on pubInfo:  There is a description that
>appears to say CMS defined UserKeyingMaterial as a 512-bit value.  There are
>two problems with this: a) CMS does not say anything about the length of ukm
>and b) no justification is shown here for a length of 512-bits.  Is this a
>magic length?

512 bits is the SHA-1 block size, so it is the maximum entropy that can be
inserted in this manner.

Russ 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA13648 for ietf-smime-bks; Wed, 25 Nov 1998 11:24:13 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA13644 for <[e-mail]>; Wed, 25 Nov 1998 11:24:12 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA00705; Wed, 25 Nov 1998 14:28:39 -0500
Message-Id: <4.1.19981125110310.0098a2e0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123 (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 25 Nov 1998 14:29:19 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on CMC-09
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5B02@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>1.  AuthenticatedData cannot be processed in a single pass for both creation
>and writting.  The ASN must be changed to 
>       AuthenticatedData ::= SEQUENCE {
>               version         CMSVersion,
>               originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>               recipientInfos RecipientInfos,
>               macAlgorithm MessageAuthenticationCodeAlgorithm,
>               digestAlgorithm [1] DigestAlgorithm OPTIONAL,
>               encapContentInfo EncapsulatedContentInfo,
>               authenctiatedAttributes [2] IMPLICIT AuthAttributes
>OPTIONAL,
>               mac MessageAuthencticationCode,
>               unauthenticatedAttributes [3] IMPLICIT UnauthAttributes
>OPTIONAL
>       }
>
>With the current layout, while the verification can be done in one pass the
>creation requires two passes.  The required steps are 1) compute the hash on
>the data, 2) create the authenticated attributes and write, 3) write the
>content, 4) compute and write the mac.  This means that we had to process
>the content twice.

You are correct.  The digest algorithm is needed before the content, and the
authenitcated attributes should follow the content.  I had bundled the digest
algorithm and authenitcated attributes together since they are related.  I can
handle this in words.


>2.  Section 2.0 Paragraph 3:  Should read "each content type permits..." the
>s is missing on permits

Agree.


>3.  Section 3.0 Paragraph "conent is ..." please add "data" to the list of
>defined content types defined in the document

Agree.


>4.  Section 4.0 Last Paragraph:  Please delete the last sentence in this
>paragraph.  I don't understand what is going on in this paragraph.  We have
>obously defined how to do the encapsulated content in this document (such as
>signed data in signed data), we just have not defined any other base content
>types 

Agree.  This was intended to allow arbitrary content types to be encapsulated. 
I agree that it does not belong in this section.  Does the thought belong
somewhere else?

Also, I added the Data ASN.1 definition:

  The data content type shall have ASN.1 type Data:

        Data ::= OCTET STRING


>5.  Section 2.0 Paragraph 1.  Change "ContentInfo encapsulates one or more
>content types." to "ContentInfo encapsulates an identified content type."
>There is no sequence so the one or more is misleading.

I agree with your point.  How about:

   ContentInfo encapsulates a single identified content type, and
   the identified type may provide further encapsulation.


>6.  Section 3.0  Should we change the title on this section from General
>Syntax to Content Info?  Since we are no longer restricting the exported
>types to ContentInfo then there is no longer a single general syntax
>anymore.

This is the title used by PKCS#7 v1.5.  My hope is to make it easier for the
reader who is concerned about backward compatibility.

What do other people think about this one?


>7.  Section 6.1 -  I must have  missed this one coming through the list.
>While I have no objects to including the attribute sequence, I strongly
>suggest that the name/type be change to UnprotectedAttributes.   Plaintext
>originally confused me as a new type of textual attributes.

Unprotected is fine.


>8.  Section 9.2: Paragraph 2;  Please change to "If authAttributeInfo is
>absent ..." or add the word "the"

This has to be reworked to implement your first change.  The authAttributeInfo
structure is being broken up.


>9.  Section 9.2:  Was there a reason for removing the "rather than the
>implcit [0] .." phrase.  This exists in the process for signed data and I
>think should be here as well.

For authenticated-data, digests are only computed on the content.  They are
never computed on the attributes.  The IMPLICIT [0] stuff was about the
attribute encoding.


>10.  Global -- You have some inconsitant labeling  Some references are
>bracked and some are not.  Please go through the document and choose one
>method or the other but be consistant.  (Examples are 11.0 uses brackets but
>10.2.2 does not.)

I changed 10.2.2.  I did not see any others like that one.


>11.  Section 11..2 Para 1 Last sentence.  This is a tautalogy.  I think you
>meant to use the phrase "the authenctor's message ditest algorith."

Agree.  It shoudl be the originator's algorithm.


>12.  Section 11.2 Para 3.  Missing "an" before unauthencticate attribute.

Agree.


>13.  Section 12.3.1.1 Para "keyEncryptionAlgrothm must ..." I have a problem
>with the phase a "and contain a", the first 6 or 7 time I read this I
>assumed it was a field in the parameters rather than being the parameter
>itself.  Writing as "The algorihtm identifier parameter field for
>id-alg-ESDH is KeyWrapAlgorihtm and must be present." avoids this issue.

Okay.  How about:

   The algorihtm identifier parameter field for id-alg-ESDH
   is KeyWrapAlgorihtm, and this parameter must be present.


>14.  Section 12.3.3 Last paragarph.  What is this paragraph doing here?  It
>is talking about key agreement in the symetric key -encryption section.

The output of a key agreement algorithm is a key-encryption key, and this
key-encryption key is used to encrypt the content-encryption key.  The last
paragraph is a backward pointer telling folks that the same techniques are used
regardless of the source of the key-encryption key.  I will add an sentence to
the front of this paragraph that hopefully makes this more clear.


>15.  Section 12.6.2 - You have not modified the key wrap algorithm to allow
>for arbitrary length RC2 key sources.

Are you suggesting an explicit length field or something else?


>16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV present and is its
>value the constant 'A5' repeated n time?  The IV was not present in the
>previous versions but would appear to be present now.  We still have the IV
>restriction on the key wrap algorithm however.

There is no field needed to carry the IV as it is always "A5...A5".  For 3DES,
the parameter is always NULL, and for RC2 the parameter is the effective key
length.  Where do you see an IV?

Russ




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08841 for ietf-smime-bks; Tue, 24 Nov 1998 14:36:56 -0800 (PST)
Received: from rbhub101.chamb.disa.mil (rbhub101.chamb.disa.mil [209.22.120.24]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08834; Tue, 24 Nov 1998 14:36:52 -0800 (PST)
Received: by rbhub101.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <XN8YHTD3>; Tue, 24 Nov 1998 17:42:01 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, [e-mail]
Subject: RE: Defining terms in -msg and -cert
Date: Tue, 24 Nov 1998 17:42:03 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Paul,

	Recommend deleting the last three.  "S/MIME agent" appears (from
your definition of it) to be a superclass of receiving agent and sending
agent.  Knowing what a "receiving agent" and a "sending agent" are would
seem to cover theWaterFront.  Also, suggest inserting "user" in front of
"software" in your two proposed definitions of "receiving agent" and
"sending agent".  

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%  

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[e-mail]]
> Sent:	Sunday, November 22, 1998 1:26 PM
> To:	[e-mail]
> Subject:	Defining terms in -msg and -cert
> 
> Greetings again. It was pointed out by an implementor that the -msg and
> -cert draft use at least five different terms for S/MIME software:
> "receiving agent"
> "sending agent"
> "S/MIME agent"
> "processing software"
> "user agent"
> Since some of these are used in SHOULD and MUST statements, we need to
> clarify them. I think the best thing to do to eliminate the last two, and
> define the first three. In the cases where we use "user agent" to mean
> generic "mail user agent", we can spell that out.
> 
> How do these definitions sound?
> 
> A receving agent is software that interprets and processes S/MIME CMS
> objects, MIME body parts that contain CMS objects, or both.
> 
> A sending agent is software that creates S/MIME CMS objects, MIME body
> parts that contain CMS objects, or both.
> 
> An S/MIME agent is user software that is a receiving agent, a sending
> agent, or both.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07918 for ietf-smime-bks; Tue, 24 Nov 1998 12:26:11 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07914 for <[e-mail]>; Tue, 24 Nov 1998 12:26:11 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGB6LP>; Tue, 24 Nov 1998 12:28:44 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5B02@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Russ Housley (E-mail)" <[e-mail]>, "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Comments on CMC-09
Date: Tue, 24 Nov 1998 12:28:42 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Lets start with the biggest issue first:

1.  AuthenticatedData cannot be processed in a single pass for both creation
and writting.  The ASN must be changed to 
	AuthenticatedData ::= SEQUENCE {
		version 	CMSVersion,
		originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
		recipientInfos RecipientInfos,
		macAlgorithm MessageAuthenticationCodeAlgorithm,
		digestAlgorithm [1] DigestAlgorithm OPTIONAL,
		encapContentInfo EncapsulatedContentInfo,
		authenctiatedAttributes [2] IMPLICIT AuthAttributes
OPTIONAL,
		mac MessageAuthencticationCode,
		unauthenticatedAttributes [3] IMPLICIT UnauthAttributes
OPTIONAL
	}

With the current layout, while the verification can be done in one pass the
creation requires two passes.  The required steps are 1) compute the hash on
the data, 2) create the authenticated attributes and write, 3) write the
content, 4) compute and write the mac.  This means that we had to process
the content twice.

2.  Section 2.0 Paragraph 3:  Should read "each content type permits..." the
s is missing on permits

3.  Section 3.0 Paragraph "conent is ..." please add "data" to the list of
defined content types defined in the document

4.  Section 4.0 Last Paragraph:  Please delete the last sentence in this
paragraph.  I don't understand what is going on in this paragraph.  We have
obously defined how to do the encapsulated content in this document (such as
signed data in signed data), we just have not defined any other base content
types 

5.  Section 2.0 Paragraph 1.  Change "ContentInfo encapsulates one or more
content types." to "ContentInfo encapsulates an identified content type."
There is no sequence so the one or more is misleading.

6.  Section 3.0  Should we change the title on this section from General
Syntax to Content Info?  Since we are no longer restricting the exported
types to ContentInfo then there is no longer a single general syntax
anymore.

7.  Section 6.1 -  I must have  missed this one coming through the list.
While I have no objects to including the attribute sequence, I strongly
suggest that the name/type be change to UnprotectedAttributes.   Plaintext
originally confused me as a new type of textual attributes.

8.  Section 9.2: Paragraph 2;  Please change to "If authAttributeInfo is
absent ..." or add the word "the"

9.  Section 9.2:  Was there a reason for removing the "rather than the
implcit [0] .." phrase.  This exists in the process for signed data and I
think should be here as well.

10.  Global -- You have some inconsitant labeling  Some references are
bracked and some are not.  Please go through the document and choose one
method or the other but be consistant.  (Examples are 11.0 uses brackets but
10.2.2 does not.)

11.  Section 11..2 Para 1 Last sentence.  This is a tautalogy.  I think you
meant to use the phrase "the authenctor's message ditest algorith."

12.  Section 11.2 Para 3.  Missing "an" before unauthencticate attribute.

13.  Section 12.3.1.1 Para "keyEncryptionAlgrothm must ..." I have a problem
with the phase a "and contain a", the first 6 or 7 time I read this I
assumed it was a field in the parameters rather than being the parameter
itself.  Writing as "The algorihtm identifier parameter field for
id-alg-ESDH is KeyWrapAlgorihtm and must be present." avoids this issue.

14.  Section 12.3.3 Last paragarph.  What is this paragraph doing here?  It
is talking about key agreement in the symetric key -encryption section.

15.  Section 12.6.2 - You have not modified the key wrap algorithm to allow
for arbitrary length RC2 key sources.

16.  Section 12.3.1.1 - In the KeyWrapAlgorithm is the IV present and is its
value the constant 'A5' repeated n time?  The IV was not present in the
previous versions but would appear to be present now.  We still have the IV
restriction on the key wrap algorithm however.

jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08232 for ietf-smime-bks; Mon, 23 Nov 1998 15:06:11 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08228 for <[e-mail]>; Mon, 23 Nov 1998 15:06:10 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGBR7S>; Mon, 23 Nov 1998 15:08:24 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5AF6@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>
Cc: [e-mail]
Subject: RE: RecipientInfo vs SignerInfo key identification
Date: Mon, 23 Nov 1998 15:08:12 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

While it is true that the inclusion of attribute certificates will cause
this problem, that is going to be a rare item in the current world.  This is
going to generally be in closed (or semi-closed) rollouts and not hit the
internet in general.

Existing clients will be able to read messages which include secure receipt
requests, they would not generate a return receipt.  There may also be some
issues about current clients reading an acutal receipt, but that is the
unexpected not expected case.

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[e-mail]]
Sent: Monday, November 23, 1998 2:56 PM
To: Jim Schaad (Exchange); 'Russ Housley'; [e-mail]
Cc: [e-mail]
Subject: RE: RecipientInfo vs SignerInfo key identification


> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[e-mail]]
> Sent: Monday, November 23, 1998 2:47 PM
> To: Blake Ramsdell; 'Russ Housley'; [e-mail]
> Cc: [e-mail]
> Subject: RE: RecipientInfo vs SignerInfo key identification
> 
> These discussions occured when we were still meeting in San 
> Fransico.  If we
> allow for this to occur in the S/MIME world we immeadiately 
> hit the demon of
> backwards compatability.  I don't know about your product, 
> but ours does not
> look at capabilites of recipients when sending signed mail.  
> Thus we MUST
> use the Issuer/Serial Number identification as we have no idea if the
> receiving client has the ability to understand anything new.

Isn't this a problem if you have attribute certificates or secure return
receipts also?  These features will not be supported by v2 clients either
(and will cause a similar interoperability problem).

Likewise, the RecipientInfo changes for this same purpose seem to have
exactly the same problem (and we got around this by ticking the version
number), so the demon is still with us.

I personally don't want this changed, but I wanted to make sure I understood
the arguments against it.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08171 for ietf-smime-bks; Mon, 23 Nov 1998 14:57:25 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08167 for <[e-mail]>; Mon, 23 Nov 1998 14:57:24 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id SAA04955; Mon, 23 Nov 1998 18:01:11 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-09.txt
Date: Mon, 23 Nov 1998 18:01:10 -0500
Sender: [e-mail]
Precedence: bulk

--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-09.txt
	Pages		: 50
	Date		: 20-Nov-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 <[e-mail]> 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-09.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-09.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-09.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08113 for ietf-smime-bks; Mon, 23 Nov 1998 14:52:15 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA08109 for <[e-mail]>; Mon, 23 Nov 1998 14:52:14 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Mon, 23 Nov 98 14:56:04 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XF1JC95V>; Mon, 23 Nov 1998 14:56:04 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Jim Schaad (Exchange)'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, <[e-mail]>
cc: <[e-mail]>
Subject: RE: RecipientInfo vs SignerInfo key identification
Date: Mon, 23 Nov 1998 14:56:03 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A47378E10202-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Jim Schaad (Exchange) [mailto:[e-mail]]
> Sent: Monday, November 23, 1998 2:47 PM
> To: Blake Ramsdell; 'Russ Housley'; [e-mail]
> Cc: [e-mail]
> Subject: RE: RecipientInfo vs SignerInfo key identification
> 
> These discussions occured when we were still meeting in San 
> Fransico.  If we
> allow for this to occur in the S/MIME world we immeadiately 
> hit the demon of
> backwards compatability.  I don't know about your product, 
> but ours does not
> look at capabilites of recipients when sending signed mail.  
> Thus we MUST
> use the Issuer/Serial Number identification as we have no idea if the
> receiving client has the ability to understand anything new.

Isn't this a problem if you have attribute certificates or secure return
receipts also?  These features will not be supported by v2 clients either
(and will cause a similar interoperability problem).

Likewise, the RecipientInfo changes for this same purpose seem to have
exactly the same problem (and we got around this by ticking the version
number), so the demon is still with us.

I personally don't want this changed, but I wanted to make sure I understood
the arguments against it.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA08062 for ietf-smime-bks; Mon, 23 Nov 1998 14:45:16 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA08058 for <[e-mail]>; Mon, 23 Nov 1998 14:45:15 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGBR3V>; Mon, 23 Nov 1998 14:47:28 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5AF5@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: RecipientInfo vs SignerInfo key identification
Date: Mon, 23 Nov 1998 14:47:19 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Blake,

These discussions occured when we were still meeting in San Fransico.  If we
allow for this to occur in the S/MIME world we immeadiately hit the demon of
backwards compatability.  I don't know about your product, but ours does not
look at capabilites of recipients when sending signed mail.  Thus we MUST
use the Issuer/Serial Number identification as we have no idea if the
receiving client has the ability to understand anything new.

This is a fine change for CMS but verboten for S/MIME

jim

-----Original Message-----
From: Blake Ramsdell [mailto:[e-mail]]
Sent: Monday, November 23, 1998 1:32 PM
To: 'Russ Housley'; [e-mail]
Cc: [e-mail]
Subject: RE: RecipientInfo vs SignerInfo key identification


> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, November 23, 1998 8:16 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: RecipientInfo vs SignerInfo key identification
> 
> 
> The addition of SubjectKeyIdentifier to SignerInfo was 
> considered.  Many
> developers felt that backward compatibility with PKCS#7 v1.5 
> and S/MIME v2
> was more important that the shorter certificate reference.

When was this considered?  I can't find a discussion about it in the past
(of course, that refers more to my blindness than anything else.)

> It woulf be very easy to add SubjectKeyIdentifier to SignerInfo if the
> group concensus has changed.

It seems that you can tick the version number as we do if ACs or
encapsulated content other than id-data is present.

I really don't recall discussing this, and it seems that certificate
references should be the same across the board.  I do agree that backward
compatibility is paramount, and we can accomplish that by using the version
number tick that we are already using for other non-backward-compatible
things.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07286 for ietf-smime-bks; Mon, 23 Nov 1998 13:28:04 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA07282 for <[e-mail]>; Mon, 23 Nov 1998 13:28:03 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Mon, 23 Nov 98 13:31:54 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XF1JC9X3>; Mon, 23 Nov 1998 13:31:54 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
cc: <[e-mail]>
Subject: RE: RecipientInfo vs SignerInfo key identification
Date: Mon, 23 Nov 1998 13:31:52 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A470BC09474-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Monday, November 23, 1998 8:16 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: RecipientInfo vs SignerInfo key identification
> 
> 
> The addition of SubjectKeyIdentifier to SignerInfo was 
> considered.  Many
> developers felt that backward compatibility with PKCS#7 v1.5 
> and S/MIME v2
> was more important that the shorter certificate reference.

When was this considered?  I can't find a discussion about it in the past
(of course, that refers more to my blindness than anything else.)

> It woulf be very easy to add SubjectKeyIdentifier to SignerInfo if the
> group concensus has changed.

It seems that you can tick the version number as we do if ACs or
encapsulated content other than id-data is present.

I really don't recall discussing this, and it seems that certificate
references should be the same across the board.  I do agree that backward
compatibility is paramount, and we can accomplish that by using the version
number tick that we are already using for other non-backward-compatible
things.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA07147 for ietf-smime-bks; Mon, 23 Nov 1998 13:16:46 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA07143 for <[e-mail]>; Mon, 23 Nov 1998 13:16:45 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Mon, 23 Nov 98 13:20:35 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XF1JC9X1>; Mon, 23 Nov 1998 13:20:35 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on MSG spec
Date: Mon, 23 Nov 1998 13:20:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A470E299403-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Monday, November 23, 1998 5:01 AM
> To: Blake Ramsdell; [e-mail]
> Subject: RE: Comments on MSG spec
> 
> At 03:44 PM 11/20/98 -0800, Blake Ramsdell wrote:
> > <snip>
> >By the way, I think that the 3DES reference sucks (a 1979 
> IEEE Spectrum
> >article?).  Any suggestions?
> >
> 
> The IEEE Spectrum article is usually cited to give Tuchman 
> credit for the
> work; I think it's the first published description of 3DES.  
> (Schneier uses
> that reference, too.) However, if you're looking for 
> something better, Ford
> & Baum cite ANSI X9.52, "Triple Data Encryption Algorithm Modes of
> Operation", 1997.  I had thought that X9.17 covered it, too, 
> but I can't
> find my copy of X9.17 at this moment.  The ANSI refs are 
> probably better
> than Tuchman, in that they give you a single place that 
> describes both DES
> and 3DES.

I guess my point was more along the lines of "I need that which is necessary
and sufficient to implement the triple-DES algorithm as it is used in
S/MIME".  If ANSI X9.52 is publicly available in a known or easy-to-find
location, then that would make a great reference.

If it's not, I'd like to find (or create) something that is.  I looked at
TLS and they have the same reference, which I can't find.

Am I too lofty in my goals?

> >I believe that the theory here is that RC2 is or was a 
> trademark of RSADSI,
> >and so use of that trademark (that little (r) in the title 
> of RFC2268)
> >seemed to indicate that "if you had another algorithm with a 
> different name
> >that behaved exactly the same way, you'd be free and clear from any
> >potential IP concerns using RC2 in box copy, etc."
> >
> 
> Now that I remember what this is all about, I'd like to agree 
> with Paul's
> suggestion:  kill the "or a compatible algorithm" stuff.

So the (r) is not a concern?  Just asking.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA05565 for ietf-smime-bks; Mon, 23 Nov 1998 10:10:03 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA05561 for <[e-mail]>; Mon, 23 Nov 1998 10:10:01 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XPLGBL03>; Mon, 23 Nov 1998 10:12:18 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5AE4@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: RecipientInfo vs SignerInfo key identification
Date: Mon, 23 Nov 1998 10:12:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I would not be againist the addition of SKI in CMS, but if that was done
then I believe that the S/MIME message draft would be required to add a MUST
NOT on its use.  The addition of SKI would make sense for other groups
without the history of PKCS#7 already deployed to use.

jim

-----Original Message-----
From: Russ Housley [mailto:[e-mail]]
Sent: Monday, November 23, 1998 8:16 AM
To: [e-mail]
Cc: [e-mail]
Subject: Re: RecipientInfo vs SignerInfo key identification


Peter:

The addition of SubjectKeyIdentifier to SignerInfo was considered.  Many
developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
was more important that the shorter certificate reference.

It woulf be very easy to add SubjectKeyIdentifier to SignerInfo if the
group concensus has changed.

Russ


At 03:10 AM 11/23/98 +0000, Peter Gutmann wrote:
>I've noticed that RecipientInfo identifies a key with a CHOICE between 
>IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows 
>IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the 
>RecipientInfo should also require it in the SignerInfo, could these be
merged 
>to create a unified identifier type (ie they both use a RecipientInfo-style

>CHOICE)?
> 
>Peter.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA03450 for ietf-smime-bks; Mon, 23 Nov 1998 08:14:44 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA03446 for <[e-mail]>; Mon, 23 Nov 1998 08:14:43 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA18177; Mon, 23 Nov 1998 11:18:54 -0500
Message-Id: <4.1.19981123110435.009656c0@209.172.119.123>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 23 Nov 1998 11:16:09 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: RecipientInfo vs SignerInfo key identification
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

The addition of SubjectKeyIdentifier to SignerInfo was considered.  Many
developers felt that backward compatibility with PKCS#7 v1.5 and S/MIME v2
was more important that the shorter certificate reference.

It woulf be very easy to add SubjectKeyIdentifier to SignerInfo if the
group concensus has changed.

Russ


At 03:10 AM 11/23/98 +0000, Peter Gutmann wrote:
>I've noticed that RecipientInfo identifies a key with a CHOICE between 
>IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows 
>IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the 
>RecipientInfo should also require it in the SignerInfo, could these be merged 
>to create a unified identifier type (ie they both use a RecipientInfo-style 
>CHOICE)?
> 
>Peter.
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA02314 for ietf-smime-bks; Mon, 23 Nov 1998 05:03:53 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA02310 for <[e-mail]>; Mon, 23 Nov 1998 05:03:52 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA11769; Mon, 23 Nov 1998 08:07:56 -0500
Message-Id: <4.1.19981123074744.00a5c2d0@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 23 Nov 1998 08:00:45 -0500
To: "Blake Ramsdell" <[e-mail]>, <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: RE: Comments on MSG spec
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 03:44 PM 11/20/98 -0800, Blake Ramsdell wrote:
> <snip>
>By the way, I think that the 3DES reference sucks (a 1979 IEEE Spectrum
>article?).  Any suggestions?
>

The IEEE Spectrum article is usually cited to give Tuchman credit for the
work; I think it's the first published description of 3DES.  (Schneier uses
that reference, too.) However, if you're looking for something better, Ford
& Baum cite ANSI X9.52, "Triple Data Encryption Algorithm Modes of
Operation", 1997.  I had thought that X9.17 covered it, too, but I can't
find my copy of X9.17 at this moment.  The ANSI refs are probably better
than Tuchman, in that they give you a single place that describes both DES
and 3DES.



>>         4. Section 2.6, second sentence:  This is rough 
>> wording.  What do you
>> mena by "RC2 ... or a compatible algorithm"?  Which 
>> algorithms are "compatible"
>> with RC2?
>
>I believe that the theory here is that RC2 is or was a trademark of RSADSI,
>and so use of that trademark (that little (r) in the title of RFC2268)
>seemed to indicate that "if you had another algorithm with a different name
>that behaved exactly the same way, you'd be free and clear from any
>potential IP concerns using RC2 in box copy, etc."
>

Now that I remember what this is all about, I'd like to agree with Paul's
suggestion:  kill the "or a compatible algorithm" stuff.

<snip>

>
>> 
>>         6.  Section 3.1, last paragraph before 3.1.1:  this 
>> paragraph is out of
>> place.  It belongs in Section 4, if it's not already covered there.
>
>I agree with Paul's comments here.
>

The problem I had was that 3.1 talks about preparing a message.  Three
steps are listed (preparing the MIME entity, canonicalization, applying
transfer encoding), none of which deals with applying security services.
Out of nowhere comes a paragraph that says a receiving agent first
processes the security services, then ...  It just didn't seem to flow.
I'm not willing to argue about it any more, though; it's not that big a deal.


					Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA26775 for ietf-smime-bks; Sun, 22 Nov 1998 17:05:33 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA26771 for <[e-mail]>; Sun, 22 Nov 1998 17:05:32 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.053 #1) id 0zhkVf-0004sI-00 for [e-mail]; Mon, 23 Nov 1998 01:09:48 +0000
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1998 01:08:31 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [ssl-users] Client Certificates in Communicator 4.5
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Sorry, wrong list AARGH!


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA26700 for ietf-smime-bks; Sun, 22 Nov 1998 16:44:16 -0800 (PST)
Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA26696 for <[e-mail]>; Sun, 22 Nov 1998 16:44:06 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.053 #1) id 0zhkAh-0001LC-00; Mon, 23 Nov 1998 00:48:07 +0000
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1998 00:45:37 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Bodo Moeller <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: [ssl-users] Client Certificates in Communicator 4.5
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Bodo Moeller wrote:
> 
> Dr Stephen Henson <[e-mail]>:
> 
> It's not simply a "provision" to do so, in fact the server is even
> obliged to send the list.  The relevant definition (from
> draft-ietf-tls-protocol-06.txt, but it's the same in the early SSL 3.0
> specs) is
> 
>     struct {
>         ClientCertificateType certificate_types<1..2^8-1>;
>         DistinguishedName certificate_authorities<3..2^16-1>;
>     } CertificateRequest;
> 
> <3..2^16-1> means that the list of certification authorities is at
> least 3 octets, at most 2^16-1 octets long -- i.e. may not be empty.
> I think that SSLeay will send an empty list when
> SSL_CTX_set_client_CA_list has not been called, but it is asked to
> demand client certificates anyway.  SSLeay-based software that
> behaves in that way is in violation of the specification.
> 

Yes it does violate the SSL spec in this sense but nevertheless
Communicator versions before 4.06 permitted this and client auth worked
fine with an empty list. MSIE and Communicator 4.06 and later offer a
choice from the supplied list and give rather misleading behaviour when
no match is taken: MSIE presents an empty list to choose from and
Communicator just says you have no client certificates.

> Also note that your wording "There is a provision to just send the
> acceptable issuer names not just as part of the server chain" is
> misleading.  The certificates in the server chain may have nothing to
> do with the CAs the server accepts for clients.  For example, the
> server's certificate might be issued by one of the large commercial
> CAs (Verisign, Thawte, ...), but the only accepted client certs might
> be those issued be the webmaster's own CA (perhaps used in order to
> protect /server-stat and access to the logfiles from the public).
> 

This has to be taken into the context of the original query where the
sender was assuming that the acceptable CA list was just communicated by
including the CAs as part of the server CA chain.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23594 for ietf-smime-bks; Sun, 22 Nov 1998 10:21:59 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA23590 for <[e-mail]>; Sun, 22 Nov 1998 10:21:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sun, 22 Nov 1998 10:25:46 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Defining terms in -msg and -cert
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Greetings again. It was pointed out by an implementor that the -msg and
-cert draft use at least five different terms for S/MIME software:
"receiving agent"
"sending agent"
"S/MIME agent"
"processing software"
"user agent"
Since some of these are used in SHOULD and MUST statements, we need to
clarify them. I think the best thing to do to eliminate the last two, and
define the first three. In the cases where we use "user agent" to mean
generic "mail user agent", we can spell that out.

How do these definitions sound?

A receving agent is software that interprets and processes S/MIME CMS
objects, MIME body parts that contain CMS objects, or both.

A sending agent is software that creates S/MIME CMS objects, MIME body
parts that contain CMS objects, or both.

An S/MIME agent is user software that is a receiving agent, a sending
agent, or both.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22969 for ietf-smime-bks; Sun, 22 Nov 1998 06:06:41 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22965 for <[e-mail]>; Sun, 22 Nov 1998 06:06:39 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id DAA06977 for <[e-mail]>; Mon, 23 Nov 1998 03:10:40 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91174384005061>; Mon, 23 Nov 1998 03:10:40 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: RecipientInfo vs SignerInfo key identification
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Mon, 23 Nov 1998 03:10:40 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've noticed that RecipientInfo identifies a key with a CHOICE between 
IssuerAndSerialNumber and SubjectKeyIdentifier, but SignerInfo only allows 
IssuerAndSerialNumber.  Presumably whatever reason requires the SKI in the 
RecipientInfo should also require it in the SignerInfo, could these be merged 
to create a unified identifier type (ie they both use a RecipientInfo-style 
CHOICE)?
 
Peter.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA14025 for ietf-smime-bks; Fri, 20 Nov 1998 16:36:22 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA14015 for <[e-mail]>; Fri, 20 Nov 1998 16:35:41 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id QAA13591; Fri, 20 Nov 1998 16:41:05 -0800 (PST)
To: "Jim Schaad (Exchange)" <[e-mail]>
Cc: [e-mail]
Subject: Re: More X942-03 Comments
References: <2FBF98FC7852CF11912A0000000000010ECB5ADF@DINO>
From: EKR <[e-mail]>
Date: 20 Nov 1998 16:41:04 -0800
In-Reply-To: "Jim Schaad's message of "Fri, 20 Nov 1998 16:28:48 -0800"
Message-ID: <[e-mail]>
Lines: 40
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Jim Schaad (Exchange)" <[e-mail]> writes:
> 1.  Section 2.1.2 in the paragraph on pubInfo:  There is a description that
> appears to say CMS defined UserKeyingMaterial as a 512-bit value.  There are
> two problems with this: a) CMS does not say anything about the length of ukm
> and b) no justification is shown here for a length of 512-bits.  Is this a
> magic length?
I'm trying to remember myself. ISTR that some previous CMS version
had 512 bits. I'm not fixated on this number by any means.
IIRC, KEA uses 512 bits.

> 2.  Section 2.1.4:  Please append the following or something similar. "Note:
> RC2 is restricted to effective key lengths of 128-bits or fewer.  Expansion
> of 128-bits of input key to a 256-bit effective key length does not add any
> additional security."
Will do.

> 3.  Section 2.1.6:  I don't recognize the 3DES oid that you have here.  I
> was expecting to see "06 09 1a 86 48 86 f7 0d 03 07" with a comment of
> "DES-EDE3-CBC OID"
>
> 4.  Section 2.1.7:  The counter is incorrect.
Yes The examples are wrong. Stephen Henson and I have now 
agreed on an example set that will go out in the next revision.

> 5.  Section 2.2:  I think we need to change the value of m.  If we are
> suggesting a value of m for DES and CMS is saying that 3DES is the manditory
> algorithm, then we are not making any sense.  I think that we need to have a
> value of m which is appropriate for 3DES, and potentially a rule of thumb
> for shorter key lengths.
Correct. See my previous comments on this topic in my message to
Russ. I'm concerned about the parameter generation algorithm.

> 6.  Section 2.1.5:  This section ends with the phrase "may not be
> necessary".  This gives no information to make an intellegient guess if this
> is required or not.  Can we add some text about why it would or would not be
> a good idea to do this?
I'll try to produce some.

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA13972 for ietf-smime-bks; Fri, 20 Nov 1998 16:27:19 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA13964 for <[e-mail]>; Fri, 20 Nov 1998 16:26:37 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <XDHGS5LP>; Fri, 20 Nov 1998 16:28:51 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5ADF@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'EKR'" <[e-mail]>, [e-mail]
Subject: More X942-03 Comments
Date: Fri, 20 Nov 1998 16:28:48 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

1.  Section 2.1.2 in the paragraph on pubInfo:  There is a description that
appears to say CMS defined UserKeyingMaterial as a 512-bit value.  There are
two problems with this: a) CMS does not say anything about the length of ukm
and b) no justification is shown here for a length of 512-bits.  Is this a
magic length?

2.  Section 2.1.4:  Please append the following or something similar. "Note:
RC2 is restricted to effective key lengths of 128-bits or fewer.  Expansion
of 128-bits of input key to a 256-bit effective key length does not add any
additional security."

3.  Section 2.1.6:  I don't recognize the 3DES oid that you have here.  I
was expecting to see "06 09 1a 86 48 86 f7 0d 03 07" with a comment of
"DES-EDE3-CBC OID"

4.  Section 2.1.7:  The counter is incorrect.

5.  Section 2.2:  I think we need to change the value of m.  If we are
suggesting a value of m for DES and CMS is saying that 3DES is the manditory
algorithm, then we are not making any sense.  I think that we need to have a
value of m which is appropriate for 3DES, and potentially a rule of thumb
for shorter key lengths.

6.  Section 2.1.5:  This section ends with the phrase "may not be
necessary".  This gives no information to make an intellegient guess if this
is required or not.  Can we add some text about why it would or would not be
a good idea to do this?

jim


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13710 for ietf-smime-bks; Fri, 20 Nov 1998 15:40:39 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA13706 for <[e-mail]>; Fri, 20 Nov 1998 15:40:38 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 20 Nov 98 15:44:37 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XF1JC821>; Fri, 20 Nov 1998 15:44:37 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, <[e-mail]>
Subject: RE: Comments on MSG spec
Date: Fri, 20 Nov 1998 15:44:34 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A4B216F7082-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Friday, November 20, 1998 8:22 AM
> To: [e-mail]
> Subject: Comments on MSG spec
> 
>         1.  Section 2.5.3, the first paragraph is pretty 
> rough reading. 
> Recommend that the last two sentences be changed to something like:
> This attribute tells the receiver which of the sender's 
> certificates should be
> used for encrypting the session key when the receiver later 
> wants to send an
> encrypted message to the sender.  This attribute simplifies 
> interoperability
> among clients that use separate keys for signing and encryption.

Agree.

>         2.  Section 2.5.3, last paragraph:  Second sentence 
> (the one in
> parentheses):  change "to" to "too".  Third sentence, change 
> "senders" to
> "sender's".

Agree.

>         3.  Section 2.6, first sentence:  Is the reference to 
> [DES] dangling? 
> It would seem that one reference to tripleDES would be sufficient.

Not dangling -- [DES] tells you how to implement DES, [3DES] tells you how
to implement triple-DES, but not DES.

By the way, I think that the 3DES reference sucks (a 1979 IEEE Spectrum
article?).  Any suggestions?

>         4. Section 2.6, second sentence:  This is rough 
> wording.  What do you
> mena by "RC2 ... or a compatible algorithm"?  Which 
> algorithms are "compatible"
> with RC2?

I believe that the theory here is that RC2 is or was a trademark of RSADSI,
and so use of that trademark (that little (r) in the title of RFC2268)
seemed to indicate that "if you had another algorithm with a different name
that behaved exactly the same way, you'd be free and clear from any
potential IP concerns using RC2 in box copy, etc."

>         5.  Section 2.6.3 is essentially repeated in the Security
> Considerations
> section.  It's better there, anyway; I recommend deleting 2.6.3.

I agree with Paul's comments here.  Can't complain too much about this.

> 
>         6.  Section 3.1, last paragraph before 3.1.1:  this 
> paragraph is out of
> place.  It belongs in Section 4, if it's not already covered there.

I agree with Paul's comments here.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA13664 for ietf-smime-bks; Fri, 20 Nov 1998 15:30:02 -0800 (PST)
Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.8.8/8.8.5) with SMTP id PAA13660 for <[e-mail]>; Fri, 20 Nov 1998 15:30:01 -0800 (PST)
Received: from 208.236.41.9 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.2); Fri, 20 Nov 98 15:33:37 -0800
X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5
Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id <XF1JC8HW>; Fri, 20 Nov 1998 15:33:37 -0800
Message-ID: <[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>, <[e-mail]>
Subject: RE: Comment on draft-ietf-cert-05.txt
Date: Fri, 20 Nov 1998 15:33:35 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
X-WSS-ID: 1A4B23DB6980-01-01
Content-Type: text/plain;  charset=iso-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

> -----Original Message-----
> From: Al Arsenault [mailto:[e-mail]]
> Sent: Friday, November 20, 1998 11:11 AM
> To: [e-mail]
> Subject: Comment on draft-ietf-cert-05.txt
> 
> There are no PKIX v1 certificates.  (This looks like an artifact of a
> global replacement X.509 -> PKIX.)  Recommend that this be changed to
> "Receiving agents MUST support PKIX certificates..."  unless 
> there is some
> other type of certificates that you want to support (say, for backward
> compatibility with S/MIMEv2).  If there is such a type of 
> certificates,
> please identify it.

However, there are PKIX certificates that have the version field set to v1.
This version field could also be set to v2, which I don't think we need to
support, and v3 which I think we do.  I understand that these version
numbers are from X.509 and not from PKIX.

I am happy to change this to simply be PKIX certificates, but the intent was
to exclude the use of (X.509) v2 certificates.  Language welcome.

Blake
--
Blake C. Ramsdell
Worldtalk Corporation
For current info, check http://www.deming.com/users/blaker
Voice [phone] x103  Fax [phone]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13304 for ietf-smime-bks; Fri, 20 Nov 1998 14:06:59 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA13300; Fri, 20 Nov 1998 14:06:58 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 14:10:20 -0800
To: Al Arsenault <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Comment on draft-ietf-cert-05.txt
In-Reply-To: <4.1.19981120140615.00a555b0@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 02:11 PM 11/20/98 -0500, Al Arsenault wrote:
>	The CERT draft, section 2.2, first sentence, says "Receiving agents MUST
>support PKIX V1 and PKIX v3 certificates..."
>
>There are no PKIX v1 certificates.  (This looks like an artifact of a
>global replacement X.509 -> PKIX.)  Recommend that this be changed to
>"Receiving agents MUST support PKIX certificates..."  unless there is some
>other type of certificates that you want to support (say, for backward
>compatibility with S/MIMEv2).  If there is such a type of certificates,
>please identify it.

I agree. I think we should just say "...support PKIX certificates." This is
particularly hairy because PKIX version 2 certificates have a "1" in their
version field and so on.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA13280 for ietf-smime-bks; Fri, 20 Nov 1998 14:03:08 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA13275; Fri, 20 Nov 1998 14:03:06 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 14:06:44 -0800
To: Al Arsenault <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Comments on MSG spec
In-Reply-To: <4.1.19981120111142.00a43100@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 11:21 AM 11/20/98 -0500, Al Arsenault wrote:
>        1.  Section 2.5.3, the first paragraph is pretty rough reading. 
>Recommend that the last two sentences be changed to something like:
>This attribute tells the receiver which of the sender's certificates should be
>used for encrypting the session key when the receiver later wants to send an
>encrypted message to the sender.  This attribute simplifies interoperability
>among clients that use separate keys for signing and encryption.

That sounds good to me.

>        3.  Section 2.6, first sentence:  Is the reference to [DES] dangling? 
>It would seem that one reference to tripleDES would be sufficient.

I think we can take out the [DES] reference.

>        4. Section 2.6, second sentence:  This is rough wording.  What do you
>mena by "RC2 ... or a compatible algorithm"?  Which algorithms are
"compatible"
>with RC2?

Don't ask. It's a bad historical artifact. We should definitely remove the
"or a compatible algorithm".

>        5.  Section 2.6.3 is essentially repeated in the Security
>Considerations
>section.  It's better there, anyway; I recommend deleting 2.6.3.

I disagree, because without it 2.6 is incomplete. I think the duplication
is OK.

>        6.  Section 3.1, last paragraph before 3.1.1:  this paragraph is
out of
>place.  It belongs in Section 4, if it's not already covered there.

I disagree. Section 4 has nothing about this topic. True, we don't have a
separate section on "what to do when you receive an S/MIME message", but I
think discussing it for each type of message is just fine.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA12274 for ietf-smime-bks; Fri, 20 Nov 1998 11:14:10 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA12270 for <[e-mail]>; Fri, 20 Nov 1998 11:14:09 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id OAA21710 for <[e-mail]>; Fri, 20 Nov 1998 14:18:14 -0500
Message-Id: <4.1.19981120140615.00a555b0@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 14:11:22 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Comment on draft-ietf-cert-05.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Once again, reviewing documents for the first time in a while; apologies if
this is OBE, but:

	The CERT draft, section 2.2, first sentence, says "Receiving agents MUST
support PKIX V1 and PKIX v3 certificates..."

There are no PKIX v1 certificates.  (This looks like an artifact of a
global replacement X.509 -> PKIX.)  Recommend that this be changed to
"Receiving agents MUST support PKIX certificates..."  unless there is some
other type of certificates that you want to support (say, for backward
compatibility with S/MIMEv2).  If there is such a type of certificates,
please identify it.

					Al Arsenault


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10504 for ietf-smime-bks; Fri, 20 Nov 1998 08:24:46 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10500 for <[e-mail]>; Fri, 20 Nov 1998 08:24:45 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA15445 for <[e-mail]>; Fri, 20 Nov 1998 11:28:49 -0500
Message-Id: <4.1.19981120111142.00a43100@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 11:21:50 -0500
To: [e-mail]
From: Al Arsenault <[e-mail]>
Subject: Comments on MSG spec
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Folks,

        I've had a chance to look at a few of the documents again recently.
 The
latest version of the MSG spec on the web server is
draft-ietf-smime-msg-5.txt.  I have a few minor comments on that document;
apologies if any or all of these are OBE.

        1.  Section 2.5.3, the first paragraph is pretty rough reading. 
Recommend that the last two sentences be changed to something like:
This attribute tells the receiver which of the sender's certificates should be
used for encrypting the session key when the receiver later wants to send an
encrypted message to the sender.  This attribute simplifies interoperability
among clients that use separate keys for signing and encryption.

        2.  Section 2.5.3, last paragraph:  Second sentence (the one in
parentheses):  change "to" to "too".  Third sentence, change "senders" to
"sender's".

        3.  Section 2.6, first sentence:  Is the reference to [DES] dangling? 
It would seem that one reference to tripleDES would be sufficient.

        4. Section 2.6, second sentence:  This is rough wording.  What do you
mena by "RC2 ... or a compatible algorithm"?  Which algorithms are "compatible"
with RC2?

        5.  Section 2.6.3 is essentially repeated in the Security
Considerations
section.  It's better there, anyway; I recommend deleting 2.6.3.

        6.  Section 3.1, last paragraph before 3.1.1:  this paragraph is out of
place.  It belongs in Section 4, if it's not already covered there.

                                        Al Arsenault


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10445 for ietf-smime-bks; Fri, 20 Nov 1998 08:15:18 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10441 for <[e-mail]>; Fri, 20 Nov 1998 08:15:16 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id IAA10121; Fri, 20 Nov 1998 08:20:16 -0800 (PST)
To: Russ Housley <[e-mail]>
Cc: [e-mail]
Subject: Re: X942-03
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 20 Nov 1998 08:20:15 -0800
In-Reply-To: Russ Housley's message of "Thu, 19 Nov 1998 16:55:40 -0500"
Message-ID: <[e-mail]>
Lines: 67
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Russ Housley <[e-mail]> writes:
> For consistency, please use the spelling that CMS inherited from PKCS#7 v1.5:
> 	key-encryption key
> 	content-encryption key
All right.

> I expected section 2.1.1 to include: g^q (mod p) == 1.
I'm not sure that this is sufficient. However, it follows from
the following criterion, (which I just added) which is listed 
in FIPS-186

      h is any integer with 1 < h < p-1 such that h(p-1)/q mod p > 1
        (g has order q mod p)


> In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
> symmetric algorithm with which this KEK will be used."  I think it would be
> more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
> algorithm identifier; no parameters associated with the symmetric algorithm
> identifier are used.
How about:
algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which 
  this KEK will be used. Note that this is NOT an AlgorithmIdentifier,
  but simply the OBJECT IDENTIFIER. No paramters are used.

> Later in section 2.1.2, you say: "Note that pubInfo is required in
> Static-Static mode, but MAY appear in Ephemeral-Static mode."  I would
> prefer to see the first half of the sentence reworded to include "MUST."
Note that pubInfo MUST be used in Static-Static mode,
but MAY appear in Ephemeral-Static mode.

> In section 2.1.5, you need to upcase "MAY NOT."
Hmm... This makes me a little queasy. This is a descriptive, not
prescriptive statement...

> In section 2.2, you say: " When symmetric ciphers stronger than DES are to
> be used, a larer m may be advisable."  This screams for a paragraph in
> Security Consderations.
> 
> Please add a section parallel to section 2.3 that describes Static-Static
> Mode.  The term is used in the body of the document, so it probably needs a
> description.
All right.

> Please add a paragraph is the security Considerations section regarding the
> size of the private key, x, and the size of the generated symmetric keys.
> In general, the private key need to be twices the size of the resulting
> symmetric keys.  Note: KEA uses a 160 bit private key to generate 80 bit
> SKIPJACK keys.
I agree that you are correct here, but this puts us in very unpleasant
waters: 
The FIPS-186 key/parameter generation algorithm only describes how
to generate for m==160. X9.42 DOES describe how to generate for
<arbitrary m. However, X9.42 isn't publicly available, so we shouldn't
make a normative reference to it, but rather should describe the
procedure inline.

I suppose I could try to write something like:
Follow FIPS-186, except substituting 'm' for 160, but I'm pretty
nervous about that. 

I'd like to get the sense of the group here.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA10344 for ietf-smime-bks; Fri, 20 Nov 1998 08:04:05 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA10340 for <[e-mail]>; Fri, 20 Nov 1998 08:04:04 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id LAA14492; Fri, 20 Nov 1998 11:07:12 -0500
Message-Id: <4.1.19981120105848.00a5c690@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 11:00:22 -0500
To: EKR <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: X942-03 Comments
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <Al Arsenault's message of "Fri, 20 Nov 1998 08:01:25 -0500"> <"Hollenbeck, Scott"'s message of "Tue, 17 Nov 1998 13:09:56 -0500"> <000501be1255$7c549270$[e-mail]> <4.1.19981120075821.00a5a680@209.172.119.123>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 08:03 AM 11/20/98 -0800, EKR wrote:
>Al Arsenault <[e-mail]> writes:
>> One minor nit on <draft-ieft-smime-x942-03>:  Section 2.1.2, you don't
>> fully explain how "counter" works.  You note that it has an initial value
>> of 1, but don't indicate whether it should be incremented based on number
>> of bytes, number of keys generated, etc.
>Fair enough. 
>How's the following language?
>
>counter is a 32 bit number, represented in network byte order. Its
>  initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 (hex),
>  and it is incremented by one every time the above key generation
>  function is run with a given ZZ.
>
>-Ekr
>
>-- 
>[Eric Rescorla                                   [e-mail]]


Fine.  This indicates both when & by how much you increment, and when you
reset to the initial value.


				Al Arsenault

-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA10309 for ietf-smime-bks; Fri, 20 Nov 1998 07:59:12 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA10305 for <[e-mail]>; Fri, 20 Nov 1998 07:59:03 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id IAA10007; Fri, 20 Nov 1998 08:03:37 -0800 (PST)
To: Al Arsenault <[e-mail]>
Cc: <[e-mail]>
Subject: Re: X942-03 Comments
References: <"Hollenbeck, Scott"'s message of "Tue, 17 Nov 1998 13:09:56 -0500"> <000501be1255$7c549270$[e-mail]> <4.1.19981120075821.00a5a680@209.172.119.123>
From: EKR <[e-mail]>
Date: 20 Nov 1998 08:03:36 -0800
In-Reply-To: Al Arsenault's message of "Fri, 20 Nov 1998 08:01:25 -0500"
Message-ID: <[e-mail]>
Lines: 17
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Al Arsenault <[e-mail]> writes:
> One minor nit on <draft-ieft-smime-x942-03>:  Section 2.1.2, you don't
> fully explain how "counter" works.  You note that it has an initial value
> of 1, but don't indicate whether it should be incremented based on number
> of bytes, number of keys generated, etc.
Fair enough. 
How's the following language?

counter is a 32 bit number, represented in network byte order. Its
  initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01 (hex),
  and it is incremented by one every time the above key generation
  function is run with a given ZZ.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09331 for ietf-smime-bks; Fri, 20 Nov 1998 05:48:12 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09327 for <[e-mail]>; Fri, 20 Nov 1998 05:48:11 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA09426; Fri, 20 Nov 1998 08:51:21 -0500
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: rhousley#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 19 Nov 1998 16:55:40 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: X942-03
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

It is looking good.  I have a few comments.

For consistency, please use the spelling that CMS inherited from PKCS#7 v1.5:
	key-encryption key
	content-encryption key

I expected section 2.1.1 to include: g^q (mod p) == 1.

In section 2.1.2, you say: "algorithm is the ASN.1 algorithm OID of the
symmetric algorithm with which this KEK will be used."  I think it would be
more clear to say that is is the OBJECT IDENTIFIER protion of the symmetric
algorithm identifier; no parameters associated with the symmetric algorithm
identifier are used.

Later in section 2.1.2, you say: "Note that pubInfo is required in
Static-Static mode, but MAY appear in Ephemeral-Static mode."  I would
prefer to see the first half of the sentence reworded to include "MUST."

In section 2.1.5, you need to upcase "MAY NOT."

In section 2.2, you say: " When symmetric ciphers stronger than DES are to
be used, a larer m may be advisable."  This screams for a paragraph in
Security Consderations.

Please add a section parallel to section 2.3 that describes Static-Static
Mode.  The term is used in the body of the document, so it probably needs a
description.

Please add a paragraph is the security Considerations section regarding the
size of the private key, x, and the size of the generated symmetric keys.
In general, the private key need to be twices the size of the resulting
symmetric keys.  Note: KEA uses a 160 bit private key to generate 80 bit
SKIPJACK keys.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA09146 for ietf-smime-bks; Fri, 20 Nov 1998 05:05:19 -0800 (PST)
Received: from thehub.knight-hub.com ([e-mail] [205.177.16.3]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA09141 for <[e-mail]>; Fri, 20 Nov 1998 05:05:18 -0800 (PST)
Received: from intern_pc ([205.177.169.194]) by thehub.knight-hub.com (8.8.8/8.8.8) with SMTP id IAA08067; Fri, 20 Nov 1998 08:08:15 -0500
Message-Id: <4.1.19981120075821.00a5a680@209.172.119.123>
X-Sender: aarsenault#mail.spyrus.com@209.172.119.123
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 20 Nov 1998 08:01:25 -0500
To: EKR <[e-mail]>
From: Al Arsenault <[e-mail]>
Subject: Re: X942-03 Comments
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <"Hollenbeck, Scott"'s message of "Tue, 17 Nov 1998 13:09:56 -0500"> <000501be1255$7c549270$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

One minor nit on <draft-ieft-smime-x942-03>:  Section 2.1.2, you don't
fully explain how "counter" works.  You note that it has an initial value
of 1, but don't indicate whether it should be incremented based on number
of bytes, number of keys generated, etc.

			Al Arsenault


-- these are my opinions only. They do not necessarily reflect the 
opinions of my employer, or of any other organization with which I have a 
relationship.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA07563 for ietf-smime-bks; Thu, 19 Nov 1998 00:40:10 -0800 (PST)
Received: from ns0.eris.dera.gov.uk (ns0.eris.dera.gov.uk [128.98.1.1]) by mail.proper.com (8.8.8/8.8.5) with SMTP id AAA07557 for <[e-mail]>; Thu, 19 Nov 1998 00:40:09 -0800 (PST)
Received: (qmail 18444 invoked from network); 19 Nov 1998 08:44:11 -0000
Received: from unknown (HELO mail-relay.eris.dera.gov.uk) (128.98.2.7) by ns0.eris.dera.gov.uk with SMTP; 19 Nov 1998 08:44:11 -0000
Received: (qmail 32014 invoked from network); 19 Nov 1998 08:44:06 -0000
Received: from wottoway.eris.dera.gov.uk (HELO wottaway.eris.dera.gov.uk) (128.98.10.17) by mail-relay.eris.dera.gov.uk with SMTP; 19 Nov 1998 08:44:06 -0000
Received: by localhost with Microsoft MAPI; Thu, 19 Nov 1998 08:43:30 -0000
Message-ID: <[e-mail]>
From: William Ottaway <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: draft-ietf-smime-domsec-01.txt
Date: Thu, 19 Nov 1998 08:43:27 -0000
X-Mailer: Microsoft Internet E-mail/MAPI - 8.0.0.4211
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Hi all,

This new draft is a result of the comments I received at the Chicago 
meeting. I hope to go through the changes at the Orlando meeting and also 
take the opportunity to talk about the future of the paper.

Bill.

___________________________________________________

William Ottaway
L323,                               Tel: [phone]
DERA Malvern,                Fax: [phone]
St. Andrews Road,          email: [e-mail]
Malvern,
Worcs,
WR14 3PS




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA03044 for ietf-smime-bks; Wed, 18 Nov 1998 14:16:29 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA03040 for <[e-mail]>; Wed, 18 Nov 1998 14:16:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id RAA07540; Wed, 18 Nov 1998 17:19:50 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-domsec-01.txt
Date: Wed, 18 Nov 1998 17:19:50 -0500
Sender: [e-mail]
Precedence: bulk

--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-01.txt
	Pages		: 8
	Date		: 17-Nov-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.
 
This draft is being discussed on the 'ietf-smime' mailing list. To
subscribe, send a message to:
     [e-mail]
with the single word
     subscribe
in the body of the message. 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-domsec-01.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-domsec-01.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-domsec-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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00624 for ietf-smime-bks; Wed, 18 Nov 1998 10:02:35 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA00620 for <[e-mail]>; Wed, 18 Nov 1998 10:02:33 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zgBzk-0005qS-00 for [e-mail]; Wed, 18 Nov 1998 18:06:24 +0000
Message-ID: <[e-mail]>
Date: Wed, 18 Nov 1998 16:15:45 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: DH certificate examples?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

The CMS mandatory algorithms imply that implementations must be able to
handle DH and DSA. In certificate terms this (presumably) means a
certificate carrying a DSA key signed by an authority with a DSA key and
a certificate carrying a DH key signed by an authority with a DSA key.

The PKIX examples include DSA signed by DSA but not DH signed by DSA.
Does an example of such a certificate exist?

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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA02723 for ietf-smime-bks; Tue, 17 Nov 1998 11:22:17 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA02719 for <[e-mail]>; Tue, 17 Nov 1998 11:22:16 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id LAA00936; Tue, 17 Nov 1998 11:26:55 -0800 (PST)
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Re: X942-03 Comments
References: <000501be1255$7c549270$[e-mail]>
From: EKR <[e-mail]>
Date: 17 Nov 1998 11:26:53 -0800
In-Reply-To: "Hollenbeck, Scott"'s message of "Tue, 17 Nov 1998 13:09:56 -0500"
Message-ID: <[e-mail]>
Lines: 19
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

"Hollenbeck, Scott" <[e-mail]> writes:
> Just dropping in with a few mechanical comments:
> 
> The title page header still refers to revision #2.
> 
> In the Abstract, "Diffie-Hellam" should be "Diffie-Hellman".
> 
> Section 1.2: RFC 2119 is referenced but it doesn't appear in
> the list of referenced documents.
> 
> Section 2.1.1, last paragraph: "In CMS" should be "In [CMS]".
> 
> It's good to see all of this work progressing along nicely!
Thanks. I've made the editorial changes. 

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02354 for ietf-smime-bks; Tue, 17 Nov 1998 10:43:48 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA02350 for <[e-mail]>; Tue, 17 Nov 1998 10:43:47 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zfqA5-0002mk-00 for [e-mail]; Tue, 17 Nov 1998 18:47:37 +0000
Message-ID: <[e-mail]>
Date: Tue, 17 Nov 1998 18:46:28 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: X942-03 Comments
References: <000501be1255$7c549270$[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

One minor comment: 2.1.7 says "no pubInfo is used" but the hexdump says
that some is used.

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA02001 for ietf-smime-bks; Tue, 17 Nov 1998 10:05:12 -0800 (PST)
Received: from ops1.internic.net (ops1.internic.net [198.41.1.248]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA01996 for <[e-mail]>; Tue, 17 Nov 1998 10:05:10 -0800 (PST)
Received: from largo (largo.internic.net [198.41.2.244]) by ops1.internic.net (8.9.1/8.9.1) with SMTP id NAA02091 for <[e-mail]>; Tue, 17 Nov 1998 13:09:14 -0500 (EST)
Reply-To: <[e-mail]>
From: "Hollenbeck, Scott" <[e-mail]>
To: <[e-mail]>
Subject: X942-03 Comments
Date: Tue, 17 Nov 1998 13:09:56 -0500
Message-ID: <000501be1255$7c549270$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

Just dropping in with a few mechanical comments:

The title page header still refers to revision #2.

In the Abstract, "Diffie-Hellam" should be "Diffie-Hellman".

Section 1.2: RFC 2119 is referenced but it doesn't appear in
the list of referenced documents.

Section 2.1.1, last paragraph: "In CMS" should be "In [CMS]".

It's good to see all of this work progressing along nicely!

Scott Hollenbeck (mailto:[e-mail])
Network Solutions, Inc.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA01414 for ietf-smime-bks; Tue, 17 Nov 1998 08:56:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA01410 for <[e-mail]>; Tue, 17 Nov 1998 08:56:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id LAA08280; Tue, 17 Nov 1998 11:59:25 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-03.txt
Date: Tue, 17 Nov 1998 11:59:24 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-03.txt
	Pages		: 7
	Date		: 16-Nov-98
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
   group. Diffie-Hellam is a key agreement algorithm used by two parties
   to agree on a shared secret. An algorithm for converting the shared
   secret into an arbitrary amount of keying material is provided. The
   resulting keying material is used as a symmetric encryption key.  The
   D-H variant described requires the recipient to have a certificate,
   but the originator may have a static key pair (with the public key
   placed in a certificate) or an ephemeral key pair.

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

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-03.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x942-03.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA29822 for ietf-smime-bks; Tue, 17 Nov 1998 05:22:36 -0800 (PST)
Received: from smtp2.erols.com (smtp2.erols.com [207.172.3.235]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA29818 for <[e-mail]>; Tue, 17 Nov 1998 05:22:34 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-111-161.s161.tnt1.ann.erols.com [207.172.111.161]) by smtp2.erols.com (8.8.8/8.8.5) with ESMTP id IAA21859; Tue, 17 Nov 1998 08:27:15 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: "Jim Schaad (Exchange)" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: Comments on smime-cms-07
Date: Tue, 17 Nov 1998 08:21:45 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

We can certainly live with a hash of the content, rather than
a MAC.

Regards,
Rich

----------
> From: Russ Housley <[e-mail]>
> To: Jim Schaad (Exchange) <[e-mail]>
> Cc: [e-mail]
> Subject: RE: Comments on smime-cms-07
> Date: Monday, November 16, 1998 5:43 PM
> 
> Jim:
> 
> >> >3.  Section 9 - Authenticated-data Content Type:  I think I 
> >> have identified
> >> >what I consider to be a security weakness.  Specifically if 
> >> you create an
> >> >authenticated data object with authenticated attributes, I 
> >> can remove the
> >> >authenticated attributes and come up with a stil legal 
> >> authenticated data
> >> >object.  To fix this I propose that we change authenticated 
> >> data in the
> >> >following ways:
> >> >  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
> >> >  b) autenticatedAttributes becomes a REQUIRED field (remove 
> >> the OPTIONAL)
> >> >  c) a digest-value becomes a required attribute in the
> >> >autenticatedAttributes (replacing mac-value)
> >> >  d) in processing, you hash the encapContentInfo, put the has in the
> >> >authenticated attributes and MAC this value.
> >> 
> >> I understand your proposed change, but I do not understand 
> >> the "security
> >> weakness."  In CMS-07, two MAC values are computed.  The 
> >> first MAC value is
> >> computed from the content, then this MAC value is encoded in 
> >> an authenticated
> >> attribute.  The second MAC value is computed from the DER 
> >> encoded attributes. 
> >> The two MAC values should not be the same.  So, if the 
> >> attributes are removed
> >> by an attacker, the MAC value check should fail.
> >> 
> >> If you are concerned about an attacker who is a recipient, 
> >> and thus has the
> >> symmetic key needed to compute the MAC, then I do not think 
> >> that anything can
> >> be done to make authenticated-data secure.
> >
> >What I am looking at is more of a man in the middle attack.  If I
intercept
> >the message, I can modify it and then send on to the receiptient after
> >having removed all of the attributes.  Since I have removed all of the
> >attributes only one MAC computation would be computed and that is the
same
> >MAC computation as was in the attributes as the macValue.
> 
> Are yo saying that the attacker can take the value from the attribute and
> place it in the authenticated-data macValue?  The value in the attribute
is
> exactly the one needed if there were no attributes present.  You are
> correct, this is a problem.
> 
> Rick Ankney, are you out there?  Would your customers accept a hash of
the
> content in the attributes?
> 
> Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA22371 for ietf-smime-bks; Mon, 16 Nov 1998 16:06:50 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA22367 for <[e-mail]>; Mon, 16 Nov 1998 16:06:48 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-99-53.s53.tnt13.ann.erols.com [207.172.99.53]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id QAA08659; Mon, 16 Nov 1998 16:10:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 16 Nov 1998 17:43:46 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on smime-cms-07
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5A6F@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>> >3.  Section 9 - Authenticated-data Content Type:  I think I 
>> have identified
>> >what I consider to be a security weakness.  Specifically if 
>> you create an
>> >authenticated data object with authenticated attributes, I 
>> can remove the
>> >authenticated attributes and come up with a stil legal 
>> authenticated data
>> >object.  To fix this I propose that we change authenticated 
>> data in the
>> >following ways:
>> >  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
>> >  b) autenticatedAttributes becomes a REQUIRED field (remove 
>> the OPTIONAL)
>> >  c) a digest-value becomes a required attribute in the
>> >autenticatedAttributes (replacing mac-value)
>> >  d) in processing, you hash the encapContentInfo, put the has in the
>> >authenticated attributes and MAC this value.
>> 
>> I understand your proposed change, but I do not understand 
>> the "security
>> weakness."  In CMS-07, two MAC values are computed.  The 
>> first MAC value is
>> computed from the content, then this MAC value is encoded in 
>> an authenticated
>> attribute.  The second MAC value is computed from the DER 
>> encoded attributes. 
>> The two MAC values should not be the same.  So, if the 
>> attributes are removed
>> by an attacker, the MAC value check should fail.
>> 
>> If you are concerned about an attacker who is a recipient, 
>> and thus has the
>> symmetic key needed to compute the MAC, then I do not think 
>> that anything can
>> be done to make authenticated-data secure.
>
>What I am looking at is more of a man in the middle attack.  If I intercept
>the message, I can modify it and then send on to the receiptient after
>having removed all of the attributes.  Since I have removed all of the
>attributes only one MAC computation would be computed and that is the same
>MAC computation as was in the attributes as the macValue.

Are yo saying that the attacker can take the value from the attribute and
place it in the authenticated-data macValue?  The value in the attribute is
exactly the one needed if there were no attributes present.  You are
correct, this is a problem.

Rick Ankney, are you out there?  Would your customers accept a hash of the
content in the attributes?

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA21559 for ietf-smime-bks; Mon, 16 Nov 1998 14:06:20 -0800 (PST)
Received: from atlas.arc.nasa.gov (atlas-ops.arc.nasa.gov [198.123.8.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA21553 for <[e-mail]>; Mon, 16 Nov 1998 14:06:19 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-51-227.s227.tnt16.ann.erols.com [207.172.51.227]) by atlas.arc.nasa.gov (8.8.5/8.7.3/arc) with SMTP id OAA18962; Mon, 16 Nov 1998 14:10:02 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 16 Nov 1998 14:16:01 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Comments on CMS-08
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5A9D@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>1.  Section 5.3 paragraph #2 page 8.  The new text on content-type
>attribute, the 3 sentence should start "The content-type attribute is not
>required" not "The content-type is not required"

Agree.  This is a simple typo.

>2.  Section 10.2.2 has a reference to PKCS#5 that should be PKCS#6

Agee.  This is also a typo, but one that has been there a long time.

>3.  Section 12.3.3:  You are stating that a Triple-DES key should be used to
>wrap an RC2 content-encryption key.

I caught this error yesterday.  It is fixed.

>I still have the problem of tieing the key-encryption key and
>content-encryption key algorithms.  But I think you said that was still and
>open issue.  If not, then I need to start lobbing to make it an open issue.

This is addressed in draft-ietf-smime-cms-09.txt.  I will send it out later
today or first thing tomorrow.  Many thanks to Steve Henson for the words
he provided on this tpoic.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA11165 for ietf-smime-bks; Sat, 14 Nov 1998 19:52:49 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA11161 for <[e-mail]>; Sat, 14 Nov 1998 19:52:48 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id QAA19157 for <[e-mail]>; Sun, 15 Nov 1998 16:56:16 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91110217602208>; Sun, 15 Nov 1998 16:56:16 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: CMS: Comment on checksum algorithm.
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sun, 15 Nov 1998 16:56:16 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson <[e-mail]> wrote:
 
>Paul Hoffman / IMC wrote:
>>Er, I really don't like "left" and "right", since a fair number of people
>>in the world write from right to left. I propose:
>> 
>>most significant (first) octet to least significant (last) octet
 
>Yes I'll go with that. "First" and "last" were the terms used in a similar 
>(but not identical) algorithm mentioned in the PKCS#11 spec.
 
The algorithm is just a Flectcher checksum, I've sent the CMS draft author a 
list of slightly more accessible references for this, perhaps it'd be possible 
to take a description of the algorithm from one of these, or at least refer to 
them for more information (including details of the properties of the 
algorithm).
 
One comment on the algorithm when it's used to check for malicious 
modifications, it may be useful to iterate it multiple times and use the 
32-bit instead of 16-bit version to avoid problems where an attacker can 
manipulate the data in a predictable way and then try to cancel it by 
adjusting the checksum (for example if the wrapping is done using CFB or OFB 
mode).  The security of an encrypted weak checksum is an open question, which 
is why I'm paranoid in my implementation (of something completely unrelated to 
CMS) and use 10 iterations of the 32-bit Fletcher checksum.  This isn't a 
problem in the current application, but who knows where the key wrapping will 
end up being used, which means an attacker could end up being able to mount a 
related-key attack if they can bend the checksum straight again after flipping 
a few key bits (or even just try an exhaustive search like Matt Blaze did with 
Clipper).  With a single iteration you can in any case flip the low keys bits 
and have a fairly high probability of being able to get the checksum correct.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA11048 for ietf-smime-bks; Sat, 14 Nov 1998 18:57:50 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA11044 for <[e-mail]>; Sat, 14 Nov 1998 18:57:49 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zesRA-0000uj-00 for [e-mail]; Sun, 15 Nov 1998 03:01:17 +0000
Message-ID: <[e-mail]>
Date: Sun, 15 Nov 1998 03:00:18 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: CMS: Comment on checksum algorithm.
References: <Dr Stephen Henson's message of "Sat, 14 Nov 1998 23:35:11 +0000"> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Paul Hoffman / IMC wrote:
> 
> 
> Er, I really don't like "left" and "right", since a fair number of people
> in the world write from right to left. I propose:
> 
> most significant (first) octet to least significant (last) octet
> 

Yes I'll go with that. "First" and "last" were the terms used in a
similar (but not identical) algorithm mentioned in the PKCS#11 spec.

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA10812 for ietf-smime-bks; Sat, 14 Nov 1998 17:12:03 -0800 (PST)
Received: from aum (ip08.proper.com [165.227.249.8]) by mail.proper.com (8.8.8/8.8.5) with SMTP id RAA10808 for <[e-mail]>; Sat, 14 Nov 1998 17:12:02 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Sat, 14 Nov 1998 17:15:17 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: CMS: Comment on checksum algorithm.
In-Reply-To: <[e-mail]>
References: <Dr Stephen Henson's message of "Sat, 14 Nov 1998 23:35:11 +0000"> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 04:44 PM 11/14/98 -0800, EKR wrote:
>> IMHO "most significant octet to least significant octet" might be
>> considered ambiguous. Perhaps "first to last octet" (assuming that's
>> what it means) would be clearer.
>It might be ambiguous, but so is 'first to last', IMHO.
>
>How about 
>'most significant (leftmost) to least significant (rightmost) octet'

Er, I really don't like "left" and "right", since a fair number of people
in the world write from right to left. I propose:

most significant (first) octet to least significant (last) octet

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA10722 for ietf-smime-bks; Sat, 14 Nov 1998 16:39:38 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA10718 for <[e-mail]>; Sat, 14 Nov 1998 16:39:37 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id QAA29546; Sat, 14 Nov 1998 16:44:18 -0800 (PST)
To: Dr Stephen Henson <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: Re: CMS: Comment on checksum algorithm.
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 14 Nov 1998 16:44:17 -0800
In-Reply-To: Dr Stephen Henson's message of "Sat, 14 Nov 1998 23:35:11 +0000"
Message-ID: <[e-mail]>
Lines: 37
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Dr Stephen Henson <[e-mail]> writes:
> Couple of comments re the checksum algorithm:
> 
> > 12.6.1  Sum of Sums Key Checksum
> > 
> >    The Sum of Sums [SUM] 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
> >             eight zero bits and the key octet.
> >        2b.  sum1 = sum1 + temp.
> >        2c.  sum2 = sum2 + sum1.
> >    3.  Use sum2 as the checksum value.
> > 
> 
> IMHO "most significant octet to least significant octet" might be
> considered ambiguous. Perhaps "first to last octet" (assuming that's
> what it means) would be clearer.
It might be ambiguous, but so is 'first to last', IMHO.

How about 
'most significant (leftmost) to least significant (rightmost) octet'

> Finally isn't the whole thing equivalent to:
> 
> {n*K_1 + (n-1)*K_2 + ... + K_n} mod 2^16
> 
> Where an K_i represents the i'th octet of an n byte key? Or am I
> misinterpreting something?
It certainly looks like it to me.

-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA08679 for ietf-smime-bks; Sat, 14 Nov 1998 15:34:00 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA08675 for <[e-mail]>; Sat, 14 Nov 1998 15:33:59 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zepG2-0002XD-00 for [e-mail]; Sat, 14 Nov 1998 23:37:34 +0000
Message-ID: <[e-mail]>
Date: Sat, 14 Nov 1998 23:35:11 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: CMS: Comment on checksum algorithm.
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Couple of comments re the checksum algorithm:

> 12.6.1  Sum of Sums Key Checksum
> 
>    The Sum of Sums [SUM] 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
>             eight zero bits and the key octet.
>        2b.  sum1 = sum1 + temp.
>        2c.  sum2 = sum2 + sum1.
>    3.  Use sum2 as the checksum value.
> 

IMHO "most significant octet to least significant octet" might be
considered ambiguous. Perhaps "first to last octet" (assuming that's
what it means) would be clearer.

I assume 2a this is just setting temp to the value of the key octet
(i.e. treat key octet as an unsigned 8 bit integer).

Finally isn't the whole thing equivalent to:

{n*K_1 + (n-1)*K_2 + ... + K_n} mod 2^16

Where an K_i represents the i'th octet of an n byte key? Or am I
misinterpreting something?

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA02598 for ietf-smime-bks; Fri, 13 Nov 1998 20:02:43 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA02594 for <[e-mail]>; Fri, 13 Nov 1998 20:02:42 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <WW0N7QZW>; Fri, 13 Nov 1998 20:05:11 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A9D@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Comments on CMS-08
Date: Fri, 13 Nov 1998 20:05:09 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

1.  Section 5.3 paragraph #2 page 8.  The new text on content-type
attribute, the 3 sentence should start "The content-type attribute is not
required" not "The content-type is not required"

2.  Section 10.2.2 has a reference to PKCS#5 that should be PKCS#6

3.  Section 12.3.3:  You are stating that a Triple-DES key should be used to
wrap an RC2 content-encryption key.

-----

I still have the problem of tieing the key-encryption key and
content-encryption key algorithms.  But I think you said that was still and
open issue.  If not, then I need to start lobbing to make it an open issue.

jim



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA27834 for ietf-smime-bks; Fri, 13 Nov 1998 09:03:36 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA27830 for <[e-mail]>; Fri, 13 Nov 1998 09:03:33 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id MAA18422; Fri, 13 Nov 1998 12:05:30 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 13 Nov 1998 12:02:34 -0500
To: Russ Housley <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: RE: Comments on smime-cms-07
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <2FBF98FC7852CF11912A0000000000010ECB5A6F@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Russ,

The only reference I know for 3DES MAC is from Section 8.5 of PKCS#11 on
"Data Types for Mechanisms" where it is included in the list of mechanism
types that could be supported by a token as follow:

 For Cryptoki Version 2.01, the following mechanism types are defined:

 #define CKM_DES3_MAC                   0x00000134
 #define CKM_DES3_MAC_GENERAL           0x00000135

Francois Rousseau
AEPOS Technologies

At 03:49 PM 12/11/98 -0500, you wrote:
>Francois:
>
>I guess that I should remove DES MAC.
>
>I do not know of any reference fro 3DES MAC.
>
>Russ
>
>At 08:10 AM 11/11/98 -0500, Francois Rousseau wrote:
>>Russ,
>>
>>Further to Jim's EMail and although I did not attend the meeting in
>>Chicago, the minutes of the meeting on this issue states that:
>>
>>"Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
>>by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
>>algorithm.  The wording in CMS will be: "If authenticatedData is
>>implemented, then HMAC-with-SHA1 must be implemented."  The group also
>>decided that DES MAC will not be included in CMS as an optional algorithm." 
>>
>>As suggested by Jim, I would for myself prefer 3DES MAC as a "may" instead
>>of DES MAC. 
>>
>>Francois Rousseau
>>AEPOS Technologies
>>
>><snip>
>>>> 
>>>>> 5.  Section 12.5.2.  DES MAC should be struck and replace 
>>>>> with 3DES MAC.
>>>> 
>>>> My notes from Chicago indicate that HMAC with SHA-1 and DES 
>>>> MAC are the two
>>>> algorithms that will be included.  As 12.5 says: "CMS 
>>>> implementations that
>>>> support authenticatedData must include HMAC with SHA-1.  CMS 
>>>> implementations
>>>> may also include DES MAC."
>>>
>>>I'll believe your notes over my memory.  I had thought that DES MAC was
>>>struck and replaced with 3DES MAC.
>>>
>>>> 
>>>> 
>>>> Enjoy,
>>>>   Russ
>>>> 
>>>
>>>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA26548 for ietf-smime-bks; Fri, 13 Nov 1998 05:40:28 -0800 (PST)
Received: from mail.maxware.nl (mail.maxware.nl [195.193.216.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA26544 for <[e-mail]>; Fri, 13 Nov 1998 05:40:26 -0800 (PST)
X-Internal-ID: 36482F110000015B
Received: from mail (195.193.216.130) by mail.maxware.nl (NPlex 2.0.098); 13 Nov 1998 14:43:31 +0100
Reply-To: "Frank W. Nolden" <[e-mail]>
From: "Frank W. Nolden" <[e-mail]>
To: <[e-mail]>, <Stefan_Salzmann/HAM/[e-mail]>
Subject: ASN.1 compiler
Date: Fri, 13 Nov 1998 14:43:27 +0100
Message-ID: <01be0f0b$98031bb0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0282_01BE0F13.F9C783B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0282_01BE0F13.F9C783B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


Hi Stefan,

I have received an email some time ago from van Dyke and Associates with =
a
reference to their website where they have put a freeware GNU SNACC =
ASN.1
compiler and library. Source code is provided.
The site address is (at least it was):

http://www.jgvandyke.com/services/infosec/sfl.htm

Hope this helps.
Regards,

Frank W. Nolden
Systems Architect

MaXware Benelux BV
tel: [phone]
email: [e-mail]
SMS email: [e-mail]



-----Original Message-----
From: Stefan_Salzmann/HAM/[e-mail]
<Stefan_Salzmann/HAM/[e-mail]>
To: [e-mail] <[e-mail]>
Date: Wednesday, November 11, 1998 7:31 PM
Subject: ASN.1 Toolkit


>Hello Everybody,
>
>does anyone know a free ASN.1 Toolkit for developing ASN.1 =
specifications
and
>encoding them. Are there any free resources on the internet?
>
>Thanks for your response
>Stefan
>
>
>



----------------------------------------------------------------
INFORMATION    AUTOMATIC VIRUS CHECK (GEMPLUS)   No virus known.
----------------------------------------------------------------






----------------------------------------------------------------
INFORMATION    AUTOMATIC VIRUS CHECK (GEMPLUS)   No virus known.
----------------------------------------------------------------







------=_NextPart_000_0282_01BE0F13.F9C783B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.71.1712.3"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><BR>Hi Stefan,<BR><BR>I have received an email some time ago from =
van Dyke=20
and Associates with a<BR>reference to their website where they have put =
a=20
freeware GNU SNACC ASN.1<BR>compiler and library. Source code is=20
provided.<BR>The site address is (at least it was):<BR><BR><A=20
href=3D"http://www.jgvandyke.com/services/infosec/sfl.htm">http://www.jgv=
andyke.com/services/infosec/sfl.htm</A><BR><BR>Hope=20
this helps.<BR>Regards,<BR><BR>Frank W. Nolden<BR>Systems=20
Architect<BR><BR>MaXware Benelux BV<BR>tel: [phone]<BR>email: =
<A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR>SM=
S email:=20
+<A=20
href=3D"mailto:[e-mail]">[e-mail]</A><BR><BR><BR><BR>=
-----Original=20
Message-----<BR>From: <A=20
href=3D"mailto:Stefan_Salzmann/HAM/[e-mail]">Stefan_Salzmann/HAM/L=
[e-mail]</A><BR>&lt;<A=20
href=3D"mailto:Stefan_Salzmann/HAM/[e-mail]">Stefan_Salzmann/HAM/L=
[e-mail]</A>&gt;<BR>To:=20
<A href=3D"mailto:[e-mail]">[e-mail]</A> &lt;<A=20
href=3D"mailto:[e-mail]">[e-mail]</A>&gt;<BR>Date: =
Wednesday,=20
November 11, 1998 7:31 PM<BR>Subject: ASN.1 Toolkit<BR><BR><BR>&gt;Hello =

Everybody,<BR>&gt;<BR>&gt;does anyone know a free ASN.1 Toolkit for =
developing=20
ASN.1 specifications<BR>and<BR>&gt;encoding them. Are there any free =
resources=20
on the internet?<BR>&gt;<BR>&gt;Thanks for your=20
response<BR>&gt;Stefan<BR>&gt;<BR>&gt;<BR>&gt;<BR><BR><BR><BR>-----------=
-----------------------------------------------------<BR>INFORMATION&nbsp=
;&nbsp;&nbsp;=20
AUTOMATIC VIRUS CHECK (GEMPLUS)&nbsp;&nbsp; No virus=20
known.<BR>---------------------------------------------------------------=
-<BR><BR><BR><BR><BR><BR><BR>--------------------------------------------=
--------------------<BR>INFORMATION&nbsp;&nbsp;&nbsp;=20
AUTOMATIC VIRUS CHECK (GEMPLUS)&nbsp;&nbsp; No virus=20
known.<BR>---------------------------------------------------------------=
-<BR><BR><BR><BR><BR><BR>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0282_01BE0F13.F9C783B0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14474 for ietf-smime-bks; Thu, 12 Nov 1998 12:54:00 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14470 for <[e-mail]>; Thu, 12 Nov 1998 12:53:59 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA07098; Thu, 12 Nov 1998 12:56:48 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 15:49:16 -0500
To: Francois Rousseau <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on smime-cms-07
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <2FBF98FC7852CF11912A0000000000010ECB5A6F@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Francois:

I guess that I should remove DES MAC.

I do not know of any reference fro 3DES MAC.

Russ

At 08:10 AM 11/11/98 -0500, Francois Rousseau wrote:
>Russ,
>
>Further to Jim's EMail and although I did not attend the meeting in
>Chicago, the minutes of the meeting on this issue states that:
>
>"Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
>by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
>algorithm.  The wording in CMS will be: "If authenticatedData is
>implemented, then HMAC-with-SHA1 must be implemented."  The group also
>decided that DES MAC will not be included in CMS as an optional algorithm." 
>
>As suggested by Jim, I would for myself prefer 3DES MAC as a "may" instead
>of DES MAC. 
>
>Francois Rousseau
>AEPOS Technologies
>
><snip>
>>> 
>>>> 5.  Section 12.5.2.  DES MAC should be struck and replace 
>>>> with 3DES MAC.
>>> 
>>> My notes from Chicago indicate that HMAC with SHA-1 and DES 
>>> MAC are the two
>>> algorithms that will be included.  As 12.5 says: "CMS 
>>> implementations that
>>> support authenticatedData must include HMAC with SHA-1.  CMS 
>>> implementations
>>> may also include DES MAC."
>>
>>I'll believe your notes over my memory.  I had thought that DES MAC was
>>struck and replaced with 3DES MAC.
>>
>>> 
>>> 
>>> Enjoy,
>>>   Russ
>>> 
>>
>>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14466 for ietf-smime-bks; Thu, 12 Nov 1998 12:53:54 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14462 for <[e-mail]>; Thu, 12 Nov 1998 12:53:53 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA07100 for <[e-mail]>; Thu, 12 Nov 1998 12:56:49 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 12 Nov 1998 15:57:41 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: 43rd IETF-ORLANDO, FL: S/MIME WG Session
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

S/MIME WG:

In Orlando, the S/MIME WG will meet on Wednesday, December 9 from 1530 to 1730.

Please let me know immediately if you would like a slot on the agenda.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA09492 for ietf-smime-bks; Thu, 12 Nov 1998 07:32:57 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA09488 for <[e-mail]>; Thu, 12 Nov 1998 07:32:56 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id KAA11500; Thu, 12 Nov 1998 10:35:48 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cms-08.txt
Date: Thu, 12 Nov 1998 10:35:48 -0500
Sender: [e-mail]
Precedence: bulk

--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-08.txt
	Pages		: 51
	Date		: 11-Nov-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 <[e-mail]> 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-08.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-cms-08.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nic.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-08.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

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

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id AAA04796 for ietf-smime-bks; Thu, 12 Nov 1998 00:54:24 -0800 (PST)
Received: from mail.maxware.nl (mail.maxware.nl [195.193.216.130]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id AAA04792 for <[e-mail]>; Thu, 12 Nov 1998 00:54:22 -0800 (PST)
X-Internal-ID: 36482F110000009B
Received: from mail (195.193.216.130) by mail.maxware.nl (NPlex 2.0.098); 12 Nov 1998 09:56:45 +0100
From: "Erik Kruit" <[e-mail]>
To: <Stefan_Salzmann/HAM/[e-mail]>, <[e-mail]>
Subject: Re: ASN.1 Toolkit
Date: Thu, 12 Nov 1998 09:56:44 +0100
Message-ID: <01be0e1a$5f675a60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Sender: [e-mail]
Precedence: bulk

Hi Stefan,

I have received an email some time ago from van Dyke and Associates with a
reference to their website where they have put a freeware GNU SNACC ASN.1
compiler and library. Source code is provided.
The site address is (at least it was):

http://www.jgvandyke.com/services/infosec/sfl.htm

Hope this helps.
Regards,

Frank W. Nolden
Systems Architect

MaXware Benelux BV
tel: [phone]
email: [e-mail]
SMS email: [e-mail]



-----Original Message-----
From: Stefan_Salzmann/HAM/[e-mail]
<Stefan_Salzmann/HAM/[e-mail]>
To: [e-mail] <[e-mail]>
Date: Wednesday, November 11, 1998 7:31 PM
Subject: ASN.1 Toolkit


>Hello Everybody,
>
>does anyone know a free ASN.1 Toolkit for developing ASN.1 specifications
and
>encoding them. Are there any free resources on the internet?
>
>Thanks for your response
>Stefan
>
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA02046 for ietf-smime-bks; Wed, 11 Nov 1998 17:39:22 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA02042 for <[e-mail]>; Wed, 11 Nov 1998 17:39:21 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA13350; Wed, 11 Nov 1998 17:42:11 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Wed, 11 Nov 1998 20:43:29 -0500
To: "Jim Schaad (Exchange)" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: More Comments on smime-cms-07
Cc: "Ietf-Smime (E-mail)" <[e-mail]>
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5A21@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

These identifiers will be replaced with a id-alg-ESDH that has a parameter
that names wrap algorithm.  If the wrap algorithm needs parameters, those
will be carried in wrap algorithm parameters.

Russ

At 05:50 PM 11/2/98 -0800, Jim Schaad (Exchange) wrote:
>It has been pointed out to me that the parameter encoding for
>id-alg-ESDHwith3DES and id-alg-ESDHwithRC2 is not consistant with the
>consensus that I remember from the August IETF meeting.  At that point the
>preference I remember was for encoding parameters as NULL rather than as
>absent.  Since I don't see any place where these items are used with
>parameters I think this change to encoding as NULL should be done.
>
>That being said, I think that given the previous message that I sent out
>id-alg-ESDHwithRC2 needs to have a parameter, the same one as
>RC2wrapParameter (i.e. the actual RC2 key size).  This is needed so that the
>correct decryption can be done on the key encryption key immeadiately
>without having to wait for the MEK parameters to show up.
>
>jim schaad
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01847 for ietf-smime-bks; Wed, 11 Nov 1998 17:21:25 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01843 for <[e-mail]>; Wed, 11 Nov 1998 17:21:24 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA12817; Wed, 11 Nov 1998 17:23:27 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 17:19:14 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: Comments on updated X9.42 draft
Cc: [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric & Robert:

Okay. I will settle for a section in security considerations that tells
when the originator and recipient need to perform validation.  Since the
draft still supports Static-Static D-H as well as Ephemeral-Static D-H,
there are times that when each party needs to be concerned.

Robert:

Can you propose some text?

Russ

At 08:13 AM 11/10/98 -0500, Robert Zuccherato wrote:
>Russ;
>
>> ----------
>> From: 	Russ Housley[SMTP:[e-mail]]
>> Sent: 	Monday, November 09, 1998 3:26 PM
>> To: 	Robert Zuccherato
>> Cc: 	Eric Rescorla; [e-mail]
>> Subject: 	RE: Comments on updated X9.42 draft
>> 
>> If the recipient is an authomated service, such as a time stamp agent
>> or a
>> mail list agent, the attacker may be able to tell whether or not the
>> recipient could generate the shared secret allowing proper decryption.
>> If
>> the attacker can tell, then the attack seems to be a real concern.
>> 
>Agreed.  I'm just concerned with mandating other users, who will not be
>responding to messages that don't decrypt properly, to use this
>technique.
>
>> How do we tell implementors when this is an issue and when it is not?
>> Do we
>> put it in security considertions?
>> 
>That would be my preference.  I don't see why we couldn't describe when
>these attacks are a concern and it is recommended to perform public key
>validation.
>
>	Robert.
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01842 for ietf-smime-bks; Wed, 11 Nov 1998 17:21:24 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01838; Wed, 11 Nov 1998 17:21:23 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA12824; Wed, 11 Nov 1998 17:23:38 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 17:24:42 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Diffie-Hellman Public Key Validation
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Mon, 09 Nov 1998 15:45:02 EST."             <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Eric:

>> I guess that we will have to determine whether or not the CA performed
>> public key validation prior to certification from the certificate policy
>> OID.  This is not a very nice answer, but I cannot come up with another 
>> answer.
>
>Can you produce some proposed text for this? Is there a fixed set of
>OIDs that are appropriate or do you need an ever-growing lookup table?

For now, I think that we should simply say that the public key validation
does not need to be performed by the end entity if the CA did the
validation at the time the public key was certified.  I think that the PKIX
group should propose a mechanism for indicaing that validation was done in
a certificate.  Once that is specified, we can duplicate the information in
the S/MIME documents before DRAFT standard.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA01832 for ietf-smime-bks; Wed, 11 Nov 1998 17:20:58 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA01826 for <[e-mail]>; Wed, 11 Nov 1998 17:20:57 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-39-181.s181.tnt10.ann.erols.com [207.172.39.181]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id RAA12841 for <[e-mail]>; Wed, 11 Nov 1998 17:23:48 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 19:06:10 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: draft-ietf-smime-cms-08.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

I just sent off an updated CMS draft.  It has most of the changes discussed
on the list.  There are two notable exceptions: EnvelopedData extensibility
and Key Agreement OID flexibility.  These two are still being discussed on
the list, and the resolutions will be placed in the next update.

Russ



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26003 for ietf-smime-bks; Wed, 11 Nov 1998 08:30:52 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA25999 for <[e-mail]>; Wed, 11 Nov 1998 08:30:51 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id LAA10284 for <[e-mail]>; Wed, 11 Nov 1998 11:39:12 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA01449 for <[e-mail]>; Wed, 11 Nov 1998 11:32:05 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B9.005B8FB9 ; Wed, 11 Nov 1998 11:40:05 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 11 Nov 1998 17:13:48 +0100
Subject: ASN.1 Toolkit
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

Hello Everybody,

does anyone know a free ASN.1 Toolkit for developing ASN.1 specifications and
encoding them. Are there any free resources on the internet?

Thanks for your response
Stefan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA24854 for ietf-smime-bks; Wed, 11 Nov 1998 05:11:35 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id FAA24850 for <[e-mail]>; Wed, 11 Nov 1998 05:11:33 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id IAA02043; Wed, 11 Nov 1998 08:13:26 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Wed, 11 Nov 1998 08:10:32 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: RE: Comments on smime-cms-07
Cc: [e-mail], [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5A6F@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Russ,

Further to Jim's EMail and although I did not attend the meeting in
Chicago, the minutes of the meeting on this issue states that:

"Slide #9: Message Authentication Code (MAC) Algorithms:  The group decided
by a clear majority that HMAC-with-SHA1 will be the mandatory-to-implement
algorithm.  The wording in CMS will be: "If authenticatedData is
implemented, then HMAC-with-SHA1 must be implemented."  The group also
decided that DES MAC will not be included in CMS as an optional algorithm." 

As suggested by Jim, I would for myself prefer 3DES MAC as a "may" instead
of DES MAC. 

Francois Rousseau
AEPOS Technologies

<snip>
>> 
>>> 5.  Section 12.5.2.  DES MAC should be struck and replace 
>>> with 3DES MAC.
>> 
>> My notes from Chicago indicate that HMAC with SHA-1 and DES 
>> MAC are the two
>> algorithms that will be included.  As 12.5 says: "CMS 
>> implementations that
>> support authenticatedData must include HMAC with SHA-1.  CMS 
>> implementations
>> may also include DES MAC."
>
>I'll believe your notes over my memory.  I had thought that DES MAC was
>struck and replaced with 3DES MAC.
>
>> 
>> 
>> Enjoy,
>>   Russ
>> 
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00466 for ietf-smime-bks; Tue, 10 Nov 1998 15:54:51 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00462 for <[e-mail]>; Tue, 10 Nov 1998 15:54:50 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zdNfi-0003gG-00 for [e-mail]; Tue, 10 Nov 1998 23:58:06 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Nov 1998 23:42:58 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: [ssl-users] ssleay, private CA and Netscape 4.xx ...
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Seems I am cracking up... apologies I CC'ed that to the wrong list.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA29575 for ietf-smime-bks; Tue, 10 Nov 1998 13:36:51 -0800 (PST)
Received: from post.mail.demon.net (post-11.mail.demon.net [194.217.242.40]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA29571 for <[e-mail]>; Tue, 10 Nov 1998 13:36:50 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zdLW9-0002Ie-00; Tue, 10 Nov 1998 21:40:05 +0000
Message-ID: <[e-mail]>
Date: Tue, 10 Nov 1998 21:38:05 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: Garry Glendown <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Subject: Re: [ssl-users] ssleay, private CA and Netscape 4.xx ...
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Garry Glendown wrote:
> 
> I guess I'm finally cracking up ...
> 

Aren't we all :-)


> After messing around some time ago and finally getting a working CA up
> and running, I somehow did something today that blew that (even though
> all files in the CA-directory are unchanged ...)
> 
> Anyway, no matter what I do in order to get it running again, all
> Netscape does is complain about not being able to get the page due to
> the certificate being incorrect ("the certificate is not approved for
> the attempted application") or a broken transmission ... the server
> currently complains about one of two possible errors:
> 

OK the usual reason for this is an invalid value for nsCertType. If
should be 0x40 for SSL server certificates or omitted entirely.

> 
> I'm pretty sure the reason for this lies somewhere in the nsCertType
> field ... but I've tried just about any combination I could think of for
> the last several hours .. (including commenting it out).So, could
> someone please give me a hint what the field has to be when generating
> the CA and what when generating "regular" Certs? (I guess I might have
> messed it up when I generated a cert-req for a Thawte test cert ...)
> 

Did you just comment out the field in ssleay.cnf? The actual value in
there only gets set in a certificate when the 'ca' program signs a
request. Normally it isn't used at all. Also the certificate request
doesn't contain a nsCertType field so that can't be it :-)

If you just want to change or experiment with the nsCertType extension
then my ca-fix program (see homepage) is probably easiest.

If you are still having problems send me a copy of the certificate and
CA certificate and I'll check it over.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA29128 for ietf-smime-bks; Tue, 10 Nov 1998 12:56:34 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA29124 for <[e-mail]>; Tue, 10 Nov 1998 12:56:33 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <W4525FR4>; Tue, 10 Nov 1998 12:58:31 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A6F@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on smime-cms-07
Date: Tue, 10 Nov 1998 12:58:28 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I remove those items with which I had no more problems.

> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, November 10, 1998 12:41 PM
> To: Jim Schaad (Exchange)
> Cc: [e-mail]
> Subject: Re: Comments on smime-cms-07
> 
> 
> Jim:
>  
> 
> >3.  Section 9 - Authenticated-data Content Type:  I think I 
> have identified
> >what I consider to be a security weakness.  Specifically if 
> you create an
> >authenticated data object with authenticated attributes, I 
> can remove the
> >authenticated attributes and come up with a stil legal 
> authenticated data
> >object.  To fix this I propose that we change authenticated 
> data in the
> >following ways:
> >  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
> >  b) autenticatedAttributes becomes a REQUIRED field (remove 
> the OPTIONAL)
> >  c) a digest-value becomes a required attribute in the
> >autenticatedAttributes (replacing mac-value)
> >  d) in processing, you hash the encapContentInfo, put the has in the
> >authenticated attributes and MAC this value.
> 
> I understand your proposed change, but I do not understand 
> the "security
> weakness."  In CMS-07, two MAC values are computed.  The 
> first MAC value is
> computed from the content, then this MAC value is encoded in 
> an authenticated
> attribute.  The second MAC value is computed from the DER 
> encoded attributes. 
> The two MAC values should not be the same.  So, if the 
> attributes are removed
> by an attacker, the MAC value check should fail.
> 
> If you are concerned about an attacker who is a recipient, 
> and thus has the
> symmetic key needed to compute the MAC, then I do not think 
> that anything can
> be done to make authenticated-data secure.

What I am looking at is more of a man in the middle attack.  If I intercept
the message, I can modify it and then send on to the receiptient after
having removed all of the attributes.  Since I have removed all of the
attributes only one MAC computation would be computed and that is the same
MAC computation as was in the attributes as the macValue.

> 
> 
> >5.  Section 12.5.2.  DES MAC should be struck and replace 
> with 3DES MAC.
> 
> My notes from Chicago indicate that HMAC with SHA-1 and DES 
> MAC are the two
> algorithms that will be included.  As 12.5 says: "CMS 
> implementations that
> support authenticatedData must include HMAC with SHA-1.  CMS 
> implementations
> may also include DES MAC."

I'll believe your notes over my memory.  I had thought that DES MAC was
struck and replaced with 3DES MAC.

> 
> 
> Enjoy,
>   Russ
> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28990 for ietf-smime-bks; Tue, 10 Nov 1998 12:42:39 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28986 for <[e-mail]>; Tue, 10 Nov 1998 12:42:38 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.106]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA22749; Tue, 10 Nov 1998 12:45:11 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 15:00:15 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: CMS: Algorithm Dependancy Issues
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

This was harder to do than I expected, but I did it.  The ASN.1 changes
need to be thoroughly checked in draft-ietf-smime-cms-08.txt.  I hope to
have this new version out before the end of the week.

Russ


At 09:38 AM 11/7/98 +0000, Peter Gutmann wrote:
>While people are commenting on the use of CMS as a general protocol bucket, 
>there's something which has bothered me for awhile: The use of the term 
>MailListRecipientInfo to describe the use of shared symmetric keys.  While I 
>appreciate that there are historical reasons for the ML naming, is it too
late 
>to change it to something more appropriate like SymmetricKeyRecipientInfo?  
>Its use doesn't have much to do with mailing lists, and since CMS is supposed 
>to be an application-independent format it would be more accurate to describe 
>it by what it actually does rather than one particular possible
application of 
>the technique when used with S/MIME.
> 
>An example of where this causes confusion is with authData (MAC'd data): If 
>you exclude MailListRecipientInfo, the key management is based entirely on 
>public-key technology, because the other two recipientInfos all use
public-key 
>mechanisms (KeyTrans has "must contain a key transport public key", KeyAgree 
>has "must contain a key agreement public key").  However the most common use 
>for a MAC - using a shared key/password for integrity protection - requires 
>the use of the rather badly misnamed MailListRecipientInfo, which is the only 
>way to specify a shared key.  It isn't at all obvious from flicking through 
>the RecipientInfo's that you're supposed to manage a shared key by pretending 
>you're on a mailing list.
> 
>If the name change to the more accurate description isn't possible, would it 
>at least be possible to add comments where necessary in the text to point out 
>that the ML stuff should be used for shared keys?  This would require for 
>example changing the authData text in section 9 to:
> 
>  3.  For each recipient, the ... defined in Section 6.2.  The most common
use 
>      for a MAC is with a key shared by both the sender and recipient, which 
>      would entail the use of the MailListRecipientInfo type.
> 
>Peter.
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA28985 for ietf-smime-bks; Tue, 10 Nov 1998 12:42:32 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA28981 for <[e-mail]>; Tue, 10 Nov 1998 12:42:31 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.66.65.106]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id MAA22751; Tue, 10 Nov 1998 12:45:14 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 10 Nov 1998 15:40:55 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Comments on smime-cms-07
Cc: [e-mail]
In-Reply-To: <2FBF98FC7852CF11912A0000000000010ECB5A0F@DINO>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Jim:

>1.  the usage of the phrase "protection content type" is inconsistant
>between section 2 (general overview) and section 3 (General syntax).  For
>one it is the same as the data content type for the other it is an OID.  No
>suggested text since I was not clear on which one you really meant it to be.

You are correct.  I think I fixed it.  I removed most of the "protection" words
from both sections, and it is more clear without them.  The first paragraph of
section 2 contains the correct definition:  "This document defines one
protection content, ContentInfo."

>2.  Section 6.2.2 the paragraph on recipientEncryptedKeys:  Change to
>"includes a receipient identifier and encrypted key for one or  more
>recipients."

The paragraph reads:
recipientEncryptedKeys includes a recipient identifier and encrypted key for
one or more recipients.  The KeyAgreeRecipientIdentifier is a CHOICE with two
alternatives specifying the recipient's certificate, and thereby the
recipient's public key, that was used by the sender to generate a pairwise
key-encryption key.  The recipient's certificate must contain a key agreement
public key.  The content-encryption key is encrypted in the pairwise
key-encryption key.  The issuerAndSerialNumber alternative identifies the
recipient's certificate by the issuer's distinguished name and the certificate
serial number; the RecipientKeyIdentifier is described below.  The encryptedKey
is the result of encrypting the content-encryption key in the pairwise
key-encryption key generated using the key agreement algorithm.

>3.  Section 9 - Authenticated-data Content Type:  I think I have identified
>what I consider to be a security weakness.  Specifically if you create an
>authenticated data object with authenticated attributes, I can remove the
>authenticated attributes and come up with a stil legal authenticated data
>object.  To fix this I propose that we change authenticated data in the
>following ways:
>  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
>  b) autenticatedAttributes becomes a REQUIRED field (remove the OPTIONAL)
>  c) a digest-value becomes a required attribute in the
>autenticatedAttributes (replacing mac-value)
>  d) in processing, you hash the encapContentInfo, put the has in the
>authenticated attributes and MAC this value.

I understand your proposed change, but I do not understand the "security
weakness."  In CMS-07, two MAC values are computed.  The first MAC value is
computed from the content, then this MAC value is encoded in an authenticated
attribute.  The second MAC value is computed from the DER encoded attributes. 
The two MAC values should not be the same.  So, if the attributes are removed
by an attacker, the MAC value check should fail.

If you are concerned about an attacker who is a recipient, and thus has the
symmetic key needed to compute the MAC, then I do not think that anything can
be done to make authenticated-data secure.

>4.  Section 9.2 paragraph 4:  I don't understand why this paragraph exists.
>It does not appear to have an analogus paragraph in the signature message
>digest paragraphs.  I think this paragraph should be struck.

Okay.  I'll delete it.

>5.  Section 12.5.2.  DES MAC should be struck and replace with 3DES MAC.

My notes from Chicago indicate that HMAC with SHA-1 and DES MAC are the two
algorithms that will be included.  As 12.5 says: "CMS implementations that
support authenticatedData must include HMAC with SHA-1.  CMS implementations
may also include DES MAC."

>6.  ASN Module changes:
> - ContentType is defined twice

I removed the second one.

Enjoy,
  Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id JAA26992 for ietf-smime-bks; Tue, 10 Nov 1998 09:04:40 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id JAA26988 for <[e-mail]>; Tue, 10 Nov 1998 09:04:38 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id MAA26220; Tue, 10 Nov 1998 12:06:33 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 10 Nov 1998 12:02:28 -0500
To: Russ Housley <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Russ,

I agree with your suggestions for Sections 5.1, 5.3 and 5.4.

However, for your reply on my support of extensibility on Section 6, I have
send you my response on another thread.

Francois Rousseau
AEPOS Technologies

Russ Housley wrote:
>Francois:
>
>>Sec 5.1, based on how the last sentence of the definition of the SignedData
>>"certificates" field currently reads, if no attribute certificates are
>>present although the content type may be other than id-data, the version
>>could be misinterpreted to be 1. I would suggest that the last sentence of
>>this definition be amended as follows:
>>
>>"If no attribute certificates are present in the collection and the
>>encapsulated content type is id-data, then the value of version shall be 1.
>> However, if attribute certificates are present or the encapsulated content
>>type is other than id-data, then the value of version shall be 3."
>
>Since this is really a restatement of the discussion already present in the
>version discussion.  Therefore, I suggest the following:  "As discussed
above,
>if attribute certificates are present, then the value of version shall be 3."
>
>
>>Sec 5.3, the definition of the SignerInfo "signedAttributes" field
>>indicates that both the "content-type" and the "message-digest" attributes
>>must be present if the field is present. However, this does address the
>>exception created by the "countersignature" attribute in Sec 11.4 where it
>>is indicated that the signedAttributes field need not contain a
>>content-type attribute, as there is no content type for countersignatures.
>>To address this, I would suggest that the statement on the "content-type
>>attribute" under the SignerInfo "signedAttributes" field reads as follows:
>>
>>"A content-type attribute having as its value the content type of the
>>EncapsulatedContentInfo value being signed except within a
>>countersignature, as there is no content type for countersignatures.
>>Sections 11.1 and 11.4 respectively define the content-type and the
>>countersignature attributes."
>
>How about: "A content-type attribute having as its value the content type
>of the
>EncapsulatedContentInfo value being signed.  Section 11.1 defines the
>content-type attribute.  The content-type is not required when used as
part of
>a countersignature unsigned attribute as defined in section 11.4."
>
>
>>Sec 5.4, similarly as Sec 5.3 above, the fourth sentence of the second
>>paragraph should be amended to read as follows:
>>
>>"Since the SignedAttributes value, when present, must contain the message
>>digest and the content type attributes, except within a countersignature,
>>those values are indirectly included in the result."
>
>How about: "Since the SignedAttributes value, when present, must contain the
>content type and the content message digest attributes, those values are
>indirectly included in the result.  The content-type is not required when
used
>as part of a countersignature unsigned attribute as defined in section 11.4."
>
>
>>Sec 6, I agree with others that it would be preferable if EnvelopeData was
>>also extensible per message and/or per recipient.
>
>I recall a long discussion concerning this issue.  My recollection is that
>maintaining backward compatibility with S/MIME v2 and PKCS#7 v1.5 was more
>important than this extensibility.
>
>Russ
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA26896 for ietf-smime-bks; Tue, 10 Nov 1998 08:55:38 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA26892 for <[e-mail]>; Tue, 10 Nov 1998 08:55:37 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id LAA26096; Tue, 10 Nov 1998 11:57:14 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Tue, 10 Nov 1998 11:54:20 -0500
To: [e-mail]
From: Francois Rousseau <[e-mail]>
Subject: Re: CMS -EnvelopedData extensibility
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Russ,

I do not agree that the proposed extensibility, as previously proposed by
Darren, will necessarily affect the backward compatibility with S/MIME v2
and PKCS#7 v1.5 as you have suggested.

To support this proposed extensibility while still addressing your backward
compatibility concern, CMS would only have to mandate that the "CMSVersion"
shall be 2 when the optional unsigned attribute is added to the
EnvelopedData. Similarly CMS would also have to mandate that the
"CMSVersion" shall be 2 when the optional unsigned attribute is added to
the KeyTransRecipientInfo. There should be not backward compatibility issue
with PKCS#7 v1.5 when the unsigned attribute is added to the
KeyAgreeRecipientInfo since it never existed before.

Francois Rousseau
AEPOS Technologies


Darren wrote:
>Russ,
>
>Thanks for the confirmation.  The point I was trying to make is that it's
not encrypted attributes that are needed, it's clear attributes.
>
>Currently, if I wish to encrypt a message and send the recipient an
arbitrary set of certificates and CRLs, I would have to either wrap the
EnvelopedData in a SignedData or vice versa, and store the certs/CRLs in
the SignedData.
>
>IMHO, this is wasteful when a simple addition to EnvelopedData would save
having to do an extra ASN.1 encoding ad MIME wrapping.
>
>Regards,
>
>Darren 
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>
>>>> Russ Housley <[e-mail]> 11/10/98 03:16am >>>
>Darren:
>
>This was discussed.  Backward compatibility was considered more important
>than encrypted attributes.
>
>Russ
>
>At 09:39 AM 11/6/98 +0000, Darren Harter wrote:
>>It's possible that this one has slipped through unnoticed, but I'm a little 
>>suprised by the lack of response.
>>
>>I think John has a good point in that unlike SignedData, EnvelopeData is
not 
>>extensible.  Regardless of how unlikely it may seem, it is possible that an 
>>appliation may wish to send some information 'in-the-clear' using 
>>EnvlopedData.  For example, to carry CRLs, other certs, and clear label
etc. 
>> I believe it should be possible to do this without forcin gthe application 
>>to wrap the EnvelopedData in another SignedData.  After all CMS will be
used 
>>for purposes other than S/MIME.
>>
>>I agree with John that EnvelopedData should be extended to allow 
>>unauthenticated clear data to be passed on both a global and per-recipient 
>>basis.
>>
>>I don't how other list members feel, but I would be suprised if the IESG 
>>would approve a standard that was not extensible and future proofed in this 
>>way.
>>
>>Regards,
>>
>>Darren
>>
>>-------------------------------------------------------------
>>Darren Harter BSc Hons MBCS CEng
>>CASM Technical Architect
>>CASM Programme Office
>>CESG
>>Work: [e-mail] 
>>Home: [e-mail] 
>>
>>>>> "John Ross" <[e-mail]> 11/02/98 06:55pm >>>
>>CMS-EnvelopedData is currently not easy to extend to carry additional 
>>information or attributes.  Is that intentional?
>>
>>Generally, it is a good idea to include a way of extending protocols when 
>>defining standards. Including a protocol extension mechanism facilitates 
>>easy migration to meeting new requirements. 
>>
>>In  particular,  in the case of EnvelopedData future extensions may be 
>>required to support additional Algorithms.
>>
>>The first Question I have to the Mail list is:
>>
>>1) Is there support for providing an extensibility mechanism in 
>>EnvelopedData? YES or NO.
>>
>>If there is support, then  the second question is 
>>2 ) Should a similar scheme to SignedData unsigned attributes could be
used? 
>>YES or NO.
>>
>>The extension mechanism could be per EnvelopedData (i.e per message).
>>
>> The following is an example ASN.1:
>> 
>> EnvelopedData ::= SEQUENCE {
>>     version CMSVersion,
>>     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>>     recipientInfos RecipientInfos,
>>     encryptedContentInfo EncryptedContentInfo 
>>     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>>
>>The extension mechanism could also be per recipient using the key transport 
>>recipient information and key agreement recipient info.
>>
>>The following is an example ASN.1:
>> 
>>KeyTransRecipientInfo ::= SEQUENCE {
>>     version CMSVersion,  -- always set to 0 or 2
>>     rid RecipientIdentifier,
>>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>>     encryptedKey EncryptedKey 
>>      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>>
>>
>>  KeyAgreeRecipientInfo ::= SEQUENCE {
>>     version CMSVersion,  -- always set to 3
>>     originator [0] EXPLICIT OriginatorIdentifierOrKey,
>>     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>>     recipientEncryptedKeys RecipientEncryptedKeys 
>>     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }
>>
>>
>
>
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id FAA25019 for ietf-smime-bks; Tue, 10 Nov 1998 05:19:33 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id FAA25015 for <[e-mail]>; Tue, 10 Nov 1998 05:19:32 -0800 (PST)
Received: 	id IAA24164; Tue, 10 Nov 1998 08:18:08 -0500
Received: by gateway id <W1GJNKQ8>; Tue, 10 Nov 1998 08:15:14 -0500
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Russ Housley'" <[e-mail]>
Cc: Eric Rescorla <[e-mail]>, [e-mail]
Subject: RE: Comments on updated X9.42 draft
Date: Tue, 10 Nov 1998 08:13:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

Russ;

> ----------
> From: 	Russ Housley[SMTP:[e-mail]]
> Sent: 	Monday, November 09, 1998 3:26 PM
> To: 	Robert Zuccherato
> Cc: 	Eric Rescorla; [e-mail]
> Subject: 	RE: Comments on updated X9.42 draft
> 
> If the recipient is an authomated service, such as a time stamp agent
> or a
> mail list agent, the attacker may be able to tell whether or not the
> recipient could generate the shared secret allowing proper decryption.
> If
> the attacker can tell, then the attack seems to be a real concern.
> 
Agreed.  I'm just concerned with mandating other users, who will not be
responding to messages that don't decrypt properly, to use this
technique.

> How do we tell implementors when this is an issue and when it is not?
> Do we
> put it in security considertions?
> 
That would be my preference.  I don't see why we couldn't describe when
these attacks are a concern and it is recommended to perform public key
validation.

	Robert.




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA15965 for ietf-smime-bks; Tue, 10 Nov 1998 01:52:19 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA15949 for <[e-mail]>; Tue, 10 Nov 1998 01:52:12 -0800 (PST)
Received: by access.itsec.gov.uk; id AA00979; Tue, 10 Nov 98 09:44:03 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma000976; Tue, 10 Nov 98 09:43:37 GMT
Received: by ingress.itsec.dmz; id AA12328; Tue, 10 Nov 98 09:44:55 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma012314; Tue, 10 Nov 98 09:44:44 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Tue, 10 Nov 1998 09:43:56 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Tue, 10 Nov 1998 09:36:46 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: CMS -EnvelopedData extensibility
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA15960
Sender: [e-mail]
Precedence: bulk

Russ,

Thanks for the confirmation.  The point I was trying to make is that it's not encrypted attributes that are needed, it's clear attributes.

Currently, if I wish to encrypt a message and send the recipient an arbitrary set of certifictes and CRLs, I would have to either wrap the EnvelopedData in a SignedData or vice versa, and store the certs/CRLs in the SignedData.

IMHO, this is wasteful when a simple addition to EnvelopedData would save having to do an extra ASN.1 encoding ad MIME wrapping.

Regards,

Darren 

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]

>>> Russ Housley <[e-mail]> 11/10/98 03:16am >>>
Darren:

This was discussed.  Backward compatibility was considered more important
than encrypted attributes.

Russ

At 09:39 AM 11/6/98 +0000, Darren Harter wrote:
>It's possible that this one has slipped through unnoticed, but I'm a little 
>suprised by the lack of response.
>
>I think John has a good point in that unlike SignedData, EnvelopeData is not 
>extensible.  Regardless of how unlikely it may seem, it is possible that an 
>appliation may wish to send some information 'in-the-clear' using 
>EnvlopedData.  For example, to carry CRLs, other certs, and clear label etc. 
> I believe it should be possible to do this without forcin gthe application 
>to wrap the EnvelopedData in another SignedData.  After all CMS will be used 
>for purposes other than S/MIME.
>
>I agree with John that EnvelopedData should be extended to allow 
>unauthenticated clear data to be passed on both a global and per-recipient 
>basis.
>
>I don't how other list members feel, but I would be suprised if the IESG 
>would approve a standard that was not extensible and future proofed in this 
>way.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail] 
>Home: [e-mail] 
>
>>>> "John Ross" <[e-mail]> 11/02/98 06:55pm >>>
>CMS-EnvelopedData is currently not easy to extend to carry additional 
>information or attributes.  Is that intentional?
>
>Generally, it is a good idea to include a way of extending protocols when 
>defining standards. Including a protocol extension mechanism facilitates 
>easy migration to meeting new requirements. 
>
>In  particular,  in the case of EnvelopedData future extensions may be 
>required to support additional Algorithms.
>
>The first Question I have to the Mail list is:
>
>1) Is there support for providing an extensibility mechanism in 
>EnvelopedData? YES or NO.
>
>If there is support, then  the second question is 
>2 ) Should a similar scheme to SignedData unsigned attributes could be used? 
>YES or NO.
>
>The extension mechanism could be per EnvelopedData (i.e per message).
>
> The following is an example ASN.1:
> 
> EnvelopedData ::= SEQUENCE {
>     version CMSVersion,
>     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>     recipientInfos RecipientInfos,
>     encryptedContentInfo EncryptedContentInfo 
>     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>
>The extension mechanism could also be per recipient using the key transport 
>recipient information and key agreement recipient info.
>
>The following is an example ASN.1:
> 
>KeyTransRecipientInfo ::= SEQUENCE {
>     version CMSVersion,  -- always set to 0 or 2
>     rid RecipientIdentifier,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     encryptedKey EncryptedKey 
>      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>
>
>  KeyAgreeRecipientInfo ::= SEQUENCE {
>     version CMSVersion,  -- always set to 3
>     originator [0] EXPLICIT OriginatorIdentifierOrKey,
>     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     recipientEncryptedKeys RecipientEncryptedKeys 
>     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }
>
>




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00589 for ietf-smime-bks; Mon, 9 Nov 1998 19:12:35 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00585 for <[e-mail]>; Mon, 9 Nov 1998 19:12:34 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12691; Mon, 9 Nov 1998 19:15:09 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 09 Nov 1998 22:16:34 -0500
To: "Darren Harter" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: CMS -EnvelopedData extensibility
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Darren:

This was discussed.  Backward compatibility was considered more important
than encrypted attributes.

Russ

At 09:39 AM 11/6/98 +0000, Darren Harter wrote:
>It's possible that this one has slipped through unnoticed, but I'm a little 
>suprised by the lack of response.
>
>I think John has a good point in that unlike SignedData, EnvelopeData is not 
>extensible.  Regardless of how unlikely it may seem, it is possible that an 
>appliation may wish to send some information 'in-the-clear' using 
>EnvlopedData.  For example, to carry CRLs, other certs, and clear label etc. 
> I believe it should be possible to do this without forcin gthe application 
>to wrap the EnvelopedData in another SignedData.  After all CMS will be used 
>for purposes other than S/MIME.
>
>I agree with John that EnvelopedData should be extended to allow 
>unauthenticated clear data to be passed on both a global and per-recipient 
>basis.
>
>I don't how other list members feel, but I would be suprised if the IESG 
>would approve a standard that was not extensible and future proofed in this 
>way.
>
>Regards,
>
>Darren
>
>-------------------------------------------------------------
>Darren Harter BSc Hons MBCS CEng
>CASM Technical Architect
>CASM Programme Office
>CESG
>Work: [e-mail]
>Home: [e-mail]
>
>>>> "John Ross" <[e-mail]> 11/02/98 06:55pm >>>
>CMS-EnvelopedData is currently not easy to extend to carry additional 
>information or attributes.  Is that intentional?
>
>Generally, it is a good idea to include a way of extending protocols when 
>defining standards. Including a protocol extension mechanism facilitates 
>easy migration to meeting new requirements. 
>
>In  particular,  in the case of EnvelopedData future extensions may be 
>required to support additional Algorithms.
>
>The first Question I have to the Mail list is:
>
>1) Is there support for providing an extensibility mechanism in 
>EnvelopedData? YES or NO.
>
>If there is support, then  the second question is 
>2 ) Should a similar scheme to SignedData unsigned attributes could be used? 
>YES or NO.
>
>The extension mechanism could be per EnvelopedData (i.e per message).
>
> The following is an example ASN.1:
> 
> EnvelopedData ::= SEQUENCE {
>     version CMSVersion,
>     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
>     recipientInfos RecipientInfos,
>     encryptedContentInfo EncryptedContentInfo 
>     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>
>The extension mechanism could also be per recipient using the key transport 
>recipient information and key agreement recipient info.
>
>The following is an example ASN.1:
> 
>KeyTransRecipientInfo ::= SEQUENCE {
>     version CMSVersion,  -- always set to 0 or 2
>     rid RecipientIdentifier,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     encryptedKey EncryptedKey 
>      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
>
>
>  KeyAgreeRecipientInfo ::= SEQUENCE {
>     version CMSVersion,  -- always set to 3
>     originator [0] EXPLICIT OriginatorIdentifierOrKey,
>     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
>     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
>     recipientEncryptedKeys RecipientEncryptedKeys 
>     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }
>
>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00532 for ietf-smime-bks; Mon, 9 Nov 1998 19:07:57 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00528 for <[e-mail]>; Mon, 9 Nov 1998 19:07:56 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12592; Mon, 9 Nov 1998 19:09:57 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 09 Nov 1998 15:26:59 -0500
To: Robert Zuccherato <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: Comments on updated X9.42 draft
Cc: Eric Rescorla <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Robert:

A reply to your few comments on my document comments.

>> >2.1.5.  Public Key Validation
>> >
>> >   The following algorithm MAY be used to validate received public
>> keys.
>> 
>> I think that we need to require validation at the tie the public key
>> is
>> placed in a certificate OR at the time the public key is used to
>> compute ZZ.
>> 
>Actually, I don't think that in a store and forward environment and
>using ephemeral-static DH, public-key validation is necessarily
>required.  Let us first consider the situation from the point of view of
>the sender.  In this situation, the sender is combining his ephemeral
>private key with the receiver's certified public key.  Because the
>receiver's public key is certified, it could not have been changed by a
>third party attacker, so the only entity that could possibly be
>performing a "small-subgroup" type of attack is the receiver.  However,
>the sender should not be concerned about this situation.  The sender
>will be agreeing on a secret key with the receiver anyway, so the
>receiver will get access to the encrypted information.  Whether or not
>the receiver also gets access to the sender's private key does not
>matter (because the key is ephemeral).

We agree that there is not an issue with the originator.

>Now let us consider the receiver.  In this situation, the receiver is
>combining it's static private key with the uncertified public key of the
>sender.  Because the public key is uncertified, it could have been
>modified by an attacker, so the threat of a "small-subgroup" type of
>attack is real.  However, because this is a store and forward
>environment, it is possible that the receiver might not respond to the
>sender if the message does not properly decrypt and the receiver
>probably won't use the shared key for any further communications.  Since
>the success of the "small-subgroup" attacks relies on the attacker being
>able to obtain information about when the decryption was successful or
>obtaining a message encrypted with the "bogus" shared key, this attack
>would not be applicable.

If the recipient is an authomated service, such as a time stamp agent or a
mail list agent, the attacker may be able to tell whether or not the
recipient could generate the shared secret allowing proper decryption.  If
the attacker can tell, then the attack seems to be a real concern.

>> >   The primary purpose of public key validation is to prevent a small
>> >   subgroup attack [REFERENCE?] on the sender's key pair. If
>> Ephemeral-
>> >   Static mode is used, this check is unnecessary. Note that this
>> pro-
>> >   cedure may be subject to pending patents.
>> 
>> I suggest that you break this into two paragraphs.  Make the patent
>> statement a separant paragraph.
>> 
>> Also, there seem to be cases where the recipient is an automated
>> responder
>> (perhaps a timestamp service) that have concerns with a small subgroup
>> attack too.  Any time that the attacker can determine the
>> success/failure
>> of the key generation there seems to be an issue.
>> 
>True.  But in cases where the attacker cannot determine the
>success/failure of the key generation this isn't an issue, and so
>shouldn't be mandated.

How do we tell implementors when this is an issue and when it is not? Do we
put it in security considertions?

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00484 for ietf-smime-bks; Mon, 9 Nov 1998 19:06:26 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00480 for <[e-mail]>; Mon, 9 Nov 1998 19:06:26 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12557; Mon, 9 Nov 1998 19:09:01 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 09 Nov 1998 11:35:11 -0500
To: Francois Rousseau <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Francois:

>Sec 5.1, based on how the last sentence of the definition of the SignedData
>"certificates" field currently reads, if no attribute certificates are
>present although the content type may be other than id-data, the version
>could be misinterpreted to be 1. I would suggest that the last sentence of
>this definition be amended as follows:
>
>"If no attribute certificates are present in the collection and the
>encapsulated content type is id-data, then the value of version shall be 1.
> However, if attribute certificates are present or the encapsulated content
>type is other than id-data, then the value of version shall be 3."

Since this is really a restatement of the discussion already present in the
version discussion.  Therefore, I suggest the following:  "As discussed above,
if attribute certificates are present, then the value of version shall be 3."


>Sec 5.3, the definition of the SignerInfo "signedAttributes" field
>indicates that both the "content-type" and the "message-digest" attributes
>must be present if the field is present. However, this does address the
>exception created by the "countersignature" attribute in Sec 11.4 where it
>is indicated that the signedAttributes field need not contain a
>content-type attribute, as there is no content type for countersignatures.
>To address this, I would suggest that the statement on the "content-type
>attribute" under the SignerInfo "signedAttributes" field reads as follows:
>
>"A content-type attribute having as its value the content type of the
>EncapsulatedContentInfo value being signed except within a
>countersignature, as there is no content type for countersignatures.
>Sections 11.1 and 11.4 respectively define the content-type and the
>countersignature attributes."

How about: "A content-type attribute having as its value the content type
of the
EncapsulatedContentInfo value being signed.  Section 11.1 defines the
content-type attribute.  The content-type is not required when used as part of
a countersignature unsigned attribute as defined in section 11.4."


>Sec 5.4, similarly as Sec 5.3 above, the fourth sentence of the second
>paragraph should be amended to read as follows:
>
>"Since the SignedAttributes value, when present, must contain the message
>digest and the content type attributes, except within a countersignature,
>those values are indirectly included in the result."

How about: "Since the SignedAttributes value, when present, must contain the
content type and the content message digest attributes, those values are
indirectly included in the result.  The content-type is not required when used
as part of a countersignature unsigned attribute as defined in section 11.4."


>Sec 6, I agree with others that it would be preferable if EnvelopeData was
>also extensible per message and/or per recipient.

I recall a long discussion concerning this issue.  My recollection is that
maintaining backward compatibility with S/MIME v2 and PKCS#7 v1.5 was more
important than this extensibility.

Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00477 for ietf-smime-bks; Mon, 9 Nov 1998 19:06:23 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00468 for <[e-mail]>; Mon, 9 Nov 1998 19:06:21 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12545; Mon, 9 Nov 1998 19:08:50 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 09 Nov 1998 10:07:46 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Peter:

I agree that example data would be highly desirable.  However, I do not
think that we should keep progression to proposed standard.  This can more
easily be accomodated when we progress to draft standard.

Russ


At 03:25 PM 11/3/98 +0000, Peter Gutmann wrote:
>>CMS is now read for Working Group Last Call.  The X9.42 draft is not
complete,
>>but it should be posted near the end of the week.  Last Call will close two
>>weeks after the X9.42 draft is posted.
> 
>One minor request, would it be possible to include a short example of data
>wrapped up with each CMS content-type at the end of the draft (data,
>encryptedData, etc)?  This would help solve some of the "we thought you were
>supposed to interpret the text this way" problems which have come up, and
>provide useful test vectors for implementors.
> 
>Peter.
> 
>


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00476 for ietf-smime-bks; Mon, 9 Nov 1998 19:06:23 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00467 for <[e-mail]>; Mon, 9 Nov 1998 19:06:21 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12555; Mon, 9 Nov 1998 19:08:59 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
X-Priority: 5 (Lowest)
Date: Mon, 09 Nov 1998 10:44:12 -0500
To: "Flanigan, Bill" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail] a.mil>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

<html>
Bill:<br>
<br>
Are we alking about the same sentence?&nbsp; It looks okay to me.<br>
<font face="Arial, Helvetica">
<dl>
<dd>For the signature to be valid, the message digest value calculated by
the recipient must be the same as the value of the messageDigest
attribute included in the signedAttributes of the signedData
signerInfo.<br>
<br>
</font>
</dl>Russ<br>
<br>
At 04:17 PM 11/3/98 -0500, Flanigan, Bill wrote:<br>
&gt;I have another &quot;minor&quot; request.&nbsp; The last sentence of
the second paragraph<br>
&gt;in Section 5.6 seems to be particularly convoluted--like nested
eggs.&nbsp; How<br>
&gt;would this process REALLY work in determining if the signature is
valid?<br>
&gt;Perhaps some wordsmithing as well as breaking the sentence up into
two might<br>
&gt;help.&nbsp; Any thoughts anyone? <br>
&gt;<br>
&gt;Bill<br>
&gt;<br>
&gt;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%<br>
&gt;William F. Flanigan, Jr., Ph.D.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Voice:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703)
681-2318<br>
&gt;Defense Information Systems Agency&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Fax:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703)
681-2814 <br>
&gt;Information Assurance Office (JED)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
DSN:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
761&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <br>
&gt;5600 Columbia Pike, Room 632&nbsp;&nbsp;&nbsp;&nbsp; Voice
Mail:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (703)
681-2318&nbsp;&nbsp; <br>
&gt;Falls Church, VA 22041-2717&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Internet:&nbsp; &lt;[e-mail]&gt;<br>
&gt;%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
<br>
&gt;<br>
&gt;&gt; -----Original Message-----<br>
&gt;&gt;
From:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Paul
Hoffman / IMC [SMTP:[e-mail]]<br>
&gt;&gt;
Sent:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Tuesday,
November 03, 1998 1:03 PM<br>
&gt;&gt; To:<x-tab>&nbsp;&nbsp;</x-tab>[e-mail]<br>
&gt;&gt; Subject:<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>Re: WG Last
Call:draft-ietf-smime-cms-07.txt<br>
&gt;&gt; <br>
&gt;&gt; &gt;One minor request, would it be possible to include a short
example of<br>
&gt;&gt; data<br>
&gt;&gt; &gt;wrapped up with each CMS content-type at the end of the
draft (data,<br>
&gt;&gt; &gt;encryptedData, etc)?&nbsp; This would help solve some of the
&quot;we thought you<br>
&gt;&gt; were<br>
&gt;&gt; &gt;supposed to interpret the text this way&quot; problems which
have come up, and<br>
&gt;&gt; &gt;provide useful test vectors for implementors.<br>
&gt;&gt; <br>
&gt;&gt; I would second this request, even if it delays the drafts a bit.
From<br>
&gt;&gt; Jim's<br>
&gt;&gt; previous message, it is clear that the few people implementing
right now<br>
&gt;&gt; are not 100% on track on this.<br>
&gt;&gt; <br>
&gt;&gt; Russ, can you add these? Or, if anyone else can provide them
quicker, that<br>
&gt;&gt; would be wonderful.<br>
&gt;&gt; <br>
&gt;&gt; --Paul Hoffman, Director<br>
&gt;&gt; --Internet Mail Consortium<br>
</html>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00464 for ietf-smime-bks; Mon, 9 Nov 1998 19:06:17 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00456; Mon, 9 Nov 1998 19:06:16 -0800 (PST)
Received: from rhousley_laptop.spyrus.com (207-172-37-5.s5.tnt7.ann.erols.com [207.172.37.5]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id TAA12549; Mon, 9 Nov 1998 19:08:52 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 09 Nov 1998 10:17:20 -0500
To: Paul Hoffman / IMC <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Experince with PKIX Part 1 tells me that such test data is very useful to
implementors, but that it is quite difficult to get correct.  Concensus of
the example data is very important.

Here is how I want to proceed:
1.  Move forward with CMS without examples.
2.  Start a companion document that contains example.
3.  If appropriate, merge CMS and the examples at Draft Standard.

Russ

At 10:03 AM 11/3/98 -0800, Paul Hoffman / IMC wrote:
>>One minor request, would it be possible to include a short example of data
>>wrapped up with each CMS content-type at the end of the draft (data,
>>encryptedData, etc)?  This would help solve some of the "we thought you were
>>supposed to interpret the text this way" problems which have come up, and
>>provide useful test vectors for implementors.
>
>I would second this request, even if it delays the drafts a bit. From Jim's
>previous message, it is clear that the few people implementing right now
>are not 100% on track on this.
>
>Russ, can you add these? Or, if anyone else can provide them quicker, that
>would be wonderful.
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA29686 for ietf-smime-bks; Mon, 9 Nov 1998 18:28:59 -0800 (PST)
Received: from pop02.globecomm.net (pop02.globecomm.net [206.253.129.186]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA29682 for <[e-mail]>; Mon, 9 Nov 1998 18:28:58 -0800 (PST)
Received: from home (du0005.ima.net [202.75.0.134]) by pop02.globecomm.net (8.9.0/8.8.0) with SMTP id VAA14996 for <[e-mail]>; Mon, 9 Nov 1998 21:32:17 -0500 (EST)
Message-ID: <002301be0c52$cdf83540$86004bca@home>
From: "Enzo Michelangeli" <[e-mail]>
To: <[e-mail]>
Subject: Re: Algorithm Dependancy Issues
Date: Tue, 10 Nov 1998 10:32:52 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3026.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3026.0
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Darren Harter <[e-mail]>
To: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Date: Tuesday, November 10, 1998 2:36 AM
Subject: Re: Algorithm Dependancy Issues


>Enzo,
>
>IHO, the aim of the S/MIME WG is to ensure interoperability of S/MIME.  I
view S/MIME as a profile (the MSG spec) of the CMS/ESS and other specs.  So
to be S/MIME compliant you must meet the mandatory elements of the MSG spec
and this implies compliancy with certain aspects of the CMS spec, but not
all of it.
>
>I believe that vendors should be able to remain CMS compliant without being
S/MIME compliant or dependant of S/MIME's algorithms suite.
>
>IMHO, protocol and procedural compliancy should be treated differently from
algorithm compliancy.  I would like to see CMS be algorithm independant.
>
>For this reason, IMO I believe your question should have been:
>
>Wouldn't that endanger interoperability between S/MIME-compliant agents
sitting on the two sides of the fence, and exchanging mail through a
gateway?
>
>And the answer would be no, as the S/MIME spec ensures interoperability.


But there are gateways that bridge between Internet (RFC822+MIME) and
non-Internet mail transports. Why should those two worlds risk
non-interoperability, even when the agents on both sides comply with CMS?

The S/MIME working group might choose not to address this issue, but then
someone else (a CMS working group?) should.

Enzo





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA29029 for ietf-smime-bks; Mon, 9 Nov 1998 17:56:04 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA29024 for <[e-mail]>; Mon, 9 Nov 1998 17:56:02 -0800 (PST)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id RAA08025; Mon, 9 Nov 1998 17:58:14 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 09 Nov 1998 17:54:29 -0800
To: Stefan_Salzmann/HAM/[e-mail], [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: Difference between SMIME and PGP
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id RAA29025
Sender: [e-mail]
Precedence: bulk

At 05:20 PM 11/4/98 +0100, Stefan_Salzmann/HAM/[e-mail] wrote:
   
   I am struggling on the difference between SMIME and PGP. One of my
customers
   wants to make the decision between using SMIME and PGP. I have been talking
   already with them but we got stuck in detailes.
   
   Basically its quit clear. SMIME will be supported by all important industry
   leaders such as Netscape, Microsoft, Novell etc. 

I'd like to note that PGP is supported by NAI, Microsoft, Novell, and more
that are coming soon.

   Further SMIME supports the
   hierarchical trust model and PGP only supports the "web of trust" model. 

Actually, this is false. PGP supports all trust models, direct trust,
hierarchical trust, and web of trust. As I said in my previous message, PGP
supports 255 levels of hierarchy.

However, I forgot to say that OpenPGP does not mandate *any* trust model.
As a matter of fact, the OpenPGP working group has rejected any mandate of
trust model. You are permitted to use an OpenPGP certificate with PKIX
evaluation rules, and still be OpenPGP compliant!

   Now
   with PGP Version 6.0, PGP will support also X.509 certificates. Those
can also
   be loaded into an PGP client than an SMIME Client can do it.
   So where is the difference now? Is it just the fact that the industry
decided to
   go with SMIME or are there more differences (advantages for SMIME) when
looking
   more closely.

Actually, the industry hasn't decided to go with anything. Furthermore,
there is no reason why you can't have PGP messages backed by X.509
certificates, and it is trivial to use S/MIME with OpenPGP certificates.
I'm planning on writing a short informational RFC on how to do it once we
all get RFC numbers for our respective systems.

   For instance using RSA public key encryption versus Deffie Helman public
key
   encryption. How about Digital Signature Standard (DSS)? I have red about
DSS and
   understand that DSS is the standard that provides the Digital Signature
   Algorithm. Before applying it there has to be calculated an Digest using
SHA. I
   always thought that calculating the digest would be the signature
already!! So
   why using the DSA in addition? Will the digest be decrypted using the
Deffie
   Helman private key? 

The issue of algorithm is orthogonal to message encoding. The PGP-S/MIME
question is really one of message encoding format. Each requires DSS, and
allows RSA.

The DSS (Digital Signature Standard) describes how to make a signature
using DSA (Digital Signature Algorithm) and SHA1 (Secure Hash Algorithm).
That's how they relate. You could (for example) use DSA with RIPEMD-160,
but it wouldn't be DSS because DSS specifies the hash algorithm you should
be using for the signature.

DSA is a signature-only algorithm. Consequently, you aren't doing a
"decryption" with it when you evaluate a signature. I recommend you look in
a crypto source book, like Schneier's "Applied Cryptography" or Menezes,
van Oorschot, and Vanstone's "Handbook of Applied Cryptography" for details
of how DSS is done. There is also source code available from a wide variety
of places.

   Users that apply Deffie Helman exchange their public values
   in order to derive an secret key that will be known at both party sides.
Is that
   secret key the private key used to encrypt message digests or is the
private key
   generated by the DSA algorithm?

Like I said, DSS has its own signature-only key. As for "Diffie-Hellman"
depending on the variant of DH you're using, you may or may not have an
actual key. Many real-time systems use ephemeral DH merely to exchange
symmetric keys. In OpenPGP, we use the Elgamal system for encryption.
S/MIME is using an X9.42 algorithm that is very close (if not identical) to
Elgamal.

   In PGP further exist key rings that contain the public keys of other
users? How
   does that work with X.509 Certificates that actually contain the public
key. If
   there has to be a public key revoked, it happens in the key ring. Would
it be
   possible to export that revoked certificate. If not the revoked public
key would
   resist only lokally.

Most systems, be they PGP or X.509, use something akin to a directory to
store certs, revocations, etc. Typically, these are HTTP or LDAP based
systems.

   Are there any differences/advantages between RSA and Deffie Helman?

Again, this is orthoganal to encoding, as these are merely algorithms. But
yes, of course. The security of RSA is based upon the difficulty of
factoring large numbers. Most people who toss around the term
"Diffie-Hellman" use it to cover an entire family of algorithms whose
security is all based on the difficulty of solving discrete logs. These
include DSA, X9.42, Schnorr, and Elgamal. They are all approximately of the
same strength.

There are also a wide variety of advantages and disadvantages. Frequently,
these are the same. For example, in RSA encryption and signatures are the
same, which is simple, but leads to some hygenic problems. A signature-only
system like DSA is less flexible, but easier to export, and enforces good
key hygene (meaning that it is bad practice to use the same key for
signatures as for encryption). I could go on with a discussion of all this,
but this thread is already off-topic for this mailing list. Feel free to
mail me privately or phone.
   
   You see I am very confused right now and I have the feeling that all my
security
   theories woun´t match with those used in PGP.

There are many good reasons for being confused. One of the most important
ones is that there really aren't a lot of differences between the systems.
They are all trying to solve the same problem, but each has a slightly
different slant to it.
   
   I really would appreciate it if there would be someone helping my to
remove all
   that dust of my mind...
   
   Thank you in advance

You're welcome.

	Jon   

-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA28198 for ietf-smime-bks; Mon, 9 Nov 1998 17:06:15 -0800 (PST)
Received: from fusebox.pgp.com (fusebox.pgp.com [161.69.1.11]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA28194 for <[e-mail]>; Mon, 9 Nov 1998 17:06:12 -0800 (PST)
Received: from foobar (dhcp-47-64.dhcp.nai.com [161.69.47.64]) by fusebox.pgp.com (8.8.7/8.8.7) with SMTP id RAA07780; Mon, 9 Nov 1998 17:08:14 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.3 (32)
Date: Mon, 09 Nov 1998 16:59:41 -0800
To: Stefan_Salzmann/HAM/[e-mail], [e-mail]
From: Jon Callas <[e-mail]>
Subject: Re: PGP 6.0 ... One more question
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

At 05:38 PM 11/4/98 +0100, Stefan_Salzmann/HAM/[e-mail] wrote:
   I have got one more question for the community. Does PGP Version 6.0
supports
   the hierachical trust model? If yes are there any restrictions?
   
I'd like to note that this question really is not germane to this mailing
list for two reasons: (1) you're asking a PGP question on the S/MIME list
and (2) you are asking a question about a Network Associates product, not
about the standard.

However, the answer to your question is: Yes. Both PGP 6.0 and OpenPGP
support hierarchical trust. In OpenPGP Formats, see section 5.2.3.12 and
5.2.3.2 for the syntactic mechanisms for hierarchical CAs. Up to 255 levels
of CAs are allowed by the system. This feature is called a "trust signature."

The product PGP 6.0 will evaluate any level CA hierarchy, but will generate
only a two-level CA system with its "meta-introducer" feature. What this
means is that you can have a PGP cert that is a root cert, and then have
one additional sub-CA that signs leaf certs. We limited the feature in the
product only because it was very hard to get the UI right. As I said
before, the shipping software accepts the full, OpenPGP 255 levels.

The trust signature also provides for scope-limited cross-certification.
The signatures are the same, it's just who you give them to.

	Jon



-----
Jon Callas                                  [e-mail]
CTO, Total Network Security                 3965 Freedom Circle
Network Associates, Inc.                    Santa Clara, CA 95054
[phone]                              
Fingerprints: D1EC 3C51 FCB1 67F8 4345 4A04 7DF9 C2E6 F129 27A9 (DSS)
              665B 797F 37D1 C240 53AC 6D87 3A60 4628           (RSA)


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA20741 for ietf-smime-bks; Mon, 9 Nov 1998 07:55:10 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id HAA20733 for <[e-mail]>; Mon, 9 Nov 1998 07:54:56 -0800 (PST)
Received: by access.itsec.gov.uk; id AA28609; Mon, 9 Nov 98 15:46:19 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma028604; Mon, 9 Nov 98 15:45:53 GMT
Received: by ingress.itsec.dmz; id AA06481; Mon, 9 Nov 98 15:47:11 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma006450; Mon, 9 Nov 98 15:46:57 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Mon, 09 Nov 1998 15:46:09 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Mon, 09 Nov 1998 15:42:18 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Algorithm Dependancy Issues
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA20737
Sender: [e-mail]
Precedence: bulk

Enzo,

IHO, the aim of the S/MIME WG is to ensure interoperability of S/MIME.  I view S/MIME as a profile (the MSG spec) of the CMS/ESS and other specs.  So to be S/MIME compliant you must meet the mandatory elements of the MSG spec and this implies compliancy with certain aspects of the CMS spec, but not all of it.

I believe that vendors should be able to remain CMS compliant without being S/MIME compliant or dependant of S/MIME's algorithms suite.

IMHO, protocol and procedural compliancy should be treated differently from algorithm compliancy.  I would like to see CMS be algorithm independant.

For this reason, IMO I believe your question should have been:

Wouldn't that endanger interoperability between S/MIME-compliant agents sitting on the two sides of the fence, and exchanging mail through a gateway?

And the answer would be no, as the S/MIME spec ensures interoperability.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]

>>> "Enzo Michelangeli" <[e-mail]> 11/06/98 11:38am >>>

Wouldn't that endanger interoperability between CMS-compliant agents sitting
on the two sides of the fence, and exchanging mail through a gateway?

Enzo






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA26826 for ietf-smime-bks; Sun, 8 Nov 1998 20:35:54 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA26822 for <[e-mail]>; Sun, 8 Nov 1998 20:35:53 -0800 (PST)
Received: (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) id UAA23047; Sun, 8 Nov 1998 20:39:59 -0800 (PST)
To: Robert Zuccherato <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, [e-mail]
Subject: Re: Comments on updated X9.42 draft
References: <[e-mail]>
From: EKR <[e-mail]>
Date: 08 Nov 1998 20:39:58 -0800
In-Reply-To: Robert Zuccherato's message of "Fri, 6 Nov 1998 15:53:34 -0500"
Message-ID: <[e-mail]>
Lines: 19
X-Mailer: Gnus v5.6.43/XEmacs 20.4 - "Emerald"
Sender: [e-mail]
Precedence: bulk

Robert Zuccherato <[e-mail]> writes:

> I have one further comment on the X9.42 draft.  Presently it states:
> > X9.42 requires that the private key x be in the interval [2^(m-1) + 1,
> > (q - 2)]. 
> > 
> The latest (ballot) version of X9.42 actually only requires that private
> keys be in the interval [2, q-2].  Restricting the key space to
> [2^(m-1)+1, (q-2)] only results in a smaller key space, which is
> (slightly) easier to attack.  There is no reason to restrict it like
> this.
Works for me.

I took that restriction directly from an X9.42 draft. I'm perfectly
happy to relax it.
-Ekr

-- 
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA17170 for ietf-smime-bks; Fri, 6 Nov 1998 17:19:37 -0800 (PST)
Received: from smtp3.erols.com (smtp3.erols.com [207.172.3.236]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA17166 for <[e-mail]>; Fri, 6 Nov 1998 17:19:36 -0800 (PST)
Received: from fujitsu1.ny.certco.com (207-172-40-46.s46.tnt11.ann.erols.com [207.172.40.46]) by smtp3.erols.com (8.8.8/8.8.5) with ESMTP id UAA04779; Fri, 6 Nov 1998 20:22:26 -0500 (EST)
Message-Id: <[e-mail]>
Reply-To: <[e-mail]>
From: "Rich Ankney" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: CMS: Algorithm Dependancy Issues
Date: Fri, 6 Nov 1998 20:21:57 -0500
X-MSMail-Priority: Normal
X-Priority: 3
X-Mailer: Microsoft Internet Mail 4.70.1161
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

I would agree with this change in terminology (as would most
of X9, who like this because it provides X9.17-like (ugh) functionality).

/ Rich

----------
> From: Peter Gutmann <[e-mail]>
> To: [e-mail]
> Subject: Re: CMS: Algorithm Dependancy Issues
> Date: Saturday, November 07, 1998 4:38 AM
> 
> While people are commenting on the use of CMS as a general protocol
bucket, 
> there's something which has bothered me for awhile: The use of the term 
> MailListRecipientInfo to describe the use of shared symmetric keys. 
While I 
> appreciate that there are historical reasons for the ML naming, is it too
late 
> to change it to something more appropriate like
SymmetricKeyRecipientInfo?  
> Its use doesn't have much to do with mailing lists, and since CMS is
supposed 
> to be an application-independent format it would be more accurate to
describe 
> it by what it actually does rather than one particular possible
application of 
> the technique when used with S/MIME.
>  
> An example of where this causes confusion is with authData (MAC'd data):
If 
> you exclude MailListRecipientInfo, the key management is based entirely
on 
> public-key technology, because the other two recipientInfos all use
public-key 
> mechanisms (KeyTrans has "must contain a key transport public key",
KeyAgree 
> has "must contain a key agreement public key").  However the most common
use 
> for a MAC - using a shared key/password for integrity protection -
requires 
> the use of the rather badly misnamed MailListRecipientInfo, which is the
only 
> way to specify a shared key.  It isn't at all obvious from flicking
through 
> the RecipientInfo's that you're supposed to manage a shared key by
pretending 
> you're on a mailing list.
>  
> If the name change to the more accurate description isn't possible, would
it 
> at least be possible to add comments where necessary in the text to point
out 
> that the ML stuff should be used for shared keys?  This would require for

> example changing the authData text in section 9 to:
>  
>   3.  For each recipient, the ... defined in Section 6.2.  The most
common use 
>       for a MAC is with a key shared by both the sender and recipient,
which 
>       would entail the use of the MailListRecipientInfo type.
>  
> Peter.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA15199 for ietf-smime-bks; Fri, 6 Nov 1998 13:01:05 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id NAA15195 for <[e-mail]>; Fri, 6 Nov 1998 13:01:04 -0800 (PST)
Received: 	id PAA06139; Fri, 6 Nov 1998 15:57:56 -0500
Received: by gateway id <W1GJNDHD>; Fri, 6 Nov 1998 15:55:09 -0500
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Eric Rescorla <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on updated X9.42 draft
Date: Fri, 6 Nov 1998 15:53:34 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I have one further comment on the X9.42 draft.  Presently it states:
> X9.42 requires that the private key x be in the interval [2^(m-1) + 1,
> (q - 2)]. 
> 
The latest (ballot) version of X9.42 actually only requires that private
keys be in the interval [2, q-2].  Restricting the key space to
[2^(m-1)+1, (q-2)] only results in a smaller key space, which is
(slightly) easier to attack.  There is no reason to restrict it like
this.

	Robert.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14886 for ietf-smime-bks; Fri, 6 Nov 1998 12:43:16 -0800 (PST)
Received: from aum (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA14882; Fri, 6 Nov 1998 12:43:12 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 12:45:56 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: CMS: Algorithm Dependancy Issues
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Based on Peter's discussion, I second the request to change the name.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA14791 for ietf-smime-bks; Fri, 6 Nov 1998 12:35:18 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA14787 for <[e-mail]>; Fri, 6 Nov 1998 12:35:17 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id JAA09591 for <[e-mail]>; Sat, 7 Nov 1998 09:38:11 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91038469108229>; Sat, 7 Nov 1998 09:38:11 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: CMS: Algorithm Dependancy Issues
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Sat, 7 Nov 1998 09:38:11 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

While people are commenting on the use of CMS as a general protocol bucket, 
there's something which has bothered me for awhile: The use of the term 
MailListRecipientInfo to describe the use of shared symmetric keys.  While I 
appreciate that there are historical reasons for the ML naming, is it too late 
to change it to something more appropriate like SymmetricKeyRecipientInfo?  
Its use doesn't have much to do with mailing lists, and since CMS is supposed 
to be an application-independent format it would be more accurate to describe 
it by what it actually does rather than one particular possible application of 
the technique when used with S/MIME.
 
An example of where this causes confusion is with authData (MAC'd data): If 
you exclude MailListRecipientInfo, the key management is based entirely on 
public-key technology, because the other two recipientInfos all use public-key 
mechanisms (KeyTrans has "must contain a key transport public key", KeyAgree 
has "must contain a key agreement public key").  However the most common use 
for a MAC - using a shared key/password for integrity protection - requires 
the use of the rather badly misnamed MailListRecipientInfo, which is the only 
way to specify a shared key.  It isn't at all obvious from flicking through 
the RecipientInfo's that you're supposed to manage a shared key by pretending 
you're on a mailing list.
 
If the name change to the more accurate description isn't possible, would it 
at least be possible to add comments where necessary in the text to point out 
that the ML stuff should be used for shared keys?  This would require for 
example changing the authData text in section 9 to:
 
  3.  For each recipient, the ... defined in Section 6.2.  The most common use 
      for a MAC is with a key shared by both the sender and recipient, which 
      would entail the use of the MailListRecipientInfo type.
 
Peter.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14249 for ietf-smime-bks; Fri, 6 Nov 1998 11:34:59 -0800 (PST)
Received: from dylithium.adga.ca (dylithium.adga.ca [207.112.67.34]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA14240 for <[e-mail]>; Fri, 6 Nov 1998 11:33:38 -0800 (PST)
Received: from xfile ([207.112.70.165]) by dylithium.adga.ca (980427.SGI.8.8.8/8.8.8-ajr) with SMTP id OAA06569; Fri, 6 Nov 1998 14:34:20 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
Date: Fri, 06 Nov 1998 14:31:28 -0500
To: Russ Housley <[e-mail]>
From: Francois Rousseau <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Russ,

Here are few comments.

Sec 5.1, based on how the last sentence of the definition of the SignedData
"certificates" field currently reads, if no attribute certificates are
present although the content type may be other than id-data, the version
could be misinterpreted to be 1. I would suggest that the last sentence of
this definition be amended as follows:

"If no attribute certificates are present in the collection and the
encapsulated content type is id-data, then the value of version shall be 1.
 However, if attribute certificates are present or the encapsulated content
type is other than id-data, then the value of version shall be 3."

Sec 5.3, the definition of the SignerInfo "signedAttributes" field
indicates that both the "content-type" and the "message-digest" attributes
must be present if the field is present. However, this does address the
exception created by the "countersignature" attribute in Sec 11.4 where it
is indicated that the signedAttributes field need not contain a
content-type attribute, as there is no content type for countersignatures.
To address this, I would suggest that the statement on the "content-type
attribute" under the SignerInfo "signedAttributes" field reads as follows:

"A content-type attribute having as its value the content type of the
EncapsulatedContentInfo value being signed except within a
countersignature, as there is no content type for countersignatures.
Sections 11.1 and 11.4 respectively define the content-type and the
countersignature attributes."

Sec 5.4, similarly as Sec 5.3 above, the fourth sentence of the second
paragraph should be amended to read as follows:

"Since the SignedAttributes value, when present, must contain the message
digest and the content type attributes, except within a countersignature,
those values are indirectly included in the result."

Sec 6, I agree with others that it would be preferable if EnvelopeData was
also extensible per message and/or per recipient.

Francois Rousseau
AEPOS Technologies 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA14135 for ietf-smime-bks; Fri, 6 Nov 1998 11:16:05 -0800 (PST)
Received: from aum (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id LAA14131; Fri, 6 Nov 1998 11:16:01 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Fri, 06 Nov 1998 11:18:45 -0800
To: "Darren Harter" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: CMS:  Algorithm Dependancy Issues
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

Without a minimum set of algorithms, you cannot have two protocols that
both use CMS talk to each other. This was a strongly-desired feature of
CMS, since the IETF strives to have its protocols work together, or at
least not clash in an ugly fashion.

The required set of algorithms is tiny. It assures us that if some protocol
developer comes along tomorrow and says, "hmmmm, CMS looks good" that they
don't pick some odd encryption algorithm that will never interact with
S/MIME or other CMS-using protocols.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA12209 for ietf-smime-bks; Fri, 6 Nov 1998 06:44:39 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA12205 for <[e-mail]>; Fri, 6 Nov 1998 06:44:37 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id JAA26533; Fri, 6 Nov 1998 09:46:59 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-x942-02.txt
Date: Fri, 06 Nov 1998 09:46:59 -0500
Sender: [e-mail]
Precedence: bulk

--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		: Diffie-Hellman Key Agreement Method
	Author(s)	: E. Rescorla
	Filename	: draft-ietf-smime-x942-02.txt
	Pages		: 7
	Date		: 05-Nov-98
	
   This document standardizes one particular Diffie-Hellman variant,
   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
   group. An algorithm for converting the shared secret into an arbi-
   trary amount of keying material is provided.

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-x942-02.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-smime-x942-02.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:	[e-mail].  In the body type:
	"FILE /internet-drafts/draft-ietf-smime-x942-02.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="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-x942-02.txt

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

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA10000 for ietf-smime-bks; Fri, 6 Nov 1998 03:32:56 -0800 (PST)
Received: from pop01.globecomm.net (pop01.globecomm.net [206.253.129.185]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id DAA09996 for <[e-mail]>; Fri, 6 Nov 1998 03:32:55 -0800 (PST)
Received: from home (du0002.ima.net [202.75.0.131]) by pop01.globecomm.net (8.9.0/8.8.0) with SMTP id GAA12082; Fri, 6 Nov 1998 06:35:32 -0500 (EST)
Message-ID: <017401be097a$0a034880$83004bca@home>
From: "Enzo Michelangeli" <[e-mail]>
To: "Darren Harter" <[e-mail]>, <[e-mail]>
Subject: Re: Algorithm Dependancy Issues
Date: Fri, 6 Nov 1998 19:38:26 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3026.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3026.0
Sender: [e-mail]
Precedence: bulk

-----Original Message-----
From: Darren Harter <[e-mail]>
To: [e-mail] <[e-mail]>
Date: Friday, November 06, 1998 7:00 PM
Subject: CMS: Algorithm Dependancy Issues


> I'd like to raise an issue that is giving me some problems.
> Currently, the CMS spec describes a number of algorithms for both
> authentication and confidentiality, mandating some of them and
> leaving others optional.
>
> I believe the right algorithms etc are mandated for S/MIME over the
> Internet.
> But, as CMS is intended for use outside of S/MIME as a 'protocol
> bucket' by other applications that may not wish (or may no be able)
> to support the mandated algorithm set, surely the best place to
> specify and mandate algorithms is in the MSG spec.


Wouldn't that endanger interoperability between CMS-compliant agents sitting
on the two sides of the fence, and exchanging mail through a gateway?

Enzo





Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA05471 for ietf-smime-bks; Fri, 6 Nov 1998 01:49:17 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA05464 for <[e-mail]>; Fri, 6 Nov 1998 01:49:15 -0800 (PST)
Received: by access.itsec.gov.uk; id AA01972; Fri, 6 Nov 98 09:40:36 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma001962; Fri, 6 Nov 98 09:40:32 GMT
Received: by ingress.itsec.dmz; id AA10190; Fri, 6 Nov 98 09:41:49 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma010176; Fri, 6 Nov 98 09:41:39 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Fri, 06 Nov 1998 09:40:55 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Fri, 06 Nov 1998 09:49:11 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail]
Subject: CMS:  Algorithm Dependancy Issues
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA05467
Sender: [e-mail]
Precedence: bulk

I'd like to raise an issue that is giving me some problems.  Currently, the CMS spec describes a number of algorithms for both authentication and confidentiality, mandating some of them and leaving others optional.

I believe the right algorithms etc are mandated for S/MIME over the Internet.  But, as CMS is intended for use outside of S/MIME as a 'protocol bucket' by other applications that may not wish (or may no be able) to support the mandated algorithm set, surely the best place to specify and mandate algorithms is in the MSG spec.  

That way vendors will be able to claim conformance to CMS without having to implement the mandatory algorithm set.  It will make no difference to those claiming conformance to S/MIME.  To me the latter means conforming to the profile of CMS/ESS etc. that the MSG spec lays down.

Likewise, it concerns me that the CMS spec is reliant on the X942 spec.  Again, I believe this should be referred to by the MSG spec not CMS.

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id BAA05439 for ietf-smime-bks; Fri, 6 Nov 1998 01:49:02 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id BAA05431 for <[e-mail]>; Fri, 6 Nov 1998 01:48:59 -0800 (PST)
Received: by access.itsec.gov.uk; id AA01971; Fri, 6 Nov 98 09:40:36 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma001963; Fri, 6 Nov 98 09:40:32 GMT
Received: by ingress.itsec.dmz; id AA10192; Fri, 6 Nov 98 09:41:50 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma010174; Fri, 6 Nov 98 09:41:39 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Fri, 06 Nov 1998 09:40:55 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Fri, 06 Nov 1998 09:39:47 +0000
From: "Darren Harter" <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: CMS -EnvelopedData extensibility
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id BAA05435
Sender: [e-mail]
Precedence: bulk

It's possible that this one has slipped through unnoticed, but I'm a little suprised by the lack of response.

I think John has a good point in that unlike SignedData, EnvelopeData is not extensible.  Regardless of how unlikely it may seem, it is possible that an appliation may wish to send some information 'in-the-clear' using EnvlopedData.  For example, to carry CRLs, other certs, and clear label etc.  I believe it should be possible to do this without forcin gthe application to wrap the EnvelopedData in another SignedData.  After all CMS will be used for purposes other than S/MIME.

I agree with John that EnvelopedData should be extended to allow unauthenticated clear data to be passed on both a global and per-recipient basis.

I don't how other list members feel, but I would be suprised if the IESG would approve a standard that was not extensible and future proofed in this way.

Regards,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]

>>> "John Ross" <[e-mail]> 11/02/98 06:55pm >>>
CMS-EnvelopedData is currently not easy to extend to carry additional information or attributes.  Is that intentional?

Generally, it is a good idea to include a way of extending protocols when defining standards. Including a protocol extension mechanism facilitates easy migration to meeting new requirements. 

In  particular,  in the case of EnvelopedData future extensions may be required to support additional Algorithms.

The first Question I have to the Mail list is:

1) Is there support for providing an extensibility mechanism in EnvelopedData? YES or NO.

If there is support, then  the second question is 
2 ) Should a similar scheme to SignedData unsigned attributes could be used? YES or NO.

The extension mechanism could be per EnvelopedData (i.e per message).

 The following is an example ASN.1:
 
 EnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo 
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

The extension mechanism could also be per recipient using the key transport recipient information and key agreement recipient info.

The following is an example ASN.1:
 
KeyTransRecipientInfo ::= SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey 
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


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




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA14831 for ietf-smime-bks; Thu, 5 Nov 1998 17:01:07 -0800 (PST)
Received: from post.mail.demon.net (post-22.mail.demon.net [194.217.242.7]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA14827 for <[e-mail]>; Thu, 5 Nov 1998 17:01:06 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zbaJP-0003xR-00 for [e-mail]; Fri, 6 Nov 1998 01:03:39 +0000
Message-ID: <[e-mail]>
Date: Fri, 06 Nov 1998 01:03:12 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: Comments on updated X9.42 draft
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Just a minor comment. Could an example be included with some "pubInfo"
please? Just to make sure everyone does it right :-)

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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12854 for ietf-smime-bks; Thu, 5 Nov 1998 14:38:29 -0800 (PST)
Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA12850 for <[e-mail]>; Thu, 5 Nov 1998 14:38:27 -0800 (PST)
Received: 	id RAA21381; Thu, 5 Nov 1998 17:38:56 -0500
Received: by gateway id <W1GJM0RA>; Thu, 5 Nov 1998 17:36:10 -0500
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: Eric Rescorla <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Comments on updated X9.42 draft
Date: Thu, 5 Nov 1998 17:34:29 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.1960.3)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

Russ;

A few comments on your comments.

> ----------
> From: 	Russ Housley[SMTP:[e-mail]]
> Sent: 	Thursday, November 05, 1998 10:54 AM
> To: 	Eric Rescorla
> Cc: 	[e-mail]
> Subject: 	Comments on updated X9.42 draft
> 
> 
> >2.1.5.  Public Key Validation
> >
> >   The following algorithm MAY be used to validate received public
> keys.
> 
> I think that we need to require validation at the tie the public key
> is
> placed in a certificate OR at the time the public key is used to
> compute ZZ.
> 
Actually, I don't think that in a store and forward environment and
using ephemeral-static DH, public-key validation is necessarily
required.  Let us first consider the situation from the point of view of
the sender.  In this situation, the sender is combining his ephemeral
private key with the receiver's certified public key.  Because the
receiver's public key is certified, it could not have been changed by a
third party attacker, so the only entity that could possibly be
performing a "small-subgroup" type of attack is the receiver.  However,
the sender should not be concerned about this situation.  The sender
will be agreeing on a secret key with the receiver anyway, so the
receiver will get access to the encrypted information.  Whether or not
the receiver also gets access to the sender's private key does not
matter (because the key is ephemeral).

Now let us consider the receiver.  In this situation, the receiver is
combining it's static private key with the uncertified public key of the
sender.  Because the public key is uncertified, it could have been
modified by an attacker, so the threat of a "small-subgroup" type of
attack is real.  However, because this is a store and forward
environment, it is possible that the receiver might not respond to the
sender if the message does not properly decrypt and the receiver
probably won't use the shared key for any further communications.  Since
the success of the "small-subgroup" attacks relies on the attacker being
able to obtain information about when the decryption was successful or
obtaining a message encrypted with the "bogus" shared key, this attack
would not be applicable.

Because there is a potential patent involved here, I think we should be
careful.  If ephemeral-static DH is used and the receiver will not be
sending back any further information, public key validation is not
required for security.  We probably don't want to require it in these
situations.

> >
> >           1. Verify that y lies within the interval [2,p-1]. If it
> does not,
> >           the key is invalid.
> >           2. Compute y^q (mod p). If the result == 1, the key is
> valid.
> >           Otherwise the key is invalid.
> 
> There seems to be an alternative check that can be performed.  Since
> we do
> not know what is actually claimed in the Certicom pending patent,
> secure
> alternatives seem to be a good idea.  The alternative is:  verify that
> Y ^
> [(p-1) / q] is not congruent to 0, 1, or g.
> 
Actually, this check is not sufficient.  Let h be a generator of a small
subgroup modulo p.  Assume an attacker can replace the valid public key
ya with h*ya.  Then (h*ya)^[(p-1)/q] (mod p) is not congruent to 0,1 or
g, but it can be used for a "small subgroup" attack. 

> >   The primary purpose of public key validation is to prevent a small
> >   subgroup attack [REFERENCE?] on the sender's key pair. If
> Ephemeral-
> >   Static mode is used, this check is unnecessary. Note that this
> pro-
> >   cedure may be subject to pending patents.
> 
> I suggest that you break this into two paragraphs.  Make the patent
> statement a separant paragraph.
> 
> Also, there seem to be cases where the recipient is an automated
> responder
> (perhaps a timestamp service) that have concerns with a small subgroup
> attack too.  Any time that the attacker can determine the
> success/failure
> of the key generation there seems to be an issue.
> 
True.  But in cases where the attacker cannot determine the
success/failure of the key generation this isn't an issue, and so
shouldn't be mandated.

	Robert.



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA11715 for ietf-smime-bks; Thu, 5 Nov 1998 13:25:23 -0800 (PST)
Received: from spyrus.com (prometheus.spyrus.com [209.66.65.49]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA11711 for <[e-mail]>; Thu, 5 Nov 1998 13:25:21 -0800 (PST)
Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by spyrus.com (8.7.6/8.7.3/arc) with SMTP id NAA27388; Thu, 5 Nov 1998 13:27:09 -0800 (PST)
Message-Id: <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 05 Nov 1998 10:54:46 -0500
To: Eric Rescorla <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Comments on updated X9.42 draft
Cc: [e-mail]
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>Abstract
>
>   This document standardizes one particular Diffie-Hellman variant,
>   based on the ANSI X9.42 standard, developed by the ANSI X9F1 working
>   group. An algorithm for converting the shared secret into an arbi-
>   trary amount of keying material is provided.

I think we need to expand this just a bit.  In particular, some readers may
need to know that D-H is a key agreement algorithm, used by to parties to
agree on a shared secret.  The resulting shared secret is used as a
symmetric cryptographic key.  Further, the D-H variant described requires
the recipient to have a certificate, but the originator may have a static
key pair (with the public key placed in a certificate) or an ephemeral key
pair.

>TODO
>
>   Redo the examples to match the new algorithm for computing K.

When will these be ready?  I would like to go to Working Group Last Call
shortly.

>2.  Overview Of Method
>
>   Diffie-Hellman key agreement requires that both the sender and reci-
>   pient of a message have key pairs. By combining one's private key and
>   the other party's public key, both parties can compute the same
>   shared secret number. This number can then be converted into crypto-
>   graphic keying material. That keying material is typically used as a
>   key encryption key (KEK) to encrypt (wrap) a key (a message encryp-
>   tion key -- MEK) which is in turn used to encrypt the message data.

For alignment of terminology between this document and CMS, please use
key-encryption key and content-encryption key.

>2.1.  Key Agreement
>
>   The first stage of the key agreement process is to compute a shared
>   secret number ZZ (which will be constant for any pair of Diffie-
>   Hellman keys). ZZ is then converted into a shared symmetric key. Note
>   that the symmetric key will be different for each key agreement, due
>   to the introduction of public random components.

I suggest a slight rewording:

The first stage of the key agreement process is to compute a shared secret
number, called ZZ.  When the same originator and recipient public/private
key pairs are used, the same ZZ value will result.  The ZZ value is then
converted into a shared symmetric cryptographic key. When the originator
employs a static private/public key pair, the introduction of public random
values are used to ensure that the resulting symmetric key will be
different for each key agreement.

>
>2.1.1.  Generation of ZZ
>
> [SNIP]
>   where ^ denotes exponentiation
>         ya is party a's public key; ya = g ^ xa (mod p)
>         yb is party b's public key; yb = g ^ xb (mod p)
>         xa is party a's private key
>         xb is party b's private key
>         p is a large prime
>         g is a generator for the integer group specified by p.

Please expand this list to include q as defined in X9.42.  I realize that
it does not directly impact the equations above, but this seems like the
right place to describe the relationship between p, q, and g.
 
>2.1.2.  Generation of Keying Material
>
> [SNIP]
>   algorithm is the ASN.1 algorithm OID of the symmetric algorithm with which
>     this KEK will be used.
>   counter is a 32 bit number, represented in network byte order.
>   Its initial value is 1, i.e. the byte sequence 00 00 00 01 (hex)
>   pubInfo is a random string provided by the sender. In CMS, it is provided
>   as a parameter in the UserKeyingMaterial field (a 512 bit byte string).

What is "a 512 bit byte string?"  I think you want to say 512 bit value.
>
>   Note that the only source of secret entropy in this computation is
>   ZZ, so the security of this data is limited to the size of ZZ, even
>   if more data than ZZ is generated. However, since pubInfo is dif-
>   ferent for each message, a different KEK will be generated for each
>   message.

Since PubInfo is optional, this paragraph is too strong.  I suggest that
you say that PubInfo must be present if the originator uses a static
public/private key pair.  Further, I suggest that you say that PubInfo may
be present if the originator uses a ephemeral public/private key pair.

>2.1.3.  KEK Computation
>
>   Each key encryption algorithm requires a specific size key (n). The
>   KEK is generated by mapping the left n-most bytes of KM onto the key.
>   Consequently, for a DES [FIPS-46-1] key, which requires 64 bits of
>   keying material, the algorithm is only run once, with a counter value
>   of 1.  The first 64 bits of the output are parity adjusted and con-
>   verted into a DES key.  For 3DES, which requires 192 bits of keying
>   material, the algorithm must be run twice, once with a counter value
>   of 1 (to generate K1', K2', and the first 32 bits of K3') and once
>   with a counter value of 2 (to generate the last 32 bits of K3).
>   K1',K2' and K3' are then parity adjusted to generate the 3 DES keys
>   K1,K2 and K3.

Please address the two key-encryption key algorithms discussed in CMS:
Triple-DES and RC2.  This is in line with the Working Group decisions made
in Chicago.

>2.1.5.  Public Key Validation
>
>   The following algorithm MAY be used to validate received public keys.

I think that we need to require validation at the tie the public key is
placed in a certificate OR at the time the public key is used to compute ZZ.
>
>           1. Verify that y lies within the interval [2,p-1]. If it does not,
>           the key is invalid.
>           2. Compute y^q (mod p). If the result == 1, the key is valid.
>           Otherwise the key is invalid.

There seems to be an alternative check that can be performed.  Since we do
not know what is actually claimed in the Certicom pending patent, secure
alternatives seem to be a good idea.  The alternative is:  verify that Y ^
[(p-1) / q] is not congruent to 0, 1, or g.

>   The primary purpose of public key validation is to prevent a small
>   subgroup attack [REFERENCE?] on the sender's key pair. If Ephemeral-
>   Static mode is used, this check is unnecessary. Note that this pro-
>   cedure may be subject to pending patents.

I suggest that you break this into two paragraphs.  Make the patent
statement a separant paragraph.

Also, there seem to be cases where the recipient is an automated responder
(perhaps a timestamp service) that have concerns with a small subgroup
attack too.  Any time that the attacker can determine the success/failure
of the key generation there seems to be an issue.

Enjoy,
  Russ


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id HAA08018 for ietf-smime-bks; Thu, 5 Nov 1998 07:34:34 -0800 (PST)
Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id HAA08014 for <[e-mail]>; Thu, 5 Nov 1998 07:34:33 -0800 (PST)
Received: from exchng-fairfax.p-e-c.com by relay1.UU.NET with ESMTP  (peer crosschecked as: [204.254.216.13]) id QQfoew25189; Thu, 5 Nov 1998 10:36:18 -0500 (EST)
Received: by exchang-fairfax.pec.com with Internet Mail Service (5.0.1460.8) id <V0W7WC26>; Thu, 5 Nov 1998 10:38:02 -0500
Message-ID: <[e-mail]>
From: WHenry <[e-mail]>
To: "'Stefan_Salzmann/HAM/[e-mail]'" <Stefan_Salzmann/HAM/[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Some comments on SMIME versus PGP
Date: Thu, 5 Nov 1998 10:38:01 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.0.1460.8)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id HAA08015
Sender: [e-mail]
Precedence: bulk

 Stefan,

 The most important thing in ANY cryptographic system is KEY MANAGEMENT. In
a PKI, the key management agent is the Certificate Authority (CA).

 You might want to bring up the issue of Trust Models. There are essentially
three models supported in the market today: Web of Trust (sometimes called
Key-Ring Trust), In-Sourced Trust, and Outsourced Trust.

 There are different levels of trust (and risk) associated with products
that support these different models. In the case of PGP (as I know it),
there is no central key management agent. All keys are generated on the fly
and passed around informally. There is no independent agent that verifies
the integrity of users and associated certificates (i.e. cryptographic
keys). This method works okay in the case of a small number of users who
share PGP keys in a literal handshake (or trust their being passed via
email); but the integrity of the system breaks down quickly as keys are
passed from one user to the next.

 An In-Sourced Trust Model basically means the key management function is
implemented and managed by some trusted entity within some closed community
(a corporation, for example). An example here would be Entrust.

 An Out-Sourced Trust Model means key management is literally outsourced to
a 3rd party, like Verisign.

 Which trust model your organization chooses to rely on for key management
should, in no small measure, dictate the PKI product to implement.

 Regards,
 Bill Henry

 

> -----Original Message-----
> From:	Stefan_Salzmann/HAM/[e-mail]
> [SMTP:Stefan_Salzmann/HAM/[e-mail]]
> Sent:	Thursday, November 05, 1998 4:55 AM
> To:	[e-mail]
> Cc:	[e-mail]
> Subject:	Some comments on SMIME versus PGP
> 
> 
> Our customer (a german bank) uses lotus notes. We are implementing an
> smime
> plugin right now. A couple days ago some representatives have been at a
> general
> german bank conference. At that conference they discussed with other banks
> secure email implementations. At the conference many banks argumented pro
> PGP
> and said that PGP would be better than SMIME. Because our customer doesn´t
> want
> to swim against the stream it now tryes to do some convincing work pro
> SMIME.
> Therefore I was looking for the difference between SMIME and PGP.
> Your urls helped in the way that they provide a relyable source for
> statements
> pro and against one of those two methods. As well I was struggling to much
> in
> detailed differences. I missed the big picture or better to say I didn´t
> have
> some relyable sources for confirming my thoughts.
> In my opinion (as far as I have red), SMIME will become the major standard
> because of its compliance with PKI components and the support of major
> standards
> as X.509v3 and PKCS (which isn´t a standard but adopted mainly). As well I
> believe the incompatibility between SMIME and PGP will work against PGP.
> Would you agree on that?
> 
> 
> 
> 
> 
> "Enzo Michelangeli" <[e-mail]> on 05.11.98 09:59:36
> 
> To:   Stefan Salzmann/HAM/Lotus@LOTUSINT
> cc:
> Subject:  Re: The URLs you gave me are fantastic, its exactly what I
> need!!
>       Thanks once again <eom>
> 
>  << File: ATT08586.txt >> 


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id DAA06435 for ietf-smime-bks; Thu, 5 Nov 1998 03:26:37 -0800 (PST)
Received: from access.itsec.gov.uk (access.itsec.gov.uk [193.195.170.254]) by mail.proper.com (8.8.8/8.8.5) with SMTP id DAA06431 for <[e-mail]>; Thu, 5 Nov 1998 03:26:34 -0800 (PST)
Received: by access.itsec.gov.uk; id AA17505; Thu, 5 Nov 98 11:18:04 GMT
Received: from ingress.itsec.dmz(192.168.1.250) by access.itsec.gov.uk via smap (3.2) id xma017501; Thu, 5 Nov 98 11:17:56 GMT
Received: by ingress.itsec.dmz; id AA29715; Thu, 5 Nov 98 11:19:13 GMT
Received: from sleepy.itsec.lepernet(10.10.10.25) by ingress.itsec.dmz via smap (3.2) id xma029708; Thu, 5 Nov 98 11:19:09 GMT
Received: from CESG-Message_Server by cesg.gov.uk with Novell_GroupWise; Thu, 05 Nov 1998 11:18:25 +0000
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise 5.2
Date: Thu, 05 Nov 1998 11:25:00 +0000
From: "Darren Harter" <[e-mail]>
To: Stefan_Salzmann/HAM/[e-mail]
Cc: [e-mail]
Subject: Re: Difference between SMIME and PGP
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id DAA06432
Sender: [e-mail]
Precedence: bulk

Stefan,

You seem to have the signature and encryption elements of S/MIME confused.

Let's take signatures first.

The SHA algorithm converts a given message to a unique 160-bit number (the hash).  The problem is that anybody can generate this hash from a given message.  So, an attacker could change the message, generate the newhash value and substitute it for the one that the originator stated.  It is for this reason that SHA alone cannot provide a signature.

The DSA algorithm takes the result of the SHA process and effectively encrypts the hash using the originators private signature key.  The encrypted hash (160 bits - known as S) is then sent to the recipient along with an integrity check number (160 bits - known as R).  The recipient recalculates the hash using SHA and then decrypts S using the hash value that he has computed along with the originators public key (stored in his X.509 certificate) and produces a value V.  If V == R then the signature is valid, otherwise it is not.  There is a random element to this, but I didn't wantto cloud the explaination.

As you can see to provide an integrity and proof or origin service both DSA and SHA need to be applied.  

Now, let's take confidentiality....

First a random message encryption key (MEK) is generated, and the message is encrypted using this key and your chosen algorithm - say 3DES.

A Diffie-Hellman exchange is then used to generate a shared secret key between the originator and the recipient - call this the Key Encryption Key or KEK.  The random message encryption key (MEK) is then encrypted using the KEK, and the result stored in a token. This is repeated for each recipient.

The encrypted message, and all of the per-recipient tokens are then sent to all recipients.  The recipient will identify their token, perform a Diffie-Hellman exchange to calculate the shared secret key (KEK), and use it to decrypt the random message encryption key (MEK).  Once the MEK has been obtained, the message may be decrypted.

As you can see the message is only encrypted once regardless of the number of recipients.

In summary, DSA/SHA are used for the authentication/signature service, and D-H/3DES for the confidentiality/encryption service.  The two do not mix in any way.

Hope this helps,

Darren

-------------------------------------------------------------
Darren Harter BSc Hons MBCS CEng
CASM Technical Architect
CASM Programme Office
CESG
Work: [e-mail]
Home: [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA04036 for ietf-smime-bks; Thu, 5 Nov 1998 02:00:37 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA04032 for <[e-mail]>; Thu, 5 Nov 1998 02:00:36 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id FAA26523; Thu, 5 Nov 1998 05:08:22 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id FAA02351; Thu, 5 Nov 1998 05:01:32 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B3.0037CEC3 ; Thu, 5 Nov 1998 05:09:34 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
cc: [e-mail]
Message-ID: <[e-mail]>
Date: Thu, 5 Nov 1998 10:54:33 +0100
Subject: Some comments on SMIME versus PGP
Mime-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=YyVh35C0xiRx8kaEn5cHRMXi1p9aDHIFGgGcjppME5GSFiZd8BIJaMFW"
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

--0__=YyVh35C0xiRx8kaEn5cHRMXi1p9aDHIFGgGcjppME5GSFiZd8BIJaMFW
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-transfer-encoding: quoted-printable


Our customer (a german bank) uses lotus notes. We are implementing an s=
mime
plugin right now. A couple days ago some representatives have been at a=
 general
german bank conference. At that conference they discussed with other ba=
nks
secure email implementations. At the conference many banks argumented p=
ro PGP
and said that PGP would be better than SMIME. Because our customer does=
n=B4t want
to swim against the stream it now tryes to do some convincing work pro =
SMIME.
Therefore I was looking for the difference between SMIME and PGP.
Your urls helped in the way that they provide a relyable source for sta=
tements
pro and against one of those two methods. As well I was struggling to m=
uch in
detailed differences. I missed the big picture or better to say I didn=B4=
t have
some relyable sources for confirming my thoughts.
In my opinion (as far as I have red), SMIME will become the major stand=
ard
because of its compliance with PKI components and the support of major =
standards
as X.509v3 and PKCS (which isn=B4t a standard but adopted mainly). As w=
ell I
believe the incompatibility between SMIME and PGP will work against PGP=
.
Would you agree on that?





"Enzo Michelangeli" <[e-mail]> on 05.11.98 09:59:36

To:   Stefan Salzmann/HAM/Lotus@LOTUSINT
cc:
Subject:  Re: The URLs you gave me are fantastic, its exactly what I ne=
ed!!
      Thanks once again <eom>


=

--0__=YyVh35C0xiRx8kaEn5cHRMXi1p9aDHIFGgGcjppME5GSFiZd8BIJaMFW
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline


-----Original Message-----
From: Stefan_Salzmann/HAM/[e-mail]
<Stefan_Salzmann/HAM/[e-mail]>
To: [e-mail] <[e-mail]>
Date: Thursday, November 05, 1998 3:56 PM
Subject: The URLs you gave me are fantastic, its exactly what I need!!
Thanks once again <eom>

You are welcome, but remember that the S/MIME agents available on the market
_now_ (like Netscape Messenger and Outlook Express) are complied with the
v.2 only. I'm not sure about OpenPGP, but it is possible that the current
versions of PGP (6.0 has just arrived to market) ane not yet fully compliant
with the OpenPGP Internet drafts.

Cheers --

Enzo





--0__=YyVh35C0xiRx8kaEn5cHRMXi1p9aDHIFGgGcjppME5GSFiZd8BIJaMFW--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id PAA00473 for ietf-smime-bks; Wed, 4 Nov 1998 15:22:41 -0800 (PST)
Received: from speedy.rtfm.com ([208.217.207.133]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id PAA00469 for <[e-mail]>; Wed, 4 Nov 1998 15:22:39 -0800 (PST)
Received: from localhost (ekr@localhost) by speedy.rtfm.com (8.9.1/8.6.4) with SMTP id PAA27506 for <[e-mail]>; Wed, 4 Nov 1998 15:26:30 -0800 (PST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: New X9.42 draft
Date: Wed, 04 Nov 1998 15:26:30 -0800
From: Eric Rescorla <[e-mail]>
Sender: [e-mail]
Precedence: bulk

I've submitted an updated X9.42 draft that should incorporate most of
the comments I've received. I'm still missing a reference for the
Small Subgroup attack because I'm still looking for the original 
paper, but everything else should be ok.

-Ekr
[Eric Rescorla                                   [e-mail]]


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11557 for ietf-smime-bks; Wed, 4 Nov 1998 08:42:30 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11553 for <[e-mail]>; Wed, 4 Nov 1998 08:42:29 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id LAA09579 for <[e-mail]>; Wed, 4 Nov 1998 11:50:14 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA11361 for <[e-mail]>; Wed, 4 Nov 1998 11:43:22 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B2.005C9791 ; Wed, 4 Nov 1998 11:51:21 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 17:38:15 +0100
Subject: PGP 6.0 ... One more question
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

I have got one more question for the community. Does PGP Version 6.0 supports
the hierachical trust model? If yes are there any restrictions?

Thanks
Stefan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id IAA11459 for ietf-smime-bks; Wed, 4 Nov 1998 08:33:54 -0800 (PST)
Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id IAA11455 for <[e-mail]>; Wed, 4 Nov 1998 08:33:53 -0800 (PST)
From: Stefan_Salzmann/HAM/[e-mail]
Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.8.8/8.8.7) with ESMTP id LAA08355 for <[e-mail]>; Wed, 4 Nov 1998 11:39:29 -0500 (EST)
Received: from mta2.lotus.com (MTA2.lotus.com [9.95.5.6]) by internet2.lotus.com (8.8.8/8.8.7) with SMTP id LAA10184 for <[e-mail]>; Wed, 4 Nov 1998 11:32:40 -0500 (EST)
Received: by mta2.lotus.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 852566B2.005B9C50 ; Wed, 4 Nov 1998 11:40:37 -0500
X-Lotus-FromDomain: LOTUSINT@LOTUS@MTA
To: [e-mail]
Message-ID: <[e-mail]>
Date: Wed, 4 Nov 1998 17:20:16 +0100
Subject: Difference between SMIME and PGP
Mime-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by mail.proper.com id IAA11456
Sender: [e-mail]
Precedence: bulk

Hello out there,

I am struggling on the difference between SMIME and PGP. One of my customers
wants to make the decision between using SMIME and PGP. I have been talking
already with them but we got stuck in detailes.

Basically its quit clear. SMIME will be supported by all important industry
leaders such as Netscape, Microsoft, Novell etc. Further SMIME supports the
hierarchical trust model and PGP only supports the "web of trust" model. Now
with PGP Version 6.0, PGP will support also X.509 certificates. Those can also
be loaded into an PGP client than an SMIME Client can do it.
So where is the difference now? Is it just the fact that the industry decided to
go with SMIME or are there more differences (advantages for SMIME) when looking
more closely.
For instance using RSA public key encryption versus Deffie Helman public key
encryption. How about Digital Signature Standard (DSS)? I have red about DSS and
understand that DSS is the standard that provides the Digital Signature
Algorithm. Before applying it there has to be calculated an Digest using SHA. I
always thought that calculating the digest would be the signature already!! So
why using the DSA in addition? Will the digest be decrypted using the Deffie
Helman private key? Users that apply Deffie Helman exchange their public values
in order to derive an secret key that will be known at both party sides. Is that
secret key the private key used to encrypt message digests or is the private key
generated by the DSA algorithm?
In PGP further exist key rings that contain the public keys of other users? How
does that work with X.509 Certificates that actually contain the public key. If
there has to be a public key revoked, it happens in the key ring. Would it be
possible to export that revoked certificate. If not the revoked public key would
resist only lokally.
Are there any differences/advantages between RSA and Deffie Helman?

You see I am very confused right now and I have the feeling that all my security
theories woun´t match with those used in PGP.

I really would appreciate it if there would be someone helping my to remove all
that dust of my mind...

Thank you in advance
Stefan




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA01746 for ietf-smime-bks; Tue, 3 Nov 1998 13:15:15 -0800 (PST)
Received: from rbhub100.chamb.disa.mil (rbhub100.chamb.disa.mil [209.22.120.23]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA01742 for <[e-mail]>; Tue, 3 Nov 1998 13:15:14 -0800 (PST)
Received: by rbhub100.chamb.disa.mil with Internet Mail Service (5.5.2232.9) id <WCV166AV>; Tue, 3 Nov 1998 16:18:23 -0500
Message-ID: <[e-mail]>
From: "Flanigan, Bill" <[e-mail]>
To: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-cms-07.txt
Date: Tue, 3 Nov 1998 16:17:47 -0500 
Importance: low
X-Priority: 5
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk

I have another "minor" request.  The last sentence of the second paragraph
in Section 5.6 seems to be particularly convoluted--like nested eggs.  How
would this process REALLY work in determining if the signature is valid?
Perhaps some wordsmithing as well as breaking the sentence up into two might
help.  Any thoughts anyone? 

Bill

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
William F. Flanigan, Jr., Ph.D.       Voice:           [phone]
Defense Information Systems Agency      Fax:           [phone] 
Information Assurance Office (JED)      DSN:                      761      
5600 Columbia Pike, Room 632     Voice Mail:           [phone]   
Falls Church, VA 22041-2717        Internet:  <[e-mail]>
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% 

> -----Original Message-----
> From:	Paul Hoffman / IMC [SMTP:[e-mail]]
> Sent:	Tuesday, November 03, 1998 1:03 PM
> To:	[e-mail]
> Subject:	Re: WG Last Call:draft-ietf-smime-cms-07.txt
> 
> >One minor request, would it be possible to include a short example of
> data
> >wrapped up with each CMS content-type at the end of the draft (data,
> >encryptedData, etc)?  This would help solve some of the "we thought you
> were
> >supposed to interpret the text this way" problems which have come up, and
> >provide useful test vectors for implementors.
> 
> I would second this request, even if it delays the drafts a bit. From
> Jim's
> previous message, it is clear that the few people implementing right now
> are not 100% on track on this.
> 
> Russ, can you add these? Or, if anyone else can provide them quicker, that
> would be wonderful.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA00311 for ietf-smime-bks; Tue, 3 Nov 1998 10:08:59 -0800 (PST)
Received: from aum (ip200.proper.com [165.227.249.200]) by mail.proper.com (8.8.8/8.8.5) with SMTP id KAA00307 for <[e-mail]>; Tue, 3 Nov 1998 10:08:57 -0800 (PST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Nov 1998 10:03:12 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

>One minor request, would it be possible to include a short example of data
>wrapped up with each CMS content-type at the end of the draft (data,
>encryptedData, etc)?  This would help solve some of the "we thought you were
>supposed to interpret the text this way" problems which have come up, and
>provide useful test vectors for implementors.

I would second this request, even if it delays the drafts a bit. From Jim's
previous message, it is clear that the few people implementing right now
are not 100% on track on this.

Russ, can you add these? Or, if anyone else can provide them quicker, that
would be wonderful.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA00592 for ietf-smime-bks; Mon, 2 Nov 1998 20:00:22 -0800 (PST)
Received: from post.mail.demon.net (post-20.mail.demon.net [194.217.242.27]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA00588 for <[e-mail]>; Mon, 2 Nov 1998 20:00:21 -0800 (PST)
Received: from [193.237.150.98] (helo=drh-consultancy.demon.co.uk) by post.mail.demon.net with esmtp (Exim 2.05demon1 #1) id 0zaTNK-0001Bm-00; Mon, 2 Nov 1998 23:27:06 +0000
Message-ID: <[e-mail]>
Date: Mon, 02 Nov 1998 23:26:21 +0000
From: Dr Stephen Henson <[e-mail]>
Organization: Dr S N Henson
X-Mailer: Mozilla 4.06 [en] (Win95; U)
MIME-Version: 1.0
To: "Jim Schaad (Exchange)" <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
References: <2FBF98FC7852CF11912A0000000000010ECB5A12@DINO>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

Jim Schaad (Exchange) wrote:
> 
[Stuff suggesting one seriously annoyed Jim deleted]
> 
> I had completely missed the sentences that put restrictions on the message
> encryption algorithm if certain transport algorithms are used.  I THINK THIS
> IS WRONG!!!!!  If I had understood at the time that this was the proposal I
> would have been very vocal about this.  This was introduced post draft 3 of
> section 12 on the list.  I may have just missed it.
> 

Speaking personally I can live with things as suggested. However they
would make my life bloody difficult and I'd rather not have to.

> 
> Given this I STRONGLY suggest that we
> 1)  remove the offending sentences
> 2)  keep the fixed 128-bit keys size when creating the key wraping key
> 3)  fix the wraping algorithm by adding a known padding mechisim.  (Three
> alternatives: a) add a size byte, b) use the standard content encryption
> alg, c) use a modified PKCS#1 with a NULL byte followed by random pad)

I agree with all that and again speaking personally I'd go with b) for
the following reasons.

Certain libraries have the separate algorithms corresponding to "raw"
and "padded" versions: for example in PKCS#11 we have CKM_RC2_CBC and
CKM_RC2_CBC_PAD (this uses padding compatible with standard content
encryption padding described in CMS 6.3).

As things stand there would be two seprate versions, RC2 as used for
content encryption (with padding) and RC2 as used in key wrap (no
padding). If we take option b) then we consistently end up with the same
padding used for both wrapping and content encryption. As a nice side
effect this also allows the key length to be determined unambiguously.
If adding pseudo-random bytes is still considered necessary then adding
a fixed number (e.g. one block length) still allows the key length to be
determined.

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00397 for ietf-smime-bks; Mon, 2 Nov 1998 19:35:27 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00393 for <[e-mail]>; Mon, 2 Nov 1998 19:35:26 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <VPFJRG7L>; Mon, 2 Nov 1998 17:50:29 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A21@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: More Comments on smime-cms-07
Date: Mon, 2 Nov 1998 17:50:32 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

It has been pointed out to me that the parameter encoding for
id-alg-ESDHwith3DES and id-alg-ESDHwithRC2 is not consistant with the
consensus that I remember from the August IETF meeting.  At that point the
preference I remember was for encoding parameters as NULL rather than as
absent.  Since I don't see any place where these items are used with
parameters I think this change to encoding as NULL should be done.

That being said, I think that given the previous message that I sent out
id-alg-ESDHwithRC2 needs to have a parameter, the same one as
RC2wrapParameter (i.e. the actual RC2 key size).  This is needed so that the
correct decryption can be done on the key encryption key immeadiately
without having to wait for the MEK parameters to show up.

jim schaad



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id TAA00391 for ietf-smime-bks; Mon, 2 Nov 1998 19:34:51 -0800 (PST)
Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id TAA00387 for <[e-mail]>; Mon, 2 Nov 1998 19:34:49 -0800 (PST)
Received: from cs26.cs.auckland.ac.nz ([e-mail] [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id PAA17161; Tue, 3 Nov 1998 15:25:02 +1300 (NZDT) (sender [e-mail])
Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <91005990112610>; Tue, 3 Nov 1998 15:25:01 (NZDT)
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: WG Last Call:draft-ietf-smime-cms-07.txt
Reply-To: [e-mail]
X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz
Date: Tue, 3 Nov 1998 15:25:01 (NZDT)
Message-ID: <[e-mail]>
Sender: [e-mail]
Precedence: bulk

>CMS is now read for Working Group Last Call.  The X9.42 draft is not complete,
>but it should be posted near the end of the week.  Last Call will close two
>weeks after the X9.42 draft is posted.
 
One minor request, would it be possible to include a short example of data
wrapped up with each CMS content-type at the end of the draft (data,
encryptedData, etc)?  This would help solve some of the "we thought you were
supposed to interpret the text this way" problems which have come up, and
provide useful test vectors for implementors.
 
Peter.
 



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA07696 for ietf-smime-bks; Mon, 2 Nov 1998 12:36:59 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA07692 for <[e-mail]>; Mon, 2 Nov 1998 12:36:58 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <VPFJRCLZ>; Mon, 2 Nov 1998 12:39:34 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A12@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: [e-mail]
Subject: RE: WG Last Call:draft-ietf-smime-cms-07.txt
Date: Mon, 2 Nov 1998 12:39:31 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

I was in the middle of writing a long message to Steve that he did not
understand how things were working when I found out that I was the one
laboring under a mis-impression of how things worked and he was infact
write.  And I'm pissed about this.

I had completely missed the sentences that put restrictions on the message
encryption algorithm if certain transport algorithms are used.  I THINK THIS
IS WRONG!!!!!  If I had understood at the time that this was the proposal I
would have been very vocal about this.  This was introduced post draft 3 of
section 12 on the list.  I may have just missed it.

I do not understand or want any ties between the key transport and the
message encryption unless they are absolutely necessary.  This makes my
message list agent process more difficult.  In the past all it needed to do
was the re-write the receipient infos and it was done.  (Except for the
possible problems of high/low encryption issues.)  Now it will almost
certianly need to decrypt and re-encrypt the message for anybody using RC2.
There is not a single existing S/MIME client which uses RC2 in the way
described in CMS.  The two different ways I know are to either generate the
same number of key bits as key size (Microsoft and Netscape) or to generate
a fixed number of key bits at 196 (WorldTalk).  Neither of these messages
can be forwarded intact if any D-H key transport is to be done.

Given this I STRONGLY suggest that we
1)  remove the offending sentences
2)  keep the fixed 128-bit keys size when creating the key wraping key
3)  fix the wraping algorithm by adding a known padding mechisim.  (Three
alternatives: a) add a size byte, b) use the standard content encryption
alg, c) use a modified PKCS#1 with a NULL byte followed by random pad)

jim schaad


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA02215 for ietf-smime-bks; Mon, 2 Nov 1998 02:57:36 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA02211 for <[e-mail]>; Mon, 2 Nov 1998 02:57:35 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.05demon1 #1) id 0zaHiM-00058i-00; Mon, 2 Nov 1998 11:00:04 +0000
Message-ID: <002c01be0692$d6923310$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "Russ Housley" <[e-mail]>
Cc: "MIME MIAL LIST" <[e-mail]>
Subject: CMS -EnvelopedData extensibility
Date: Mon, 2 Nov 1998 10:58:53 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0029_01BE064F.C7F640A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0029_01BE064F.C7F640A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Russ,


CMS-EnvelopedData is currently not easy to extend to carry additional =
information or attributes.  Is that intentional?
=20
Generally, it is a good idea to include a way of extending protocols =
when defining standards. Including a protocol extension mechanism =
facilitates easy migration to meeting new requirements.=20
=20
In  particular,  in the case of EnvelopedData future extensions may be =
required to support additional Algorithms.
=20
The first Question I have to you and the Mail list is:
=20
1) Is there support for providing an extensibility mechanism in =
EnvelopedData? YES or NO.
=20
If there is support, then  the second question is=20
2 ) Should a similar scheme to SignedData unsigned attributes could be =
used? YES or NO.
=20
The extension mechanism could be per EnvelopedData (i.e per message).
=20
 The following is an example ASN.1:
=20
 EnvelopedData ::=3D SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo=20
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
=20
The extension mechanism could also be per recipient using the key =
transport recipient information and key agreement recipient info.

The following is an example ASN.1:=20
=20
KeyTransRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey=20
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


  KeyAgreeRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys=20
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }


------=_NextPart_000_0029_01BE064F.C7F640A0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN"><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>Russ,</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>CMS-EnvelopedData is currently not easy to extend to =
carry=20
additional information or attributes.&nbsp; Is that =
intentional?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#000000>Generally</FONT>, it is a good =
idea to=20
include a way of extending protocols when defining standards. =
I</FONT><FONT=20
size=3D2>ncluding a protocol extension mechanism facilitates easy =
migration to=20
meeting new requirements. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In&nbsp; particular,&nbsp; in the case of =
EnvelopedData future=20
extensions may be required to support additional =
Algorithms.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The first Question I have to you and the Mail list=20
is:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1) Is there support for providing an extensibility =
mechanism=20
in EnvelopedData? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If there is support,</FONT><FONT size=3D2> =
then&nbsp; the second=20
question is </FONT></DIV>
<DIV><FONT size=3D2>2 ) Should a similar scheme to SignedData unsigned =
attributes=20
could be used? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could be per EnvelopedData =
(i.e per=20
message).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;The following is an example =
ASN.1:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>&nbsp;EnvelopedData ::=3D=20
SEQUENCE {<BR>&nbsp;&nbsp;&nbsp;&nbsp; version=20
CMSVersion,<BR>&nbsp;&nbsp;&nbsp;&nbsp; originatorInfo [0] IMPLICIT=20
OriginatorInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; recipientInfos=20
RecipientInfos,<BR>&nbsp;&nbsp;&nbsp;&nbsp; encryptedContentInfo=20
EncryptedContentInfo </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
unsignedAttrs [1]=20
IMPLICIT UnsignedAttributes OPTIONAL }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could also be per recipient =
using the=20
key transport recipient information and key agreement recipient=20
info.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>The following =
is an example=20
ASN.1:</FONT>=20
<DIV><FONT size=3D2>&nbsp;</FONT></DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyTransRecipientInfo ::=3D SEQUENCE =

{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =
0 or=20
2<BR>&nbsp;&nbsp;&nbsp;&nbsp; rid=20
RecipientIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
encryptedKey=20
EncryptedKey </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [1] IMPLICIT =
UnsignedAttributes=20
OPTIONAL }</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp; KeyAgreeRecipientInfo ::=3D SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =

3<BR>&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT=20
OriginatorIdentifierOrKey,<BR>&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT=20
UserKeyingMaterial OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
recipientEncryptedKeys RecipientEncryptedKeys </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT=20
UnsignedAttributes OPTIONAL }<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0029_01BE064F.C7F640A0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA02203 for ietf-smime-bks; Mon, 2 Nov 1998 02:55:30 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA02198 for <[e-mail]>; Mon, 2 Nov 1998 02:55:29 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.05demon1 #1) id 0zaHgQ-0004ol-00 for [e-mail]; Mon, 2 Nov 1998 10:58:03 +0000
Message-ID: <001e01be0692$8f0390c0$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "MIME MIAL LIST" <[e-mail]>
Subject: CMS -EnvelopedData extensibility
Date: Mon, 2 Nov 1998 10:56:50 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01BE064F.7EAC80D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_001A_01BE064F.7EAC80D0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

CMS-EnvelopedData is currently not easy to extend to carry additional =
information or attributes.  Is that intentional?
=20
Generally, it is a good idea to include a way of extending protocols =
when defining standards. Including a protocol extension mechanism =
facilitates easy migration to meeting new requirements.=20
=20
In  particular,  in the case of EnvelopedData future extensions may be =
required to support additional Algorithms.
=20
The first Question I have to the Mail list is:
=20
1) Is there support for providing an extensibility mechanism in =
EnvelopedData? YES or NO.
=20
If there is support, then  the second question is=20
2 ) Should a similar scheme to SignedData unsigned attributes could be =
used? YES or NO.
=20
The extension mechanism could be per EnvelopedData (i.e per message).
=20
 The following is an example ASN.1:
=20
 EnvelopedData ::=3D SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo=20
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
=20
The extension mechanism could also be per recipient using the key =
transport recipient information and key agreement recipient info.

The following is an example ASN.1:=20
=20
KeyTransRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey=20
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


  KeyAgreeRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys=20
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }


------=_NextPart_000_001A_01BE064F.7EAC80D0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>CMS-EnvelopedData is currently not easy to extend to =
carry=20
additional information or attributes.&nbsp; Is that =
intentional?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#000000>Generally</FONT>, it is a good =
idea to=20
include a way of extending protocols when defining standards. =
I</FONT><FONT=20
size=3D2>ncluding a protocol extension mechanism facilitates easy =
migration to=20
meeting new requirements. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In&nbsp; particular,&nbsp; in the case of =
EnvelopedData future=20
extensions may be required to support additional =
Algorithms.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The first Question I have to the Mail list =
is:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1) Is there support for providing an extensibility =
mechanism=20
in EnvelopedData? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If there is support,</FONT><FONT size=3D2> =
then&nbsp; the second=20
question is </FONT></DIV>
<DIV><FONT size=3D2>2 ) Should a similar scheme to SignedData unsigned =
attributes=20
could be used? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could be per EnvelopedData =
(i.e per=20
message).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;The following is an example =
ASN.1:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>&nbsp;EnvelopedData ::=3D=20
SEQUENCE {<BR>&nbsp;&nbsp;&nbsp;&nbsp; version=20
CMSVersion,<BR>&nbsp;&nbsp;&nbsp;&nbsp; originatorInfo [0] IMPLICIT=20
OriginatorInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; recipientInfos=20
RecipientInfos,<BR>&nbsp;&nbsp;&nbsp;&nbsp; encryptedContentInfo=20
EncryptedContentInfo </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
unsignedAttrs [1]=20
IMPLICIT UnsignedAttributes OPTIONAL }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could also be per recipient =
using the=20
key transport recipient information and key agreement recipient=20
info.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>The following =
is an example=20
ASN.1:</FONT>=20
<DIV><FONT size=3D2>&nbsp;</FONT></DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyTransRecipientInfo ::=3D SEQUENCE =

{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =
0 or=20
2<BR>&nbsp;&nbsp;&nbsp;&nbsp; rid=20
RecipientIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
encryptedKey=20
EncryptedKey </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [1] IMPLICIT =
UnsignedAttributes=20
OPTIONAL }</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp; KeyAgreeRecipientInfo ::=3D SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =

3<BR>&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT=20
OriginatorIdentifierOrKey,<BR>&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT=20
UserKeyingMaterial OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
recipientEncryptedKeys RecipientEncryptedKeys </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT=20
UnsignedAttributes OPTIONAL }<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_001A_01BE064F.7EAC80D0--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA02196 for ietf-smime-bks; Mon, 2 Nov 1998 02:55:28 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA02192 for <[e-mail]>; Mon, 2 Nov 1998 02:55:27 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.05demon1 #1) id 0zaHgP-0004ol-00 for [e-mail]; Mon, 2 Nov 1998 10:58:01 +0000
Message-ID: <001d01be0692$8e3b5ec0$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "MIME MIAL LIST" <[e-mail]>
Subject: CMS -EnvelopedData extensibility
Date: Mon, 2 Nov 1998 10:56:11 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01BE064F.6761FA90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_000C_01BE064F.6761FA90
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

CMS-EnvelopedData is currently not easy to extend to carry additional =
information or attributes.  Is that intentional?
=20
Generally, it is a good idea to include a way of extending protocols =
when defining standards. Including a protocol extension mechanism =
facilitates easy migration to meeting new requirements.=20
=20
In  particular,  in the case of EnvelopedData future extensions may be =
required to support additional Algorithms.
=20
The first Question I have to the Mail list is:
=20
1) Is there support for providing an extensibility mechanism in =
EnvelopedData? YES or NO.
=20
If there is support, then  the second question is=20
2 ) Should a similar scheme to SignedData unsigned attributes could be =
used? YES or NO.
=20
The extension mechanism could be per EnvelopedData (i.e per message).
=20
 The following is an example ASN.1:
=20
 EnvelopedData ::=3D SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo=20
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }
=20
The extension mechanism could also be per recipient using the key =
transport recipient information and key agreement recipient info.

The following is an example ASN.1:=20
=20
KeyTransRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey=20
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


  KeyAgreeRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys=20
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }


------=_NextPart_000_000C_01BE064F.6761FA90
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type><!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 =
HTML//EN">
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>CMS-EnvelopedData is currently not easy to extend to =
carry=20
additional information or attributes.&nbsp; Is that =
intentional?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#000000>Generally</FONT>, it is a good =
idea to=20
include a way of extending protocols when defining standards. =
I</FONT><FONT=20
size=3D2>ncluding a protocol extension mechanism facilitates easy =
migration to=20
meeting new requirements. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In&nbsp; particular,&nbsp; in the case of =
EnvelopedData future=20
extensions may be required to support additional =
Algorithms.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The first Question I have to the Mail list =
is:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1) Is there support for providing an extensibility =
mechanism=20
in EnvelopedData? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If there is support,</FONT><FONT size=3D2> =
then&nbsp; the second=20
question is </FONT></DIV>
<DIV><FONT size=3D2>2 ) Should a similar scheme to SignedData unsigned =
attributes=20
could be used? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could be per EnvelopedData =
(i.e per=20
message).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;The following is an example =
ASN.1:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>&nbsp;EnvelopedData ::=3D=20
SEQUENCE {<BR>&nbsp;&nbsp;&nbsp;&nbsp; version=20
CMSVersion,<BR>&nbsp;&nbsp;&nbsp;&nbsp; originatorInfo [0] IMPLICIT=20
OriginatorInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; recipientInfos=20
RecipientInfos,<BR>&nbsp;&nbsp;&nbsp;&nbsp; encryptedContentInfo=20
EncryptedContentInfo </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
unsignedAttrs [1]=20
IMPLICIT UnsignedAttributes OPTIONAL }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could also be per recipient =
using the=20
key transport recipient information and key agreement recipient=20
info.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>The following =
is an example=20
ASN.1:</FONT>=20
<DIV><FONT size=3D2>&nbsp;</FONT></DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyTransRecipientInfo ::=3D SEQUENCE =

{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =
0 or=20
2<BR>&nbsp;&nbsp;&nbsp;&nbsp; rid=20
RecipientIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
encryptedKey=20
EncryptedKey </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [1] IMPLICIT =
UnsignedAttributes=20
OPTIONAL }</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp; KeyAgreeRecipientInfo ::=3D SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =

3<BR>&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT=20
OriginatorIdentifierOrKey,<BR>&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT=20
UserKeyingMaterial OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
recipientEncryptedKeys RecipientEncryptedKeys </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT=20
UnsignedAttributes OPTIONAL }<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_000C_01BE064F.6761FA90--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id CAA02187 for ietf-smime-bks; Mon, 2 Nov 1998 02:54:54 -0800 (PST)
Received: from post.mail.demon.net (post-12.mail.demon.net [194.217.242.41]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id CAA02183 for <[e-mail]>; Mon, 2 Nov 1998 02:54:52 -0800 (PST)
Received: from [194.222.225.69] (helo=jrwork) by post.mail.demon.net with smtp (Exim 2.05demon1 #1) id 0zaHfh-0004hv-00 for [e-mail]; Mon, 2 Nov 1998 10:57:17 +0000
Message-ID: <000801be0692$74229d50$0400000a@jrwork>
From: "John Ross" <[e-mail]>
To: "MIME MIAL LIST" <[e-mail]>
Subject: CMS -EnvelopedData extensibility
Date: Mon, 2 Nov 1998 10:55:33 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01BE064F.50824410"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.2120.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
Sender: [e-mail]
Precedence: bulk

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01BE064F.50824410
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

CMS-EnvelopedData is currently not easy to extend to carry additional =
information or attributes.  Is that intentional?

Generally, it is a good idea to include a way of extending protocols =
when defining standards. Including a protocol extension mechanism =
facilitates easy migration to meeting new requirements.=20

In  particular,  in the case of EnvelopedData future extensions may be =
required to support additional Algorithms.

The first Question I have to the Mail list is:

1) Is there support for providing an extensibility mechanism in =
EnvelopedData? YES or NO.

If there is support, then  the second question is=20
2 ) Should a similar scheme to SignedData unsigned attributes could be =
used? YES or NO.

The extension mechanism could be per EnvelopedData (i.e per message).

 The following is an example ASN.1:
=20
 EnvelopedData ::=3D SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     encryptedContentInfo EncryptedContentInfo=20
     unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

The extension mechanism could also be per recipient using the key =
transport recipient information and key agreement recipient info.

The following is an example ASN.1:
=20
KeyTransRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 0 or 2
     rid RecipientIdentifier,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     encryptedKey EncryptedKey=20
      unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }


  KeyAgreeRecipientInfo ::=3D SEQUENCE {
     version CMSVersion,  -- always set to 3
     originator [0] EXPLICIT OriginatorIdentifierOrKey,
     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
     keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
     recipientEncryptedKeys RecipientEncryptedKeys=20
     unsignedAttrs [2] IMPLICIT UnsignedAttributes OPTIONAL }


------=_NextPart_000_0013_01BE064F.50824410
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.2106.6"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>CMS-EnvelopedData is currently not easy to extend to =
carry=20
additional information or attributes.&nbsp; Is that =
intentional?</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2><FONT color=3D#000000>Generally</FONT>, it is a good =
idea to=20
include a way of extending protocols when defining standards. =
I</FONT><FONT=20
size=3D2>ncluding a protocol extension mechanism facilitates easy =
migration to=20
meeting new requirements. </FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>In&nbsp; particular,&nbsp; in the case of =
EnvelopedData future=20
extensions may be required to support additional =
Algorithms.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The first Question I have to the Mail list =
is:</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>1) Is there support for providing an extensibility =
mechanism=20
in EnvelopedData? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>If there is support,</FONT><FONT size=3D2> =
then&nbsp; the second=20
question is </FONT></DIV>
<DIV><FONT size=3D2>2 ) Should a similar scheme to SignedData unsigned =
attributes=20
could be used? YES or NO.</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could be per EnvelopedData =
(i.e per=20
message).</FONT></DIV>
<DIV><FONT size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp;The following is an example =
ASN.1:</FONT></DIV>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 =
size=3D2>&nbsp;EnvelopedData ::=3D=20
SEQUENCE {<BR>&nbsp;&nbsp;&nbsp;&nbsp; version=20
CMSVersion,<BR>&nbsp;&nbsp;&nbsp;&nbsp; originatorInfo [0] IMPLICIT=20
OriginatorInfo OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; recipientInfos=20
RecipientInfos,<BR>&nbsp;&nbsp;&nbsp;&nbsp; encryptedContentInfo=20
EncryptedContentInfo </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
unsignedAttrs [1]=20
IMPLICIT UnsignedAttributes OPTIONAL }</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>The extension mechanism could also be per recipient =
using the=20
key transport recipient information and key agreement recipient=20
info.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>The following =
is an example=20
ASN.1:</FONT>
<DIV><FONT size=3D2>&nbsp;</FONT></DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>KeyTransRecipientInfo ::=3D SEQUENCE =

{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =
0 or=20
2<BR>&nbsp;&nbsp;&nbsp;&nbsp; rid=20
RecipientIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
encryptedKey=20
EncryptedKey </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;<FONT color=3D#000000=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [1] IMPLICIT =
UnsignedAttributes=20
OPTIONAL }</FONT></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>&nbsp; KeyAgreeRecipientInfo ::=3D SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp; version CMSVersion,&nbsp; -- always set to =

3<BR>&nbsp;&nbsp;&nbsp;&nbsp; originator [0] EXPLICIT=20
OriginatorIdentifierOrKey,<BR>&nbsp;&nbsp;&nbsp;&nbsp; ukm [1] EXPLICIT=20
UserKeyingMaterial OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
keyEncryptionAlgorithm=20
KeyEncryptionAlgorithmIdentifier,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
recipientEncryptedKeys RecipientEncryptedKeys </FONT></DIV>
<DIV><FONT size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; unsignedAttrs [2] IMPLICIT=20
UnsignedAttributes OPTIONAL }<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0013_01BE064F.50824410--



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id XAA26699 for ietf-smime-bks; Sun, 1 Nov 1998 23:34:38 -0800 (PST)
Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id XAA26695 for <[e-mail]>; Sun, 1 Nov 1998 23:34:37 -0800 (PST)
Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <VPFJQ8V1>; Sun, 1 Nov 1998 23:37:12 -0800
Message-ID: <2FBF98FC7852CF11912A0000000000010ECB5A0F@DINO>
From: "Jim Schaad (Exchange)" <[e-mail]>
To: "Ietf-Smime (E-mail)" <[e-mail]>
Subject: Comments on smime-cms-07
Date: Sun, 1 Nov 1998 23:36:54 -0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2232.9)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk

1.  the usage of the phrase "protection content type" is inconsistant
between section 2 (general overview) and section 3 (General syntax).  For
one it is the same as the data content type for the other it is an OID.  No
suggested text since I was not clear on which one you really meant it to be.

2.  Section 6.2.2 the paragraph on recipientEncryptedKeys:  Change to
"includes a receipient identifier and encrypted key for one or  more
recipients."

3.  Section 9 - Authenticated-data Content Type:  I think I have identified
what I consider to be a security weakness.  Specifically if you create an
authenticated data object with authenticated attributes, I can remove the
authenticated attributes and come up with a stil legal authenticated data
object.  To fix this I propose that we change authenticated data in the
following ways:
  a)  In AuthencatedData macAlgorithm be changed to hashAlgorithm.
  b) autenticatedAttributes becomes a REQUIRED field (remove the OPTIONAL)
  c) a digest-value becomes a required attribute in the
autenticatedAttributes (replacing mac-value)
  d) in processing, you hash the encapContentInfo, put the has in the
authenticated attributes and MAC this value.

4.  Section 9.2 paragraph 4:  I don't understand why this paragraph exists.
It does not appear to have an analogus paragraph in the signature message
digest paragraphs.  I think this paragraph should be struck.

5.  Section 12.5.2.  DES MAC should be struck and replace with 3DES MAC.

6.  ASN Module changes:
 - ContentType is defined twice


Jim Schaad