Re: AES and PKCS #1 v1.5 Issue

["Blake Ramsdell" <[e-mail]>]

----- Original Message ----- 
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>; "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 30, 2002 7:49 PM
Subject: RE: AES and PKCS #1 v1.5 Issue


> 4. [Blake] Specification purity says that key management and content
> encryption documents should not restrict each other.
> - Blake - I just completely disagree on this issue.  I think that each
> type of algorithm can put restrictions and updates on usage for the
> other type.  I believe that it is perfectly reasonable for a content
> encryption algorithm to impose limitations on what key management
> algorithms are allowed.  It could also modify the algorithms as
> necessary (for example the original drafts change the key derivation
> algorithm used with AES and D-H).  I can get behind the purity of one
> algorithm-one document, but not that they cannot put restrictions on
> each other.

I did not say that an algorithm profile could not put a restriction its use with another algorithm.  I said that if the reason for the restriction is not specific to the algorithm (in this case, the problems with PKCS #1 v1.5 are not specific to its use with AES), then it doesn't make sense to single it out in the algorithm profile.

Once again, the problem is not specific to the exact combination of AES and PKCS #1 v1.5, and so we are not doing the right thing if we have not covered it adequately in either the CMS or MSG specification.  If we're going to preclude the use of PKCS #1 v1.5, we should do it completely or not at all.  It is unreasonable, redundant and wasteful to mandate that all future symmetric algorithm profiles include information about just how bad PKCS #1 v1.5 is, when we can just provide guidance for the use / nonuse of PKCS #1 v1.5 in CMS or MSG or some other general specification.

The point is not that AES should not use PKCS #1 v1.5, the point is that if AES should not use PKCS #1 v1.5, then no future symmetric algorithm should use PKCS #1 v1.5.  Existing algorithms can be grandfathered, and we progress using new guidelines for key wrapping.  For each draft author to take their own individual stand on this issue and put their own take on this into their draft doesn't seem productive.

In my mind, we are in one of two states at this point:

1. CMS and MSG are completely reasonable in their treatment of PKCS #1 v1.5, and no language with respect to this is required in the AES draft.  If this is the case, I recommend that we remove the PKCS #1 v1.5 specific language from the AES draft.

2. CMS and MSG are incomplete in their treatment of PKCS #1 v1.5, and the language in the AES specification is attempting to remedy this.  If this is the case, I recommend that we remove the PKCS #1 v1.5 specific language from the AES draft, and clarify the language accordingly in CMS and MSG.

Blake




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6V8hso02174 for ietf-smime-bks; Wed, 31 Jul 2002 01:43:54 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6V8hrw02167 for <[e-mail]>; Wed, 31 Jul 2002 01:43:53 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Wed, 31 Jul 2002 01:43:47 -0700
Message-ID: <006001c2386d$682856a0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
References: <000301c2383c$e5d61140$[e-mail]>
Subject: Re: AES and PKCS #1 v1.5 Issue
Date: Wed, 31 Jul 2002 01:36:46 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g6V8hrw02169
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>; "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, July 30, 2002 7:49 PM
Subject: RE: AES and PKCS #1 v1.5 Issue


> 4. [Blake] Specification purity says that key management and content
> encryption documents should not restrict each other.
> - Blake - I just completely disagree on this issue.  I think that each
> type of algorithm can put restrictions and updates on usage for the
> other type.  I believe that it is perfectly reasonable for a content
> encryption algorithm to impose limitations on what key management
> algorithms are allowed.  It could also modify the algorithms as
> necessary (for example the original drafts change the key derivation
> algorithm used with AES and D-H).  I can get behind the purity of one
> algorithm-one document, but not that they cannot put restrictions on
> each other.

I did not say that an algorithm profile could not put a restriction its use with another algorithm.  I said that if the reason for the restriction is not specific to the algorithm (in this case, the problems with PKCS #1 v1.5 are not specific to its use with AES), then it doesn't make sense to single it out in the algorithm profile.

Once again, the problem is not specific to the exact combination of AES and PKCS #1 v1.5, and so we are not doing the right thing if we have not covered it adequately in either the CMS or MSG specification.  If we're going to preclude the use of PKCS #1 v1.5, we should do it completely or not at all.  It is unreasonable, redundant and wasteful to mandate that all future symmetric algorithm profiles include information about just how bad PKCS #1 v1.5 is, when we can just provide guidance for the use / nonuse of PKCS #1 v1.5 in CMS or MSG or some other general specification.

The point is not that AES should not use PKCS #1 v1.5, the point is that if AES should not use PKCS #1 v1.5, then no future symmetric algorithm should use PKCS #1 v1.5.  Existing algorithms can be grandfathered, and we progress using new guidelines for key wrapping.  For each draft author to take their own individual stand on this issue and put their own take on this into their draft doesn't seem productive.

In my mind, we are in one of two states at this point:

1. CMS and MSG are completely reasonable in their treatment of PKCS #1 v1.5, and no language with respect to this is required in the AES draft.  If this is the case, I recommend that we remove the PKCS #1 v1.5 specific language from the AES draft.

2. CMS and MSG are incomplete in their treatment of PKCS #1 v1.5, and the language in the AES specification is attempting to remedy this.  If this is the case, I recommend that we remove the PKCS #1 v1.5 specific language from the AES draft, and clarify the language accordingly in CMS and MSG.

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g6V2oeR28722 for ietf-smime-bks; Tue, 30 Jul 2002 19:50:40 -0700 (PDT)
Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6V2ocw28714 for <[e-mail]>; Tue, 30 Jul 2002 19:50:38 -0700 (PDT)
Received: from revelation ([12.230.156.246]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020731025037.PSST22139.rwcrmhc52.attbi.com@revelation>; Wed, 31 Jul 2002 02:50:37 +0000
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: AES and PKCS #1 v1.5 Issue
Date: Tue, 30 Jul 2002 19:49:31 -0700
Message-ID: <000301c2383c$e5d61140$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
In-Reply-To: <045601c22d69$65be46e0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake & Peter,

Sorry for not getting back on this issue sooner, but I had other fish
that needed to be fried.

In this message I am attempting to summarize you arguments and put in my
responses.


1. [Peter] Everybody has already implemented this.
- Three responses to this point:  
   1. I don't actually believe that this is true.  While there are quite
likely several different individuals who have implement this (you and
Getronics be examples) I don't think the "major" e-mail vendors have yet
rolled this out for general usage.  This is not yet an option in my
version of Microsoft Outlook anyway.
   2. It does not really matter if people pre-implement the documents we
are writing.  The introductory paragraphs say that we reserve the right
to mess with you head if you implement a draft document.
   3. I don't believe the current absence of hardware for doing OAEP
will last very long if it is adopted in a standardized way.  (I think
that PSS will be coming very soon as well.)

2. [Peter] It does not matter what we say, people are going to use
PKCS#1 v1.5 anyway.
- People do a lot of stupid things a great deal of the time (myself
included).  I don't believe this is a reason for us to "bless" things
that we think could be done in a better way at very little cost.

3. [Peter, Blake & Dean] The Bleichenbacher attack is not a problem for
S/MIME.
- First, CMS is not S/MIME.   I agree that this is not a huge issue for
an S/MIME implementation, however should this be an issue that needs to
be covered in every single protocol that uses AES (i.e. should CMC have
this as a huge concern).  There are going to be interactive protocols
that use CMS, if we can nip this attack in the bud for all of those
protocols, I consider this effort well spent.

4. [Blake] Specification purity says that key management and content
encryption documents should not restrict each other.
- Blake - I just completely disagree on this issue.  I think that each
type of algorithm can put restrictions and updates on usage for the
other type.  I believe that it is perfectly reasonable for a content
encryption algorithm to impose limitations on what key management
algorithms are allowed.  It could also modify the algorithms as
necessary (for example the original drafts change the key derivation
algorithm used with AES and D-H).  I can get behind the purity of one
algorithm-one document, but not that they cannot put restrictions on
each other.


Jim




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6T3x6u02922 for ietf-smime-bks; Sun, 28 Jul 2002 20:59:06 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6T3x4w02918 for <[e-mail]>; Sun, 28 Jul 2002 20:59:04 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6T3x3q9030544; Mon, 29 Jul 2002 15:59:03 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA75492; Mon, 29 Jul 2002 15:59:03 +1200 (NZST) (sender [e-mail])
Date: Mon, 29 Jul 2002 15:59:03 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: digested-data, surreptitious forwarding, D-H
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin <[e-mail]> writes:

>If the encrypted digest is attached as an unprotected attribute, it could be
>removed by an adversary, presumably?  In which case, since the recipient would
>have to know how to handle CMS messages either with or without the encrypted
>digest for backwards compatibility, the recipient wouldn't notice anything
>amiss.  So maybe that's an argument for the digest to be inside the
>envelopedData encryption, not as a separate thing.

You can't prevent a rollback attack, since you need to integrity-protect the
fact that integrity-protection is being used, which is a catch-22.  The fix
would be something like what was done in SSLv3 which messes with the RSA-
wrapped key data to include the version, but this is incredibly ugly for CMS
which can't assume PKCS #1 RSA padding.  I was just assuming that the MDC would
be by prior arrangement, and the recipient would reject any messages without
the MDC - for the EDI application, this is the standard way to handle message
exchange.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g6T3tF502876 for ietf-smime-bks; Sun, 28 Jul 2002 20:55:15 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6T3tCw02869 for <[e-mail]>; Sun, 28 Jul 2002 20:55:13 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6T3tBq9030424; Mon, 29 Jul 2002 15:55:11 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA75460; Mon, 29 Jul 2002 15:55:10 +1200 (NZST) (sender [e-mail])
Date: Mon, 29 Jul 2002 15:55:10 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: digested-data, surreptitious forwarding, D-H
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin <[e-mail]> writes:

>Interesting, I'd assumed that you could do multiple layers (like a
>digestedData and envelopedData, or signedData and envelopedData) in a single
>pass, by hashing and then encrypting each content block, then moving to the
>next one, etc..  You're saying that this isn't possible, 

It isn't, because of ASN.1 encoding restrictions.  Changing a single byte of
inner content can change several bytes of outer content due to variable-length
length-of-length encoding, and there are some data lengths which can never be
achieved, eg. when you move from a short-encoded data length to a long-encoded
one and adding a single byte to the data also increases the length-of-length
value.  When you combine this with data blocking requirements and requirements
for PKCS #5 padding, it becomes unworkably complex to implement and test unless
you buffer an entire message, in which case you're just doing a standard two-
pass encoding.

>but the scheme below can be done in one pass?

Sure, since the encoding is one-step.  With DigestedData you're encapsulating
the entire data block just to add a 20-byte hash at the end.  All this does
it add the hash at the end of the EncryptedData.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SMwla25718 for ietf-smime-bks; Sun, 28 Jul 2002 15:58:47 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SMwiw25714 for <[e-mail]>; Sun, 28 Jul 2002 15:58:44 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g6SMwb3E012073; Sun, 28 Jul 2002 15:58:37 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <PZRDQ6CQ>; Sun, 28 Jul 2002 15:59:26 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: digested-data, surreptitious forwarding, D-H
Date: Sun, 28 Jul 2002 15:59:24 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If the encrypted digest is attached as an unprotected attribute, it could be
removed by an adversary, presumably?  In which case, since the recipient
would have to know how to handle CMS messages either with or without the
encrypted digest for backwards compatibility, the recipient wouldn't notice
anything amiss.  So maybe that's an argument for the digest to be inside the
envelopedData encryption, not as a separate thing.
  

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, July 27, 2002 11:20 PM
To: [e-mail]; [e-mail]
Subject: Re: digested-data, surreptitious forwarding, D-H


Trevor Perrin <[e-mail]> writes:

>1) I'm surprised S/MIME doesn't use CMSs' digested-data with
enveloped-data.
>In the case of encrypted but not signed mails, doesn't this leave the
message
>vulnerable to things like cut-and-paste attacks (where an attacker reorders
>ciphertext blocks, so upon decrypting the recipient sees reordered
plaintext)?

Funny you should mention that, I was discussing this recently with someone
who
was quite concerned about this (they were FTP'ing large encrypted EDI
messages
around).  What they wanted was a modification to EncryptedData to include a
hash inside the encrypted content, rather than DigestedData, which would
require a second pass (they encrypt the content as they stream it in and
out,
so anything requiring two passes is a non-starter).  I have the feeling that
more people would be asking for this if they had any idea that encryption
doesn't guarantee integrity protection.

My suggestion was to put it in as an unprotectedAttrs, just encrypting the
MDC
after the content.  In other words, hash the data before you encrypt it,
then
after you've finished encrypting the data encrypt the hash and store it as
an
unprotectedAttrs.  This is a bog-standard way of appending an MDC to the
data,
and is compatible with the existing format.  The MDC info is put in as
originatorInfo, which is a bit of a kludge but seems to be the sensible
place
for it.  This would need a new originatorInfo type, but that's the only
change
necessary.

If there's any support for this sort of thing, I could crank out an
informational RFC for this fairly quickly.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6SMjrB25483 for ietf-smime-bks; Sun, 28 Jul 2002 15:45:53 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6SMjpw25479 for <[e-mail]>; Sun, 28 Jul 2002 15:45:51 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g6SMjk3E011699; Sun, 28 Jul 2002 15:45:46 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <PZRDQ6CB>; Sun, 28 Jul 2002 15:46:35 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: RE: digested-data, surreptitious forwarding, D-H
Date: Sun, 28 Jul 2002 15:46:34 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Interesting, I'd assumed that you could do multiple layers (like a
digestedData and envelopedData, or signedData and envelopedData) in a single
pass, by hashing and then encrypting each content block, then moving to the
next one, etc..  You're saying that this isn't possible, but the scheme
below can be done in one pass?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Saturday, July 27, 2002 11:20 PM
To: [e-mail]; [e-mail]
Subject: Re: digested-data, surreptitious forwarding, D-H


