Re: Next Draft of Proposed Charter

["Housley, Russ" <[e-mail]>]

Bodo:

This is a point to be raised in the security considerations section of the 
document.  It is quite reasonable to document both methods of using RSA, 
then warn people that a different key pair should be used with each one.

Russ

At 01:03 AM 5/25/2002 +0200, Bodo Moeller wrote:

>Housley, Russ <[e-mail]>:
>
> >>> Here is the next draft of the proposed working group charter.  The
> >>> biggest change from the previous posting is that both OAEP and KEM 
> become
> >>> standards track documents.
>
> >> Are the differences between the attacks and mitigations presented by OAEP
> >> and KEM really worth the high liklihood of lack of interoperability?
>
> > RSA using PKCS#1_v1.5, OAEP, and KEM all employ the same certificate, so
> > this choice does not require any adjustments in the PKI.
>
>This makes it is pretty pointless to use "provably secure"
>cryptography, though -- all security guarantees that OAEP, say, may
>promise are voided if you use the same key for decrypting messages
>using some other style of RSA.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4SCv0I21658 for ietf-smime-bks; Tue, 28 May 2002 05:57:00 -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 g4SCuwJ21650 for <[e-mail]>; Tue, 28 May 2002 05:56:58 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 28 May 2002 12:55:04 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 IAA11712; Tue, 28 May 2002 08:56:58 -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 g4SCt5x06155; Tue, 28 May 2002 08:55:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLH1N2>; Tue, 28 May 2002 08:56:57 -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 K2ZLH1NC; Tue, 28 May 2002 08:56:53 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 28 May 2002 08:34:04 -0400
Subject: Re: Next Draft of Proposed Charter
In-Reply-To: <m17BO5T-000QdtC@epsilon>
References: <[e-mail]> <p0511171bb901e26f1a10@[165.227.249.18]> <[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>

Bodo:

This is a point to be raised in the security considerations section of the 
document.  It is quite reasonable to document both methods of using RSA, 
then warn people that a different key pair should be used with each one.

Russ

At 01:03 AM 5/25/2002 +0200, Bodo Moeller wrote:

>Housley, Russ <[e-mail]>:
>
> >>> Here is the next draft of the proposed working group charter.  The
> >>> biggest change from the previous posting is that both OAEP and KEM 
> become
> >>> standards track documents.
>
> >> Are the differences between the attacks and mitigations presented by OAEP
> >> and KEM really worth the high liklihood of lack of interoperability?
>
> > RSA using PKCS#1_v1.5, OAEP, and KEM all employ the same certificate, so
> > this choice does not require any adjustments in the PKI.
>
>This makes it is pretty pointless to use "provably secure"
>cryptography, though -- all security guarantees that OAEP, say, may
>promise are voided if you use the same key for decrypting messages
>using some other style of RSA.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ON4ue28681 for ietf-smime-bks; Fri, 24 May 2002 16:04:56 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ON4tL28677 for <[e-mail]>; Fri, 24 May 2002 16:04:55 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 003C82CBC; Sat, 25 May 2002 01:04:56 +0200 (MET DST)
Received: id <m17BO5T-000QdtC@epsilon>; Sat, 25 May 2002 01:03:07 +0200 (CEST) 
Message-Id: <m17BO5T-000QdtC@epsilon>
Date: Sat, 25 May 2002 01:03:07 +0200 (CEST)
To: [e-mail]
Reply-To: [e-mail], [e-mail]
From: [e-mail] (Bodo Moeller)
Subject: Re: Next Draft of Proposed Charter
In-Reply-To: <[e-mail]>
References: <p0511171bb901e26f1a10@[165.227.249.18]> <[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>

Housley, Russ <[e-mail]>:

>>> Here is the next draft of the proposed working group charter.  The 
>>> biggest change from the previous posting is that both OAEP and KEM become 
>>> standards track documents.

>> Are the differences between the attacks and mitigations presented by OAEP 
>> and KEM really worth the high liklihood of lack of interoperability?

> RSA using PKCS#1_v1.5, OAEP, and KEM all employ the same certificate, so 
> this choice does not require any adjustments in the PKI.

This makes it is pretty pointless to use "provably secure"
cryptography, though -- all security guarantees that OAEP, say, may
promise are voided if you use the same key for decrypting messages
using some other style of RSA.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OD9if10119 for ietf-smime-bks; Fri, 24 May 2002 06:09:44 -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 g4OD9gL10114 for <[e-mail]>; Fri, 24 May 2002 06:09:42 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 May 2002 13:07:52 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 JAA18912; Fri, 24 May 2002 09:09:38 -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 g4OD7kq11383; Fri, 24 May 2002 09:07:46 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLGLM8>; Fri, 24 May 2002 09:09:36 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLGLM5; Fri, 24 May 2002 09:09:31 -0400
From: "Housley, Russ" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>
Cc: Blake Ramsdell <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 24 May 2002 09:09:28 -0400
Subject: RE: Protecting fields via message/rfc822 and merging issues
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>

Chris:

See my comment at the end.

> > > >   Obviously, my belief is that (d) is the only one
> > that works.  However,
> > >I'm not happy with how it works in the encrypted-only
> > case.  I'm also
> > >somewhat sensitive to "attribute bloat".  I therefore
> > earnestly hope
> > >somebody else sees something that I've missed.
> > >
> > >[bcr] I think that the biggest problem I'm having is
> > that we're trying to
> > >mix authenticated / unauthenticated / encrypted /
> > unencrypted headers
> > >together and try to do the right thing in an
> > automated fashion.  As much as
> > >as we might like to define this, I think the only
> > option might be to take
> > >the coward's way out and explain that the
> > presentation and merging of the
> > >headers are the problem of the client, and that it's
> > not possible to
> > >automatically mix them.  The realization that I'm
> > coming to is that there is
> > >no utility in merging the headers, and we shouldn't
> > even attempt it, and we
> > >should document that the client needs to potentially
> > make decisions about
> > >how much to trust the internal headers vs. the
> > external headers, and it is
> > >their responsibility to demonstrate the separation.
> > >
> > >[bcr] My thinking right now is along the lines of the
> > following, and I could
> > >very well be missing some important issues:
> > >
> > >1. Use message/rfc822 with a full set of headers for
> > the inner protected
> > >content.  This is backward compatible, and it's
> > entirely possible that
> > >existing clients might even process this correctly.
> > >
> > >2. Define placebo values for any outer message
> > required fields.
> > >
> > >3. Explain the client considerations for presentation.
> >
> > [RH] I would like to see a very simple approach.  The
> > sender MUST put the
> > same values in both the 822 header and the inner protected
> > header.  Whenever possible, the recipient SHOULD
> > display the values from
> > the inner protected header.  We need to explain the
> > cases where this will
> > be difficult and the ones from the outer unprotected
> > header need to be used.
> >
>[CDB] I think that some minor complexity is necessary if the solution is 
>to apply equally to SignedData and EnvelopedData (which I thought was the 
>one of the reasons for this approach).  Having the same values in the 
>outer and inner header precludes the latter.  Given that you are therefore 
>going to HAVE to merge inner and outer for some cases, I think that use of 
>"dummy" values on the outside makes sense if we're only going to have one 
>way of doing things.

[RH] You are correct.  We need to consider the ContentHints attribute 
defined in ESS too.  The original point of this attribute was to provide a 
plaintext subject line.  So, we need to provide guidance about the handling 
of the plaintext 822 subject line, the ciphertext 822 subject line, and the 
ContentHints attribute if all three are present.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NN9FX17103 for ietf-smime-bks; Thu, 23 May 2002 16:09:15 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NN9DL17099 for <[e-mail]>; Thu, 23 May 2002 16:09:13 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g4NN9FE16370; Thu, 23 May 2002 16:09:15 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3114 on Implementing Company Classification Policy
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Thu, 23 May 2002 16:09:15 -0700
From: RFC Editor <[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>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3114

        Title:	    Implementing Company Classification Policy with
                    the S/MIME Security Label
        Author(s):  W. Nicolls
        Status:	    Informational
	Date:       May 2002
        Mailbox:    [e-mail]
        Pages:      14
        Characters: 27764
        Updates/Obsoletes/SeeAlso:  None

        I-D Tag:    draft-ietf-smime-seclabel-03.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3114.txt


This document discusses how company security policy for data
classification can be mapped to the S/MIME security label.  Actual
policies from three companies provide worked examples.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3114

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3114.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.6/8.11.3) id g4NMpiU16790 for ietf-smime-bks; Thu, 23 May 2002 15:51:44 -0700 (PDT)
Received: from Obsidian (pcp01965971pcs.nrockv01.md.comcast.net [68.48.109.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NMphL16786 for <[e-mail]>; Thu, 23 May 2002 15:51:43 -0700 (PDT)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Thu, 23 May 2002 18:51:44 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "Blake Ramsdell" <[e-mail]>, <[e-mail]>
Subject: RE: Protecting fields via message/rfc822 and merging issues
Date: Thu, 23 May 2002 18:51:42 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NMphL16787
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>

Russ,

Some new comments embedded, preceded by [CDB].

Best regards,
Chris



> [RH] I think that message/rfc822 should be the 
> mandatory to implement 
> approach.  If we want to explore message/partial, it 
> should not be 
> mandatory to implement.

[CDB] I agree with this suggestion.


> > >   Obviously, my belief is that (d) is the only one 
> that works.  However,
> >I'm not happy with how it works in the encrypted-only 
> case.  I'm also
> >somewhat sensitive to "attribute bloat".  I therefore 
> earnestly hope
> >somebody else sees something that I've missed.
> >
> >[bcr] I think that the biggest problem I'm having is 
> that we're trying to
> >mix authenticated / unauthenticated / encrypted / 
> unencrypted headers
> >together and try to do the right thing in an 
> automated fashion.  As much as
> >as we might like to define this, I think the only 
> option might be to take
> >the coward's way out and explain that the 
> presentation and merging of the
> >headers are the problem of the client, and that it's 
> not possible to
> >automatically mix them.  The realization that I'm 
> coming to is that there is
> >no utility in merging the headers, and we shouldn't 
> even attempt it, and we
> >should document that the client needs to potentially 
> make decisions about
> >how much to trust the internal headers vs. the 
> external headers, and it is
> >their responsibility to demonstrate the separation.
> >
> >[bcr] My thinking right now is along the lines of the 
> following, and I could
> >very well be missing some important issues:
> >
> >1. Use message/rfc822 with a full set of headers for 
> the inner protected
> >content.  This is backward compatible, and it's 
> entirely possible that
> >existing clients might even process this correctly.
> >
> >2. Define placebo values for any outer message 
> required fields.
> >
> >3. Explain the client considerations for presentation.
> 
> [RH] I would like to see a very simple approach.  The 
> sender MUST put the 
> same values in both the 822 header and the inner protected 
> header.  Whenever possible, the recipient SHOULD 
> display the values from 
> the inner protected header.  We need to explain the 
> cases where this will 
> be difficult and the ones from the outer unprotected 
> header need to be used.
> 
[CDB] I think that some minor complexity is necessary if the solution is to apply equally to SignedData and EnvelopedData (which I thought was the one of the reasons for this approach).  Having the same values in the outer and inner header precludes the latter.  Given that you are therefore going to HAVE to merge inner and outer for some cases, I think that use of "dummy" values on the outside makes sense if we're only going to have one way of doing things.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MCtQm06659 for ietf-smime-bks; Wed, 22 May 2002 05:55:26 -0700 (PDT)
Received: from ns0.eris.dera.gov.uk ([e-mail] [128.98.1.1]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4MCtNL06648 for <[e-mail]>; Wed, 22 May 2002 05:55:24 -0700 (PDT)
Received: (qmail 2118 invoked from network); 22 May 2002 13:56:50 -0000
Received: from mailhost.eris.dera.gov.uk (qmailr@128.98.2.2) by ens0.eris.dera.gov.uk with SMTP; 22 May 2002 13:56:50 -0000
Received: (qmail 28650 invoked by uid 2853); 22 May 2002 12:54:36 -0000
Received: from unknown (HELO WOTTAWAY) (128.98.10.192) by mailhost.eris.dera.gov.uk with SMTP; 22 May 2002 12:54:34 -0000
From: "William Ottaway" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Subject: Comments on RFC2633bis
Date: Wed, 22 May 2002 14:01:49 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
X-Virus-Scanned: by internal AMaViS perl-11
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>

Hi Blake,

I have provided some comments on the X400wrap draft which relate to text
that is aligned with RFC 2633 and have therefore been asked to raise these
points with you.

1) Section 2.5, last paragraph. I understand where you are coming from but
the majority of S/MIME client users will not understand what the values in a
signed attribute mean, let alone which ones are listed in 2633, and probably
don't care. My general feeling is don't show the user this information. This
may have some impact legally (e.g. you can't sue me because I didn't know I
was signing/sending that). This is really a local issue. Perhaps rather than
stating this as a 'SHOULD' maybe a comment that it is advised
implementations support this feature, which can be turned on/off.

2) Section 3.3, 3.4.2 and 3.6. In the steps on constructing the different
types of message you don't mention applying a transfer encoding. This is
mentioned in the steps in section 3.4.3.2. I suggest that Step 3 in 3.3 and
3.4.2 and step 2 in 3.6 are changed to :-

"Transfer encoding is applied to the CMS object and it is inserted into an
application/pkcs7-mime MIME entity."



While I'm at it we had a discussion on the s/mime list back in Feb/Mar 2001
on another matter that raised its head whilst reviewing the X.400 drafts.
This was related to the 'certs only' message. This accumulated in me
suggesting the following text for section 3.6 (Thu, 1 Mar 2001
09:10:33 -0000).

"3.6 Creating a Certificate Management Message

The certificate management message or MIME entity is used to transport
certificates and/or CRLs, such as in response to a registration request.

   Step 1. The certificates and/or CRLs are made available to the CMS
generating
           process which creates a CMS object of type signedData. The
signedData
           encapContentInfo eContent field MUST be absent and signerInfos
field
           MUST be empty.

   Step 2. The CMS signedData object is enclosed in an
application/pkcs7-mime MIME entity

The smime-type parameter for a certificate management message is
"cert-management".
The file extension for this type of message is ".p7c"."

Of course step 2 would now be "Transfer encoding is applied to the CMS
object and it is inserted into an application/pkcs7-mime MIME entity."

Your reply (Thu, 1 Mar 2001 09:50:25 -0800) was "Sounds good -- we'll
rewrite it at some point."

Bill

____________________________________________________
 William Ottaway BSc Hons CEng MBCS,
 Woodward B009,
 QinetiQ                      Tel: [phone]
 Malvern Technology Centre,   Fax: [phone]
 St. Andrews Road,            email: [e-mail]
 Malvern,
 Worcs,
 WR14 3PS

 All opinions are my own.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4GG0CQ15031 for ietf-smime-bks; Thu, 16 May 2002 09:00:12 -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 g4GG09L15016 for <[e-mail]>; Thu, 16 May 2002 09:00:09 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 May 2002 15:58:28 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 MAA08946; Thu, 16 May 2002 12:00:08 -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 g4GFwHr25408; Thu, 16 May 2002 11:58:18 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLC6D3>; Thu, 16 May 2002 12:00:07 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.68]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLC6D1; Thu, 16 May 2002 11:59:57 -0400
From: "Housley, Russ" <[e-mail]>
To: "Bonatti, Chris" <[e-mail]>, Blake Ramsdell <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 16 May 2002 11:35:51 -0400
Subject: Re: Protecting fields via message/rfc822 and merging issues
In-Reply-To: <0c0901c1f011$8131cf40$[e-mail]>
References: <[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>

Chris & Blake:

My comments below, prefixed by [RH]...

To jog your memory, Chris made the original posting.
Blake replied with his comments prefixed with [bcr].

> >   The first part of the solution seems like a done deal.  I would note
>that we should be able to omit the "orig-date" and "from" fields (required
>by RFC 2822) from the inner message if we use the message/partial type vs
>message/rfc822 in the protected MIME object.  However, I think it would be
>wise if we simply allowed either type in this case.  I think that support
>for message/rfc822 is widespread, perhaps almost universal.  However, the
>level of support for message/partial is unknown (to me anyway).  Also, use
>of message/partial in this way isn't *exactly* for the reasons that RFC2046
>describes its use.  Since Ned suggested it, I would guess he thinks it is,
>though.
>
>[bcr] One way to think about message/partial is that this header privacy
>issue represents a new S/MIME idiom, and thus you need to write a bunch of
>code anyway to handle it.  The argument against message/partial would be
>that applications are using a separate MIME library which would choke on
>message/partial if it didn't already support it, and older clients that are
>unaware of this use might fail completely to process the message.  I would
>be more in favor of exploring message/rfc822, since I'm fairly certain that
>most GUI implementations just pop up a new message window.  This has the
>added benefit of automatically providing compartementalization of the
>protected headers, since those will be attributes of the new window.

[RH] I think that message/rfc822 should be the mandatory to implement 
approach.  If we want to explore message/partial, it should not be 
mandatory to implement.

> >    b) Discarding the outer 822 message and looking only at the
> > inner fields works provided that the inner message is
> > complete.  However, it does not work if only a partial
> > list of fields is included in the inner message.  Also,
> > since we negate the usefulness of the outer message in
> > all cases, we strongly encourage that it be a blank
> > "dummy" message.  This would effectively require the
> > application to do security processing even to display
> > the originator, subject line, etc. -- fields normally
> > shown in a mailbox view.  Blake also correctly pointed
> > out that this would squash useful headers like "trace"
> > (i.e., Received:...) and things added by list exploders.
>
>[bcr] Right, and I think this also includes header security policies (not
>necessarily cryptography, but generic rewriting) applied by the organization
>such as rewritten address lines for host name hiding or adding disclosed
>recipients.  I think this is where we start running into a problem, and
>where we're in danger of failing.
>
> >   Of these, I think I favor (c).  However, regardless of which option we
>choose, we should say something about using dummy values of the "orig-date"
>and "from" fields in the event that the originator wants to protect the
>confidentiality of that information.  Since these elements are required in
>an 822 message, some dummy value MUST be provided in the outer message.  I
>don't think we need to necessarily specify what these values should be, but
>we should say something about the need for them.
>
>[bcr] I agree -- I think this is going to be part of any work that we
>pursue.
>
> >   Obviously, my belief is that (d) is the only one that works.  However,
>I'm not happy with how it works in the encrypted-only case.  I'm also
>somewhat sensitive to "attribute bloat".  I therefore earnestly hope
>somebody else sees something that I've missed.
>
>[bcr] I think that the biggest problem I'm having is that we're trying to
>mix authenticated / unauthenticated / encrypted / unencrypted headers
>together and try to do the right thing in an automated fashion.  As much as
>as we might like to define this, I think the only option might be to take
>the coward's way out and explain that the presentation and merging of the
>headers are the problem of the client, and that it's not possible to
>automatically mix them.  The realization that I'm coming to is that there is
>no utility in merging the headers, and we shouldn't even attempt it, and we
>should document that the client needs to potentially make decisions about
>how much to trust the internal headers vs. the external headers, and it is
>their responsibility to demonstrate the separation.
>
>[bcr] My thinking right now is along the lines of the following, and I could
>very well be missing some important issues:
>
>1. Use message/rfc822 with a full set of headers for the inner protected
>content.  This is backward compatible, and it's entirely possible that
>existing clients might even process this correctly.
>
>2. Define placebo values for any outer message required fields.
>
>3. Explain the client considerations for presentation.

[RH] I would like to see a very simple approach.  The sender MUST put the 
same values in both the 822 header and the inner protected 
header.  Whenever possible, the recipient SHOULD display the values from 
the inner protected header.  We need to explain the cases where this will 
be difficult and the ones from the outer unprotected header need to be used.

Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FEPrP25217 for ietf-smime-bks; Wed, 15 May 2002 07:25:53 -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 g4FEPpL25206 for <[e-mail]>; Wed, 15 May 2002 07:25:51 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 May 2002 14:24:11 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 KAA23956; Wed, 15 May 2002 10:25:52 -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 g4FEO0f13700; Wed, 15 May 2002 10:24:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLCJJ5>; Wed, 15 May 2002 10:25:50 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.50]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLCJJ4; Wed, 15 May 2002 10:25:45 -0400
From: "Housley, Russ" <[e-mail]>
To: Ben Littauer <[e-mail]>, Craig McGregor <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 May 2002 10:18:30 -0400
Subject: RE: Are certificates _required_ by the sender?
In-Reply-To: <[e-mail] ury.govt.nz>
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>

Ben & Craig:

This is appropriate behavior.  RFC 2633, in section 3.3, says:

    ...  In addition to encrypting a copy of
    the content-encryption key for each recipient, a copy of the content
    encryption key SHOULD be encrypted for the originator and included in
    the envelopedData (see CMS Section 6).

Russ


At 09:41 AM 5/9/2002 +1200, Craig McGregor wrote:

>Hi Ben,
>
>Although I have not tested this theory, I suspect it is so that it can
>encrypt the message both for the recipient and sender. Otherwise the
>sender could not read their message from their sent items folder without
>access to the recipients private key - which of course is a no-no!
>
>Nothing in the S/MIME RFC's says you _have_ to have one. You should be
>able to happily encrypt but not sign e-mail without one. Practicalities
>mean for certain functionality in clients it may be necessary to have
>your own certificate.
>
>--
>Craig McGregor
>Security Specialist
>IT Systems                      http://e.govt.nz/see/mail
>The Treasury            http://www.treasury.govt.nz
>
>
>
>
>-----Original Message-----
>From: Ben Littauer [mailto:[e-mail]]
>Sent: Thursday, 9 May 2002 4:08 a.m.
>To: [e-mail]
>Subject: RE: Are certificates _required_ by the sender?
>
>
>
>Interesting you should ask this right now.  I don't believe that there
>is
>any S/MIME requirement that says that the sender needs a cert.  That
>said,
>however, MS Outlook DOES require that you have a cert before it will let
>you
>encrypt a message on someone else's cert that you've received.  Does
>anyone
>know why this is?
>
>-ben-
>
>-----Original Message-----
>From: [e-mail]
>[mailto:[e-mail]]On Behalf Of Terje Tollisen
>Sent: Wednesday, May 08, 2002 5:26
>To: [e-mail]
>Subject: Are certificates _required_ by the sender?
>
>
>
>Is the sender of an email required to have a certificate, or is it
>sufficient for the sender to have a copy of the certificate of the
>recipient? I am thinking of an automated system, where one party will
>always
>be the sender, and never receive emails. In addition, no signatures are
>required. Thus nobody will ever actually need the public key for the
>automated system. However, I'm uncertain if the sender can send S/MIME
>messages without having a certificate of it's own.
>
>Thanks for your time
>-Terry Tollisen
>
>--
>_______________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FE76S23811 for ietf-smime-bks; Wed, 15 May 2002 07:07:06 -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 g4FE74L23802 for <[e-mail]>; Wed, 15 May 2002 07:07:04 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 May 2002 14:05:24 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 KAA21830 for <[e-mail]>; Wed, 15 May 2002 10:07:05 -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 g4FE5DJ11112 for <[e-mail]>; Wed, 15 May 2002 10:05:13 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLC29H>; Wed, 15 May 2002 10:07:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.50]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLC29F; Wed, 15 May 2002 10:07:01 -0400
From: "Housley, Russ" <[e-mail]>
To: Terje Tollisen <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 15 May 2002 10:06:58 -0400
Subject: Re: Are certificates _required_ by the sender?
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>