Trevor Perrin <[e-mail]> writes:

>1) I'm surprised S/MIME doesn't use CMSs' digested-data with
enveloped-data.
>In the case of encrypted but not signed mails, doesn't this leave the
message
>vulnerable to things like cut-and-paste attacks (where an attacker reorders
>ciphertext blocks, so upon decrypting the recipient sees reordered
plaintext)?

Funny you should mention that, I was discussing this recently with someone
who
was quite concerned about this (they were FTP'ing large encrypted EDI
messages
around).  What they wanted was a modification to EncryptedData to include a
hash inside the encrypted content, rather than DigestedData, which would
require a second pass (they encrypt the content as they stream it in and
out,
so anything requiring two passes is a non-starter).  I have the feeling that
more people would be asking for this if they had any idea that encryption
doesn't guarantee integrity protection.

My suggestion was to put it in as an unprotectedAttrs, just encrypting the
MDC
after the content.  In other words, hash the data before you encrypt it,
then
after you've finished encrypting the data encrypt the hash and store it as
an
unprotectedAttrs.  This is a bog-standard way of appending an MDC to the
data,
and is compatible with the existing format.  The MDC info is put in as
originatorInfo, which is a bit of a kludge but seems to be the sensible
place
for it.  This would need a new originatorInfo type, but that's the only
change
necessary.