Terry:

To sign a message, the originator needs to have a certificate that contains 
the public key that will be used by the recipient to validate the signature.

To encrypt a message, the originator need not have a certificate; however, 
the recipient will generally not be able to authenticate the source of the 
message unless it is signed.

Russ

At 04:26 AM 5/8/2002 -0500, Terje Tollisen wrote:

>Is the sender of an email required to have a certificate, or is it 
>sufficient for the sender to have a copy of the certificate of the 
>recipient? I am thinking of an automated system, where one party will 
>always be the sender, and never receive emails. In addition, no signatures 
>are required. Thus nobody will ever actually need the public key for the 
>automated system. However, I'm uncertain if the sender can send S/MIME 
>messages without having a certificate of it's own.
>
>Thanks for your time
>-Terry Tollisen
>
>--
>_______________________________________________
>Sign-up for your own FREE Personalized E-mail at Mail.com
>http://www.mail.com/?sr=signup


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4FCJwC18823 for ietf-smime-bks; Wed, 15 May 2002 05:19:58 -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 g4FCJuL18819 for <[e-mail]>; Wed, 15 May 2002 05:19:56 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 May 2002 12:18:16 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 IAA11118; Wed, 15 May 2002 08:19:56 -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 g4FCI3e27972; Wed, 15 May 2002 08:18:03 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLCHFC>; Wed, 15 May 2002 08:19:52 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.64]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLCH19; Wed, 15 May 2002 08:19:47 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 14 May 2002 18:04:54 -0400
Subject: Proposed Charter Update for S/MIME
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_1791115==_"
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>

--=====================_1791115==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Jeff & Steve:

As you probably know, the S/MIME WG charter is out of date.  After much 
discussion on the WG mail list, no one seems to object to this proposed 
update.  Please let us know if it is acceptable to you.

Russ






--=====================_1791115==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Charter4.txt"


S/MIME Mail Security (smime)

Chair:
     Russ Housley <[e-mail]>

Security Area Director:
     Jeffrey Schiller <[e-mail]>
     Steve Belovin <[e-mail]>

Mailing Lists:
     General Discussion: [e-mail]
     To Subscribe:       [e-mail]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed  
Standards that comprise the S/MIME version 3 specification.   
Current efforts update and build upon these base specifications.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any 
algorithm.  To ensure interoperability, each algorithm should have
a specification that describes its use with CMS.  Specifications 
for the use of additional cryptographic algorithms will be 
developed.

As part of the specification update, a new suite of "mandatory 
to implement" algorithms will be selected.  These algorithms will
be reflected in updates to RFC 2632 and RFC 2633.

To aid implementers, documents containing example output for CMS
will be collected and published.  Some of the examples will include
structures and signed attributes defined in the Enhanced Security
Services (ESS) document.

In some situations it would be advantageous for the CMS RecipientInfo 
structure to support additional key management techniques, including 
cryptographic keys derived from passwords.  Also, a mechanism to 
facilitate the definition of additional key management techniques
will be defined.

Compressing data prior to encryption or signature has a number of 
advantages.  Compression improves security by removing known data 
patterns, improves throughput by reducing the amount of data which
needs to be encrypted or hashed, and reduces the overall message 
size.  Enabling S/MIME version 3 to use compression will provide 
all of these advantages.

S/MIME version 3 permits the use of previously distributed 
symmetric key-encryption keys.  Specifications for the distribution
of symmetric key-encryption keys to multiple message recipients 
will be developed.  Mail List Agents (MLAs) are one user of 
symmetric key-encryption keys.  The specification will be algorithm 
independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large organizations 
will be used as examples.

As part of S/MIME version 3, CMS is used to provide security 
to the message content.  CMS can also be employed in an X.400
electronic messaging envionments.  Specifications will be 
developed allowing this to be done in an interoperable manner.

Perform necessary interoperability testing to progress the S/MIME
version 3 specifications to Draft Standard.  Due to the dependency
of the CMS specification on the PKIX certificate and CRL profile,
the timeline for the actual progression is impossible to estimate.


Goals and Milestones:

History:
     Submit CMS compressed data content type a Proposed Standard.
     Submit security label usage specification as Informational RFC.
     Submit elliptic curve algorithm specification as Informational RFC.
     Submit mail list key distribution as a Proposed Standard.
     Submit update to RFC 2630 as a Proposed Standard.
     Submit AES key wrap algorithm description as Informational RFC.
     Last call on X.400 CMS wrapper specification.
     Last call on X.400 transport specification.
     Last call on HMAC key wrap description specification.
     First draft of CMS and ESS examples document.
     First draft of RSA OAEP algorithm specification.
     First draft of AES algorithm specification.
     First draft of update to RFC 2632.
     Frist draft of update to RFC 2633.

May 2002:
     Submit X.400 CMS wrapper specification as a Proposed Standard.
     Submit X.400 transport as a Proposed Standard.
     Submit HMAC key wrap description as an Informational RFC.

June 2002:
     Last call on CMS and ESS examples document.

July 2002:
     First draft of RSA PSS algorithm specification.
     Last call on update to RFC 2632.
     Last call on update to RFC 2633.
     Last call on AES algorithm specification.
     Last call on RSA OAEP algorithm specification.

August 2002:
     First draft of RSA KEM algorithm specification.
     Submit CMS and ESS examples document as Informational RFC.

October 2002:
     Last call on RSA PSS algorithm specification.
     Sumbit update to RFC 2632 as Proposed Standard.
     Sumbit update to RFC 2633 as Proposed Standard.

November 2002:
     Last call on RSA KEM algorithm specification.

December 2002:
     Sumbit AES algorithm specification as Proposed Standard.
     Submit RSA OAEP algorithm specification as Proposed Standard.

January 2003:
     Submit RSA PSS algorithm specification as Proposed Standard.

February 2003:
     Submit RSA KEM algorithm specification as Proposed Standard.

--=====================_1791115==_--


Received: by above.proper.com (8.11.6/8.11.3) id g4DIrdx22392 for ietf-smime-bks; Mon, 13 May 2002 11:53:39 -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 g4DIrcL22388 for <[e-mail]>; Mon, 13 May 2002 11:53:38 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 13 May 2002 11:53:37 -0700
Message-ID: <035601c1faae$edd61b90$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: AES and OAEP tying
Date: Mon, 13 May 2002 11:49:36 -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>

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, May 13, 2002 7:13 AM
Subject: Re: AES and OAEP tying


> Jim Schaad and I have already started the process to separate AES and
> OAEP.  Actually, they started out in two separate drafts, and were later
> combined.  We are going back to the original approach.

Thanks for the information.

I still would like to see that the explicit ban on PKCS #1 v1.5 with AES be
removed also.

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4DETE113813 for ietf-smime-bks; Mon, 13 May 2002 07:29:14 -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 g4DETCL13808 for <[e-mail]>; Mon, 13 May 2002 07:29:12 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 May 2002 14:27:34 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 KAA28082 for <[e-mail]>; Mon, 13 May 2002 10:29:13 -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 g4DERNv29476 for <[e-mail]>; Mon, 13 May 2002 10:27:23 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLBH9S>; Mon, 13 May 2002 10:29:11 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLBH92; Mon, 13 May 2002 10:29:03 -0400
From: "Housley, Russ" <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 May 2002 10:13:27 -0400
Subject: Re: AES and OAEP tying
In-Reply-To: <031a01c1fa60$6fd810c0$[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>

Blake:

Jim Schaad and I have already started the process to separate AES and 
OAEP.  Actually, they started out in two separate drafts, and were later 
combined.  We are going back to the original approach.

Russ

At 02:27 AM 5/13/2002 -0700, Blake Ramsdell wrote:

> From what I can tell, the AES symmetric algorithm and the OAEP key wrapping
>mechanism are being discussed in the same draft.  This is unprecedented as
>far as I can tell -- traditionally we have specified each algorithm in its
>own draft, and it does not seem useful to combine these two algorithms for
>technical reasons.  From what I can tell, this happened between -01
>(3/26/01) and -02 (7/19/01) of draft-ietf-smime-aes-alg.  I have reviewed
>the minutes from the relevant WG minutes, and did not see any significant
>discussion about this pairing -- it just happened at one point.
>
>I guess this is a rhetorical way of saying "It seems that the intent is to
>drag OAEP into the mainstream, and by precluding the use of RSA-PKCS with
>AES, we effectively block the future use of RSA-PKCS if anyone chooses to
>use AES".  Am I missing something?  I know that it's disclaimed in the
>overview that these are separate concepts, but I'm not sure of any editorial
>or technical value of their combination in a single draft.
>
>I personally recommend that OAEP be (re-) separated completely from the AES
>draft.  This seems to make things clearer in the event that an even newer,
>shinier and better symmetric key wrapping mechanism should come along.
>Well, speak of the devil...  ;)  But seriously -- I can't see any good
>editorial or technical reason to tie these mechanisms together.
>
>Also, I recommend that the prohibition of RSA-PKCS be removed for AES.  That
>also does not seem to follow the spirit of algorithm profiles for CMS.  We
>have already covered the concerns of RSA-PKCS extensively.
>
>I may have missed an earlier discussion of this very issue, but I can't find
>it in the archives.  Clarifications welcome, but I don't think this is the
>right way to proceed with these two separate mechanisms, and the current
>document is confusing to me.  Sorry I didn't bring this up earlier, but I
>seem to be paying a little bit of attention now.
>
>(closes bunker door, hiding inside)
>
>Blake
>--
>Blake Ramsdell
>Brute Squad Labs http://www.brutesquadlabs.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4DDqqK13186 for ietf-smime-bks; Mon, 13 May 2002 06:52:52 -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 g4DDqoL13182 for <[e-mail]>; Mon, 13 May 2002 06:52:50 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 13 May 2002 13:51:12 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 JAA23528 for <[e-mail]>; Mon, 13 May 2002 09:52:27 -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 g4DDobO24105 for <[e-mail]>; Mon, 13 May 2002 09:50:37 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZLBHGG>; Mon, 13 May 2002 09:52:26 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.71]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLBHGC; Mon, 13 May 2002 09:52:22 -0400
From: "Housley, Russ" <[e-mail]>
To: Paul Hoffman / IMC <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 13 May 2002 09:49:27 -0400
Subject: Re: Next Draft of Proposed Charter
In-Reply-To: <p0511171bb901e26f1a10@[165.227.249.18]>
References: < <[e-mail]> <[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>

Paul:

As I see it, we will document the way that these algorithms are 
used.  Then, if at some point in the future, the working group wants to 
change the mandatory to implement key management algorithm, the algorithm 
specification will be done, and there may even be widely deployed.

RSA using PKCS#1_v1.5, OAEP, and KEM all employ the same certificate, so 
this choice does not require any adjustments in the PKI.

Russ

At 01:49 PM 5/10/2002 -0700, Paul Hoffman / IMC wrote:

>At 1:49 PM -0400 5/10/02, Housley, Russ wrote:
>>Here is the next draft of the proposed working group charter.  The 
>>biggest change from the previous posting is that both OAEP and KEM become 
>>standards track documents.
>
>And in what way would that help us get interoperable implementations of 
>S/MIME?
>
>Are the differences between the attacks and mitigations presented by OAEP 
>and KEM really worth the high liklihood of lack of interoperability?
>
>--Paul Hoffman, Director
>--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g4D9VGJ24382 for ietf-smime-bks; Mon, 13 May 2002 02:31: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 g4D9VGL24378 for <[e-mail]>; Mon, 13 May 2002 02:31:16 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 13 May 2002 02:31:15 -0700
Message-ID: <031a01c1fa60$6fd810c0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: AES and OAEP tying
Date: Mon, 13 May 2002 02:27:44 -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>

>From what I can tell, the AES symmetric algorithm and the OAEP key wrapping
mechanism are being discussed in the same draft.  This is unprecedented as
far as I can tell -- traditionally we have specified each algorithm in its
own draft, and it does not seem useful to combine these two algorithms for
technical reasons.  From what I can tell, this happened between -01
(3/26/01) and -02 (7/19/01) of draft-ietf-smime-aes-alg.  I have reviewed
the minutes from the relevant WG minutes, and did not see any significant
discussion about this pairing -- it just happened at one point.

I guess this is a rhetorical way of saying "It seems that the intent is to
drag OAEP into the mainstream, and by precluding the use of RSA-PKCS with
AES, we effectively block the future use of RSA-PKCS if anyone chooses to
use AES".  Am I missing something?  I know that it's disclaimed in the
overview that these are separate concepts, but I'm not sure of any editorial
or technical value of their combination in a single draft.

I personally recommend that OAEP be (re-) separated completely from the AES
draft.  This seems to make things clearer in the event that an even newer,
shinier and better symmetric key wrapping mechanism should come along.
Well, speak of the devil...  ;)  But seriously -- I can't see any good
editorial or technical reason to tie these mechanisms together.

Also, I recommend that the prohibition of RSA-PKCS be removed for AES.  That
also does not seem to follow the spirit of algorithm profiles for CMS.  We
have already covered the concerns of RSA-PKCS extensively.

I may have missed an earlier discussion of this very issue, but I can't find
it in the archives.  Clarifications welcome, but I don't think this is the
right way to proceed with these two separate mechanisms, and the current
document is confusing to me.  Sorry I didn't bring this up earlier, but I
seem to be paying a little bit of attention now.

(closes bunker door, hiding inside)

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com



Received: by above.proper.com (8.11.6/8.11.3) id g4D8QsK19990 for ietf-smime-bks; Mon, 13 May 2002 01:26: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 g4D8QsL19984 for <[e-mail]>; Mon, 13 May 2002 01:26:54 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Mon, 13 May 2002 01:26:52 -0700
Message-ID: <031201c1fa56$aca524c0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: KEM, OAEP, CMS and S/MIME
Date: Mon, 13 May 2002 01:17:51 -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>

In light of these recent discussions about KEM vs. OAEP, I want to make sure
we're all on the same page.  ECC, KEM, OAEP, AES, IDEA, CAST-128, ECC,
SHA-256/384/512, etc. etc. are all soon-to-be drafts, drafts and RFCs that
explain how you might use these algorithms and techniques with CMS.

I think there have been two primary questions raised -- "OAEP is sufficient,
why do I need KEM", and "I'm concerned about what this means for the S/MIME
profile of CMS".

As far as the first one goes, there seem to be lots of "redundant" methods
specified for CMS (ECC, Diffie-Hellman, RSA-PKCS for key wrapping, IDEA and
CAST-128 for symmetric algorithms).  Each one has some set of
differentiators that make it more appropriate to use one algorithm over
another in a particular scenario.  OAEP and KEM are in that category also.
The way I see it, we can specify lots and lots of ways to do things with
CMS, and it doesn't really matter one way or another -- this process
embodies those methods in a specification so that you implement your version
the same way as everyone else, and everything's fine.

Is the concern that faced with all of these options, which one should I
pick?  If that's the case, then we're already in that situation with
symmetric algorithms.  Profile writers had better know what they're doing
when the make a profile of CMS that uses one or the other.

Is the concern that OAEP is going to be stillborn and KEM is going to
immediately replace it?  That seems pretty likely, based on the interest and
discussion about KEM.  Write both drafts, make them RFCs and see which one
wins in the new profiles that emerge.

As far as the bearing that all of this has on S/MIME, I think that the
concern is longer term.  Because of the relatively wide adoption of the
current flavors of S/MIME, I think we continue to be cautious about
modifying the profile significantly.  I'm not sure that any of these recent
discussions impact this, but I thought I'd reiterate it.  I share Paul's
concerns that significant changes to deployed profiles would be painful, and
I hope we continue to be conservative in that regard.

Blake
--
Blake Ramsdell
Brute Squad Labs http://www.brutesquadlabs.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4B9JON08993 for ietf-smime-bks; Sat, 11 May 2002 02:19:24 -0700 (PDT)
Received: from zcamail04.zca.compaq.com (zcamail04.zca.compaq.com [161.114.32.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4B9JNL08985 for <[e-mail]>; Sat, 11 May 2002 02:19:23 -0700 (PDT)
Received: from taynzmail03.nz-tay.cpqcorp.net (taynzmail03.nz-tay.cpqcorp.net [16.47.4.103]) by zcamail04.zca.compaq.com (Postfix) with ESMTP id E443A1444 for <[e-mail]>; Sat, 11 May 2002 02:23:38 -0700 (PDT)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by taynzmail03.nz-tay.cpqcorp.net (Postfix) with ESMTP id E6DAC15EA for <[e-mail]>; Sat, 11 May 2002 05:19:12 -0400 (EDT)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <JZMWRCDY>; Sat, 11 May 2002 14:42:14 +0530
Message-ID: <[e-mail]>
From: "Pradeep, PK" <[e-mail]>
To: [e-mail]
Subject: a query on example of PKCS#7 object
Date: Sat, 11 May 2002 14:55:58 +0530
Importance: high
X-Priority: 1
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
content-class: urn:content-classes:message
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F8CB.F0B86370"
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 in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1F8CB.F0B86370
Content-Type: text/plain;
	charset="iso-8859-1"

hi, 

I was going through the following example of Signed data with attributes. 

can someone tell me what the numbers and colon (:) in left side denotes... 

as per pkcs#7 document following is the defination of signed data. From this
definition it is not clear what the bumbers and colon(:) on left side
denote.

Will highly appreciate for your time to reply this query. 


thank you, 

pradeep 

9.1 SignedData type 


The signed-data content type shall have ASN.1 type SignedData:

SignedData ::= SEQUENCE {
  version Version,
  digestAlgorithms DigestAlgorithmIdentifiers,
  contentInfo ContentInfo,
  certificates
        [0] IMPLICIT ExtendedCertificatesAndCertificates
       OPTIONAL,
  crls
    [1] IMPLICIT CertificateRevocationLists OPTIONAL,
  signerInfos SignerInfos } 
DigestAlgorithmIdentifiers ::=
  SET OF DigestAlgorithmIdentifier 
SignerInfos ::= SET OF SignerInfo 

----------------------------------------------------------------------------
---------------- 

  

..... 
.......... 


------_=_NextPart_000_01C1F8CB.F0B86370
Content-Type: image/bmp;
	name="ole0.bmp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="ole0.bmp"
Content-Location: No%20AttachName

Qk0+rwAAAAAAAD4AAAAoAAAAagIAADACAAABAAEAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAA
AP///wD/////////////////////////////////////////////////////////////////////
/////////////////////////////////8AAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////wAAA////////
///////////////////////////////B////////7///////////////////////////////////
///////////////////AAAD//////w+P/4+H////B+PP//////////////9HA8fHAjPHA//f////
/////////////////////////////////////////////////8AAAP//////93f/d3v///9398//
/////////////zu7u7u7c7u7/9//////////////////////////////////////////////////
////wAAA///////79//3e////7/3////////////////+799u79rf7//3///////////////////
///////////////////////////////////AAAD//////4P3//d7////3wP////////////////7
r327r2t/r/+//////////////////////////////////////////////////////8AAAP//////
e8//z3v////vt8///////////////4ePfbuPW3+P/9//////////////////////////////////
////////////////////wAAA//////979//3e/////e3z///////////////f699u69bf6//3///
///////////////////////////////////////////////////AAAD//////3t3/3d7////d9f/
//////////////9zu7u7uzu7u//f////////////////////////////////////////////////
/////8AAAP//////h4//j4f///+P5////////////////4sDxxECMcMD/+//////////////////
////////////////////////////////////wAAA////////////////////////////////////
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////////////////////////////////////////////////////
/////////////////////8AAAP//////////////////////////////////////////////////
////////////////////////////////////////////////////wAAA////////////////////
////////////////////////////////////////////////////////////////////////////
///////AAAD/////////////////////////////////////////////////////////////////
/////////////////////////////////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
////////////////////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////D4f/hwf/////
g8///////////////4IzxwPHAx3/g///////////////////////////////////////////////
////////wAAA///////3e/97d//////vz///////////////73Pvu7u7u//v////////////////
///////////////////////////////////////AAAD///////t7/3u//////+//////////////
///va++/e7+3/+///////////////////////////////////////////////////////8AAAP//
////g3v/e9//////7////////////////+9r769xr4f/7///////////////////////////////
////////////////////////wAAA//////97e/977//////vz///////////////71vvj3+Pu//v
///////////////////////////////////////////////////////AAAD//////3t7/3v3////
/+/P///////////////vW++vf6+7/+//////////////////////////////////////////////
/////////8AAAP//////e3v/e3f/////j////////////////+87bbu7u7v/j///////////////
////////////////////////////////////////wAAA//////+Hh/+Hj//////v////////////
////gjEBA8MDB//v///////////////////////////////////////////////////////AAAD/
////////////////////////////////////////////////////////////////////////////
/////////////////////////8AAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////wAAA////////////////
////////////////////////////////////////////////////////////////////////////
///////////AAAD/////////////////////////////////////////////////////////////
/////////////////////////////////////////8AAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////wAAA
////////////////////////////////////////////////////////////////////////////
///////////////////////////AAAD/////////////////////////////////////////////
/////////////////////////////////////////////////////////8AAAP//////////////
/////////////////////8H////////v////////////////////////////////////////////
////////////wAAA//////+Hx/+Ph/+DB4Pvz////////////0cDx8cCM8cD/9//////////////
///////////////////////////////////////////AAAD//////3u7/3d7/+937+/P////////
////O7u7u7tzu7v/3////////////////////////////////////////////////////////8AA
AP//////e7v/93v/77/v7//////////////7v327v2t/v//f////////////////////////////
////////////////////////////wAAA//////97u//3e//v3+/3//////////////uvfbuva3+v
/7/////////////////////////////////////////////////////////AAAD//////4eH/897
/+/v7/fP////////////h499u49bf4//3///////////////////////////////////////////
/////////////8AAAP//////e7//93v/7/fv+8////////////9/r327r1t/r//f////////////
////////////////////////////////////////////wAAA//////973/93e/+Pd497////////
/////3O7u7u7O7u7/9/////////////////////////////////////////////////////////A
AAD//////4fj/4+H/++P7wP/////////////iwPHEQIxwwP/7///////////////////////////
/////////////////////////////8AAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////wAAA////////////
////////////////////////////////////////////////////////////////////////////
///////////////AAAD/////////////////////////////////////////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
wAAA////////////////////////////////////////////////////////////////////////
///////////////////////////////AAAD/////////////////////////////////////////
/////////////////////////////////////////////////////////////8AAAP//////////
////////////////////////////////////////////////////////////////////////////
////////////////wAAA////////////////////////////////////7///////////////////
///////////////////////////////////////////////AAAD//////4cH/4+D/4MHB4PP////
/////0cDx//f////////////////////////////////////////////////////////////////
/8AAAP//////e3f/d+//73d378//////////O7vv/9//////////////////////////////////
////////////////////////////////wAAA//////97v//37//vv7/v///////////7v+//3///
///////////////////////////////////////////////////////////////AAAD//////3vf
//fv/+/f3+////////////uv7/+/////////////////////////////////////////////////
/////////////////8AAAP//////h+//z+//7+/v78//////////h4/v/9//////////////////
////////////////////////////////////////////////wAAA//////979//37//v9/fvz///
//////9/r+//3///////////////////////////////////////////////////////////////
///AAAD//////3t3/3eP/493d4///////////3O7bf/f////////////////////////////////
/////////////////////////////////8AAAP//////h4//j+//74+P7///////////iwMB/+//
////////////////////////////////////////////////////////////////wAAA////////
////////////////////////////////////////////////////////////////////////////
///////////////////AAAD/////////////////////////////////////////////////////
/////////////////////////////////////////////////8AAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////////////////////////////////////
///////////////////////////////////AAAD/////////////////////////////////////
/////////////////////////////////////////////////////////////////8AAAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////wAAA////////////////////////////////////////////////////
///////////////////////////////////////////////////AAAD/////////////////////
////////////v///////////////////////////////////////////////////////////////
/////8AAAP///////////////////8/////////////f////////////////////////////////
////////////////////////////////////wAAA////////////////////z////////////9//
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////3///////////////////////////////////////////////
/////////////////////8AAAP/////////////////////////////////v////////////////
////////////////////////////////////////////////////wAAA////////////////////
z////////////9//////////////////////////////////////////////////////////////
///////AAAD////////////////////P////////////3///////////////////////////////
/////////////////////////////////////8AAAP/////////////////////////////////f
////////////////////////////////////////////////////////////////////wAAA////
/////////////////////////////7//////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////////////////////////////////////////////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
/////////////////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////wAAA////////////////////////////////////////////////
///////////////////////////////////////////////////////AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
/////////8AAAP///////////////////////////////////7//////////////////////////
////////////////////////////////////////wAAA////////////////////z///////////
////3//////////////////////////////////////////////////////////////////AAAD/
///////////////////P///////////////f////////////////////////////////////////
/////////////////////////8AAAP///////////////////////////////////9//////////
////////////////////////////////////////////////////////wAAA////////////////
////////////////////7///////////////////////////////////////////////////////
///////////AAAD////////////////////P///////////////f////////////////////////
/////////////////////////////////////////8AAAP///////////////////8//////////
/////9//////////////////////////////////////////////////////////////////wAAA
////////////////////////////////////3///////////////////////////////////////
///////////////////////////AAAD///////////////////////////////////+/////////
/////////////////////////////////////////////////////////8AAAP//////////////
////////////////////////////////////////////////////////////////////////////
////////////wAAA////////////////////////////////////////////////////////////
///////////////////////////////////////////AAAD/////////////////////////////
/////////////////////////////////////////////////////////////////////////8AA
AP//////////////////////////////////////////////////////////////////////////
////////////////////////////wAAA////////////////////////////////////////////
///////////////////////////////////////////////////////////AAAD/////////////
////////////////////////////////////////////////////////////////////////////
/////////////8AAAP//////////////////////////////////////////////////////////
////////////////////////////////////////////wAAA////////////////////////////
///////////////////////////////////////////////////////////////////////////A
AAD////////////////////P/////////////////++H/8fH/8eH/weH/8eP/8cf/8cD/+/j/8eH
/8cD/+/j/wcD/////////////////8AAAP///////////////////8//////////////////73v/
u7v/u3v/d3v/u3f/u7//u7v/7/f/u3v/u7v/7/f/d7v/////////////////wAAA////////////
///////////////////////////ve/+7f/+7+/+/e/+79/+7v/+7v//v9/+7+/+7v//v9/+/v///
///////////////AAAD///////////////////////////////////////d7/7t//7v7/997/7v3
/7uv/7uv//cD/7v7/7uv//cD/9+v/////////////////8AAAP///////////////////8//////
////////////93v/h3//h4f/73v/h8//h4//h4//97f/h4f/h4//97f/74//////////////////
wAAA////////////////////z//////////////////7e/+/f/+/v//3e/+/9/+/r/+/r//7t/+/
v/+/r//7t//3r//////////////////AAAD//////////////////////////////////////3t7
/9+7/9+//3d7/993/9+7/9+7/3vX/9+//9+7/3vX/3e7/////////////////8AAAP//////////
////////////////////////////A4f/48P/44P/j4f/44//4wP/4wP/A+f/44P/4wP/A+f/jwP/
////////////////wAAA////////////////////////////////////////////////////////
///////////////////////////////////////////////AAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
/8AAAP//////////////////////////////////////////////////////////////////////
////////////////////////////////wAAA////////////////////////////////////////
///////////////////////////////////////////////////////////////AAAD/////////
////////////////////////////////////////////////////////////////////////////
/////////////////8AAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////wAAA////////////////////////
////////////////////////////////////////////////////////////////////////////
///AAAD/////////////////////////////////////////////////////////////////////
/////////////////////////////////8AAAP///////////////////8//////////////////
h+P/x4f/xw//74//B4f/xw//74//B4f/74//xx//xw//x4f/B4f/74//x4P/xw//wAAA////////
////////////z/////////////////979/+7e/+79//vd/93e/+79//vd/93e//vd/+7v/+7t/+7
e/93e//vd/+77/+7t//AAAD///////////////////////////////////////v3/7t7/7v7/+/3
/797/7v7/+/3/797/+/3/7u//7u7/7v7/797/+/3/7vv/7u7/8AAAP//////////////////////
////////////////+wP/u3v/u4P/9/f/33v/u4P/9/f/33v/9/f/u6//u7v/u/v/33v/9/f/u+//
u7v/wAAA////////////////////z/////////////////+Ht/+Hh/+He//3z//ve/+He//3z//v
e//3z/+Hj/+Hu/+Hh//ve//3z/+H7/+Hu//AAAD////////////////////P////////////////
/7+3/797/797//v3//d7/797//v3//d7//v3/7+v/7+7/7+///d7//v3/7/v/7+7/8AAAP//////
////////////////////////////////v9f/33v/33v/e3f/d3v/33v/e3f/d3v/e3f/37v/37f/
37//d3v/e3f/34//37f/wAAA//////////////////////////////////////+D5//jh//jh/8D
j/+Ph//jh/8Dj/+Ph/8Dj//jA//jD//jg/+Ph/8Dj//j7//jD//AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////////////////////////////////////
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////////////////////////////////////////////////////
/////////////////////8AAAP//////////////////////////////////////////////////
////////////////////////////////////////////////////wAAA////////////////////
////////////////////////////////////////////////////////////////////////////
///////AAAD/////////////////////////////////////////////////////////////////
/////////////////////////////////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
//+HB/+H4////weHz///////////////x8fHA8f/R8cdgjPH////////////////////////////
///////////////////////AAAD//////3t3/3v3////d3vP//////////////+7u++77/8777vv
c7v//////////////////////////////////////////////////8AAAP//////+7//e/f///+/
e////////////////31/77/v//vvt+9re///////////////////////////////////////////
////////wAAA///////73/97A////997////////////////fX/vr+//+++H72tx////////////
///////////////////////////////////////AAAD//////4fv/3u3////74fP////////////
//99f++P7/+H77vvW3///////////////////////////////////////////////////8AAAP//
////v/f/e7f////3e8///////////////31/76/v/3/vu+9bf///////////////////////////
////////////////////////wAAA//////+/d/971////3d7////////////////u7ttu23/c227
7zu7///////////////////////////////////////////////////AAAD//////4OP/4fn////
j4f////////////////HwwEDAf+LAQeCMcP/////////////////////////////////////////
/////////8AAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////wAAA////////////////////////////////
///////////////////////////////////////////////////////////////////////AAAD/
////////////////////////////////////////////////////////////////////////////
/////////////////////////8AAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////wAAA////////////////
////////////////////////////////////////////////////////////////////////////
///////////AAAD/////////////////////////////////////////////////////////////
/////////////////////////////////////////8AAAP//////////////////////////////
///H/x//////////////////////////////////////////////////////////////////wAAA
/////////////////////////////////9//3//v////////////////////////////////////
///////////////////////////AAAD//////4eH/xGH////j4fP////////////34ff/9//////
/////////////////////////////////////////////////////////8AAAP//////e3v/u3v/
//93e8/////////////fe9//3///////////////////////////////////////////////////
////////////wAAA///////7e//He/////d7/////////////9973//f////////////////////
///////////////////////////////////////////AAAD///////t7/9d7////93v/////////
////33vf/7///////////////////////////////////////////////////////////////8AA
AP//////h3v/13v////Pe8/////////////fe9//3///////////////////////////////////
////////////////////////////wAAA//////+/e//Xe/////d7z////////////9973//f////
///////////////////////////////////////////////////////////AAAD//////797/+97
////d3v/////////////33vf/9//////////////////////////////////////////////////
/////////////8AAAP//////g4f/z4f///+Ph//////////////Hhx//7///////////////////
////////////////////////////////////////////wAAA////////////////////////////
///////////////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////////////////////////////////////////////
/////////////////////////////8AAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////wAAA////////////
////////////////////////////////////////////////////////////////////////////
///////////////AAAD/////////////////////////////////////////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
wAAA////////////////////////////////////9/////////+/////////////////////////
///////////////////////////////AAAD////////////////////////////////////3////
//9v/7///////////////////////////////////////////////////////8AAAP//////////
/////////8///////////////+8fGcdH/2/v3///////////////////////////////////////
////////////////wAAA////////////////////z///////////////77+7uzv/t+/f////////
///////////////////////////////////////////////AAAD/////////////////////////
///////////vv7d/+/8D79//////////////////////////////////////////////////////
/8AAAP///////////////////////////////////++Hj3/7/7f33///////////////////////
////////////////////////////////wAAA////////////////////z///////////////77uv
f4f/t/ff///////////////////////////////////////////////////////AAAD/////////
///////////P///////////////vu7d/f/8D+9//////////////////////////////////////
/////////////////8AAAP////////////////////////////////////e7u7tz/7d7v///////
////////////////////////////////////////////////wAAA////////////////////////
////////////9wcRw4v/2wO/////////////////////////////////////////////////////
///AAAD////////////////////////////////////////////b////////////////////////
/////////////////////////////////8AAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////wAAA////////
////////////////////////////////////////////////////////////////////////////
///////////////////AAAD/////////////////////////////////////////////////////
/////////////////////////////////////////////////8AAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////////////////////////////////////
///////////////////////////////////AAAD/////////////////////////////////////
///////////////////////////3//////////////////////////+//////////8AAAP//////
//////////////////////////////////////////////////////////f/////////////////
/////////7//////////wAAA//////+PD/+Hx/////8Pz////////////8cHjwPHx/+DDwIzx4Mf
gwMd/4mJx4n/74P/B/+H44f/g4OPh+MP/4P/7/+D3//////////AAAD//////3f3/3u7//////fP
////////////u7t3u7vv/++3u3Pv77/vu7v/c3O7c//v7/93/3v3e//v73d79/f/7//v/+/f////
/////8AAAP//////9/v/e7v/////+/////////////99u3e/f+//77u/a+/vv++/t/97e797/+/v
/7//e/d7/+/v9/v3+//v/+//79//////////wAAA///////3g/97u/////+D/////////////327
d69/7//vu69r7++v76+H/3uDv4P/7+//3/97A3v/7+/3+wOD/+//9//v3//////////AAAD/////
/897/3uH/////3vP////////////fYf3j3/v/++7j1vv74/vj7v/c3u/e//v7//v/4e3e//v78+H
t3v/7//3/+/f/////////8AAAP//////93v/e7//////e8////////////99u/evf+//77uvW+/v
r++vu/+LhweH/+/v//f/e7d7/+/v97+3e//v//v/79//////////wAAA//////93e/973/////97
/////////////7u797u7bf/vt7s7be+777u7//v/v///94//d/9713v/j493v9d7/4//e/+Pv///
///////AAAD//////4+H/4fj/////4f/////////////xwfDA8MB/4MPAjEBgwODAwf/8//////3
7/+P/4fnh//v74+D54f/7/8D/++//////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
////////////////////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////////////////////////////////////////////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
/////////////////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////wAAA/////////////////////////////////8H////////v////
///////////////////////////////////////////////////////AAAD//////4/v/4+H////
44/P/////////0cDx8cCM8cD/9//////////////////////////////////////////////////
/////////8AAAP//////d+//d3v////3d8//////////O7u7u7tzu7v/3///////////////////
////////////////////////////////////////wAAA///////37//3e/////f3///////////7
v327v2t/v//f///////////////////////////////////////////////////////////AAAD/
//////f3//d7////A/f///////////uvfbuva3+v/7//////////////////////////////////
/////////////////////////8AAAP//////z/f/z3v///+3z8//////////h499u49bf4//3///
////////////////////////////////////////////////////////wAAA///////3+//3e///
/7f3z/////////9/r327r1t/r//f////////////////////////////////////////////////
///////////AAAD//////3d7/3d7////13f//////////3O7u7u7O7u7/9//////////////////
/////////////////////////////////////////8AAAP//////jwP/j4f////nj///////////
iwPHEQIxwwP/7///////////////////////////////////////////////////////////wAAA
////////////////////////////////////////////////////////////////////////////
///////////////////////////AAAD/////////////////////////////////////////////
/////////////////////////////////////////////////////////8AAAP//////////////
////////////////////////////////////////////////////////////////////////////
////////////wAAA////////////////////////////////////////////////////////////
///////////////////////////////////////////AAAD/////////////////////////////
/////////////////////////////////////////////////////////////////////////8AA
AP//////////////////////////////////////////////////////////////////////////
////////////////////////////wAAA////////////////////////////////////////////
///////////////////////////////////////////////////////////AAAD/////////////
////////////////////v///////////////////////////////////////////////////////
/////////////8AAAP///////////////////8/////////////f////////////////////////
////////////////////////////////////////////wAAA////////////////////z///////
/////9/////////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////3///////////////////////////////////////
/////////////////////////////8AAAP/////////////////////////////////v////////
////////////////////////////////////////////////////////////wAAA////////////
////////z////////////9//////////////////////////////////////////////////////
///////////////AAAD////////////////////P////////////3///////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
///////f////////////////////////////////////////////////////////////////////
wAAA/////////////////////////////////7//////////////////////////////////////
///////////////////////////////AAAD/////////////////////////////////////////
/////////////////////////////////////////////////////////////8AAAP//////////
////////////////////////////////////////////////////////////////////////////
////////////////wAAA////////////////////////////////////////////////////////
///////////////////////////////////////////////AAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
/8AAAP//////////////////////////////////////////////////////////////////////
////////////////////////////////wAAA////////////////////////////////////////
///////////////////////////////////////////////////////////////AAAD/////////
////////////////////////////////////////////////////////////////////////////
/////////////////8AAAP///////////////////////////////////7//////////////////
////////////////////////////////////////////////wAAA////////////////////z///
////////////3///////////////////////////////////////////////////////////////
///AAAD////////////////////P///////////////f////////////////////////////////
/////////////////////////////////8AAAP///////////////////////////////////9//
////////////////////////////////////////////////////////////////wAAA////////
////////////////////////////7///////////////////////////////////////////////
///////////////////AAAD////////////////////P///////////////f////////////////
/////////////////////////////////////////////////8AAAP///////////////////8//
/////////////9//////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////3///////////////////////////////
///////////////////////////////////AAAD///////////////////////////////////+/
/////////////////////////////////////////////////////////////////8AAAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////wAAA////////////////////////////////////////////////////
///////////////////////////////////////////////////AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////////////////////////////////////
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////////////////////////////////////////////////////
/////////////////////8AAAP//////////////////////////////////////9////7//////
////////////////////////////////////////////////////wAAA////////////////////
///////////////////3////v///////////////////////////////////////////////////
///////AAAD////////////////////P/////////////////+/Hg9ff////////////////////
/////////////////////////////////////8AAAP///////////////////8//////////////
////77vvq9//////////////////////////////////////////////////////////wAAA////
///////////////////////////////////vfe+r3///////////////////////////////////
///////////////////////AAAD//////////////////////////////////////+9976vf////
/////////////////////////////////////////////////////8AAAP//////////////////
/8//////////////////733vq9//////////////////////////////////////////////////
////////wAAA////////////////////z//////////////////vfe+73///////////////////
///////////////////////////////////////AAAD/////////////////////////////////
//////e777u//////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////98eDEb//////////////////////////////////
////////////////////////wAAA////////////////////////////////////////////////
///////////////////////////////////////////////////////AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
/////////8AAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////wAAA////////////////////////////////
///////////////////////////////////////////////////////////////////////AAAD/
////////////////////////////////////////////////////////////////////////////
/////////////////////////8AAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////wAAA////////////////
///////////////////////////////////////////////////3/////////////////7//////
///////////AAAD/////////////////////////////////////////////////////////////
//////f/////////////////v////////////////8AAAP//////j4f/h8f/////h8//////////
/////8cHjwPHx/+DDwIzx4MfgwMd/wcRiYP/74P/j/+D4/+P/wf/B8ff////////////////wAAA
//////93e/97u/////97z///////////////u7t3u7vv/++3u3Pv77/vu7v/e7tz7//v7/93/+/3
/3f/d/93u9/////////////////AAAD///////d7/3u7//////v///////////////99u3e/f+//
77u/a+/vv++/t//7u3vv/+/v//f/7/f/9/+//7+73////////////////8AAAP//////93v/e7v/
////+////////////////327d69/7//vu69r7++v76+H/4e7g+//7+//9//vA//3/9//37vf////
////////////wAAA///////Pe/97h/////+Hz///////////////fYf3j3/v/++7j1vv74/vj7v/
e5t77//v7//P/++3/8//7//vh9/////////////////AAAD///////d7/3u//////7/P////////
//////99u/evf+//77uvW+/vr++vu/+Dp4fv/+/v//f/77f/9//3//e/3////////////////8AA
AP//////d3v/e9//////v////////////////7u797u7bf/vt7s7be+777u7//+//4//94//d/+P
1/93/3f/d9+/////////////////wAAA//////+Ph/+H4/////+D////////////////xwfDA8MB
/4MPAjEBgwODAwf//z//7//37/+P/+/n/4//j/+P47/////////////////AAAD/////////////
////////////////////////////////////////////////////////////////////////////
/////////////8AAAP//////////////////////////////////////////////////////////
////////////////////////////////////////////wAAA////////////////////////////
///////////////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////////////////////////////////////////////
/////////////////////////////8AAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////wAAA////////////
////////////////////////////////////////////////////////////////////////////
///////////////AAAD/////////////////////////////////////////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
/////////8H////////v////////////////////////////////////////////////////////
wAAA//////8Hh/+Ph//////vz////////////0cDx8cCM8cD/9//////////////////////////
///////////////////////////////AAAD//////3d7/3d7/////+/P////////////O7u7u7tz
u7v/3////////////////////////////////////////////////////////8AAAP//////v3v/
93v/////7//////////////7v327v2t/v//f////////////////////////////////////////
////////////////wAAA///////fe//3e//////3//////////////uvfbuva3+v/7//////////
///////////////////////////////////////////////AAAD//////++H/897//////fP////
////////h499u49bf4//3///////////////////////////////////////////////////////
/8AAAP//////93v/93v/////+8////////////9/r327r1t/r//f////////////////////////
////////////////////////////////wAAA//////93e/93e/////97/////////////3O7u7u7
O7u7/9/////////////////////////////////////////////////////////AAAD//////4+H
/4+H/////wP/////////////iwPHEQIxwwP/7///////////////////////////////////////
/////////////////8AAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////wAAA////////////////////////
////////////////////////////////////////////////////////////////////////////
///AAAD/////////////////////////////////////////////////////////////////////
/////////////////////////////////8AAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////wAAA////////
////////////////////////////////////////////////////////////////////////////
///////////////////AAAD/////////////////////////////////////////////////////
/////////////////////////////////////////////////8AAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////7///////////////////////////////
///////////////////////////////////AAAD//////wfH/4+D/////w/P/////////0cDx//f
/////////////////////////////////////////////////////////////////8AAAP//////
d7v/d+//////98//////////O7vv/9//////////////////////////////////////////////
////////////////////wAAA//////+/u//37//////7///////////7v+//3///////////////
///////////////////////////////////////////////////AAAD//////9+7//fv/////4P/
//////////uv7/+/////////////////////////////////////////////////////////////
/////8AAAP//////74f/z+//////e8//////////h4/v/9//////////////////////////////
////////////////////////////////////wAAA///////3v//37/////97z/////////9/r+//
3//////////////////////////////////////////////////////////////////AAAD/////
/3ff/3eP/////3v//////////3O7bf/f////////////////////////////////////////////
/////////////////////8AAAP//////j+P/j+//////h///////////iwMB/+//////////////
////////////////////////////////////////////////////wAAA////////////////////
////////////////////////////////////////////////////////////////////////////
///////AAAD/////////////////////////////////////////////////////////////////
/////////////////////////////////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
////////////////////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////////////////////////////////////////////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
/////////////////////////////////////////////////////////////////////8AAAP//
////B4//hwf/////g8//////////gjPHA8cDHf+D////////////////////////////////////
////////////////////////wAAA//////93d/97d//////vz//////////vc++7u7u7/+//////
///////////////////////////////////////////////////////AAAD//////7/3/3u/////
/+///////////+9r7797v7f/7///////////////////////////////////////////////////
/////////8AAAP//////3/f/e9//////7///////////72vvr3Gvh//v////////////////////
////////////////////////////////////////wAAA///////vz/977//////vz//////////v
W++Pf4+7/+/////////////////////////////////////////////////////////////AAAD/
//////f3/3v3/////+/P/////////+9b769/r7v/7///////////////////////////////////
/////////////////////////8AAAP//////d3f/e3f/////j///////////7zttu7u7u/+P////
////////////////////////////////////////////////////////wAAA//////+Pj/+Hj///
///v//////////+CMQEDwwMH/+//////////////////////////////////////////////////
///////////AAAD/////////////////////////////////////////////////////////////
/////////////////////////////////////////8AAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////wAAA
////////////////////////////////////////////////////////////////////////////
///////////////////////////AAAD/////////////////////////////////////////////
/////////////////////////////////////////////////////////8AAAP//////////////
////////////////////////////////////////////////////////////////////////////
////////////wAAA////////////////////////////////////////////////////////////
///////////////////////////////////////////AAAD/////////////////////////////
/////////////////////////////////////////////////////////////////////////8AA
AP//////////////////////////////wf///////+//////////////////////////////////
////////////////////////////wAAA//////+DD/+Ph/+DB4fjz///////RwPHxwIzxwP/3///
///////////////////////////////////////////////////////////AAAD//////+/3/3d7
/+93e/fP//////87u7u7u3O7u//f////////////////////////////////////////////////
/////////////8AAAP//////7/v/93v/77979/////////u/fbu/a3+//9//////////////////
////////////////////////////////////////////wAAA///////vg//3e//v33sD////////
+699u69rf6//v//////////////////////////////////////////////////////////////A
AAD//////+97/897/+/vh7fP//////+Hj327j1t/j//f////////////////////////////////
/////////////////////////////8AAAP//////73v/93v/7/d7t8///////3+vfbuvW3+v/9//
////////////////////////////////////////////////////////////wAAA//////+Pe/93
e/+Pd3vX////////c7u7u7s7u7v/3///////////////////////////////////////////////
///////////////AAAD//////++H/4+H/++Ph+f///////+LA8cRAjHDA//v////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
wAAA////////////////////////////////////////////////////////////////////////
///////////////////////////////AAAD/////////////////////////////////////////
/////////////////////////////////////////////////////////////8AAAP//////////
////////////////////////////////////////////////////////////////////////////
////////////////wAAA////////////////////////////////////////////////////////
///////////////////////////////////////////////AAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
/8AAAP/////////////////////////H/x//////////////////////////////////////////
////////////////////////////////wAAA/////////////////////////9//3//v////////
///////////////////////////////////////////////////////////////AAAD//////4OH
/xGH/4MHh4fP////34ff/9//////////////////////////////////////////////////////
/////////////////8AAAP//////73v/u3v/73d7e8/////fe9//3///////////////////////
////////////////////////////////////////////////wAAA///////v+//He//vv3t7////
/9973//f////////////////////////////////////////////////////////////////////
///AAAD//////+/7/9d7/+/fe3v/////33vf/7//////////////////////////////////////
/////////////////////////////////8AAAP//////74f/13v/7++Hh8/////fe9//3///////
////////////////////////////////////////////////////////////////wAAA///////v
v//Xe//v93t7z////9973//f////////////////////////////////////////////////////
///////////////////AAAD//////4+//+97/493e3v/////33vf/9//////////////////////
/////////////////////////////////////////////////8AAAP//////74P/z4f/74+Hh///
///Hhx//7///////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////////////////////////////////////
///////////////////////////////////AAAD/////////////////////////////////////
/////////////////////////////////////////////////////////////////8AAAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////wAAA////////////////////////////////////////////////////
///////////////////////////////////////////////////AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////////////////////////////9///////
//+////////////////////////////////////////////////////////////////AAAD/////
///////////////////////3//////9v/7//////////////////////////////////////////
/////////////////////8AAAP///////////////////8///////+8fGcdH/2/v3///////////
////////////////////////////////////////////////////wAAA////////////////////
z///////77+7uzv/t+/f////////////////////////////////////////////////////////
///////AAAD////////////////////////////vv7d/+/8D79//////////////////////////
/////////////////////////////////////8AAAP///////////////////////////++Hj3/7
/7f33///////////////////////////////////////////////////////////////wAAA////
////////////////z///////77uvf4f/t/ff////////////////////////////////////////
///////////////////////AAAD////////////////////P///////vu7d/f/8D+9//////////
/////////////////////////////////////////////////////8AAAP//////////////////
//////////e7u7tz/7d7v///////////////////////////////////////////////////////
////////wAAA////////////////////////////9wcRw4v/2wO/////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
///b/////////////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////wAAA////////////////////////////////////////////////
///////////////////////////////////////////////////////AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
/////////8AAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////wAAA////////////////////////////////
///////////////////////////////////////////////////////////////////////AAAD/
//////////////////////////////////////////////////+H///////////3////////////
//////////////+//////////8AAAP//////////////////////////////////////////////
//////v///////////f//////////////////////////7//////////wAAA////////4/+Hx///
//8Pz////8cHjwPHx/+DDwIzx4MfgwMd/weDixGDiQ+Jx4n/74P/B/+H44f/g4OPh+MP/4P/7/8H
3//////////AAAD////////3/3u7//////fP////u7t3u7vv/++3u3Pv77/vu7v/e+9zu39zt3O7
c//v7/93/3v3e//v73d79/f/7//v/3ff/////////8AAAP////////f/e7v/////+/////99u3e/
f+//77u/a+/vv++/t//773u7f3u7e797/+/v/7//e/d7/+/v9/v3+//v/+//v9//////////wAAA
////////A/97u/////+D/////327d69/7//vu69r7++v76+H/4fve7sDe7uDv4P/7+//3/97A3v/
7+/3+wOD/+//9//f3//////////AAAD///////+3/3uH/////3vP////fYf3j3/v/++7j1vv74/v
j7v/e+9zm3tzu3u/e//v7//v/4e3e//v78+Ht3v/7//3/+/f/////////8AAAP///////7f/e7//
////e8////99u/evf+//77uvW+/vr++vu/+Dj4knh4u7hweH/+/v//f/e7d7/+/v97+3e//v//v/
99//////////wAAA////////1/973/////97/////7u797u7bf/vt7s7be+777u7////////+7f/
v///94//d/9713v/j493v9d7/4//e/93v//////////AAAD////////n/4fj/////4f/////xwfD
A8MB/4MPAjEBgwODAwf//+/////zD//////37/+P/4fnh//v74+D54f/7/8D/4+//////////8AA
AP//////////////////////////////////////////////////////////////////////////
////////////////////////////wAAA////////////////////////////////////////////
///////////////////////////////////////////////////////////AAAD/////////////
////////////////////////////////////////////////////////////////////////////
/////////////8AAAP//////////////////////////////////////////////////////////
////////////////////////////////////////////wAAA////////////////////////////
///////////////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////////////////////////////////////////////
/////////////////////////////8AAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////wAAA////////////
/////////////8H////////v////////////////////////////////////////////////////
///////////////AAAD///////+H/4+H/4OPh4/P/0cDx8cCM8cD/9//////////////////////
/////////////////////////////////////////////8AAAP///////3v/d3v/73d7d8//O7u7
u7tzu7v/3///////////////////////////////////////////////////////////////////
wAAA////////e//3e//v93v3///7v327v2t/v//f////////////////////////////////////
///////////////////////////////AAAD///////97//d7/+/3e/f///uvfbuva3+v/7//////
/////////////////////////////////////////////////////////////8AAAP///////3v/
z3v/7897z8//h499u49bf4//3///////////////////////////////////////////////////
////////////////wAAA////////e//3e//v93v3z/9/r327r1t/r//f////////////////////
///////////////////////////////////////////////AAAD///////97/3d7/493e3f//3O7
u7u7O7u7/9//////////////////////////////////////////////////////////////////
/8AAAP///////4f/j4f/74+Hj///iwPHEQIxwwP/7///////////////////////////////////
////////////////////////////////wAAA////////////////////////////////////////
///////////////////////////////////////////////////////////////AAAD/////////
////////////////////////////////////////////////////////////////////////////
/////////////////8AAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////wAAA////////////////////////
////////////////////////////////////////////////////////////////////////////
///AAAD/////////////////////////////////////////////////////////////////////
/////////////////////////////////8AAAP//////////////////////////////////////
////////////////////////////////////////////////////////////////wAAA////////
////////////////////////////////////////////////////////////////////////////
///////////////////AAAD/////////////////////////////////////////////////////
/////////////////////////////////////////////////8AAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////////////////////////////////////
///////////////////////////////////AAAD/////////////////////////////////////
/////////////////////////////////////////////////////////////////8AAAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////wAAA////////////////////////////////////////////////////
///////////////////////////////////////////////////AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////////////////////////////////////
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////////////////////////////////////////////////////
/////////////////////8AAAP//////////////////////////////////////////////////
////////////////////////////////////////////////////wAAA////////////////////
////////////////////////////////////////////////////////////////////////////
///////AAAD/////////////////////////////////////////////////////////////////
/////////////////////////////////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
////////////////////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////yRExEYfXEf/Hgw/P////////////////////////////////////////////
///////////////////////////////////////AAAD///+zu7e7e6u7/7vvt8//////////////
/////////////////////////////////////////////////////////////////////8AAAP//
/7u7r7t7q7v/fe+7////////////////////////////////////////////////////////////
////////////////////////wAAA/wP/u7uPu3uru/9977v/////////////////////////////
///////////////////////////////////////////////////////AAAD///+7m7ebe7ub/33v
u///////////////////////////////////////////////////////////////////////////
/////////8AAAP///zMnoSeHESf/fe+7////////////////////////////////////////////
////////////////////////////////////////wAAA//////+///////+777f/////////////
///////////////////////////////////////////////////////////////////////AAAD/
/////z///////8eDD///////////////////////////////////////////////////////////
/////////////////////////8AAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////wAAA////////////////
////////////////////////////////////////////////////////////////////////////
///////////AAAD/////////////////////////////////////////////////////////////
/////////////////////////////////////////8AAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////wAAA
////////////////////////////////////////////////////////////////////////////
///////////////////////////AAAD/////////////////////////////////////////////
/////////////////////////////////////////////////////////8AAAP//////////////
/48f////////j///////////////////////////////////////////////////////////////
////////////wAAA////////////////77/////////v////////////////////////////////
///////////////////////////////////////////AAAD///8HEYMRAwMRhwfvh8eDhxEZg+8f
B4MDgweDEYeD/////////////////////////////////////////////////////////////8AA
AP///3u777u7u7t7v9e7u+97u7t/17+/f99/v3+7e3//////////////////////////////////
////////////////////////////wAAA////+7vvu7+/u3+/17u/73u7t3/Xv79/33+/f7t/f///
///////////////////////////////////////////////////////////AAAD/A/+Hq++rr6+7
f7+7u7/ve7uPA7uHvwPfA78Du38D////////////////////////////////////////////////
/////////////8AAAP///3ur76uPj5tzn7ubv+97m697u7ufe997n3ubc3v/////////////////
////////////////////////////////////////////wAAA////g5Pvk6+vJ4sjEScHj4cnt4cR
uyOHA4cjhyeLh//////////////////////////////////////////////////////////////A
AAD/////k++Tu7v//////7////+7//+7///f////////////////////////////////////////
/////////////////////////////8AAAP////8RgxEDA////////+///xH//wf//+P/////////
////////////////////////////////////////////////////////////wAAA////////////
////////////////////////////////////////////////////////////////////////////
///////////////AAAD/////////////////////////////////////////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
wAAA////////////////////////////////////////////////////////////////////////
///////////////////////////////AAAD/////////////////////////////////////////
/////////////////////////////////////////////////////////////8AAAP//////////
////////////////////////////////////////////////////////////////////////////
////////////////wAAA/////////////x//////////////////////////////////////////
///////////////////////////////////////////////AAAD/////////////v///////////
////////////////////////////////////////////////////////////////////////////
/8AAAP///wYlgiWDx4mHiEeDg4PHg4MH////////////////////////////////////////////
////////////////////////////////wAAA////e23vbX+7c7tzO+/v77vvf3v/////////////
///////////////////////////////////////////////////////////////AAAD////7be9t
f397u3t77+/vv+9/+///////////////////////////////////////////////////////////
/////////////////8AAAP8D/4dt720Df4O7g3vv7++/7wOH////////////////////////////
////////////////////////////////////////////////wAAA////eyXvJXt/e5t7O+/v77/v
e3v/////////////////////////////////////////////////////////////////////////
///AAAD///+CW45bh3+HJ4dHj++PB4+Hg///////////////////////////////////////////
/////////////////////////////////8AAAP//////////u////3//7/+/////////////////
////////////////////////////////////////////////////////////////wAAA///////v
///D///+f+/P7//v////////////////////////////////////////////////////////////
///////////////////AAAD/////////////////////////////////////////////////////
/////////////////////////////////////////////////8AAAP//////////////////////
////////////////////////////////////////////////////////////////////////////
////wAAA////////////////////////////////////////////////////////////////////
///////////////////////////////////AAAD/////////////////////////////////////
/////////////////////////////////////////////////////////////////8AAAP//////
////////////////////////////////////////////////////////////////////////////
////////////////////wAAA////////////////////////////////////////////////////
///////////////////////////////////////////////////AAAD/////////////////////
////////////////////////////////////////////////////////////////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////h4cRx4MRxxGDEccH////////////////
///////////////////////////////////////////////////////////////////AAAD///97
e7u7f7u7u++7u3v/////////////////////////////////////////////////////////////
/////////////////////8AAAP///397u79/u7+777u/+///////////////////////////////
////////////////////////////////////////////////////wAAA/wP/f3u7vwO7v7vvu7+H
////////////////////////////////////////////////////////////////////////////
///////AAAD///9ze5u/e5u/g++bv3v/////////////////////////////////////////////
/////////////////////////////////////8AAAP///4uHJweHJwe7jycHg///////////////
////////////////////////////////////////////////////////////////////wAAA////
////v///v7v//7//////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////Ee//////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////////////////////////////////////////////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
/////////////////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////wAAA////////////////////////////////////////////////
///////////////////////////////////////////////////////AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
/////////8AAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////wAAA////////////////////////////////
///////////////////////////////////////////////////////////////////////AAAD/
//+HhxHHgxHHHYMDgweDEYeD////////////////////////////////////////////////////
/////////////////////////8AAAP///3t7u7t/u7u7f99/v3+7e3//////////////////////
////////////////////////////////////////////////////////wAAA////f3u7v3+7v7d/
33+/f7t/f///////////////////////////////////////////////////////////////////
///////////AAAD/A/9/e7u/A7u/hwPfA78Du38D////////////////////////////////////
/////////////////////////////////////////8AAAP///3N7m797m7+7e997n3ubc3v/////
////////////////////////////////////////////////////////////////////////wAAA
////i4cnB4cnB7uHA4cjhyeLh///////////////////////////////////////////////////
///////////////////////////AAAD///////+///+/u//f////////////////////////////
/////////////////////////////////////////////////////////8AAAP////////////8H
/+P/////////////////////////////////////////////////////////////////////////
////////////wAAA////////////////////////////////////////////////////////////
///////////////////////////////////////////AAAD/////////////////////////////
/////////////////////////////////////////////////////////////////////////8AA
AP//////////////////////////////////////////////////////////////////////////
////////////////////////////wAAA////////////////////////////////////////////
///////////////////////////////////////////////////////////AAAD/////////////
////////////////////////////////////////////////////////////////////////////
/////////////8AAAP//////////////////////////////////////////////////////////
////////////////////////////////////////////wAAA////////////////////////////
///////////////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////////////////////////////////////////////
/////////////////////////////8AAAP///4eHEceDEceDiYMRx4MDg4MH////////////////
////////////////////////////////////////////////////////////wAAA////e3u7u3+7
u+9zf7u779/vf7//////////////////////////////////////////////////////////////
///////////////AAAD///9/e7u/f7u/73t/u7/v3+9/v///////////////////////////////
/////////////////////////////////////////////8AAAP8D/397u78Du7/vewO7v+/f7wO/
////////////////////////////////////////////////////////////////////////////
wAAA////c3ubv3ubv+9ze5u/79/ve5//////////////////////////////////////////////
///////////////////////////////AAAD///+LhycHhycH74uHJwePA4+HI///////////////
/////////////////////////////////////////////////////////////8AAAP///////7//
/7/v+///v//f////////////////////////////////////////////////////////////////
////////////////wAAA/////////////4Pz////7+Pv////////////////////////////////
///////////////////////////////////////////////AAAD/////////////////////////
////////////////////////////////////////////////////////////////////////////
/8AAAP//////////////////////////////////////////////////////////////////////
////////////////////////////////wAAA////////////////////////////////////////
///////////////////////////////////////////////////////////////AAAD/////////
////////////////////////////////////////////////////////////////////////////
/////////////////8AAAP//////////////////////////////////////////////////////
////////////////////////////////////////////////wAAA////////////////////////
////////////////////////////////////////////////////////////////////////////
///AAAD//////4f/////////////////h/////////////////////////+H//////////////+H
/////////////////////////////////8AAAP//////+//////////////////7////////////
//////////////v///////////////v/////////////////////////////////wAAA/xH/R4OL
EYOJD4nHif4lgwcHiYuD/9eDxxH/xxGD/wOHg4OH14MRi/+DgwfH/4cD/weDixGDiRHHxweCR8nH
gwfP///////////////AAAD/u/8773O7f3O3c7tz/21/e3tzc3//q++7u/+7u3//33vv73ur77tz
/+/ve7v/e9//e+9zu39zu7u7v+87s7t/e8///////////////8AAAP/H//vve7t/e7t7v3v/bX/7
+3t7f/+r77+7/7+7f//fe+/ve6vvu3v/7+/7v/973//773u7f3vHv7+/73u7v3/7////////////
////wAAA/9f/++97uwN7u4O/g/9tA4eHg3sD/6vvv7v/v7sD/9977+97q++7e//v74e//3vf/4fv
e7sDe9e/v7/ve7u/A4f////////////////AAAD/1/+H73Obe3O7e797/yV7e3t7c3v/u++/m/+/
m3v/33vv73u775tz/+/ve7//e9//e+9zm3tz17+/n+87u797e8///////////////8AAAP/X/3+P
iSeHi7uHB4f+W4eDg4eJh/8Rjwen/wenh/8Dh+/vhxGPJ4n/74+DB/+HA/+Dj4knh4vXBwcjj0cz
B4eDz///////////////wAAA/+//c//////7t/+/////////////////v7//v7///9//7+//////
///v//+////f////////+++/v///f/+////////////////////AAAD/z/+L7/////MP////////
/////////+//P///P///4//Pz///7////8/v/////+P//+/////zz////+5/////////////////
/////8AAAP//////////////////////////////////////////////////////////////////
////////////////////////////////////wAAA////////////////////////////////////
///////////////////////////////////////////////////////////////////AAAD/////
////////////////////////////////////////////////////////////////////////////
/////////////////////8AAAP//////////////////////////////////////////////////
////////////////////////////////////////////////////wAAA////////////////////
////////////////////////////////////////////////////////////////////////////
///////AAAD/////////////////////////////////////////////////////////////////
/////////////////////////////////////8AAAP//////////////////////////////////
////////////////////////////////////////////////////////////////////wAAA////
////////////////////////////////////////////////////////////////////////////
///////////////////////AAAD/////////////////////////////////////////////////
/////////////////////////////////////////////////////8AAAP//////////////////
////////////////////////////////////////////////////////////////////////////
////////wAAA////////////////////////////////////////////////////////////////
///////////////////////////////////////AAAD/////////////////////////////////
/////////////////////////////////////////////////////////////////////8AAAP//
////////////////////////////////////////////////////////////////////////////
////////////////////////wAAA////////////////////////////////////////////////
///////////////////////////////////////////////////////AAAD/////////////////
////////////////////////////////////////////////////////////////////////////
/////////8AAAP//////////////////////////////////////////////////////////////
////////////////////////////////////////wAAA////////////////////////////////
///////////////////////////////////////////////////////////////////////AAAD/
////////////////////////////////////////////////////////////////////////////
/////////////////////////8AAAP//////////////////////////////////////////////
////////////////////////////////////////////////////////wAAA////////////////
////////////////////////////////////////////////////////////////////////////
///////////AAAD/////////////////////////////////////////////////////////////
/////////////////////////////////////////8AAAP//////////////////////////////
////////////////////////////////////////////////////////////////////////wAAA
//////////+H////////////////////////////////////////////////////////////////
///////////////////////////AAAD///////////v/////////////////////////////////
/////////////////////////////////////////////////////////8AAAP+Hz4OH/0eDixGD
iQ+Jx4n/14PHEf8Rx8cHgkfJx4MH////////////////////////////////////////////////
////////////wAAA/3vP73v/O+9zu39zt3O7c/+r77u7/7u7u7/vO7O7f3v/////////////////
///////////////////////////////////////////AAAD/+//ve//773u7f3u7e797/6vvv7v/
x7+/v+97u79/+////////////////////////////////////////////////////////////8AA
AP/7/+97//vve7sDe7uDv4P/q++/u//Xv7+/73u7vwOH////////////////////////////////
////////////////////////////wAAA/4f/73v/h+9zm3tzu3u/e/+r77+b/9e/v5/vO7u/e3v/
///////////////////////////////////////////////////////////AAAD/v//ve/9/j4kn
h4u7hweH/7uPB6f/1wcHI49HMweHg///////////////////////////////////////////////
/////////////8AAAP+//497/3P/////+7f/v///u/+/v//vv7///3//v///////////////////
////////////////////////////////////////////wAAA/4P/74f/i+/////zD/////8R7/8/
/8/////uf//////////////////////////////////////////////////////////////////A
AAD/////////////////////////////////////////////////////////////////////////
/////////////////////////////8AAAP//////////////////////////////////////////
////////////////////////////////////////////////////////////wAAA////////////
////////////////////////////////////////////////////////////////////////////
///////////////AAAD/////////////////////////////////////////////////////////
/////////////////////////////////////////////8AAAP//////////////////////////
////////////////////////////////////////////////////////////////////////////
wAAA

------_=_NextPart_000_01C1F8CB.F0B86370--


Received: by above.proper.com (8.11.6/8.11.3) id g4ANw6Z01009 for ietf-smime-bks; Fri, 10 May 2002 16:58:06 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ANw4L01005 for <[e-mail]>; Fri, 10 May 2002 16:58:04 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g4ANw6m08402; Fri, 10 May 2002 16:58:06 -0700 (PDT)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Subject: RFC 3278 on Use of ECC Algorithms in CMS
Cc: [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Fri, 10 May 2002 16:58:06 -0700
From: RFC Editor <[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>

--NextPart


A new Request for Comments is now available in online RFC libraries.


        RFC 3278

        Title:	    Use of Elliptic Curve Cryptography (ECC)
                    Algorithms in Cryptographic Message Syntax (CMS)
        Author(s):  S. Blake-Wilson, D. Brown, P. Lambert
        Status:	    Informational
	Date:       April 2002
        Mailbox:    [e-mail], [e-mail],
                    [e-mail] 
        Pages:      16
        Characters: 33779
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-smime-ecc-06.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3278.txt


This document describes how to use Elliptic Curve Cryptography
(ECC) public-key algorithms in the Cryptographic Message Syntax
(CMS).  The ECC algorithms support the creation of digital
signatures and the exchange of keys to encrypt or authenticate
content.  The definition of the algorithm processing is based on
the ANSI X9.62 standard, developed by the ANSI X9F1 working group,
the IEEE 1363 standard, and the SEC 1 standard.

The readers attention is called to the Intellectual Property Rights
section at the end of this document.

This document is a product of the S/MIME Mail Security Working Group
of the IETF.

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [e-mail].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [e-mail].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [e-mail] with the message body 
help: ways_to_get_rfcs.  For example:

        To: [e-mail]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [e-mail].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[e-mail].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.

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

RETRIEVE: rfc
DOC-ID: rfc3278

--OtherAccess
Content-Type:   Message/External-body;
        name="rfc3278.txt";
        site="ftp.isi.edu";
        access-type="anon-ftp";
        directory="in-notes"

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

--OtherAccess--
--NextPart--


Received: by above.proper.com (8.11.6/8.11.3) id g4AKnfK26137 for ietf-smime-bks; Fri, 10 May 2002 13:49:41 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4AKneL26133 for <[e-mail]>; Fri, 10 May 2002 13:49:40 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0511171bb901e26f1a10@[165.227.249.18]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Fri, 10 May 2002 13:49:35 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Next Draft of Proposed Charter
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>

At 1:49 PM -0400 5/10/02, Housley, Russ wrote:
>Here is the next draft of the proposed working group charter.  The 
>biggest change from the previous posting is that both OAEP and KEM 
>become standards track documents.

And in what way would that help us get interoperable implementations of S/MIME?

Are the differences between the attacks and mitigations presented by 
OAEP and KEM really worth the high liklihood of lack of 
interoperability?

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4AIsDh11970 for ietf-smime-bks; Fri, 10 May 2002 11:54:13 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g4AIsAL11951 for <[e-mail]>; Fri, 10 May 2002 11:54:10 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 May 2002 18:54:35 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g4AIx4q08085 for <[e-mail]>; Sat, 11 May 2002 04:59:04 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <K11DWRQ6>; Sat, 11 May 2002 04:54:15 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (housley-lap.securitydynamics.com [10.100.79.199]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id K2ZLAWVC; Fri, 10 May 2002 14:53:02 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 10 May 2002 13:49:29 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Next Draft of Proposed Charter
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_6592799==_"
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>

--=====================_6592799==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

S/MIME WG:

Here is the next draft of the proposed working group charter.  The biggest 
change from the previous posting is that both OAEP and KEM become standards 
track documents.

Russ


--=====================_6592799==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Charter4.txt"


S/MIME Mail Security (smime)

Chair:
     Russ Housley <[e-mail]>

Security Area Director:
     Jeffrey Schiller <[e-mail]>
     Steve Belovin <[e-mail]>

Mailing Lists:
     General Discussion: [e-mail]
     To Subscribe:       [e-mail]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed  
Standards that comprise the S/MIME version 3 specification.   
Current efforts update and build upon these base specifications.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any 
algorithm.  To ensure interoperability, each algorithm should have
a specification that describes its use with CMS.  Specifications 
for the use of additional cryptographic algorithms will be 
developed.

As part of the specification update, a new suite of "mandatory 
to implement" algorithms will be selected.  These algorithms will
be reflected in updates to RFC 2632 and RFC 2633.

To aid implementers, documents containing example output for CMS
will be collected and published.  Some of the examples will include
structures and signed attributes defined in the Enhanced Security
Services (ESS) document.

In some situations it would be advantageous for the CMS RecipientInfo 
structure to support additional key management techniques, including 
cryptographic keys derived from passwords.  Also, a mechanism to 
facilitate the definition of additional key management techniques
will be defined.

Compressing data prior to encryption or signature has a number of 
advantages.  Compression improves security by removing known data 
patterns, improves throughput by reducing the amount of data which
needs to be encrypted or hashed, and reduces the overall message 
size.  Enabling S/MIME version 3 to use compression will provide 
all of these advantages.

S/MIME version 3 permits the use of previously distributed 
symmetric key-encryption keys.  Specifications for the distribution
of symmetric key-encryption keys to multiple message recipients 
will be developed.  Mail List Agents (MLAs) are one user of 
symmetric key-encryption keys.  The specification will be algorithm 
independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large organizations 
will be used as examples.

As part of S/MIME version 3, CMS is used to provide security 
to the message content.  CMS can also be employed in an X.400
electronic messaging envionments.  Specifications will be 
developed allowing this to be done in an interoperable manner.

Perform necessary interoperability testing to progress the S/MIME
version 3 specifications to Draft Standard.  Due to the dependency
of the CMS specification on the PKIX certificate and CRL profile,
the timeline for the actual progression is impossible to estimate.


Goals and Milestones:

History:
     Submit CMS compressed data content type a Proposed Standard.
     Submit security label usage specification as Informational RFC.
     Submit elliptic curve algorithm specification as Informational RFC.
     Submit mail list key distribution as a Proposed Standard.
     Submit update to RFC 2630 as a Proposed Standard.
     Submit AES key wrap algorithm description as Informational RFC.
     Last call on X.400 CMS wrapper specification.
     Last call on X.400 transport specification.
     Last call on HMAC key wrap description specification.
     First draft of CMS and ESS examples document.
     First draft of RSA OAEP algorithm specification.
     First draft of AES algorithm specification.
     First draft of update to RFC 2632.
     Frist draft of update to RFC 2633.

May 2002:
     Submit X.400 CMS wrapper specification as a Proposed Standard.
     Submit X.400 transport as a Proposed Standard.
     Submit HMAC key wrap description as an Informational RFC.

June 2002:
     Last call on CMS and ESS examples document.

July 2002:
     First draft of RSA PSS algorithm specification.
     Last call on update to RFC 2632.
     Last call on update to RFC 2633.
     Last call on AES algorithm specification.
     Last call on RSA OAEP algorithm specification.

August 2002:
     First draft of RSA KEM algorithm specification.
     Submit CMS and ESS examples document as Informational RFC.

October 2002:
     Last call on RSA PSS algorithm specification.
     Sumbit update to RFC 2632 as Proposed Standard.
     Sumbit update to RFC 2633 as Proposed Standard.

November 2002:
     Last call on RSA KEM algorithm specification.

December 2002:
     Sumbit AES algorithm specification as Proposed Standard.
     Submit RSA OAEP algorithm specification as Proposed Standard.

January 2003:
     Submit RSA PSS algorithm specification as Proposed Standard.

February 2003:
     Submit RSA KEM algorithm specification as Proposed Standard.

--=====================_6592799==_--


Received: by above.proper.com (8.11.6/8.11.3) id g48LdQF10116 for ietf-smime-bks; Wed, 8 May 2002 14:39:26 -0700 (PDT)
Received: from fledermaus.treasury.govt.nz ([202.36.173.38]) by above.proper.com (8.11.6/8.11.3) with SMTP id g48LdPL10109 for <[e-mail]>; Wed, 8 May 2002 14:39:25 -0700 (PDT)
Received: from juliet.hamlet.treasury.govt.nz (not verified[172.20.2.43]) by fledermaus.treasury.govt.nz with MailMarshal (4,0,4,0)  id <B000036e51>; Thu, 09 May 2002 09:40:17 +1200
MIME-Version: 1.0
Subject: RE: Are certificates _required_ by the sender?
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 9 May 2002 09:41:14 +1200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Are certificates _required_ by the sender?
Thread-Index: AcH2r1BvTtpboe0mTsS4jFC4AJcmdAAJwUEA
From: "Craig McGregor" <[e-mail]>
To: "Ben Littauer" <[e-mail]>
Cc: <[e-mail]>
content-class: urn:content-classes:message
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g48LdQL10111
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>

Hi Ben,

Although I have not tested this theory, I suspect it is so that it can
encrypt the message both for the recipient and sender. Otherwise the
sender could not read their message from their sent items folder without
access to the recipients private key - which of course is a no-no!

Nothing in the S/MIME RFC's says you _have_ to have one. You should be
able to happily encrypt but not sign e-mail without one. Practicalities
mean for certain functionality in clients it may be necessary to have
your own certificate.

--
Craig McGregor		
Security Specialist	
IT Systems 			http://e.govt.nz/see/mail
The Treasury		http://www.treasury.govt.nz
 



-----Original Message-----
From: Ben Littauer [mailto:[e-mail]]
Sent: Thursday, 9 May 2002 4:08 a.m.
To: [e-mail]
Subject: RE: Are certificates _required_ by the sender?



Interesting you should ask this right now.  I don't believe that there
is
any S/MIME requirement that says that the sender needs a cert.  That
said,
however, MS Outlook DOES require that you have a cert before it will let
you
encrypt a message on someone else's cert that you've received.  Does
anyone
know why this is?

-ben-

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terje Tollisen
Sent: Wednesday, May 08, 2002 5:26
To: [e-mail]
Subject: Are certificates _required_ by the sender?



Is the sender of an email required to have a certificate, or is it
sufficient for the sender to have a copy of the certificate of the
recipient? I am thinking of an automated system, where one party will
always
be the sender, and never receive emails. In addition, no signatures are
required. Thus nobody will ever actually need the public key for the
automated system. However, I'm uncertain if the sender can send S/MIME
messages without having a certificate of it's own.

Thanks for your time
-Terry Tollisen

--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup




Received: by above.proper.com (8.11.6/8.11.3) id g48GAvX27875 for ietf-smime-bks; Wed, 8 May 2002 09:10:57 -0700 (PDT)
Received: from mail01d.rapidsite.net (mail01d.rapidsite.net [207.158.192.52]) by above.proper.com (8.11.6/8.11.3) with SMTP id g48GAuL27870 for <[e-mail]>; Wed, 8 May 2002 09:10:56 -0700 (PDT)
Received: from www.blkk.com (209.130.71.190) by mail01d.rapidsite.net (RS ver 1.0.63s) with SMTP id 090740 for <[e-mail]>; Wed,  8 May 2002 12:10:50 -0400 (EDT)
From: "Ben Littauer" <[e-mail]>
To: <[e-mail]>
Subject: RE: Are certificates _required_ by the sender?
Date: Wed, 8 May 2002 12:08:13 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
X-Loop-Detect: 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 you should ask this right now.  I don't believe that there is
any S/MIME requirement that says that the sender needs a cert.  That said,
however, MS Outlook DOES require that you have a cert before it will let you
encrypt a message on someone else's cert that you've received.  Does anyone
know why this is?

-ben-

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Terje Tollisen
Sent: Wednesday, May 08, 2002 5:26
To: [e-mail]
Subject: Are certificates _required_ by the sender?



Is the sender of an email required to have a certificate, or is it
sufficient for the sender to have a copy of the certificate of the
recipient? I am thinking of an automated system, where one party will always
be the sender, and never receive emails. In addition, no signatures are
required. Thus nobody will ever actually need the public key for the
automated system. However, I’m uncertain if the sender can send S/MIME
messages without having a certificate of it's own.

Thanks for your time
-Terry Tollisen

--
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup




Received: by above.proper.com (8.11.6/8.11.3) id g48FVXR26518 for ietf-smime-bks; Wed, 8 May 2002 08:31:33 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g48FVSL26510 for <[e-mail]>; Wed, 8 May 2002 08:31:28 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 May 2002 15:29:56 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 LAA24388; Wed, 8 May 2002 11:29:37 -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 g48FTeK22526; Wed, 8 May 2002 11:29:40 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZK04AZ>; Wed, 8 May 2002 11:31:28 -0400
Message-ID: <[e-mail]>
From: "Kaliski, Burt" <[e-mail]>
To: "'Robert Zuccherato'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>
Subject: RE: Why KEM?, RE: Charter Update
Date: Wed, 8 May 2002 11:30:59 -0400 
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>

Rob,
 
I agree that RSA-OAEP is adequate, and I realize it's hard to argue for
something "better" when what's there is good enough already.
 
In several standards efforts I'm involved in (NESSIE, ISO 18033, ANSI X9F1),
and in the research community, a preference is emerging for RSA-KEM over
RSA-OAEP. Over time, formal standards bodies may therefore give preference
to RSA-KEM (while still acknowledging RSA-OAEP and perhaps even PKCS #1 v1.5
encryption for compatibility). Eventually, this will lead to a stronger
motivation to add RSA-KEM to S/MIME and other protocols. The issue here is
whether to do so sooner rather than later.
 
By the way, RSA has no proprietary interest in RSA-KEM, nor am I aware of
any patents claimed by others at this point.
 
-- Burt

-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Tuesday, May 07, 2002 4:18 PM
To: Kaliski, Burt; '[e-mail]'
Cc: Housley, Russ
Subject: RE: Why KEM?, RE: Charter Update



Burt; 

I agree that those are definitely advantages of KEM over OAEP.  However, a
number of standards (1363, PKCS#1, etc.) have already specified OAEP and
some people have already implemented it.  S/MIME is currently on the -04
version of a draft that mandates OAEP with AES. Thus, without a demonstrated
weakness with OAEP I still don't see a reason to change.  I don't see the
tighter bounds for KEM and the better architectural fit as being worth the
trouble of starting to specify a new encryption padding method.  Doing so
will necessarily cause additional interoperability and implementation
issues.  We already have an adequate replacement for PKCS #1 v1.5, why do we
need another one?

        Robert. 

 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g489QJl01011 for ietf-smime-bks; Wed, 8 May 2002 02:26:19 -0700 (PDT)
Received: from ws1-1.us4.outblaze.com (205-158-62-49.outblaze.com [205.158.62.49]) by above.proper.com (8.11.6/8.11.3) with SMTP id g489QHL01007 for <[e-mail]>; Wed, 8 May 2002 02:26:17 -0700 (PDT)
Received: (qmail 47881 invoked by uid 1001); 8 May 2002 09:26:13 -0000
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-Mailer: MIME-tools 5.41 (Entity 5.404)
Received: from [10.136.230.92] by ws1-1.us4.outblaze.com with http for [e-mail]; Wed, 08 May 2002 04:26:12 -0500
From: "Terje Tollisen" <[e-mail]>
To: [e-mail]
Date: Wed, 08 May 2002 04:26:12 -0500
Subject: Are certificates _required_ by the sender?
X-Originating-Ip: 10.136.230.92
X-Originating-Server: ws1-1.us4.outblaze.com
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>

Is the sender of an email required to have a certificate, or is it sufficient for the sender to have a copy of the certificate of the recipient? I am thinking of an automated system, where one party will always be the sender, and never receive emails. In addition, no signatures are required. Thus nobody will ever actually need the public key for the automated system. However, I’m uncertain if the sender can send S/MIME messages without having a certificate of it's own.

Thanks for your time
-Terry Tollisen

-- 
_______________________________________________
Sign-up for your own FREE Personalized E-mail at Mail.com
http://www.mail.com/?sr=signup



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47KIJe10866 for ietf-smime-bks; Tue, 7 May 2002 13:18:19 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47KI7L10850 for <[e-mail]>; Tue, 7 May 2002 13:18:07 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <K3ZDVHY8>; Tue, 7 May 2002 16:17:54 -0400
Message-ID: <[e-mail]>
From: Robert Zuccherato <[e-mail]>
To: "'Kaliski, Burt'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>
Subject: RE: Why KEM?, RE: Charter Update
Date: Tue, 7 May 2002 16:17:53 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F604.4465D130"
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 in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F604.4465D130
Content-Type: text/plain;
	charset="iso-8859-1"

Burt;

I agree that those are definitely advantages of KEM over OAEP.  However, a
number of standards (1363, PKCS#1, etc.) have already specified OAEP and
some people have already implemented it.  S/MIME is currently on the -04
version of a draft that mandates OAEP with AES. Thus, without a demonstrated
weakness with OAEP I still don't see a reason to change.  I don't see the
tighter bounds for KEM and the better architectural fit as being worth the
trouble of starting to specify a new encryption padding method.  Doing so
will necessarily cause additional interoperability and implementation
issues.  We already have an adequate replacement for PKCS #1 v1.5, why do we
need another one?

	Robert.

> -----Original Message-----
> From: Kaliski, Burt [mailto:[e-mail]]
> Sent: Monday, May 06, 2002 2:20 PM
> To: '[e-mail]'
> Cc: Housley, Russ; Kaliski, Burt
> Subject: RE: Why KEM?, RE: Charter Update
> 
> 
> 
> Russ asked me to join this discussion to explain the 
> motivation for KEM.
> (Please cc: me on further messages on this thread as I'm not 
> a subscriber to
> the ietf-smime list.) 
> RSA-KEM's primary advantages over RSA-OAEP are: 
> 1. RSA-KEM's security bounds are tighter. RSA-KEM has been 
> proved (in the
> random oracle model) to be very close in security to the RSA problem.
> RSA-OAEP has been proved (in the same model) to offer 
> security that grows in
> proportion to the security of the RSA problem, but for 
> typical RSA key sizes
> the provable level of security is not very high. While no 
> attacks faster
> than solving the RSA problem are known against RSA-OAEP if it 
> is properly
> implemented, it would be better if faster attacks could be ruled out
> explicitly. 
> 2. RSA-KEM fits better architecturally. RSA-KEM follows the 
> model described
> by Victor Shoup, which combines a public-key "encapsulation" 
> operation with
> a symmetric key operation, such as the AES KeyWrap. The same 
> symmetric key
> operation can be combined with different public-key methods (RSA,
> Diffie-Hellman, elliptic curve). It can also be used for wrapping a
> symmetric key with another symmetric key. Thus, in future versions of
> S/MIME, AES content-encryption keys can all be wrapped with 
> AES KeyWrap. The
> only difference among the public key methods would be how the 
> wrapping key
> is derived. RSA-OAEP, in contrast, uses a different technique 
> than other
> public-key methods (OAEP formatting) for processing the 
> symmetric keys. 
> RSA-OAEP is still fine to use, but RSA-KEM is better. As part 
> of continually
> improving the infrastructure, I believe it is worthwhile to introduce
> support for RSA-KEM as standards are updated. Since S/MIME 
> implementations
> are being upgraded to support AES, this is a convenient time 
> to introduce a
> more robust public-key method as well. 
> -- Burt Kaliski
> RSA Laboratories 
> 

------_=_NextPart_001_01C1F604.4465D130
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Why KEM?, RE: Charter Update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Burt;</FONT>
</P>

<P><FONT SIZE=3D2>I agree that those are definitely advantages of KEM =
over OAEP.&nbsp; However, a number of standards (1363, PKCS#1, etc.) =
have already specified OAEP and some people have already implemented =
it.&nbsp; S/MIME is currently on the -04 version of a draft that =
mandates OAEP with AES. Thus, without a demonstrated weakness with OAEP =
I still don't see a reason to change.&nbsp; I don't see the tighter =
bounds for KEM and the better architectural fit as being worth the =
trouble of starting to specify a new encryption padding method.&nbsp; =
Doing so will necessarily cause additional interoperability and =
implementation issues.&nbsp; We already have an adequate replacement =
for PKCS #1 v1.5, why do we need another one?</FONT></P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>Robert.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Kaliski, Burt [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Monday, May 06, 2002 2:20 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Housley, Russ; Kaliski, Burt</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Why KEM?, RE: Charter =
Update</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ asked me to join this discussion to =
explain the </FONT>
<BR><FONT SIZE=3D2>&gt; motivation for KEM.</FONT>
<BR><FONT SIZE=3D2>&gt; (Please cc: me on further messages on this =
thread as I'm not </FONT>
<BR><FONT SIZE=3D2>&gt; a subscriber to</FONT>
<BR><FONT SIZE=3D2>&gt; the ietf-smime list.) </FONT>
<BR><FONT SIZE=3D2>&gt; RSA-KEM's primary advantages over RSA-OAEP are: =
</FONT>
<BR><FONT SIZE=3D2>&gt; 1. RSA-KEM's security bounds are tighter. =
RSA-KEM has been </FONT>
<BR><FONT SIZE=3D2>&gt; proved (in the</FONT>
<BR><FONT SIZE=3D2>&gt; random oracle model) to be very close in =
security to the RSA problem.</FONT>
<BR><FONT SIZE=3D2>&gt; RSA-OAEP has been proved (in the same model) to =
offer </FONT>
<BR><FONT SIZE=3D2>&gt; security that grows in</FONT>
<BR><FONT SIZE=3D2>&gt; proportion to the security of the RSA problem, =
but for </FONT>
<BR><FONT SIZE=3D2>&gt; typical RSA key sizes</FONT>
<BR><FONT SIZE=3D2>&gt; the provable level of security is not very =
high. While no </FONT>
<BR><FONT SIZE=3D2>&gt; attacks faster</FONT>
<BR><FONT SIZE=3D2>&gt; than solving the RSA problem are known against =
RSA-OAEP if it </FONT>
<BR><FONT SIZE=3D2>&gt; is properly</FONT>
<BR><FONT SIZE=3D2>&gt; implemented, it would be better if faster =
attacks could be ruled out</FONT>
<BR><FONT SIZE=3D2>&gt; explicitly. </FONT>
<BR><FONT SIZE=3D2>&gt; 2. RSA-KEM fits better architecturally. RSA-KEM =
follows the </FONT>
<BR><FONT SIZE=3D2>&gt; model described</FONT>
<BR><FONT SIZE=3D2>&gt; by Victor Shoup, which combines a public-key =
&quot;encapsulation&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; operation with</FONT>
<BR><FONT SIZE=3D2>&gt; a symmetric key operation, such as the AES =
KeyWrap. The same </FONT>
<BR><FONT SIZE=3D2>&gt; symmetric key</FONT>
<BR><FONT SIZE=3D2>&gt; operation can be combined with different =
public-key methods (RSA,</FONT>
<BR><FONT SIZE=3D2>&gt; Diffie-Hellman, elliptic curve). It can also be =
used for wrapping a</FONT>
<BR><FONT SIZE=3D2>&gt; symmetric key with another symmetric key. Thus, =
in future versions of</FONT>
<BR><FONT SIZE=3D2>&gt; S/MIME, AES content-encryption keys can all be =
wrapped with </FONT>
<BR><FONT SIZE=3D2>&gt; AES KeyWrap. The</FONT>
<BR><FONT SIZE=3D2>&gt; only difference among the public key methods =
would be how the </FONT>
<BR><FONT SIZE=3D2>&gt; wrapping key</FONT>
<BR><FONT SIZE=3D2>&gt; is derived. RSA-OAEP, in contrast, uses a =
different technique </FONT>
<BR><FONT SIZE=3D2>&gt; than other</FONT>
<BR><FONT SIZE=3D2>&gt; public-key methods (OAEP formatting) for =
processing the </FONT>
<BR><FONT SIZE=3D2>&gt; symmetric keys. </FONT>
<BR><FONT SIZE=3D2>&gt; RSA-OAEP is still fine to use, but RSA-KEM is =
better. As part </FONT>
<BR><FONT SIZE=3D2>&gt; of continually</FONT>
<BR><FONT SIZE=3D2>&gt; improving the infrastructure, I believe it is =
worthwhile to introduce</FONT>
<BR><FONT SIZE=3D2>&gt; support for RSA-KEM as standards are updated. =
Since S/MIME </FONT>
<BR><FONT SIZE=3D2>&gt; implementations</FONT>
<BR><FONT SIZE=3D2>&gt; are being upgraded to support AES, this is a =
convenient time </FONT>
<BR><FONT SIZE=3D2>&gt; to introduce a</FONT>
<BR><FONT SIZE=3D2>&gt; more robust public-key method as well. </FONT>
<BR><FONT SIZE=3D2>&gt; -- Burt Kaliski</FONT>
<BR><FONT SIZE=3D2>&gt; RSA Laboratories </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F604.4465D130--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g46IKoQ24281 for ietf-smime-bks; Mon, 6 May 2002 11:20:50 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g46IKnL24276 for <[e-mail]>; Mon, 6 May 2002 11:20:49 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 May 2002 18:19: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 OAA01638 for <[e-mail]>; Mon, 6 May 2002 14:18:59 -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 g46IIxr18650 for <[e-mail]>; Mon, 6 May 2002 14:18:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <K2ZK9XXW>; Mon, 6 May 2002 14:20:46 -0400
Message-ID: <[e-mail]>
From: "Kaliski, Burt" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "Kaliski, Burt" <[e-mail]>
Subject: RE: Why KEM?, RE: Charter Update
Date: Mon, 6 May 2002 14:20:22 -0400 
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>

Russ asked me to join this discussion to explain the motivation for KEM.
(Please cc: me on further messages on this thread as I'm not a subscriber to
the ietf-smime list.) 
RSA-KEM's primary advantages over RSA-OAEP are: 
1. RSA-KEM's security bounds are tighter. RSA-KEM has been proved (in the
random oracle model) to be very close in security to the RSA problem.
RSA-OAEP has been proved (in the same model) to offer security that grows in
proportion to the security of the RSA problem, but for typical RSA key sizes
the provable level of security is not very high. While no attacks faster
than solving the RSA problem are known against RSA-OAEP if it is properly
implemented, it would be better if faster attacks could be ruled out
explicitly. 
2. RSA-KEM fits better architecturally. RSA-KEM follows the model described
by Victor Shoup, which combines a public-key "encapsulation" operation with
a symmetric key operation, such as the AES KeyWrap. The same symmetric key
operation can be combined with different public-key methods (RSA,
Diffie-Hellman, elliptic curve). It can also be used for wrapping a
symmetric key with another symmetric key. Thus, in future versions of
S/MIME, AES content-encryption keys can all be wrapped with AES KeyWrap. The
only difference among the public key methods would be how the wrapping key
is derived. RSA-OAEP, in contrast, uses a different technique than other
public-key methods (OAEP formatting) for processing the symmetric keys. 
RSA-OAEP is still fine to use, but RSA-KEM is better. As part of continually
improving the infrastructure, I believe it is worthwhile to introduce
support for RSA-KEM as standards are updated. Since S/MIME implementations
are being upgraded to support AES, this is a convenient time to introduce a
more robust public-key method as well. 
-- Burt Kaliski
RSA Laboratories 
		From: Mike Just <[e-mail]>
		To: "'Housley, Russ'" <[e-mail]>
		Cc: [e-mail]
		Subject: RE: Why KEM?, RE: Charter Update
		Date: Wed, 1 May 2002 13:33:09 -0400 
		X-Mailer: Internet Mail Service (5.5.2653.19)
		
		Thanks Russ. I did manage to look at your slides when you
first posted them to the list on April 17th. I found them very helpful.
However, I think Robert has raised some good points (based on the issues
claimed in your slides) that question the motivation for even considering a
move to KEM. I've attached his email below for your convenience. I think we
have chosen a very good direction already with OAEP and am not convinced
that we need to change this. 
		
		Mike
		
		
		
		---- Robert's email of 04/19/2002 --- 
			-----Original Message----- 
			From: Robert Zuccherato
[<mailto:[e-mail]>] 
			Sent: Friday, April 19, 2002 10:46 AM 
			To: 'Housley, Russ'; [e-mail] 
			Subject: RE: Charter Update
			
			Russ; 
			
			Having not attended the Minneapolis meeting I must
say that I was very surprised by your recommendation to drop OAEP as the
MUST implement key transport mechanism with AES in favour of KEM. It wasn't
all that long ago that you were attempting to get everyone (S/MIME, TLS,
X9.44) to agree on requiring OAEP with AES as a method of transitioning to
OAEP from PKCS#1 v1.5. Partly as a result of that effort, implementations of
OAEP have started to appear (e.g. OpenSSL) and transitions to OAEP can
actually now start to occur. If we are going to introduce a new MUST
algorithm, and thus additional uncertainty about what to use and how to
transition, we really should have a good reason.
			
			In your presentation you say that KEM has better
security proofs. That may be, however, OAEP is still secure. No actual
weaknesses in it have been found. On RSA's website there is a description of
recent results on OAEP that says "... it makes little sense replacing OAEP
with a "more secure" encoding method, because if a CCA2 adversary is able to
break RSAEP-OAEP, then she will be able to break RSAEP equipped with any
encoding method (if maybe slightly less efficiently)."
(<http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.html>)
Thus, there is no need to introduce KEM for security reasons.
			
			Your presentation also lists some standards that
already include KEM. However, all of the ones that are listed except TLS
also specify OAEP (ANSI X9.44, IEEE P1363, ISO/IEC 18033-2, PKCS#1, S/MIME).
TLS, while it specifies a variant of KEM, doesn't actually use anything that
is compatible with the KEM that S/MIME (and the other groups listed) would
be using. I would also like to point out that XML Encryption has OAEP as a
required key transport method. At this point it does seem like OAEP is
starting to get adopted by other groups and thus introducing KEM now seems
to be counterproductive.
			
			It is true that with OAEP the message length is
bounded. However, for our requirements here, is that really an issue? 
			
			For these reasons I think we should reconsider your
proposal to use RSA-KEM instead of RSA-OAEP in draft-ietf-smime-aes-alg.
			
			Robert Zuccherato 
			Entrust, Inc. 
		--------------------------------------------
		
			-----Original Message----- 
			From: Housley, Russ
[<mailto:[e-mail]>] 
			Sent: Wednesday, May 01, 2002 1:22 PM 
			To: Mike Just 
			Cc: [e-mail] 
			Subject: Re: Why KEM?, RE: Charter Update
			
			Mike:
			
			I think that I did respond to Robert's question. At
IETF 53, I gave a presentation on this subject. You can see the slides at
<http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html>.
			
			Russ
			
			
			
			At 01:14 PM 5/1/2002 -0400, Mike Just wrote:
			
				It's not clear to me that there is consensus
on this path (unfortunately, there seemed to be no reaction on either side
to this email) as reflected in the latest version of the Charter. 
				I'd like to re-iterate Robert's concerns
(from his e-mail of 04/19/2002) and ask the fundamental question: Why are we
even considering KEM when we already have a sufficient solution with OAEP? 
				Mike 
				-----Original Message----- 
				From: Housley, Russ
[<mailto:[e-mail]>] 
				Sent: Wednesday, April 24, 2002 5:14 PM 
				To: [e-mail] 
				Subject: RE: Charter Update 
				
				
				
				Is the WG consensus that RSA-OAEP, RSA-KEM,
and AES should be in separate, 
				independent documents. This would allow AES
to be used with any of the key 
				management techniques? 
				
				Russ 



Received: by above.proper.com (8.11.6/8.11.3) id g43KiG421987 for ietf-smime-bks; Fri, 3 May 2002 13:44: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 g43KiFa21983 for <[e-mail]>; Fri, 3 May 2002 13:44:15 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with SMTP ; Fri, 3 May 2002 13:44:05 -0700
Message-ID: <084401c1f2e2$16c2f250$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: rfc2633bis and multipart/encrypted
Date: Fri, 3 May 2002 13:35:39 -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>

----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Sent: Friday, May 03, 2002 7:15 AM
Subject: Re: rfc2633bis and multipart/encrypted


>
> Marc Mutz <[e-mail]> quotes:
>
> >While we are on the topic of MIME and encryption -- does anyone know
> >the history behind S/MIME not using multipart/encrypted of RFC 1847
> >for encrypted data?
>
> Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
> worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent
were a
> bigger hammer, so S/MIME won.

This is mostly true.  Another part of this is that we ended up adopting
multipart/signed, and deliberately chose not to adopt multipart/encrypted
for some reason (which I think is what Russ pointed out as backward
compatibility).  I think the general argument was that it didn't add
anything to the protocol or the processing of the data, and the only thing
that it might add in our case is a potential clue to the processing agent
that "this thing is encrypted".  I thought there was a thread about this,
but I couldn't find it.

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43GvPY14893 for ietf-smime-bks; Fri, 3 May 2002 09:57:25 -0700 (PDT)
Received: from c000.snv.cp.net (h008.c000.snv.cp.net [209.228.32.72]) by above.proper.com (8.11.6/8.11.3) with SMTP id g43GvNa14889 for <[e-mail]>; Fri, 3 May 2002 09:57:23 -0700 (PDT)
Received: (cpmta 4736 invoked from network); 3 May 2002 09:57:19 -0700
Received: from 217.82.82.229 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.72) with SMTP; 3 May 2002 09:57:19 -0700
X-Sent: 3 May 2002 16:57:19 GMT
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: Re: rfc2633bis and multipart/encrypted
Date: Fri, 3 May 2002 18:56:41 +0200
User-Agent: KMail/1.4.5
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <[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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Maybe I should introduce myself first:
I'm a KMail (kmail.kde.org) developer and responsible for the next-generation 
message handling code that will creep into KMail over the next months.
As such, I'm partly remotely, partly directly involved in the Aegypten Project 
of the German government (www.gnupg.org/aegypten), which aims to bring S/MIME 
support to the well-known OpenPGP imlementation GnuPG, and incorporate 
support into OSS mail clients, chiefly KMail and mutt.

On Friday 03 May 2002 16:15, Peter Gutmann wrote:
> Marc Mutz <[e-mail]> quotes:
> >While we are on the topic of MIME and encryption -- does anyone know
> >the history behind S/MIME not using multipart/encrypted of RFC 1847
> >for encrypted data?
>
> Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
> worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent were
> a bigger hammer, so S/MIME won.

The few arguments for using an application subtype for encrypted/signed data 
and CRLs are handwaving at best.
Now we implementors are stuck with a - let's say - suboptimal solution and the 
clean solution is disallowed by not even mentioning it in the RFC.

What are arguments against including
multipart/encrypted; protocol="application/pkcs7-encrypted"
with a "MAY create / SHOULD understand" in the successor of RFC 2633?

This would at least open the door for adoption in the future.
Then S/MIMEv2 -> S/MIMEv3 transition seems to have had some potentially much 
more grave disruptions than introducing mp/encrypted.

> (Having said that, multipart/encrypted is pretty clunky (signed data is a
>  different issue). 

- From an implementor's POV, multipart/encrypted is by no means "clunky". Yes, 
it adds an outer and an inner body part of hot air around the interesting 
stuff, but the headers of the "hot air" body parts are what counts. They 
contain the information used by the MUA to dispatch the content to the right 
backend crypto engine. What's more, it allows MUAs to guess (rightly so) that 
what comes back from the crypto engine is only another mime entity (something 
that needs further processing by the MUA itself), while that isn't at all 
clear when using application/pkcs7-mime. There, the MUA doesn't even know 
whether it's an CRL, a signed document, an encrypted document or simply 
CMS-wrapped data without cryptography. :-( (Without particular knowledge of 
S/MIME, that is.)

I understand that some (to me obscure) gatewaying and backwards compat issues, 
paired with politics, have prevented the inclusion of an elegant solution. 
app/pgp has been deprecated - and successfully so. Time to try the same with 
app/pkcs7-mime, I'd say.

> OTOH given the perpetual-motion-machine nature of
> debates over this in 1995-1996, it's arguable that any decision would have
> been regarded as bad by some subset of people).

Back at politics, then... :-(

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80sFJ3oWD+L2/6DgRAifHAKCiuoPG4tIoErrapAH26P5sRBRiIQCfUS3r
R++N3nYDzvGfdHUXlPD+l+A=
=ZZbO
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.11.6/8.11.3) id g43EQAY10383 for ietf-smime-bks; Fri, 3 May 2002 07:26:10 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g43EQ9a10378 for <[e-mail]>; Fri, 3 May 2002 07:26:09 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 May 2002 14:24:41 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 KAA03297 for <[e-mail]>; Fri, 3 May 2002 10:24:21 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g43EQ8q10043 for <[e-mail]>; Fri, 3 May 2002 10:26:08 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX155WC>; Fri, 3 May 2002 10:23:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.64]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX155WA; Fri, 3 May 2002 10:23:26 -0400
From: "Housley, Russ" <[e-mail]>
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 03 May 2002 10:18:26 -0400
Subject: Re: rfc2633bis and multipart/encrypted
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>

Marc:

I recall a discussion about maintaining backward compatibility with S/MIME v2.

Russ


At 03:36 PM 5/3/2002 +0200, Marc Mutz wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi!
>
>I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847 
>way of
>_encrypting_ mime entities, but describes mp/signed as _preferred_.
>
>In message <[e-mail]>, Simon Josefsson wrote back
>in December:
> > While we are on the topic of MIME and encryption -- does anyone know
> > the history behind S/MIME not using multipart/encrypted of RFC 1847
> > for encrypted data?  This decision causes some pain when implementing
> > a client that supports both PGP and CMS; S/MIME encryption becomes a
> > special case.  Multipart/encrypted doesn't seem to have been discussed
> > here, judging by the mail archives at least.
>
>There was no reply.
>
>The only references I could find about mp/encrypted and rfc1847 were some
>comments about gateways breaking rfc1847, which is probably what the
>respective comments in the final rfc reflect.
>
>But given the rules for determining whether a given message is an S/MIME
>message, anything that could conceivably be done to a mp/encrypted at
>gateways would downgrade to the "filename extension" rule of S/MIME message
>detection.
>
>Thus, I don't see a reason to not use mp/encrypted - esp. as mp/signed is the
>preferred mode for signing.
>
>Can someone enlighten me?
>
>If there are no reasons against it, I'd propose to include it as the 
>preferred
>method of encrypting and define a new mimetype app/pkcs7-encrypted.
>
>It will degrade gracefully since old MUAs should treat unknown multipart
>subtypes as mp/mixed and by the file-extension rule, the app/octet-stream
>with filename *.p7m will be recognized as part of a S/MIME message.
>
>Marc
>
>- --
>Marc Mutz <[e-mail]>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.0.7 (GNU/Linux)
>
>iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
>MEmwcc1Np37bsO8hTutUTSY=
>=iZh1
>-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43EFn408900 for ietf-smime-bks; Fri, 3 May 2002 07:15:49 -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 g43EFka08894 for <[e-mail]>; Fri, 3 May 2002 07:15:47 -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.2/8.12.2) with ESMTP id g43EFfK4006111; Sat, 4 May 2002 02:15:41 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id CAA74677; Sat, 4 May 2002 02:15:39 +1200 (NZST) (sender [e-mail])
Date: Sat, 4 May 2002 02:15:39 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  rfc2633bis and multipart/encrypted
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>

Marc Mutz <[e-mail]> quotes:

>While we are on the topic of MIME and encryption -- does anyone know
>the history behind S/MIME not using multipart/encrypted of RFC 1847
>for encrypted data?

Politics AFAIK.  The encryption stuff in RFC 1847 was part of the MOSS
worldview, and MOSS != S/MIME.  At the time, RSADSI and the RSA patent were a
bigger hammer, so S/MIME won.

(Having said that, multipart/encrypted is pretty clunky (signed data is a
 different issue).  OTOH given the perpetual-motion-machine nature of debates
 over this in 1995-1996, it's arguable that any decision would have been
 regarded as bad by some subset of people).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g43DbSs06734 for ietf-smime-bks; Fri, 3 May 2002 06:37:28 -0700 (PDT)
Received: from c000.snv.cp.net (h020.c000.snv.cp.net [209.228.32.84]) by above.proper.com (8.11.6/8.11.3) with SMTP id g43DbRa06730 for <[e-mail]>; Fri, 3 May 2002 06:37:27 -0700 (PDT)
Received: (cpmta 14588 invoked from network); 3 May 2002 06:37:22 -0700
Received: from 80.130.168.176 (HELO dirichlet.mathematik.uni-bielefeld.de) by smtp.mutz.com (209.228.32.84) with SMTP; 3 May 2002 06:37:22 -0700
X-Sent: 3 May 2002 13:37:22 GMT
From: Marc Mutz <[e-mail]>
Organization: KDE
To: [e-mail]
Subject: rfc2633bis and multipart/encrypted
Date: Fri, 3 May 2002 15:36:53 +0200
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
Content-Description: clearsigned data
Content-Disposition: inline
Message-Id: <[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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

I wonder why rfc2633(bis) doesn't mention (= doesn't allow) the rfc1847 way of 
_encrypting_ mime entities, but describes mp/signed as _preferred_.

In message <[e-mail]>, Simon Josefsson wrote back 
in December:
> While we are on the topic of MIME and encryption -- does anyone know
> the history behind S/MIME not using multipart/encrypted of RFC 1847
> for encrypted data?  This decision causes some pain when implementing
> a client that supports both PGP and CMS; S/MIME encryption becomes a
> special case.  Multipart/encrypted doesn't seem to have been discussed
> here, judging by the mail archives at least.

There was no reply.

The only references I could find about mp/encrypted and rfc1847 were some 
comments about gateways breaking rfc1847, which is probably what the 
respective comments in the final rfc reflect.

But given the rules for determining whether a given message is an S/MIME 
message, anything that could conceivably be done to a mp/encrypted at 
gateways would downgrade to the "filename extension" rule of S/MIME message 
detection.

Thus, I don't see a reason to not use mp/encrypted - esp. as mp/signed is the 
preferred mode for signing.

Can someone enlighten me?

If there are no reasons against it, I'd propose to include it as the preferred 
method of encrypting and define a new mimetype app/pkcs7-encrypted.

It will degrade gracefully since old MUAs should treat unknown multipart 
subtypes as mp/mixed and by the file-extension rule, the app/octet-stream 
with filename *.p7m will be recognized as part of a S/MIME message.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80pJ13oWD+L2/6DgRAqo+AKCEVWA8PCuwWhL9qqFHOWSGplgLVwCgxFDX
MEmwcc1Np37bsO8hTutUTSY=
=iZh1
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4284Tb28966 for ietf-smime-bks; Thu, 2 May 2002 01:04:29 -0700 (PDT)
Received: from mailbu.belbone.be (mailbu.belbone.be [195.13.2.31]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4284Ra28956 for <[e-mail]>; Thu, 2 May 2002 01:04:27 -0700 (PDT)
Received: from ETRUST001 (195.13.18.125) by mailbu.belbone.be; 2 May 2002 10:04:26 +0200
From: "Omer Hasret" <[e-mail]>
To: "'Bonatti, Chris'" <[e-mail]>
Cc: "'IETF SMIME WG'" <[e-mail]>
Subject: RE: Protecting fields via message/rfc822 and merging issues
Date: Thu, 2 May 2002 10:04:23 +0200
Message-ID: <003301c1f1af$f94e8cd0$0900a8c0@ETRUST001>
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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: Normal
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>

Suggestion for "From:" field below,

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Bonatti, Chris
Sent: mercredi 1 mai 2002 20:15
To: Blake Ramsdell
Cc: IETF SMIME WG
Subject: RE: Protecting fields via message/rfc822 and merging issues



Hi Blake,

  See embedded comments below.

> > b) Discarding the outer 822 message and looking only at the inner 
> > fields works provided that the inner message is complete.  However, 
> > it does not work if only a partial list of fields is included in the

> > inner message.  Also, since we negate the usefulness of the outer 
> > message in all cases, we strongly encourage that it be a blank
> > "dummy" message.  This would effectively require the
> > application to do security processing even to display
> > the originator, subject line, etc. -- fields normally
> > shown in a mailbox view.  Blake also correctly pointed
> > out that this would squash useful headers like "trace"
> > (i.e., Received:...) and things added by list exploders.
> 
> [bcr] Right, and I think this also includes header security
> policies (not necessarily cryptography, but generic 
> rewriting) applied by the organization such as rewritten 
> address lines for host name hiding or adding disclosed 
> recipients.  I think this is where we start running into a 
> problem, and where we're in danger of failing.

  I don't see this as so big a problem with (c).  All you need to do to
make sure that you don't override the outer fields is to ensure that
recipients aren't originating those fields in the inner wrapper.  I
could think of a number of ways to implement that.  In fact, it sounds
like an excellent market discriminator.  :-)


> > d) Include the signal in a CMS attribute - In a signed-only
> > or signed-and-encrypted message, the attribute should 
> > probably be in the inner signedAttrs.  For encrypted-only 
> > messages, it would have to go in the unprotectedAttrs, 
> > but this is not optimal since it shares the disadvantages 
> > of (a).  If this is the way forward, we have to have the 
> > subsequent discussion of whether to use an existing or 
> > new attribute.
> > 
> >   Obviously, my belief is that (d) is the only one that
> > works.  However, I'm not happy with how it works in the 
> > encrypted-only case.  I'm also somewhat sensitive to 
> > "attribute bloat".  I therefore earnestly hope somebody 
> > else sees something that I've missed.
> 
> [bcr] I think that the biggest problem I'm having is that
> we're trying to mix authenticated / unauthenticated / 
> encrypted / unencrypted headers together and try to do the 
> right thing in an automated fashion.  As much as as we might 
> like to define this, I think the only option might be to take 
> the coward's way out and explain that the presentation and 
> merging of the headers are the problem of the client, and 
> that it's not possible to automatically mix them.  The 
> realization that I'm coming to is that there is no utility in 
> merging the headers, and we shouldn't even attempt it, and we 
> should document that the client needs to potentially make 
> decisions about how much to trust the internal headers vs. 
> the external headers, and it is their responsibility to 
> demonstrate the separation.

  I take the point I think you're making that there might be numerous
GOOD ways of doing this depending on your assumptions, and that there
might therefore not be a BEST way.  If a product is capable of showing
you both and indicating what is authenticated or encrypted and what
isn't, that might be best.

> [bcr] My thinking right now is along the lines of the
> following, and I could very well be missing some important 
> issues:
> 
> 1. Use message/rfc822 with a full set of headers for the
> inner protected content.  This is backward compatible, and 
> it's entirely possible that existing clients might even 
> process this correctly.
> 
> 2. Define placebo values for any outer message required
> fields.

  I didn't figure we needed to do this, but it's more important in the
scenario you suggest.  For "Date:" I would suggest 1/1/1970 (zero in
UNIX, I think).  I guess I don't have a value to suggest for "From:".
The difficulty is that you need to have a minimally conformant address.
Anybody out there have a suggestion?


--------------------- From: John Doe?


> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps
we can describe a default rule similar to the option (c) I described,
hanging under a SHOULD.  That way, if there was a good reason to do
something different it's okay.

Best regards,
Chris





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41IEo022192 for ietf-smime-bks; Wed, 1 May 2002 11:14:50 -0700 (PDT)
Received: from Obsidian (pcp833816pcs.nrockv01.md.comcast.net [68.50.112.5]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41IEna22188 for <[e-mail]>; Wed, 1 May 2002 11:14:49 -0700 (PDT)
Received: from [127.0.0.1] by Obsidian (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 1 May 2002 14:14:50 -0400
From: "Bonatti, Chris" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
Cc: "IETF SMIME WG" <[e-mail]>
Subject: RE: Protecting fields via message/rfc822 and merging issues
Date: Wed, 1 May 2002 14:14:49 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <0c0901c1f011$8131cf40$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g41IEoa22189
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>

Hi Blake,

  See embedded comments below.

> > b) Discarding the outer 822 message and looking only at the
> > inner fields works provided that the inner message is
> > complete.  However, it does not work if only a partial
> > list of fields is included in the inner message.  Also,
> > since we negate the usefulness of the outer message in
> > all cases, we strongly encourage that it be a blank
> > "dummy" message.  This would effectively require the
> > application to do security processing even to display
> > the originator, subject line, etc. -- fields normally
> > shown in a mailbox view.  Blake also correctly pointed
> > out that this would squash useful headers like "trace"
> > (i.e., Received:...) and things added by list exploders.
> 
> [bcr] Right, and I think this also includes header security 
> policies (not necessarily cryptography, but generic 
> rewriting) applied by the organization such as rewritten 
> address lines for host name hiding or adding disclosed 
> recipients.  I think this is where we start running into a 
> problem, and where we're in danger of failing.

  I don't see this as so big a problem with (c).  All you need to do to make sure that you don't override the outer fields is to ensure that recipients aren't originating those fields in the inner wrapper.  I could think of a number of ways to implement that.  In fact, it sounds like an excellent market discriminator.  :-)


> > d) Include the signal in a CMS attribute - In a signed-only 
> > or signed-and-encrypted message, the attribute should 
> > probably be in the inner signedAttrs.  For encrypted-only 
> > messages, it would have to go in the unprotectedAttrs, 
> > but this is not optimal since it shares the disadvantages 
> > of (a).  If this is the way forward, we have to have the 
> > subsequent discussion of whether to use an existing or 
> > new attribute.
> > 
> >   Obviously, my belief is that (d) is the only one that 
> > works.  However, I'm not happy with how it works in the 
> > encrypted-only case.  I'm also somewhat sensitive to 
> > "attribute bloat".  I therefore earnestly hope somebody 
> > else sees something that I've missed.
> 
> [bcr] I think that the biggest problem I'm having is that 
> we're trying to mix authenticated / unauthenticated / 
> encrypted / unencrypted headers together and try to do the 
> right thing in an automated fashion.  As much as as we might 
> like to define this, I think the only option might be to take 
> the coward's way out and explain that the presentation and 
> merging of the headers are the problem of the client, and 
> that it's not possible to automatically mix them.  The 
> realization that I'm coming to is that there is no utility in 
> merging the headers, and we shouldn't even attempt it, and we 
> should document that the client needs to potentially make 
> decisions about how much to trust the internal headers vs. 
> the external headers, and it is their responsibility to 
> demonstrate the separation.

  I take the point I think you're making that there might be numerous GOOD ways of doing this depending on your assumptions, and that there might therefore not be a BEST way.  If a product is capable of showing you both and indicating what is authenticated or encrypted and what isn't, that might be best.

> [bcr] My thinking right now is along the lines of the 
> following, and I could very well be missing some important 
> issues:
> 
> 1. Use message/rfc822 with a full set of headers for the 
> inner protected content.  This is backward compatible, and 
> it's entirely possible that existing clients might even 
> process this correctly.
> 
> 2. Define placebo values for any outer message required 
> fields.

  I didn't figure we needed to do this, but it's more important in the scenario you suggest.  For "Date:" I would suggest 1/1/1970 (zero in UNIX, I think).  I guess I don't have a value to suggest for "From:".  The difficulty is that you need to have a minimally conformant address.  Anybody out there have a suggestion?

> 3. Explain the client considerations for presentation.

  I still think that we can do better than saying nothing here.  Perhaps we can describe a default rule similar to the option (c) I described, hanging under a SHOULD.  That way, if there was a good reason to do something different it's okay.

Best regards,
Chris





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41HXEH21027 for ietf-smime-bks; Wed, 1 May 2002 10:33:14 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41HXDa21023 for <[e-mail]>; Wed, 1 May 2002 10:33:13 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KCNTRCFZ>; Wed, 1 May 2002 13:33:10 -0400
Message-ID: <[e-mail]>
From: Mike Just <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Why KEM?, RE: Charter Update
Date: Wed, 1 May 2002 13:33:09 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F136.42A01540"
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 in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F136.42A01540
Content-Type: text/plain

Thanks Russ.  I did manage to look at your slides when you first posted them
to the list on April 17th.  I found them very helpful.   However, I think
Robert has raised some good points (based on the issues claimed in your
slides) that question the motivation for even considering a move to KEM.
I've attached his email below for your convenience.  I think we have chosen
a very good direction already with OAEP and am not convinced that we need to
change this.  
 
Mike
 
 
 
---- Robert's email of 04/19/2002 ---

-----Original Message-----
From: Robert Zuccherato [mailto:[e-mail]]
Sent: Friday, April 19, 2002 10:46 AM
To: 'Housley, Russ'; [e-mail]
Subject: RE: Charter Update



Russ; 

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

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

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

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

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


Robert Zuccherato 
Entrust, Inc. 

--------------------------------------------
 
 

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Wednesday, May 01, 2002 1:22 PM
To: Mike Just
Cc: [e-mail]
Subject: Re: Why KEM?, RE: Charter Update


Mike:

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

Russ


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



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

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

Mike 

-----Original Message----- 
From: Housley, Russ [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Wednesday, April 24, 2002 5:14 PM 
To: [e-mail] 
Subject: RE: Charter Update 


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

Russ 


------_=_NextPart_001_01C1F136.42A01540
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<META content=3D"MSHTML 5.50.4913.1100" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff size=3D2>Thanks=20
Russ.&nbsp; I did manage to look at your slides when you first posted =
them to=20
the list on April 17th.&nbsp; I found them very helpful.&nbsp;&nbsp; =
However, I=20
think Robert has raised some good points (based on the issues claimed =
in your=20
slides) that question the motivation for even considering a move to =
KEM.&nbsp;=20
I've attached his email below for your convenience.&nbsp; I think we =
have chosen=20
a very good direction already with OAEP and am not convinced that we =
need to=20
change this.&nbsp; </FONT></SPAN></DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Mike</FONT></SPAN></DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff size=3D2>----=20
Robert's email of 04/19/2002 ---</FONT></SPAN></DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff size=3D2>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Robert Zuccherato =

  [mailto:[e-mail]]<BR><B>Sent:</B> Friday, April =
19, 2002=20
  10:46 AM<BR><B>To:</B> 'Housley, Russ'; =
[e-mail]<BR><B>Subject:</B>=20
  RE: Charter Update<BR><BR></FONT></DIV>
  <P><FONT size=3D2>Russ;</FONT> </P>
  <P><FONT size=3D2>Having not attended the Minneapolis meeting I must =
say that I=20
  was very surprised by your recommendation to drop OAEP as the MUST =
implement=20
  key transport mechanism with AES in favour of KEM.&nbsp; It wasn't =
all that=20
  long ago that you were attempting to get everyone (S/MIME, TLS, =
X9.44) to=20
  agree on requiring OAEP with AES as a method of transitioning to OAEP =
from=20
  PKCS#1 v1.5.&nbsp; Partly as a result of that effort, implementations =
of OAEP=20
  have started to appear (e.g. OpenSSL) and transitions to OAEP can =
actually now=20
  start to occur.&nbsp; If we are going to introduce a new MUST =
algorithm, and=20
  thus additional uncertainty about what to use and how to transition, =
we really=20
  should have a good reason.</FONT></P>
  <P><FONT size=3D2>In your presentation you say that KEM has better =
security=20
  proofs.&nbsp; That may be, however, OAEP is still secure.&nbsp; No =
actual=20
  weaknesses in it have been found.&nbsp; On RSA's website there is a=20
  description of recent results on OAEP that says "... it makes little =
sense=20
  replacing OAEP with a "more secure" encoding method, because if a =
CCA2=20
  adversary is able to break RSAEP-OAEP, then she will be able to break =
RSAEP=20
  equipped with any encoding method (if maybe slightly less =
efficiently)."&nbsp;=20
  (<A target=3D_blank=20
  =
href=3D"http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.h=
tml">http://www.rsasecurity.com/rsalabs/rsa_algorithm/oaep_security.html=
</A>)&nbsp;=20
  Thus, there is no need to introduce KEM for security =
reasons.</FONT></P>
  <P><FONT size=3D2>Your presentation also lists some standards that =
already=20
  include KEM.&nbsp; However, all of the ones that are listed except =
TLS also=20
  specify OAEP (ANSI X9.44, IEEE P1363, ISO/IEC 18033-2, PKCS#1, =
S/MIME).&nbsp;=20
  TLS, while it specifies a variant of KEM, doesn't actually use =
anything that=20
  is compatible with the KEM that S/MIME (and the other groups listed) =
would be=20
  using.&nbsp; I would also like to point out that XML Encryption has =
OAEP as a=20
  required key transport method.&nbsp; At this point it does seem like =
OAEP is=20
  starting to get adopted by other groups and thus introducing KEM now =
seems to=20
  be counterproductive.</FONT></P>
  <P><FONT size=3D2>It is true that with OAEP the message length is =
bounded.&nbsp;=20
  However, for our requirements here, is that really an issue?&nbsp; =
</FONT></P>
  <P><FONT size=3D2>For these reasons I think we should reconsider your =
proposal=20
  to use RSA-KEM instead of RSA-OAEP in =
draft-ietf-smime-aes-alg.</FONT></P><BR>
  <P><FONT size=3D2>Robert Zuccherato</FONT> <BR><FONT =
size=3D2>Entrust, Inc.</FONT>=20
  </P></BLOCKQUOTE></FONT></SPAN></DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>--------------------------------------------</FONT></SPAN></DIV=
>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D364562717-01052002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Housley, Russ=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, May 01, =
2002 1:22=20
  PM<BR><B>To:</B> Mike Just<BR><B>Cc:</B> =
[e-mail]<BR><B>Subject:</B>=20
  Re: Why KEM?, RE: Charter Update<BR><BR></FONT></DIV>Mike:<BR><BR>I =
think that=20
  I did respond to Robert's question.&nbsp; At IETF 53, I gave a =
presentation on=20
  this subject.&nbsp; You can see the slides at <A=20
  =
href=3D"http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html"=
=20
  =
eudora=3D"autourl">http://www.ietf.org/proceedings/02mar/slides/smime-1/=
index.html</A>.<BR><BR>Russ<BR><BR><BR>At=20
  01:14 PM 5/1/2002 -0400, Mike Just wrote:<BR><BR>
  <BLOCKQUOTE class=3Dcite cite type=3D"cite"><FONT size=3D2>It's not =
clear to me=20
    that there is consensus on this path (unfortunately, there seemed =
to be no=20
    reaction on either side to this email) as reflected in the latest =
version of=20
    the Charter.<BR></FONT><BR><FONT size=3D2>I'd like to re-iterate =
Robert's=20
    concerns (from his e-mail of 04/19/2002) and ask the fundamental =
question:=20
    Why are we even considering KEM when we already have a sufficient =
solution=20
    with OAEP?<BR></FONT><BR><FONT size=3D2>Mike <BR></FONT><BR><FONT=20
    size=3D2>-----Original Message-----</FONT> <BR><FONT size=3D2>From: =
Housley,=20
    Russ [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>=20
    <BR><FONT size=3D2>Sent: Wednesday, April 24, 2002 5:14 PM</FONT> =
<BR><FONT=20
    size=3D2>To: [e-mail]</FONT> <BR><FONT size=3D2>Subject: =
RE: Charter=20
    Update</FONT> <BR><BR><BR><FONT size=3D2>Is the WG consensus that =
RSA-OAEP,=20
    RSA-KEM, and AES should be in separate, </FONT><BR><FONT =
size=3D2>independent=20
    documents.&nbsp; This would allow AES to be used with any of the =
key=20
    </FONT><BR><FONT size=3D2>management techniques?</FONT> =
<BR><BR><FONT=20
    size=3D2>Russ</FONT> </BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1F136.42A01540--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41HNBJ20499 for ietf-smime-bks; Wed, 1 May 2002 10:23:11 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41HN9a20493 for <[e-mail]>; Wed, 1 May 2002 10:23:09 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 17:21:44 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 NAA06753 for <[e-mail]>; Wed, 1 May 2002 13:21:25 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g41HNAT22866 for <[e-mail]>; Wed, 1 May 2002 13:23:10 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1Z9TQ>; Wed, 1 May 2002 13:20:35 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.38]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1Z9TL; Wed, 1 May 2002 13:20:28 -0400
From: "Housley, Russ" <[e-mail]>
To: Mike Just <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 01 May 2002 13:21:30 -0400
Subject: Re: Why KEM?, RE: Charter Update
In-Reply-To: <[e-mail] .com>
Mime-Version: 1.0
Content-Type: text/html; 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>

<html>
Mike:<br><br>
I think that I did respond to Robert's question.&nbsp; At IETF 53, I gave
a presentation on this subject.&nbsp; You can see the slides at
<a href="http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html" eudora="autourl">http://www.ietf.org/proceedings/02mar/slides/smime-1/index.html</a>.<br><br>
Russ<br><br>
<br>
At 01:14 PM 5/1/2002 -0400, Mike Just wrote:<br><br>
<blockquote type=cite class=cite cite><font size=2>It's not clear to me
that there is consensus on this path (unfortunately, there seemed to be
no reaction on either side to this email) as reflected in the latest
version of the Charter.<br>
</font><br>
<font size=2>I'd like to re-iterate Robert's concerns (from his e-mail of
04/19/2002) and ask the fundamental question: Why are we even considering
KEM when we already have a sufficient solution with OAEP?<br>
</font><br>
<font size=2>Mike <br>
</font><br>
<font size=2>-----Original Message-----</font> <br>
<font size=2>From: Housley, Russ
[<a href="mailto:[e-mail]">mailto:[e-mail]</a>]</font>
<br>
<font size=2>Sent: Wednesday, April 24, 2002 5:14 PM</font> <br>
<font size=2>To: [e-mail]</font> <br>
<font size=2>Subject: RE: Charter Update</font> <br><br>
<br>
<font size=2>Is the WG consensus that RSA-OAEP, RSA-KEM, and AES should
be in separate, </font><br>
<font size=2>independent documents.&nbsp; This would allow AES to be used
with any of the key </font><br>
<font size=2>management techniques?</font> <br><br>
<font size=2>Russ</font> </blockquote></html>


Received: by above.proper.com (8.11.6/8.11.3) id g41HEAp20288 for ietf-smime-bks; Wed, 1 May 2002 10:14:10 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41HE8a20284 for <[e-mail]>; Wed, 1 May 2002 10:14:08 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <KCNTRB63>; Wed, 1 May 2002 13:14:05 -0400
Message-ID: <[e-mail]>
From: Mike Just <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Subject: Why KEM?, RE: Charter Update
Date: Wed, 1 May 2002 13:14:03 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F133.97C1A140"
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 in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1F133.97C1A140
Content-Type: text/plain

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

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

Mike 

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Wednesday, April 24, 2002 5:14 PM
To: [e-mail]
Subject: RE: Charter Update



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

Russ

------_=_NextPart_001_01C1F133.97C1A140
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>Why KEM?, RE: Charter Update</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>It's not clear to me that there is consensus on this =
path (unfortunately, there seemed to be no reaction on either side to =
this email) as reflected in the latest version of the =
Charter.</FONT></P>

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

<P><FONT SIZE=3D2>Mike </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, April 24, 2002 5:14 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Charter Update</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Is the WG consensus that RSA-OAEP, RSA-KEM, and AES =
should be in separate, </FONT>
<BR><FONT SIZE=3D2>independent documents.&nbsp; This would allow AES to =
be used with any of the key </FONT>
<BR><FONT SIZE=3D2>management techniques?</FONT>
</P>

<P><FONT SIZE=3D2>Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1F133.97C1A140--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41F14c16614 for ietf-smime-bks; Wed, 1 May 2002 08:01:04 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41F12a16610 for <[e-mail]>; Wed, 1 May 2002 08:01:02 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 14:59:37 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 KAA22058 for <[e-mail]>; Wed, 1 May 2002 10:59:21 -0400 (EDT)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g41F17805114 for <[e-mail]>; Wed, 1 May 2002 11:01:07 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZFXDR>; Wed, 1 May 2002 08:01:00 -0700
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1Z7AY; Wed, 1 May 2002 10:58:28 -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: Wed, 01 May 2002 11:00:07 -0400
Subject: Re: Charter Update
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="=====================_13120766==_"
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>

--=====================_13120766==_
Content-Type: text/plain; charset="us-ascii"; format=flowed

Here is an update to the document that I posted earlier.  I think that it 
addresses all of the comments.

Russ


--=====================_13120766==_
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: attachment; filename="Charter4.txt"


S/MIME Mail Security (smime)

Chair:
     Russ Housley <[e-mail]>

Security Area Director:
     Jeffrey Schiller <[e-mail]>
     Marcus Leech <[e-mail]>

Mailing Lists:
     General Discussion: [e-mail]
     To Subscribe:       [e-mail]
     Archive:            http://www.imc.org/ietf-smime/

Description of Working Group:

The S/MIME Working Group has completed a series of Proposed  
Standards that comprise the S/MIME version 3 specification.   
Current efforts update and build upon these base specifications.

The Cryptographic Message Syntax (CMS) is cryptographic algorithm 
independent, yet there is always more than one way to use any 
algorithm.  To ensure interoperability, each algorithm should have
a specification that describes its use with CMS.  Specifications 
for the use of additional cryptographic algorithms will be 
developed.

As part of the specification update, a new suite of "mandatory 
to implement" algorithms will be selected.  These algorithms will
be reflected in updates to RFC 2632 and RFC 2633.

To aid implementers, documents containing example output for CMS
will be collected and published.  Some of the examples will include
structures and signed attributes defined in the Enhanced Security
Services (ESS) document.

In some situations it would be advantageous for the CMS RecipientInfo 
structure to support additional key management techniques, including 
cryptographic keys derived from passwords.  Also, a mechanism to 
facilitate the definition of additional key management techniques
will be defined.

Compressing data prior to encryption or signature has a number of 
advantages.  Compression improves security by removing known data 
patterns, improves throughput by reducing the amount of data which
needs to be encrypted or hashed, and reduces the overall message 
size.  Enabling S/MIME version 3 to use compression will provide 
all of these advantages.

S/MIME version 3 permits the use of previously distributed 
symmetric key-encryption keys.  Specifications for the distribution
of symmetric key-encryption keys to multiple message recipients 
will be developed.  Mail List Agents (MLAs) are one user of 
symmetric key-encryption keys.  The specification will be algorithm 
independent.

S/MIME version 3 supports security labels.  Specifications that show 
how this feature can be used to implement an organizational security 
policy will be developed.  Security policies from large organizations 
will be used as examples.

As part of S/MIME version 3, CMS is used to provide security 
to the message content.  CMS can also be employed in an X.400
electronic messaging envionments.  Specifications will be 
developed allowing this to be done in an interoperable manner.

Perform necessary interoperability testing to progress the S/MIME
version 3 specifications to Draft Standard.  Due to the dependency
of the CMS specification on the PKIX certificate and CRL profile,
the timeline for the actual progression is impossible to estimate.


Goals and Milestones:

History:
     Submit CMS compressed data content type a Proposed Standard.
     Submit security label usage specification as Informational RFC.
     Submit elliptic curve algorithm specification as Informational RFC.
     Submit mail list key distribution as a Proposed Standard.
     Submit update to RFC 2630 as a Proposed Standard.
     Submit AES key wrap algorithm description as Informational RFC.
     Last call on X.400 CMS wrapper specification.
     Last call on X.400 transport specification.
     Last call on HMAC key wrap description specification.
     First draft of CMS and ESS examples document.
     First draft of RSA OAEP algorithm specification.
     First draft of AES algorithm specification.
     First draft of update to RFC 2632.
     Frist draft of update to RFC 2633.

May 2002:
     First draft of RSA KEM algorithm specification.
     Submit X.400 CMS wrapper specification as a Proposed Standard.
     Submit X.400 transport as a Proposed Standard.
     Submit HMAC key wrap description as an Informational RFC.

June 2002:
     First draft of RSA PSS algorithm specification.
     Last call on CMS and ESS examples document.

July 2002:
     Last call on update to RFC 2632.
     Last call on update to RFC 2633.
     Last call on AES algorithm specification.
     Last call on RSA OAEP algorithm specification.

August 2002:
     Last call on RSA KEM algorithm specification.
     Submit CMS and ESS examples document as Informational RFC.

September 2002:
     Last call on RSA PSS algorithm specification.

October 2002:
     Sumbit update to RFC 2632 as Proposed Standard.
     Sumbit update to RFC 2633 as Proposed Standard.

December 2002:
     Sumbit AES algorithm specification as Proposed Standard.
     Submit RSA KEM algorithm specification as Proposed Standard.
     Submit RSA PSS algorithm specification as Proposed Standard.
     Submit RSA OAEP algorithm specification as Historical RFC.

--=====================_13120766==_--