If there's any support for this sort of thing, I could crank out an
informational RFC for this fairly quickly.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g6S6K4Z20177 for ietf-smime-bks; Sat, 27 Jul 2002 23:20:04 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6S6K2w20164 for <[e-mail]>; Sat, 27 Jul 2002 23:20:02 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6S6Jfq9008922; Sun, 28 Jul 2002 18:19:41 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA501030; Sun, 28 Jul 2002 18:19:40 +1200 (NZST) (sender [e-mail])
Date: Sun, 28 Jul 2002 18:19:40 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  digested-data, surreptitious forwarding, D-H
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Trevor Perrin <[e-mail]> writes:

>1) I'm surprised S/MIME doesn't use CMSs' digested-data with enveloped-data.
>In the case of encrypted but not signed mails, doesn't this leave the message
>vulnerable to things like cut-and-paste attacks (where an attacker reorders
>ciphertext blocks, so upon decrypting the recipient sees reordered plaintext)?

Funny you should mention that, I was discussing this recently with someone who
was quite concerned about this (they were FTP'ing large encrypted EDI messages
around).  What they wanted was a modification to EncryptedData to include a
hash inside the encrypted content, rather than DigestedData, which would
require a second pass (they encrypt the content as they stream it in and out,
so anything requiring two passes is a non-starter).  I have the feeling that
more people would be asking for this if they had any idea that encryption
doesn't guarantee integrity protection.

My suggestion was to put it in as an unprotectedAttrs, just encrypting the MDC
after the content.  In other words, hash the data before you encrypt it, then
after you've finished encrypting the data encrypt the hash and store it as an
unprotectedAttrs.  This is a bog-standard way of appending an MDC to the data,
and is compatible with the existing format.  The MDC info is put in as
originatorInfo, which is a bit of a kludge but seems to be the sensible place
for it.  This would need a new originatorInfo type, but that's the only change
necessary.

If there's any support for this sort of thing, I could crank out an
informational RFC for this fairly quickly.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6R2SiV29523 for ietf-smime-bks; Fri, 26 Jul 2002 19:28:44 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6R2Sew29519 for <[e-mail]>; Fri, 26 Jul 2002 19:28:41 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g6R2Sc3E009758 for <[e-mail]>; Fri, 26 Jul 2002 19:28:38 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <PVNJC1L3>; Fri, 26 Jul 2002 19:28:33 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: Trevor Perrin <[e-mail]>, "'[e-mail]'" <[e-mail]>
Subject: RE: digested-data, surreptitious forwarding, D-H
Date: Fri, 26 Jul 2002 19:28:32 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

scratch question 3, this week has fried my brains more than I thought..

> -----Original Message-----
> From: Trevor Perrin [mailto:[e-mail]]
> Sent: Friday, July 26, 2002 2:32 PM
> To: '[e-mail]'
> Subject: digested-data, surreptitious forwarding, D-H
> 
> 
> 
> 
> With more diligence I probably could've answered these from 
> the archives.
> But a few questions:
> 
> 1) I'm surprised S/MIME doesn't use CMSs' digested-data with 
> enveloped-data.
> In the case of encrypted but not signed mails, doesn't this leave the
> message vulnerable to things like cut-and-paste attacks 
> (where an attacker
> reorders ciphertext blocks, so upon decrypting the recipient 
> sees reordered
> plaintext)?
> 
> 2) At some point I thought there was an Internet-Draft for a signed
> attribute to address Don Davis' surreptitious forwarding 
> concern.  I don't
> see it now.  Has that been dropped, or has some other fix 
> been incorporated
> somewhere?
> 
> 3) I see that Diffie-Hellman key pairs can be encrypted to, 
> using either
> static-static or ephemeral-static modes.  It seems like a 
> Diffie-Hellman key
> pair should be able to sign as well, using something like a 
> static-ephemeral
> mode.  Is there a cryptographic reason why this 
> can't/shouldn't be done, or
> is it just incidental that it isn't supported?  
> 
> The reason it seems like this might be useful is that Diffie-Hellman
> agreement values can be cached, so a signer could perform 
> lots of signatures
> efficiently with such a key pair, which could be useful for 
> something like a
> DOMSEC gateway, which may have high volume mail flows and 
> large key pairs.
> 
> Trevor
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QLWZA22585 for ietf-smime-bks; Fri, 26 Jul 2002 14:32:35 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6QLWXw22581 for <[e-mail]>; Fri, 26 Jul 2002 14:32:33 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g6QLWW3E002162 for <[e-mail]>; Fri, 26 Jul 2002 14:32:32 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <PVNJC1FW>; Fri, 26 Jul 2002 14:32:27 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: digested-data, surreptitious forwarding, D-H
Date: Fri, 26 Jul 2002 14:32:25 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

With more diligence I probably could've answered these from the archives.
But a few questions:

1) I'm surprised S/MIME doesn't use CMSs' digested-data with enveloped-data.
In the case of encrypted but not signed mails, doesn't this leave the
message vulnerable to things like cut-and-paste attacks (where an attacker
reorders ciphertext blocks, so upon decrypting the recipient sees reordered
plaintext)?

2) At some point I thought there was an Internet-Draft for a signed
attribute to address Don Davis' surreptitious forwarding concern.  I don't
see it now.  Has that been dropped, or has some other fix been incorporated
somewhere?

3) I see that Diffie-Hellman key pairs can be encrypted to, using either
static-static or ephemeral-static modes.  It seems like a Diffie-Hellman key
pair should be able to sign as well, using something like a static-ephemeral
mode.  Is there a cryptographic reason why this can't/shouldn't be done, or
is it just incidental that it isn't supported?  

The reason it seems like this might be useful is that Diffie-Hellman
agreement values can be cached, so a signer could perform lots of signatures
efficiently with such a key pair, which could be useful for something like a
DOMSEC gateway, which may have high volume mail flows and large key pairs.

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QJnWS15844 for ietf-smime-bks; Fri, 26 Jul 2002 12:49:32 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6QJnQw15825 for <[e-mail]>; Fri, 26 Jul 2002 12:49:26 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Jul 2002 19:48:29 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA25088 for <[e-mail]>; Fri, 26 Jul 2002 15:49:28 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6QJlKF03838 for <[e-mail]>; Fri, 26 Jul 2002 15:47:20 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <NGM1D1QF>; Fri, 26 Jul 2002 12:49:24 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVAR49; Fri, 26 Jul 2002 15:49:15 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Jul 2002 15:46:44 -0400
Subject: WG Last Call: draft-ietf-smime-cms-rsaes-oaep-04.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear S/MIME WG:

This message announces Working Group Last Call for rsaes-oaep.

	Title		: Use of the RSAES-OAEP Transport Algorithm in CMS
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-04.txt
	Pages		: 12
	Date		: 24-Jul-02
	
The intent is to publish rsaes-oaep as a Standards Track RFC.

Please review rsaes-oaep, and post any comments to the [e-mail] 
mail list by Sunday, 11 August 2002.  Unless traffic on the mail list 
indicates otherwise, I will
send these to the IESG shortly after WG Last Call closes.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6QJnQo15822 for ietf-smime-bks; Fri, 26 Jul 2002 12:49:26 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6QJnNw15812 for <[e-mail]>; Fri, 26 Jul 2002 12:49:24 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Jul 2002 19:48:27 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA25076 for <[e-mail]>; Fri, 26 Jul 2002 15:49:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6QJlI503829 for <[e-mail]>; Fri, 26 Jul 2002 15:47:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPVARVB>; Fri, 26 Jul 2002 15:49:23 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.39]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPVAR40; Fri, 26 Jul 2002 15:49:16 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Jul 2002 15:49:01 -0400
Subject: Re: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-04.txt
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

Thanks for reading the document.

This text recommends the most prudent approach.  Use the key for only one 
algorithm and only one purpose.

Russ

At 04:12 AM 7/26/2002 +1200, Peter Gutmann wrote:

> >   Generally, good cryptographic practice employs a given RSA key pair
> >   in only one scheme.  This practice avoids the risk that vulnerability
> >   in one scheme may compromise the security of the other, and may be
> >   essential to maintain provable security.  While PKCS #1 Version 1.5
> >   [PKCS#1v1.5] has been employed for both key transport and digital
> >   signature without any known bad interactions, such a combined use of
> >   an RSA key pair is not recommended in the future.  Therefore, an RSA
> >   key pair used for RSAES-OAEP key transport should not also be used
> >   for other purposes.
>
>Does "other purposes" here mean "signing" or "other types of key transport"?
>The comparison with PKCS #1 v1 seems to imply "signing", but it could also be
>interpreted to mean PKCS #1v1 vs. PKCS #1v2 key transport... I could see that
>the latter might lead to problems when you're communicating with existing
>implementations, or a mixture of old and new.
>
>Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g6PGCbS09928 for ietf-smime-bks; Thu, 25 Jul 2002 09:12:37 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PGCZw09920 for <[e-mail]>; Thu, 25 Jul 2002 09:12:35 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6PGCVq9010727 for <[e-mail]>; Fri, 26 Jul 2002 04:12:31 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA229841 for [e-mail]; Fri, 26 Jul 2002 04:12:31 +1200 (NZST) (sender [e-mail])
Date: Fri, 26 Jul 2002 04:12:31 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-cms-rsaes-oaep-04.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>   Generally, good cryptographic practice employs a given RSA key pair
>   in only one scheme.  This practice avoids the risk that vulnerability
>   in one scheme may compromise the security of the other, and may be
>   essential to maintain provable security.  While PKCS #1 Version 1.5
>   [PKCS#1v1.5] has been employed for both key transport and digital
>   signature without any known bad interactions, such a combined use of
>   an RSA key pair is not recommended in the future.  Therefore, an RSA
>   key pair used for RSAES-OAEP key transport should not also be used
>   for other purposes.

Does "other purposes" here mean "signing" or "other types of key transport"?
The comparison with PKCS #1 v1 seems to imply "signing", but it could also be
interpreted to mean PKCS #1v1 vs. PKCS #1v2 key transport... I could see that
the latter might lead to problems when you're communicating with existing
implementations, or a mixture of old and new.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6PC9Bg25736 for ietf-smime-bks; Thu, 25 Jul 2002 05:09:11 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6PC9Aw25731 for <[e-mail]>; Thu, 25 Jul 2002 05:09:10 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00143; Thu, 25 Jul 2002 08:08:05 -0400 (EDT)
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-rsaes-oaep-04.txt
Date: Thu, 25 Jul 2002 08:08:04 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: Use of the RSAES-OAEP Transport Algorithm in CMS
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cms-rsaes-oaep-04.txt
	Pages		: 12
	Date		: 24-Jul-02
	
This document describes the use of the RSAES-OAEP key transport
method of key management within the Cryptographic Message Syntax
(CMS).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-cms-rsaes-oaep-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-rsaes-oaep-04.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-cms-rsaes-oaep-04.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-rsaes-oaep-04.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H8H0110528 for ietf-smime-bks; Wed, 17 Jul 2002 01:17:00 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H8Gxw10518 for <[e-mail]>; Wed, 17 Jul 2002 01:16:59 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Wed, 17 Jul 2002 01:16:58 -0700
Message-ID: <045601c22d69$65be46e0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <000001c22d54$7a1dc7b0$[e-mail]>
Subject: Re: AES and PKCS #1 v1.5 Issue
Date: Wed, 17 Jul 2002 01:10:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g6H8H0w10521
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, July 16, 2002 10:40 PM
Subject: AES and PKCS #1 v1.5 Issue


> At the face-to-face meeting, I indicated that it is still my belief that
> we should prohibit the use of RSA PKCS#1 v1.5 to transport AES keys due
> to the somewhat weaker security provided by this method.  While I agree
> that there is no known attack against RSA PKCS#1 v1.5 in the case of
> S/MIME (as a store-and-forward mail system), I do believe that one can
> construct an attack against an arbitrary CMS-based protocol.  Since this
> is a discussion of how to use AES with CMS and not just with S/MIME, I
> believe that the more general case should rule what happens in this
> document.

My position continues to be along the lines of specification purity -- it is my opinion that the AES algorithm profile for CMS is not the forum for flogging PKCS #1 v1.5 unless there are specific issues that are unique to the specific combined use of AES and PKCS #1 v1.5.

This is especially in light of the fact that:

1. RFC 3218 discusses the issue of the MMA and CMS at length (as I believe Peter has already pointed out)

2. CMSALG already discusses this in at least two places -- roughly a page of text.

3. There is a TBD in MSG-bis that says we should discuss it some more there.

> Having done implementations of the RSA-OAEP padding already, I do NOT
> believe that there is a serious development hurdle to getting RSA-OAEP
> distributed.

Not everyone controls the key unwrapping and unpadding, as in the case of hardware tokens or software libraries that don't separate the block decryption from the block unpadding.  Some of us are more "applied" cryptogruffers than others ;).

> 1.  Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
> document.
> 2.  Remove the ban, but allow the author to present a diatribe on why
> it's a bad idea.
> 3.  Remove the ban entirely and force an update to SMimeCapabilities to
> allow for products to advise that the combination is not acceptable.

In the event that we decide to continue with any ban on the use of PKCS #1 v1.5 in any CMS context, it is my recommendation that we either a) modify the existing CMS / CMSALG / MSG specification in that way, or b) create a separate document that explains the issue further.

If we have failed to explain just how bad PKCS #1 v1.5 is, then I believe this is a failing of MSG and CMSALG and should be addressed there, not in the AES algorithm profile.

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H7Cd629618 for ietf-smime-bks; Wed, 17 Jul 2002 00:12:39 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H7Caw29607 for <[e-mail]>; Wed, 17 Jul 2002 00:12:37 -0700 (PDT)
Received: from coot.wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.5/8.12.5) with ESMTP id g6H7B2Qp025062; Wed, 17 Jul 2002 17:11:03 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: Dean Povey <[e-mail]>
To: [e-mail]
cc: "'Peter Gutmann'" <[e-mail]>, [e-mail]
Subject: Re: AES and PKCS #1 v1.5 Issue 
In-reply-to: Your message of "Wed, 17 Jul 2002 15:26:38 +0900." <000801c22d5a$edb78890$[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Wed, 17 Jul 2002 17:11:02 +1000
X-Scanned-By: MIMEDefang 2.15 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, 17 Jul 2002 15:26:38 +0900, "Jim Schaad" wrote: 
>
>Peter, 
>
>There is one large difference between TLS and CMS.  The TLS protocol has
>already been modified to deal with the attacks on PKCS#1 v1.5, CMS has
>not been modified to deal with these attacks.  Therefore I do not
>necessarily think that the TLS conclusion on this is sufficient.
>

Well strictly speaking there was no modification to the TLS protocol
per se, only how implementations handle PKCS#1 padding failures... er well I 
guess that kind of is a modification to the protocol.

Besides that, I agree with Peter.  The side-channel attacks in CMS have to
be addressed anyway, because people will support PKCS#1 for backwards
interoperability with existing implementations.  There is no problem with 
S/MIME (as you have no random oracle), and the same is most likely true 
for any other CMS based application.

It would be much better to make OAEP a SHOULD and give the appropriate
recommendations to avoid side-channel attacks for the PKCS#1 stuff (and any
of the various other side-channel attacks e.g. timing analysis, Vaudenay
attack on CBC, etc).  There is a lot of infrastructure already heavily
invested in PKCS#1, some of which (like hardware accelerators for example)
will take a while to change.

Dean.


-- 
Dean Povey,             |em: [e-mail]|JCSI: Java security toolkit
Wedgetail Communications|ph:  [phone]   |uPKI: Embedded/C PKI toolkit
Level 14, 388 Queen St, |fax: [phone]   |uSSL: Embedded/C SSL toolkit
Brisbane, Australia     |www: www.wedgetail.com |XML Security: XML Signatures 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H6cd523962 for ietf-smime-bks; Tue, 16 Jul 2002 23:38:39 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H6cbw23953 for <[e-mail]>; Tue, 16 Jul 2002 23:38:37 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6H6bu1o008717; Wed, 17 Jul 2002 18:37:56 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA300483; Wed, 17 Jul 2002 18:37:56 +1200 (NZST) (sender [e-mail])
Date: Wed, 17 Jul 2002 18:37:56 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: AES and PKCS #1 v1.5 Issue
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>There is one large difference between TLS and CMS.  The TLS protocol has
>already been modified to deal with the attacks on PKCS#1 v1.5, CMS has
>not been modified to deal with these attacks.  Therefore I do not
>necessarily think that the TLS conclusion on this is sufficient.

There's an RFC on this for S/MIME as well.

(The obvious comment is that TLS was modified because it needed to be.  
You'd really have to bend over backwards to create an S/MIME 
implementation which was vulnerable to the Bleichenbacher attack, and
even if you had one I can't imagine any MTA which would just sit there
and calmly accept 1M email messages from the same source in today's
spam-aware world).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H6RZM21967 for ietf-smime-bks; Tue, 16 Jul 2002 23:27:35 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H6RXw21963 for <[e-mail]>; Tue, 16 Jul 2002 23:27:33 -0700 (PDT)
Received: from revelation (revelation.soaringhawk.net [133.93.76.147] (may be forged)) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H6RVu13533; Wed, 17 Jul 2002 15:27:31 +0900 (JST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>
Subject: RE: AES and PKCS #1 v1.5 Issue
Date: Wed, 17 Jul 2002 15:26:38 +0900
Message-ID: <000801c22d5a$edb78890$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter, 

There is one large difference between TLS and CMS.  The TLS protocol has
already been modified to deal with the attacks on PKCS#1 v1.5, CMS has
not been modified to deal with these attacks.  Therefore I do not
necessarily think that the TLS conclusion on this is sufficient.

Jim


> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]] 
> Sent: Wednesday, July 17, 2002 3:21 PM
> To: [e-mail]; [e-mail]
> Subject: Re: AES and PKCS #1 v1.5 Issue
> 
> 
> "Jim Schaad" <[e-mail]> writes:
> 
> >The face-to-face meeting was presented with the following choices:
> >
> >1.  Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
> >document.
> >2.  Remove the ban, but allow the author to present a diatribe on why
> >it's a bad idea.
> >3.  Remove the ban entirely and force an update to 
> SMimeCapabilities to
> >allow for products to advise that the combination is not acceptable.
> 
> Didn't we go through all this (endlessly) ages ago, and more or less
> resolve to let people use PKCS #1 if they wanted to?
> 
> [pause]
> 
> Oh, sorry, that was ietf-tls which looked at it.  The conclusion there
> was:
> 
> >If people are interested in seeing OAEP adopted it won't 
> need to use the
> >momentum AES has created.  If people aren't interested then 
> it won't get
> >adopted, but that's the way it should be.
> 
> ietf-tls also looked into simple-RSA, the general opinion was that if
> any change is made, simple-RSA would be a better choice since 
> there's no
> OAEP deployed base to be compatible with.
> 
> Given that every S/MIME implementation around already does AES with 
> PKCS #1 (is there anyone who hasn't added AES support yet?), mandating
> OAEP is just going to be another X9.42 - everyone pretends to do it
> but does PKCS #1 instead.  This is going to sound somewhat 
> cavalier :-), 
> but as far as I'm concerned the RFC can really say whatever it wants.
> Option 1 will be ignored entirely, 2 will be read but ignored, and 3
> would be the pragmatic solution (or do 2+3, which seems the obvious 
> one - tell people it's a bad thing, and provide an SMimeCap to allow
> OAEP if people want it).
> 
> Peter.
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H6LdH21296 for ietf-smime-bks; Tue, 16 Jul 2002 23:21:39 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H6Lbw21292 for <[e-mail]>; Tue, 16 Jul 2002 23:21:37 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g6H6Ko1o008454; Wed, 17 Jul 2002 18:20:50 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA290621; Wed, 17 Jul 2002 18:20:49 +1200 (NZST) (sender [e-mail])
Date: Wed, 17 Jul 2002 18:20:49 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  AES and PKCS #1 v1.5 Issue
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Jim Schaad" <[e-mail]> writes:

>The face-to-face meeting was presented with the following choices:
>
>1.  Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
>document.
>2.  Remove the ban, but allow the author to present a diatribe on why
>it's a bad idea.
>3.  Remove the ban entirely and force an update to SMimeCapabilities to
>allow for products to advise that the combination is not acceptable.

Didn't we go through all this (endlessly) ages ago, and more or less
resolve to let people use PKCS #1 if they wanted to?

[pause]

Oh, sorry, that was ietf-tls which looked at it.  The conclusion there
was:

>If people are interested in seeing OAEP adopted it won't need to use the
>momentum AES has created.  If people aren't interested then it won't get
>adopted, but that's the way it should be.

ietf-tls also looked into simple-RSA, the general opinion was that if
any change is made, simple-RSA would be a better choice since there's no
OAEP deployed base to be compatible with.

Given that every S/MIME implementation around already does AES with 
PKCS #1 (is there anyone who hasn't added AES support yet?), mandating
OAEP is just going to be another X9.42 - everyone pretends to do it
but does PKCS #1 instead.  This is going to sound somewhat cavalier :-), 
but as far as I'm concerned the RFC can really say whatever it wants.
Option 1 will be ignored entirely, 2 will be read but ignored, and 3
would be the pragmatic solution (or do 2+3, which seems the obvious 
one - tell people it's a bad thing, and provide an SMimeCap to allow
OAEP if people want it).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H615d15745 for ietf-smime-bks; Tue, 16 Jul 2002 23:01:05 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6H613w15736 for <[e-mail]>; Tue, 16 Jul 2002 23:01:03 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jul 2002 06:00:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id CAA01957; Wed, 17 Jul 2002 02:01:07 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6H5x2309219; Wed, 17 Jul 2002 01:59:02 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TP47Z85>; Wed, 17 Jul 2002 02:01:06 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.15]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP47Z8X; Wed, 17 Jul 2002 02:00:59 -0400
From: "Housley, Russ" <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Jul 2002 01:53:47 -0400
Subject: Re: Change from "cert-only" in RFC2633-bis-01
In-Reply-To: <02c401c22c70$099e16f0$[e-mail]>
References: <000001c22c6f$aed48330$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I would prefer to keep the MIME type the same, but add words that clarify 
the processing.  I see no reason to assign a second MIME type for the same 
thing.

Russ


At 07:25 PM 7/15/2002 -0700, Blake Ramsdell wrote:

>----- Original Message -----
>From: "Jim Schaad" <[e-mail]>
>To: <[e-mail]>; "'Blake Ramsdell'" <[e-mail]>
>Sent: Monday, July 15, 2002 7:22 PM
>Subject: Change from "cert-only" in RFC2633-bis-01
>
>
> > Blake,
> >
> > I think that there may be a major problem in making this change.
> >
> > Issues:
> > 1.  You need to have a backwards compability section describing what the
> > old "certs-only" smime-type is and what it does.
>
> From draft-ietf-smime-rfc2633bis-01.txt section 3.6:
>
>Please note that in prior versions of S/MIME, the smime-type parameter
>was set to "certs-only" for messages that contained only certificates
>and/or certificate revocation lists. The new use of "cert-management"
>is meant to clarify the semantic that both certificates and
>certificate revocation lists might be found in these messages.
>Receiving implementations SHOULD accept "certs-only" and
>"cert-management" and treat them equivalently (that is, both could
>contain certificates and/or certificate revocation lists).
>
>Please let me know what other clarification would be useful here -- indeed 
>this is something to be careful of if we change this smime-type.
>
> > 2.  I dislike the term cert-management, because you are not doing
> > certificate managmement.  A better term would be cert-distribution.
>
>And I'll further complain that "it distributes CRLs as well as 
>certs".  This might end up being an interesting rathole.  Well, 
>"interesting" as far as ratholes go, that is ;).
>
> > Personally I have no problem with leaving this smime-type as is.
>
>Me neither.  Maybe this should change back to "certs-only" and we focus on 
>clarifying the generation / processing of the data rather than changing 
>the smime-type.
>
>Blake


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6H5fMX15126 for ietf-smime-bks; Tue, 16 Jul 2002 22:41:22 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H5fKw15121 for <[e-mail]>; Tue, 16 Jul 2002 22:41:21 -0700 (PDT)
Received: from revelation ([133.93.76.147]) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H5fJu13448; Wed, 17 Jul 2002 14:41:19 +0900 (JST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: AES and PKCS #1 v1.5 Issue
Date: Wed, 17 Jul 2002 14:40:29 +0900
Message-ID: <000001c22d54$7a1dc7b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is intended to start the final discussion on the question
of forcing AES to use RSA-OAEP in the AES draft.

At the face-to-face meeting, I indicated that it is still my belief that
we should prohibit the use of RSA PKCS#1 v1.5 to transport AES keys due
to the somewhat weaker security provided by this method.  While I agree
that there is no known attack against RSA PKCS#1 v1.5 in the case of
S/MIME (as a store-and-forward mail system), I do believe that one can
construct an attack against an arbitrary CMS-based protocol.  Since this
is a discussion of how to use AES with CMS and not just with S/MIME, I
believe that the more general case should rule what happens in this
document.

Having done implementations of the RSA-OAEP padding already, I do NOT
believe that there is a serious development hurdle to getting RSA-OAEP
distributed.

The face-to-face meeting was presented with the following choices:

1.  Leave the ban on RSA PKCS#1 v1.5 as is currently present in the
document.
2.  Remove the ban, but allow the author to present a diatribe on why
it's a bad idea.
3.  Remove the ban entirely and force an update to SMimeCapabilities to
allow for products to advise that the combination is not acceptable.

The vote on the face-to-face was unanimous on keeping the ban.  The
discussion on this issue is now open on the list.

Jim



Received: by above.proper.com (8.11.6/8.11.3) id g6H0FxN08816 for ietf-smime-bks; Tue, 16 Jul 2002 17:15:59 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6H0Fvw08812 for <[e-mail]>; Tue, 16 Jul 2002 17:15:57 -0700 (PDT)
Received: from revelation (revelation.soaringhawk.net [133.93.76.147] (may be forged)) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6H0Ftu12275; Wed, 17 Jul 2002 09:15:56 +0900 (JST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: Change from "cert-only" in RFC2633-bis-01
Date: Wed, 17 Jul 2002 09:15:11 +0900
Message-ID: <000801c22d27$04a630d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <02c401c22c70$099e16f0$[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

I have just noticed in doing some re-writes on the CMC draft in the PKIX
group that it also refers to "certs-only".  I don't know if there are
other RFC's that might also do this.  I think that this might be a good
reason to revert back.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Blake Ramsdell
> Sent: Tuesday, July 16, 2002 11:25 AM
> To: [e-mail]; [e-mail]
> Subject: Re: Change from "cert-only" in RFC2633-bis-01
> 
> 
> 
> ----- Original Message ----- 
> From: "Jim Schaad" <[e-mail]>
> To: <[e-mail]>; "'Blake Ramsdell'" 
> <[e-mail]>
> Sent: Monday, July 15, 2002 7:22 PM
> Subject: Change from "cert-only" in RFC2633-bis-01
> 
> 
> > Blake,
> > 
> > I think that there may be a major problem in making this change.
> > 
> > Issues: 
> > 1.  You need to have a backwards compability section 
> describing what the
> > old "certs-only" smime-type is and what it does.
> 
> >From draft-ietf-smime-rfc2633bis-01.txt section 3.6:
> 
> Please note that in prior versions of S/MIME, the smime-type parameter
> was set to "certs-only" for messages that contained only certificates
> and/or certificate revocation lists. The new use of "cert-management"
> is meant to clarify the semantic that both certificates and
> certificate revocation lists might be found in these messages.
> Receiving implementations SHOULD accept "certs-only" and
> "cert-management" and treat them equivalently (that is, both could
> contain certificates and/or certificate revocation lists).
> 
> Please let me know what other clarification would be useful 
> here -- indeed this is something to be careful of if we 
> change this smime-type.
> 
> > 2.  I dislike the term cert-management, because you are not doing
> > certificate managmement.  A better term would be cert-distribution.
> 
> And I'll further complain that "it distributes CRLs as well 
> as certs".  This might end up being an interesting rathole.  
> Well, "interesting" as far as ratholes go, that is ;).
> 
> > Personally I have no problem with leaving this smime-type as is.
> 
> Me neither.  Maybe this should change back to "certs-only" 
> and we focus on clarifying the generation / processing of the 
> data rather than changing the smime-type.
> 
> Blake
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6G2XAR15336 for ietf-smime-bks; Mon, 15 Jul 2002 19:33:10 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6G2X9w15332 for <[e-mail]>; Mon, 15 Jul 2002 19:33:09 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 15 Jul 2002 19:33:11 -0700
Message-ID: <02c401c22c70$099e16f0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <000001c22c6f$aed48330$[e-mail]>
Subject: Re: Change from "cert-only" in RFC2633-bis-01
Date: Mon, 15 Jul 2002 19:25:22 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g6G2XAw15333
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message ----- 
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>; "'Blake Ramsdell'" <[e-mail]>
Sent: Monday, July 15, 2002 7:22 PM
Subject: Change from "cert-only" in RFC2633-bis-01


> Blake,
> 
> I think that there may be a major problem in making this change.
> 
> Issues: 
> 1.  You need to have a backwards compability section describing what the
> old "certs-only" smime-type is and what it does.

>From draft-ietf-smime-rfc2633bis-01.txt section 3.6:

Please note that in prior versions of S/MIME, the smime-type parameter
was set to "certs-only" for messages that contained only certificates
and/or certificate revocation lists. The new use of "cert-management"
is meant to clarify the semantic that both certificates and
certificate revocation lists might be found in these messages.
Receiving implementations SHOULD accept "certs-only" and
"cert-management" and treat them equivalently (that is, both could
contain certificates and/or certificate revocation lists).

Please let me know what other clarification would be useful here -- indeed this is something to be careful of if we change this smime-type.

> 2.  I dislike the term cert-management, because you are not doing
> certificate managmement.  A better term would be cert-distribution.

And I'll further complain that "it distributes CRLs as well as certs".  This might end up being an interesting rathole.  Well, "interesting" as far as ratholes go, that is ;).

> Personally I have no problem with leaving this smime-type as is.

Me neither.  Maybe this should change back to "certs-only" and we focus on clarifying the generation / processing of the data rather than changing the smime-type.

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g6G2NY815181 for ietf-smime-bks; Mon, 15 Jul 2002 19:23:34 -0700 (PDT)
Received: from mail.ietf54.wide.ad.jp (www.ietf54.wide.ad.jp [133.93.192.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6G2NWw15176 for <[e-mail]>; Mon, 15 Jul 2002 19:23:32 -0700 (PDT)
Received: from revelation (revelation.soaringhawk.net [133.93.76.147] (may be forged)) by mail.ietf54.wide.ad.jp (8.11.6/8.11.6) with ESMTP id g6G2NXu09693; Tue, 16 Jul 2002 11:23:33 +0900 (JST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: Change from "cert-only" in RFC2633-bis-01
Date: Tue, 16 Jul 2002 11:22:47 +0900
Message-ID: <000001c22c6f$aed48330$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Blake,

I think that there may be a major problem in making this change.

Issues: 
1.  You need to have a backwards compability section describing what the
old "certs-only" smime-type is and what it does.
2.  I dislike the term cert-management, because you are not doing
certificate managmement.  A better term would be cert-distribution.

Personally I have no problem with leaving this smime-type as is.

Jim



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6FLQPR06757 for ietf-smime-bks; Mon, 15 Jul 2002 14:26:25 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g6FLQNw06753 for <[e-mail]>; Mon, 15 Jul 2002 14:26:23 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Jul 2002 21:25:39 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA29863; Mon, 15 Jul 2002 17:25:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g6FLNpE01908; Mon, 15 Jul 2002 17:23:51 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TP47HQK>; Mon, 15 Jul 2002 17:25:53 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.9.33 [10.3.9.33]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TP47HQ1; Mon, 15 Jul 2002 17:25:47 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Jul 2002 04:52:39 -0400
Subject: S/MIME WG Finished with draft-ietf-smime-hmac-key-wrap-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jeff & Steve:

The S/MIME WG is finished with draft-ietf-smime-hmac-key-wrap-00.txt.  The 
intent is to publish this document as an Informational RFC.  The two 
authors have independently written implementations of the specification, 
and the implementations interoperate.  This indicates that the 
specification contains the necessary detail.

	Title		: Wrapping an HMAC key with a Triple-DES Key or an AES Key
	Author(s)	: J. Schaad, R. Housley
	Filename	: draft-ietf-smime-hmac-key-wrap-00.txt
	Date		: January 2002

Russ 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g6C9qO907207 for ietf-smime-bks; Fri, 12 Jul 2002 02:52:24 -0700 (PDT)
Received: from bsd.sigaba.com (bsd.sigaba.com [67.113.238.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g6C9qMw07199 for <[e-mail]>; Fri, 12 Jul 2002 02:52:22 -0700 (PDT)
Received: from exchange1.sigaba.com (exchange1.sigaba.com [10.10.10.10]) by bsd.sigaba.com (8.12.2/8.12.2) with ESMTP id g6C9qIL2023819 for <[e-mail]>; Fri, 12 Jul 2002 02:52:18 -0700
Received: by exchange.sigaba.com with Internet Mail Service (5.5.2653.19) id <3YS1SNQG>; Fri, 12 Jul 2002 02:52:01 -0700
Message-ID: <[e-mail]>
From: Trevor Perrin <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RFC 3183: Domain Security Services
Date: Fri, 12 Jul 2002 02:52:00 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello all,

I think domain security is a great idea, so I'm curious about this RFC's
status.  I saw in the archives that Baycorp's MailMarshall product
implements it.  Are there other implementations existing or in progress?  Is
it likely that this RFC will progress onto the standards track?

As a technical question, RFC 3183 defines a naming convention where an
entity with a certificate for the name "[e-mail]"
is trusted for producing domain signatures on behalf of *@acme.com.

This convention seems to accomplish the same thing as the name constraints
extension does for CAs: it gives an entity authority over some set of names.
But by allowing one special name to stand for the whole domain, this
convention seems like it could violate the intention of the name constraints
extension.

For example, suppose a CA's certificate has the email name constraint
"permitted subtree = acme.com".  This only allows the CA to issue
certificates for mailbox addresses at the host acme.com, not for all
addresses within the acme.com domain.  But if the CA issues a certificate to
[e-mail], this domain signing authority will be
trusted to sign for, say, [e-mail].  It seems odd that the CA
could grant a domain signing authority the ability to sign for Bob, since
the CA was not itself trusted to issue Bob a certificate.    

So perhaps it would be better to allow domain authority certificates to use
the name constraints extension, instead of a specialized naming convention,
to express who they are authoritative for, and to extend validation of CA
name constraints to the domain authority certificate.  Then the above
violation of name constraints couldn't occur, and RFC 3183 could be made
simpler, since it could reference a pre-existing mechanism for delimiting
trust, and not have to invent its own.

A further advantage might be that the name constraints extension is more
expressive than the RFC 3183 naming convention, since name constraints can
specify trust on the basis of hosts instead of whole domains, and can
exclude particular hosts, mailboxes, or subdomains, from the granting of
trust as well..

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g69ENhq12697 for ietf-smime-bks; Tue, 9 Jul 2002 07:23:43 -0700 (PDT)
Received: from mx2.magma.ca (mx2.magma.ca [206.191.0.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g69ENgw12693 for <[e-mail]>; Tue, 9 Jul 2002 07:23:42 -0700 (PDT)
Received: from mail4.magma.ca (mail4.magma.ca [206.191.0.222]) by mx2.magma.ca (Magma's Mail Server) with ESMTP id g69ENbXR019427; Tue, 9 Jul 2002 10:23:37 -0400 (EDT)
Received: from tony (ottawa-hs-209-217-122-183.s-ip.magma.ca [209.217.122.183]) by mail4.magma.ca (Magma's Mail Server) with ESMTP id g69ENR2L010406; Tue, 9 Jul 2002 10:23:36 -0400 (EDT)
From: "Tony Capel" <[e-mail]>
To: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
Date: Tue, 9 Jul 2002 10:23:30 -0400
Message-ID: <002101c22754$361d6f30$01b5a8c0@tony>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

many of us like your compression addition and would like it widely (if
not ubiquitously!) implemented.

One perceived barrier to the adoption of s/mime is the expansion of
message size due to the repeated application of transfer (base64)
encoding at each wrap.  Messaging system operators become alarmed when
told message sizes may more than double as a result.  (Indeed the NIST
draft profile depreciates such coding of inner wraps to address this
issue.)

The ability to offer compression also addresses overall message
expansion and will be an important capability to offer in compensation
when "marketing" the adoption of s/mime by large organizations.


Tony Capel

  
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Peter Gutmann
Sent: July 9, 2002 4:49 AM
To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt


"Blake Ramsdell" <[e-mail]> writes:

>I didn't see much uptake on this besides Russ saying "MAY", and I'm
worried
>about compatibility.  I will put a slide in my presentation about this
for
>Yokohama.

AFAIK the major use at the moment is in EDI environments (large, highly-
compressible messages, and everything is "by prior arrangement" anyway).
There
are a couple of apps which support it out there though, so having it
mentioned
would be nice just to let implementers know it's there.

Peter.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g698o4r08049 for ietf-smime-bks; Tue, 9 Jul 2002 01:50:04 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g698o1w08045 for <[e-mail]>; Tue, 9 Jul 2002 01:50:02 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g698nU42005491; Tue, 9 Jul 2002 20:49:30 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA42599; Tue, 9 Jul 2002 20:49:28 +1200 (NZST) (sender [e-mail])
Date: Tue, 9 Jul 2002 20:49:28 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Blake Ramsdell" <[e-mail]> writes:

>I didn't see much uptake on this besides Russ saying "MAY", and I'm worried
>about compatibility.  I will put a slide in my presentation about this for
>Yokohama.

AFAIK the major use at the moment is in EDI environments (large, highly-
compressible messages, and everything is "by prior arrangement" anyway). There
are a couple of apps which support it out there though, so having it mentioned
would be nice just to let implementers know it's there.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g68I5GI20228 for ietf-smime-bks; Mon, 8 Jul 2002 11:05:16 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g68I5Ew20218 for <[e-mail]>; Mon, 8 Jul 2002 11:05:14 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 8 Jul 2002 11:05:13 -0700
Message-ID: <027701c226a9$98122650$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt
Date: Mon, 8 Jul 2002 11:02:16 -0700
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 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

(IETF-SMIME added per Francois's's suggestion)

----- Original Message -----
From: <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Monday, July 08, 2002 7:37 AM
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2633bis-01.txt


> I thought that you had previously agreed that RFC2633bis ought to say that
> compression [RFC 3274] MAY be applied before encryption or signing and
that
> the S/MIME capability should be used to negotiate this beforehand, but I
see
> no mention of this in the latest revised version of RFC2633bis.  The
> optional support for compression under S/MIME might be very useful
> especially for wireless environments.
>
> Do you plan to mention compression in the next version of RFC2633bis?

I didn't see much uptake on this besides Russ saying "MAY", and I'm worried
about compatibility.  I will put a slide in my presentation about this for
Yokohama.

So that's what's called a "non-answer" ;).

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65DXqf13516 for ietf-smime-bks; Fri, 5 Jul 2002 06:33:52 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65DXow13511 for <[e-mail]>; Fri, 5 Jul 2002 06:33:51 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24449; Fri, 5 Jul 2002 09:32:59 -0400 (EDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Document Action: AES Key Wrap Algorithm to Informational
Date: Fri, 05 Jul 2002 09:32:58 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'AES Key Wrap Algorithm'
<draft-ietf-smime-aes-keywrap-00.txt> as an Informational RFC.  This
document is the product of the S/MIME Mail Security Working Group.  The
IESG contact persons are Jeffrey Schiller and Steve Bellovin.


Note to RFC Editor:

Please replace the Status of this Memo text with the following:

         This document is an Internet-Draft and is subject to
         all provisions of Section 10 of RFC2026 except that the
         right to produce derivative works is not granted.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65Abmt00263 for ietf-smime-bks; Fri, 5 Jul 2002 03:37:48 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65Ablw00259 for <[e-mail]>; Fri, 5 Jul 2002 03:37:47 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17583; Fri, 5 Jul 2002 06:36:58 -0400 (EDT)
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-rfc2633bis-01.txt
Date: Fri, 05 Jul 2002 06:36:58 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: S/MIME Version 3.1 Message Specification
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2633bis-01.txt
	Pages		: 
	Date		: 03-Jul-02
	
S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
consistent way to send and receive secure MIME data. Based on the
popular Internet MIME standard, S/MIME provides the following
cryptographic security services for electronic messaging applications:
authentication, message integrity and non-repudiation of origin (using
digital signatures) and data confidentiality (using encryption).

S/MIME can be used by traditional mail user agents (MUAs) to add
cryptographic security services to mail that is sent, and to interpret
cryptographic security services in mail that is received. However,
S/MIME is not restricted to mail; it can be used with any transport
mechanism that transports MIME data, such as HTTP. As such, S/MIME
takes advantage of the object-based features of MIME and allows secure
messages to be exchanged in mixed-transport systems.

Further, S/MIME can be used in automated message transfer agents that
use cryptographic security services that do not require any human
intervention, such as the signing of software-generated documents and
the encryption of FAX messages sent over the Internet.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-rfc2633bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2633bis-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-rfc2633bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2633bis-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65Abh900248 for ietf-smime-bks; Fri, 5 Jul 2002 03:37:43 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65Abgw00244 for <[e-mail]>; Fri, 5 Jul 2002 03:37:42 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17570; Fri, 5 Jul 2002 06:36:53 -0400 (EDT)
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-rfc2632bis-01.txt
Date: Fri, 05 Jul 2002 06:36:53 -0400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--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		: S/MIME Version 3.1 Certificate Handling
	Author(s)	: B. Ramsdell
	Filename	: draft-ietf-smime-rfc2632bis-01.txt
	Pages		: 
	Date		: 03-Jul-02
	
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM]. S/MIME agents MUST meet the certificate processing
requirements documented in this document in addition to those stated
in [KEYM].
This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key
management supported by CMS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also 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-rfc2632bis-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-smime-rfc2632bis-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-rfc2632bis-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-smime-rfc2632bis-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 localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g65AHPa28911 for ietf-smime-bks; Fri, 5 Jul 2002 03:17:25 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g65AHOw28906; Fri, 5 Jul 2002 03:17:24 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA20354; Fri, 5 Jul 2002 12:21:26 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002070512165338:175 ; Fri, 5 Jul 2002 12:16:53 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Jul 2002 12:14:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>, S-MIME / IETF <[e-mail]>
Subject: Attribute Certification
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 12:16:53, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/07/2002 12:17:24, Serialize complete at 05/07/2002 12:17:24
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Request for public comments on Draft ETSI TR 102 044 V0.0.7 (2002-07):

"Identification of requirements for attribute certification"

The ETSI Electronic Signatures Infrastructure Working Group has drafted a
technical report to identify a set of requirements that will provide a basis
on which a subsequent standard can build policy requirements for attributes
certified by Attribute Authorities or Certification Authorities either in a
subject's PKCs (Public Key Certificates) or in ACs (Attribute Certificates).

The scope of this document is to extensively investigate on the attribute
certification related topics in order to cover the general use of certified
attributes in the context of electronic signatures, but attributes that can
be used in such a context can also be used for other reasons, e.g.: for
authorisation.

COMMENTS ARE REQUESTED BY 8 TH SEPTEMBER 2002. Details of how to obtain
a copy of this document and submit comments are given towards the end of
this message.

BACKGROUND

The development of policy documents is one of the tasks the ETSI Electronic
Signature and Infrastructure Working Group is progressing within the
European Electronic Signature Standardisation Initiative (EESSI).
The ETSI El Sign Web-site (see below) provides further information about the
ETSI activities and the EESSI program.

REQUESTED ACTION.

Please send your comments and suggestions not later than 8 th September
either to the ETSI El Sign e-mail list [e-mail], with copy to
the editor on [e-mail] or only to the editor, as you wish.
Please put "Attribute Certification" at the front of the Subject field of
all submissions to the e-mail list on this topic.

To register with the EL-SIGN list and download the draft document
(draft_TR_102044_v007.pdf) see:

http://portal.etsi.org/sec/el-sign.asp

The purpose of the open e-mail list is to stimulate discussion of the
published comments and contributions. Therefore, early submissions are
welcome. We expect that discussions will go on through the open e-mail list
under and after the comments period.

With regards,

Denis Pinkas. Bull.
Editor - Identification of requirements for attribute certification.

Franco Ruggieri. FIR DIG Consultants.
Task leader - Identification of requirements for attribute certification.