Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt

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

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "Blake Ramsdell" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>
Sent: Saturday, March 30, 2002 10:58 AM
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt


> I am fine with this approach.

In ipki-pkalgs there is the following language with regard to MD2:

At the Selected Areas in Cryptography '95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find
collisions [RC95].  Collisions occur when one can find two different
messages that generate the same message digest.  A checksum operation
in MD2 is the only remaining obstacle to the success of the attack.
For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as
the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value.

[RC95]   Rogier, N. and Chauvaud, P., "The compression function of
         MD2 is not collision free," Presented at Selected Areas in
         Cryptography '95, May 1995.


I can copy this language and reference directly, unless it's sufficient to
say "there's an issue, go look at pkalgs for more information".

Blake




Received: by above.proper.com (8.11.6/8.11.3) id g2V4Fb229944 for ietf-smime-bks; Sat, 30 Mar 2002 20:15:37 -0800 (PST)
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 g2V4FWm29940 for <[e-mail]>; Sat, 30 Mar 2002 20:15:32 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Sat, 30 Mar 2002 20:25:33 -0800
Message-ID: <1bd101c1d86b$ac09aca0$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References: <2640579.1016485832703.JavaMail.administrator@highland> <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Sat, 30 Mar 2002 20:22:29 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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]>; <[e-mail]>
Sent: Saturday, March 30, 2002 10:58 AM
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt


> I am fine with this approach.

In ipki-pkalgs there is the following language with regard to MD2:

At the Selected Areas in Cryptography '95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find
collisions [RC95].  Collisions occur when one can find two different
messages that generate the same message digest.  A checksum operation
in MD2 is the only remaining obstacle to the success of the attack.
For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as
the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value.

[RC95]   Rogier, N. and Chauvaud, P., "The compression function of
         MD2 is not collision free," Presented at Selected Areas in
         Cryptography '95, May 1995.


I can copy this language and reference directly, unless it's sufficient to
say "there's an issue, go look at pkalgs for more information".

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2UJvNg20810 for ietf-smime-bks; Sat, 30 Mar 2002 11:57:23 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g2UJvLm20806 for <[e-mail]>; Sat, 30 Mar 2002 11:57:21 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Mar 2002 19:56:32 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 OAA06307; Sat, 30 Mar 2002 14:56:28 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2UJvOT16638; Sat, 30 Mar 2002 14:57:24 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1MXTM>; Sat, 30 Mar 2002 14:55:02 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.123]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1MXT2; Sat, 30 Mar 2002 14:54:59 -0500
From: "Housley, Russ" <[e-mail]>
To: Blake Ramsdell <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 30 Mar 2002 13:58:30 -0500
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
In-Reply-To: <1ab501c1d77d$306b5970$[e-mail]>
References: <2640579.1016485832703.JavaMail.administrator@highland> <[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:

I am fine with this approach.

Russ


At 03:55 PM 3/29/2002 -0800, Blake Ramsdell wrote:
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: <[e-mail]>
>Cc: "'Blake Ramsdell'" <[e-mail]>; <[e-mail]>
>Sent: Friday, March 29, 2002 1:57 PM
>Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
>
>
> > I think that we should include is as a MAY for validation.  I do not think
> > that anyone should generate new certificates that use MD2.
>
>My opinion is we should say SHOULD verify, and MUST NOT generate, perhaps
>mentioning the known issues with MD2 in the security considerations.
>
>Blake


Received: by above.proper.com (8.11.6/8.11.3) id g2TNmwf10024 for ietf-smime-bks; Fri, 29 Mar 2002 15:48:58 -0800 (PST)
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 g2TNmwm10020 for <[e-mail]>; Fri, 29 Mar 2002 15:48:58 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Fri, 29 Mar 2002 15:58:42 -0800
Message-ID: <1ab501c1d77d$306b5970$[e-mail]>
From: "Blake Ramsdell" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <2640579.1016485832703.JavaMail.administrator@highland> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Fri, 29 Mar 2002 15:55:22 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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: <[e-mail]>
Cc: "'Blake Ramsdell'" <[e-mail]>; <[e-mail]>
Sent: Friday, March 29, 2002 1:57 PM
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt


> I think that we should include is as a MAY for validation.  I do not think
> that anyone should generate new certificates that use MD2.

My opinion is we should say SHOULD verify, and MUST NOT generate, perhaps
mentioning the known issues with MD2 in the security considerations.

Blake



Received: by above.proper.com (8.11.6/8.11.3) id g2TLxZm05651 for ietf-smime-bks; Fri, 29 Mar 2002 13:59:35 -0800 (PST)
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 g2TLxXm05647 for <[e-mail]>; Fri, 29 Mar 2002 13:59:34 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Mar 2002 21:58:45 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 QAA11594; Fri, 29 Mar 2002 16:58:41 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2TLxZD09343; Fri, 29 Mar 2002 16:59:35 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1MTY2>; Fri, 29 Mar 2002 16:57:13 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.9]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1MTYH; Fri, 29 Mar 2002 16:57:10 -0500
From: "Housley, Russ" <[e-mail]>
To: [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, 29 Mar 2002 16:57:43 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
In-Reply-To: <000e01c1cec7$9632f420$[e-mail]>
References: <2640579.1016485832703.JavaMail.administrator@highland>
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>

Jim:

The PKIX PKAlgs Document does include MD2.  It is included for exactly the 
reason that Blake stated.

I think that we should include is as a MAY for validation.  I do not think 
that anyone should generate new certificates that use MD2.

Russ


At 03:55 PM 3/18/2002 -0600, Jim Schaad wrote:

>MD2 is is known to have pseudo collisions.  In the previous version of
>the draft md2 was a SHOULD (along with the rest of the RSA algorithms).
>You have promoted it when I consider it to be a suspect algorithm.
>
>There is a difference between what we consider to be good practice and
>how backwards compability works.  I think that making it a MAY (or
>omitting entirely) and adding a note that this is a common algorithm
>still (is that really true? 11 out of 108 with what types of experation
>dates) is sufficent to address your needs without having an endorsement
>of this as a good algorithm on our (the WG) part.
>
>Remember that md2 is not an acceptable PKIX algorithm.  I think we
>should follow that lead.
>
>jim
>
> > -----Original Message-----
> > From: Blake Ramsdell [mailto:[e-mail]]
> > Sent: Monday, March 18, 2002 3:10 PM
> > To: [e-mail]; [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> >
> >
> > Thanks for the comments, Jim -- one quick question below.
> >
> > ----- Original Message -----
> > From: "Jim Schaad" <[e-mail]>
> > To: <[e-mail]>; "'Blake Ramsdell'"
> > <[e-mail]>
> > Sent: Monday, March 18, 2002 10:27 AM
> > Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> >
> >
> > > 1.  I strongly disagree that md2-with-RSA is a MUST.  I think this
> > > should be a MAY or omitted.
> >
> > On what basis you you disagree?
> >
> > For compatibility, dropping MD2 may not be the best idea.
> > Based on a quick
> > evaluation of the root self-signed certificates that I have,
> > I found 108
> > total certificates, 11 of which were signed with MD2 (44 were
> > signed with
> > MD5, the rest with SHA-1).
> >
> > Blake
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PJJlv18675 for ietf-smime-bks; Mon, 25 Mar 2002 11:19:47 -0800 (PST)
Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PJJk418670 for <[e-mail]>; Mon, 25 Mar 2002 11:19:46 -0800 (PST)
Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id <H4HA83S6>; Mon, 25 Mar 2002 14:19:43 -0500
Message-ID: <[e-mail]>
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Subject: Patch Files to v2.0.1 S/MIME Freeware Library Now Available
Date: Mon, 25 Mar 2002 14:19:42 -0500
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>

All,

Getronics Government Solutions has delivered a set of patch files
(Patch A) that fix bugs (see below) in the v2.0.1 S/MIME Freeware 
Library (SFL) source code.  The SFL source code files are freely
available at <http://www.getronicsgov.com/hot/sfl_home.htm>.  

The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message 
Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. 
It also implements portions of the RFC 2633 Message Specification and 
RFC 2632 Certificate Handling document.  When used in conjunction with
the Crypto++ freeware library, the SFL implements the RFC 2631 
Diffie-Hellman (D-H) Key Agreement Method specification.  It has been 
successfully tested using the Microsoft (MS) Windows NT/98/2000/XP, Linux
and Sun Solaris 2.8 operating systems.  Further enhancements, ports and 
testing of the SFL are still in process.  Further releases of the SFL
will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided
by the Fortezza Crypto Card.  The v2.0.1 (Patch A) SFL uses the v1.3 R10
Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. 
The v2.0.1 SFL release includes: SFL High-level library; Free 
(a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL;
Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; 
test utilities; test drivers; and test data.  All CTILs were tested as 
Dynamically Linked Libraries (DLL) using MS Windows.  The Fortezza, BSAFE
and Crypto++ CTILs were tested with the respective security libraries as
shared objects using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and envelopedData 
messages with the MS Internet Explorer Outlook Express v4.01, Netscape
Communicator 4.X, Entrust and Baltimore S/MIME products.  Signed messages
have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability testing
with 
Microsoft that exercised the majority of the features specified by RFCs 
2630, 2631 and 2634.  This testing included the RSA, DSA, E-S D-H, 3DES, SHA
and Fortezza algorithms.  We used the SFL to successfully process the 
SFL-supported sample data included in the S/MIME WG "Examples of S/MIME 
Messages" document.  We also used the SFL to generate S/MIME v3 sample 
messages that were included in the "Examples" document.

The use of the v2.0.1 SFL is described in the v2.0 SFL Application 
Programming Interface (API) and v2.0 SDD documents.  The v2.0 SMP 
Components Setup Manual that describes the component installation
procedures for the v2.0.1 SFL, v2.0.1 Certificate Management Library (CML),
and v1.3 R10 eSNACC libraries.  The use of the v2.0.1 CTIL API is
described in the v2.0 CTIL API document. 


Patch A includes the following enhancements (compared to v2.0.1 SFL
and CTIL releases):

1) v2.0.1 (Patch A) SFL was tested using v1.3 R10 eSNACC ASN.1 C++ library
that fixed a bug in the code that implements the SET OF sorting as part
of the Distinguished Encoding Rules (DER).  The eSNACC DER bug was 
causing the SFL to report signature verification problems when attempting
to verify valid signed S/MIME messages.

2) v2.0.1 (Patch A) SFL was tested using v1.3 R10 eSNACC ASN.1 C++ library
that also includes a bug fix that resulted in a significant decrease in the
time required to decode objects greater than 1MB in size.  For example, this
eSNACC bug fix resulted in a 300-fold improvement in the SFL decryption of
objects that are greater than 1MB in size.

3) Fixed bugs in Microsoft CAPI CTIL code that handles the use of two
RSA certificates (and corresponding private keys) that include the same
subject name, but are distinguished by the keyUsage extension (one for 
signature, one for encryption).  

4) The SFL timing routine was updated in the sm_EDTImingTest.cpp test 
utility to time variable loop counter of messages of variable content 
size.  This test now handles ASN.1 Encode, Decode, Encrypt and Decrypt
tests (./SMIME/testsrc/util/sm_EDTImingTest.cpp). 

5) SFL and Microsoft CAPI CTIL were updated to fix minor memory leaks
and other minor bugs.

6) Corrected bug in CertNameToStr (sm_capi.cpp) to process names 
longer than 100 characters.

7) Improved CertificateBuilder by adding a separate certificatePolicies
extension creation menu item.  

8) The demonstration program in ./SMIME/testutil/testTripleWrap has 
been updated to demonstrate multiple certificate loads into 
RecipientInfos for encryption.  This program also demonstrates the
Microsoft CAPI CTIL initialization and usage.


We are still in the process of enhancing and testing the SFL.  Future 
releases may include: additional PKCS #11 CTIL testing; finish 
CertificateBuilder command line utility; enhancing 
CertificateBuilder to support creation of Attribute Certificates; 
add "Certificate Management Messages over CMS" ASN.1 encode/decode 
functions; add enhanced test routines; bug fixes; support for other 
crypto APIs; and support for other operating systems. 

The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.


The following SFL files are available from 
<http://www.getronicsgov.com/hot/sfl_lib.htm>:

1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL 
API, Software Test Description, Implementers Guide, Overview Briefing
and Public License.     

2) smimeR2.0.1.tar.gz:  Source code, MS Windows project files and 
Unix makefiles for SFL Hi-Level library.

3) snacc13r10rn.tar.gz (source code and binaries available from Getronics 
eSNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>): 
Source code, MS Windows project files and Unix makefiles for
v1.3 R10 eSNACC ASN.1 Compiler and Library that has been enhanced by
Getronics to implement the Distinguished Encoding Rules.  Source code is
compilable for Linux, Solaris 2.8 and MS Windows NT/98/2000/XP. This
file includes a sample test project demonstrating the use of the eSNACC
classes.  

4) smCTIR2.0.1.tar.gz:  Source code, MS Windows project files and 
Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, 
Fortezza, SPEX/, PKCS #11 and MS CAPI v2.0.  The CTIL source code includes
PKCS #12 software developed by the OpenSSL Project for use in the OpenSSL
Toolkit <http://www.openssl.org/>

5) sm_CTIL_MGR_R2.0.1.tar.gz: Source code, MS Windows project files and 
Unix makefiles for the CTILManager library that provides CTIL-related 
processing services used by the SFL, ACL and CML.

6) smTest2.0.1.tar.gz: Source code, MS Windows project files and 
Unix makefiles for test drivers used to test the SFL.  This file includes 
sample CMS/ESS test data and test X.509 Certificates.  It also includes 
the CertificateBuilder utility that can be used to create X.509
Certificates.

7) sfl_v2.0.1_Patch_A.zip: Contains patch files that include aforementioned
enhancements to v2.0.1 SFL, Microsoft CAPI CTIL, CertificateBuilder.


All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  Getronics is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL 
source code. The application developer must independently obtain these 
libraries and then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.getronicsgov.com/hot/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.getronicsgov.com/hot/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by Getronics) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
Getronics used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile.  

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.

============================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
============================================ 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2PIdtt16400 for ietf-smime-bks; Mon, 25 Mar 2002 10:39:55 -0800 (PST)
Received: from wfhqex03.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2PIds416390 for <[e-mail]>; Mon, 25 Mar 2002 10:39:54 -0800 (PST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Subject: v1.3 R10 Enhanced SNACC Freeware Now Available
Date: Mon, 25 Mar 2002 13:39:44 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: v1.3 R10 Enhanced SNACC Freeware Now Available
Thread-Index: AcHUKNh2i8U3gwBJS3uA143QFn4OIw==
From: "Pawling, John" <[e-mail]>
To: "SMIME WG (E-mail)" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g2PIds416397
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>

All,

Getronics Government Solutions has delivered the v1.3 R10 Enhanced
SNACC (eSNACC) Abstract Syntax Notation One (ASN.1) Compiler,
C++ library and C library source code and binaries tested on the 
Linux, Sun Solaris 2.8 and Microsoft Windows NT/98/2000/XP operating
systems.  The eSNACC software is freely available to everyone from:
<http://www.getronicsgov.com/hot/snacc_home.htm>.  The v1.3 R10
eSNACC release fixes significant bugs present in the previous
releases.

The eSNACC ASN.1 software can be used to ASN.1 encode and decode
objects.  In past releases, Getronics improved the eSNACC C++ 
library to implement the Distinguished Encoding Rules (DER), 
support large ASN.1 INTEGERs, and improve memory usage.    


v1.3 R10 eSNACC enhancements (compared to v1.3 R8 and R9 releases):

1) We corrected the eSNACC ASN.1 C and C++ libraries to properly
implement the sorting of SET OF components as specified in the 1997
X.690 DER requirements.  The eSNACC ASN.1 C++ library was incorrectly 
ignoring the tag and length of each component when determining 
their order.  The bug was present in the v1.3 R7, v1.3 R8, and 
v1.3 R9 releases of the eSNACC ASN.1 C++ library.  This bug caused
interoperability problems with correct DER implementations.  For 
example, this bug caused the S/MIME Freeware Library (SFL) (that
uses the eSNACC ASN.1 C++ library) to report signature verification 
problems when attempting to verify valid signed S/MIME messages.   

2) We corrected several bugs in the eSNACC ASN.1 C++ and C  
libraries that we discovered when testing them using the Simple
Network Management Protocol (SNMP) v1 test suite developed by the
University of Oulu.  The bugs were all error handling problems that
occurred when each ASN.1 library attempted to decode invalidly 
encoded indefinite lengths on primitive types.  These were all bugs
in the original SNACC code.  We used the v1.3 R10 eSNACC ASN.1 C++ 
and C libraries to successfully process all 18,000 test cases in 
the SNMPv1 Oulu test suite.  

3) We fixed a bug in CSM_Buffer::Write(...) (sm_buffer.cpp file)
that resulted in a significant decrease in the time required to
ASN.1 decode objects greater than 1MB in size.


We tested the v1.3 R10 eSNACC release with the v2.0.1 S/MIME
Freeware Library (SFL) (with patch files applied) available 
from <http://www.getronicsgov.com/hot/sfl_home.htm> that 
uses the eSNACC ASN.1 software to encode and decode the IETF 
S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced
Security Services for S/MIME (RFC 2634) security protocol.  

We tested the v1.3 R10 eSNACC release with the freeware v2.0.1
Certificate Management Library (CML) (no patch files required) 
available from  <http://www.getronicsgov.com/hot/cml_home.htm> 
that uses the eSNACC ASN.1 software to encode and decode X.509 
certificates, attribute certificates and Certificate Revocation 
Lists as specified in the 2000 X.509 Recommendation.

We tested the v1.3 R10 eSNACC release with the freeware v2.0.1
Access Control Library (ACL) (no patch files required to use
v1.3 R10 eSNACC release) available from
<http://www.getronicsgov.com/hot/acl_home.htm>.  The ACL uses
the eSNACC ASN.1 software to encode and decode security
labels and other objects (such as Security Policy Information 
Files) required to provide rule based access control as 
specified in SDN.801.

The eSNACC ASN.1 software implements the majority of the 
ASN.1 encoding/decoding rules as specified in the 1988 X.209 
Recommendation.  It implements the DER as specified in the 1997 
X.690 Recommendation.  It does not support all of the latest ASN.1
features, but there are strategies that allow it to be used to 
produce ASN.1 hex encodings that are identical to those produced by
ASN.1 libraries that do support the latest ASN.1 features.  Also note
that many of the PKIX specs, such as RFC 2459 and RFC 2630, include 
1988-compliant ASN.1 syntax modules which can be compiled using the
eSNACC compiler.

The eSNACC ASN.1 library is totally unencumbered as stated 
in the Enhanced SNACC Software Public License.  All source code
for the eSNACC software is being provided at no cost and with no
financial limitations regarding its use and distribution.  
Organizations can use the eSNACC software without paying
any royalties or licensing fees.  

The Internet Mail Consortium (IMC) has established an eSNACC
web page <http://www.imc.org/imc-snacc/>.  The IMC has established 
an eSNACC mail list which is used to: distribute information 
regarding eSNACC releases; discuss related issues; and 
provide a means for integrators to provide feedback, comments,
bug reports, etc.  Subscription information for the imc-snacc
mail list is at the IMC web site listed above.

We welcome all feedback regarding the eSNACC software.
If bugs are reported, then we will investigate each reported
bug and, if required, will produce a patch or an updated
release of the software to repair the bug. 

This release announcement was sent to several mail lists,
but please send all messages regarding the eSNACC 
software to the imc-snacc mail list ONLY.  Please do not send 
messages regarding the eSNACC software to any of the 
IETF mail lists.  We will respond to all messages sent to the
imc-snacc mail list.

===========================================
John Pawling, [e-mail]
Getronics Government Solutions, LLC
===========================================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LI19824750 for ietf-smime-bks; Thu, 21 Mar 2002 10:01:09 -0800 (PST)
Received: from wfhqex03.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LI18424746 for <[e-mail]>; Thu, 21 Mar 2002 10:01:08 -0800 (PST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D102.5D72D0F0"
Subject: RE: Labeling and SMIME
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Date: Thu, 21 Mar 2002 13:01:03 -0500
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Labeling and SMIME
Thread-Index: AcHQ+8w0Eci0JOFwR8qsICIm202I2QABK4WA
From: "Pawling, John" <[e-mail]>
To: <[e-mail]>, "Piers Chivers" <[e-mail]>
Cc: <[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>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C1D102.5D72D0F0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

All,
=20
I believe that RFC 2630 CMS and RFC 2634 ESS allow sufficient
flexibility regarding the binding of security labels with data.  For
example, the original signer of the signedData signerInfo can apply a
security label that is bound with the original encapsulated content.
Another entity can encapsulate the original signedData in an outer
signedData in which the entity can apply a security label that is bound
with the outer signedData's encapsulated content (i.e. the inner
signedData).  An application can unambiguously process the nested
signedData layers to identify each signer that created each security
label.=20
=20
I agree with all of Sean Turner's statements.
=20
In summary, I believe that nested signedData layers can be used to meet
Piers' requirements.  I do not believe that CMS and ESS should be
changed regarding the creation and use of security labels. =20
=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
John Pawling, [e-mail]=20
Getronics Government Solutions, LLC=20
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20
-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Thursday, March 21, 2002 11:14 AM
To: 'Piers Chivers'
Cc: [e-mail]
Subject: RE: Labeling and SMIME


Piers,
=20
There is another way that this can be handled depending on the order of
evalution of security labels by your software.  It would be possible to
add a new security label in a wrapping layer which both 1) gave the new
label to be used and 2) overrode the inner label. =20
=20
This method does have a number of possible pitfalls to be considered, 1)
the label evaluation needs to ensure that the new label applier has the
right to apply the label and 2) the change in label corresponds to some
type of policy.  This does mean that a single engine with the ability to
save state needs to be used to evaluate the labels.  This is not going
to be supported by some software, and is done purely in the label engine
there needs to be a way of making sure that all of the labels apply to a
single message (inclusion of a message id as a label parameter would be
one method).
=20
This allows for the concept of both lowering and upping the security
level needed to view a document.
=20
jim
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Piers Chivers
Sent: Thursday, March 21, 2002 9:11 AM
To: 'Sean P. Turner'
Cc: [e-mail]
Subject: RE: Labeling and SMIME


Sean,
Thanks for the response.  Whether or not a label is part of a document
and hence changing the label changes the document is a philosophical
debate.  Nevertheless, it is an important one.  I think that in a
business world the person who signs the content of a document could be
different from the person who labels a document.  Business policy should
dictate who is allowed to sign documents.  Similarly, policy should
dictate who is allowed to set or change a label.  The CMS spec doesn't
allow for this. =20
=20
Further to my earlier suggestion, I would suggest that this should be
addressed at the CMS level.  One possibility is a signedMetaAttributes
field in the SignerInfo with a metaSignature field that is a signature
of the signedMetaAttributes.  signedMetaAttributes should always contain
the message digest attribute similar to signedAttrs.  This way the
document and the label attribute are cryptographically bound.
=20
Piers
=20
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com
=20
-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]]=20
Sent: 20 March 2002 21:22
To: Piers Chivers
Cc: [e-mail]
Subject: Re: Labeling and SMIME
=20
Piers,=20
One way to allow a message to change label values over time would be to
have the message (say it's marked A, where A is higher than B) include
not only the marking A in the security label but also include an
indication of when it should be considered to be marked B.  You could do
this with a security category.=20
To me you always want to link the message/document, label, and signature
in the same blob.  Firstly, if you have a document I hope you've got the
marking in the document's contents.  Then, if you have to change the
classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature
wouldn't be valid anymore anyway.  To me when you change the label's
values you're essentially changing the message/document and hence it
ought to be treated as a new message/document.=20
spt=20
Piers Chivers wrote:=20
Hi,
I think that the current SMIME implementation for labeling is too
inflexible.This is probably because it is modeled on a military world
where a Top Secret message stays Top Secret for ever.However, in the
commercial world a "Commercially Sensitive" document may become "Public"
overtime or because of a change of circumstances (details released to
Stock Markets, document signed off by marketing etc.).
Since, in SMIME, the label of a message is signed with the content of
the document it is impossible for the label to be changed without
re-computing a signature on the content of the document.This is
erroneous since the person changing the label may not be the original
creator of the document contents.Hence the proof-of-origin of the
document will be lost.=20
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows:=20
a new MIME entity application/pkcs7-labeled that has 2 parts:=20
application/pkcs7-document that contains the document part of a
multipart/signed entity and=20
application/pkcs7-label - a MIME entity that contains a signed CMS
object containing the label and the original document's detached
signature.The latter signature is provided by the person who creates the
message.The outer signed CMS object is signed by the labeler of the
document.Typically, the signatories will be the same person.=20
This approach allows labeled documents to be re-classified over time but
keeps the original document signature.=20
Any thoughts?=20
Thanks,=20
Piers=20
Piers Chivers=20
Product Architect=20
Protek Network Security=20
[phone]=20
www.protek.com=20

------_=_NextPart_001_01C1D102.5D72D0F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<TITLE>Message</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C1D0EB.024B0F10" =
rel=3DFile-List><o:SmartTagType=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
name=3D"PersonName"></o:SmartTagType><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle20 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal; =
mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; mso-bidi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply; =
mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; mso-bidi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D490324717-21032002>All,</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D490324717-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D490324717-21032002>I believe=20
that RFC 2630&nbsp;CMS and RFC 2634 ESS allow&nbsp;sufficient =
flexibility=20
regarding the binding of&nbsp;security labels with data.&nbsp; For =
example, the=20
original signer of the signedData signerInfo can apply a security label =
that is=20
bound with the original encapsulated content.&nbsp; Another entity can=20
encapsulate the original signedData in an outer signedData in which the=20
entity&nbsp;can apply a&nbsp;security label that is bound with =
the&nbsp;outer=20
signedData's encapsulated content (i.e. the inner=20
signedData).&nbsp;</SPAN></FONT><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D490324717-21032002>&nbsp;An&nbsp;application&nbsp;can&nbsp;unambi=
guously=20
process the nested signedData layers to&nbsp;identify each&nbsp;signer=20
that&nbsp;created each security label.&nbsp;</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D490324717-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT><SPAN class=3D490324717-21032002>I agree with all of Sean =
Turner's=20
statements.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D490324717-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D490324717-21032002>In summary,=20
I&nbsp;believe that nested signedData layers can be used to meet Piers'=20
requirements.&nbsp; I do not believe that CMS and ESS should be changed=20
regarding the creation and use&nbsp;of security labels.&nbsp;=20
</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D490324717-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D490324717-21032002><FONT=20
face=3D"Courier New" =
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT>=20
<BR><FONT face=3D"Courier New" size=3D2>John Pawling,=20
[e-mail]</FONT> <BR><FONT face=3D"Courier New"=20
size=3D2>Getronics Government Solutions, LLC</FONT> <BR><FONT =
face=3D"Courier New"=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D</FONT> =
</DIV></SPAN></FONT>
<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> Jim Schaad=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, March 21, 2002 =
11:14=20
  AM<BR><B>To:</B> 'Piers Chivers'<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: Labeling and=20
  SMIME<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002>Piers,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002>There is another way that this can be =
handled=20
  depending on the order of evalution of security labels by your =
software.&nbsp;=20
  It would be possible to add a new security label in a wrapping layer =
which=20
  both 1) gave the new label to be used and 2) overrode the inner =
label.&nbsp;=20
  </SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D565370916-21032002>This=20
  method does have a number of possible pitfalls to be considered, 1) =
the label=20
  evaluation needs to ensure that the new label applier has the right to =
apply=20
  the label and 2) the change in label corresponds to some type of =
policy.&nbsp;=20
  This does mean that a single engine with the ability to save state =
needs to be=20
  used to evaluate the labels.&nbsp; This is not going to be supported =
by some=20
  software, and is done purely in the label engine there needs to be a =
way of=20
  making sure that all of the labels apply to a single message =
(inclusion of a=20
  message id as a label parameter would be one =
method).</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D565370916-21032002>This=20
  allows for the concept of both lowering and upping the security level =
needed=20
  to view a document.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D565370916-21032002>jim</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
    [e-mail] [mailto:[e-mail]] =
<B>On=20
    Behalf Of </B>Piers Chivers<BR><B>Sent:</B> Thursday, March 21, 2002 =
9:11=20
    AM<BR><B>To:</B> 'Sean P. Turner'<BR><B>Cc:</B>=20
    [e-mail]<BR><B>Subject:</B> RE: Labeling and=20
    SMIME<BR><BR></FONT></DIV>
    <DIV class=3DSection1>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Sean,<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks =
for the=20
    response.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Whether or =
not a=20
    label is part of a document and hence changing the label changes the =

    document is a philosophical debate.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
    </SPAN>Nevertheless, it is an important one.<SPAN=20
    style=3D"mso-spacerun: yes">&nbsp; </SPAN>I think that in a business =
world the=20
    person who signs the content of a document could be different from =
the=20
    person who labels a document.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
    </SPAN>Business policy should dictate who is allowed to sign =
documents.<SPAN=20
    style=3D"mso-spacerun: yes">&nbsp; </SPAN>Similarly, policy should =
dictate who=20
    is allowed to set or change a label. <SPAN=20
    style=3D"mso-spacerun: yes">&nbsp;</SPAN>The CMS spec doesn't allow =
for=20
    this.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
    </SPAN><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Further =
to my=20
    earlier suggestion, I would suggest that this should be addressed at =
the CMS=20
    level.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>One =
possibility is a=20
    <SPAN class=3DSpellE>signedMetaAttributes</SPAN> field in the <SPAN=20
    class=3DSpellE>SignerInfo</SPAN> with a <SPAN=20
    class=3DSpellE>metaSignature</SPAN> field that is a signature of the =
<SPAN=20
    class=3DSpellE>signedMetaAttributes</SPAN>.<SPAN=20
    style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN class=3DSpellE><SPAN =

    class=3DGramE>signedMetaAttributes</SPAN></SPAN> should always =
contain the=20
    message digest attribute similar to <SPAN=20
    class=3DSpellE>signedAttrs</SPAN>.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
    </SPAN>This way the document and the label attribute are =
cryptographically=20
    bound.<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Piers<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <DIV>
    <P class=3DMsoAutoSig><st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><FONT=20
    face=3D"Times New Roman" color=3Dnavy size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Piers=20
    Chivers</SPAN></FONT></st1:PersonName><FONT color=3Dnavy =
size=3D2><SPAN=20
    lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Product=20
    Architect</SPAN></FONT><FONT color=3Dnavy><SPAN=20
    style=3D"COLOR: navy; mso-no-proof: =
yes"><o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Protek=20
    Network Security<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
    lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">+44=20
    (0)1270 507800<o:p></o:p></SPAN></FONT></P>
    <P class=3DMsoAutoSig><U><FONT face=3D"Times New Roman" =
color=3D#0080ff=20
    size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><A=20
    =
href=3D"http://www.protek.com">www.protek.com</A></SPAN></FONT></U><FONT =

    color=3D#0080ff size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><o:p></o:p></SPAN></FONT></P></DIV>
    <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DTahoma =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
    Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">From:</SPAN></B> Sean P.=20
    Turner [mailto:[e-mail]] <BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> 20 March 2002 =
21:22<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Piers Chivers<BR><B><SPAN =

    style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> =
[e-mail]<BR><B><SPAN=20
    style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: Labeling and=20
    SMIME</SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times =
New Roman"=20
    size=3D3><SPAN style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times =
New Roman"=20
    size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Piers, =
<o:p></o:p></SPAN></FONT></P>
    <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">One way to allow a message to change label =
values=20
    over time would be to have the message (say it's marked A, where A =
is higher=20
    than B) include not only the marking A in the security label but =
also=20
    include an indication of when it should be considered to be marked =
B.&nbsp;=20
    You could do this with a security category. =
<o:p></o:p></SPAN></FONT></P>
    <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">To me you always want to link the =
message/document,=20
    label, and signature in the same blob.&nbsp; Firstly, if you have a =
document=20
    I hope you've got the marking in the document's contents.&nbsp; =
Then, if you=20
    have to change the classification you'd also have to change the =
marking in=20
    the document; thereby, changing the document's contents and the =
original=20
    signature wouldn't be valid anymore anyway.&nbsp; To me when you =
change the=20
    label's values you're essentially changing the message/document and =
hence it=20
    ought to be treated as a new message/document. =
<o:p></o:p></SPAN></FONT></P>
    <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">spt <o:p></o:p></SPAN></FONT></P>
    <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
    style=3D"FONT-SIZE: 12pt">Piers Chivers wrote: =
<o:p></o:p></SPAN></FONT></P>
    <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"=20
      TYPE=3D"CITE"><U1:SMARTTAGTYPE=20
      namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"=20
      name=3D"PersonName" /><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:BreakWrappedTables/>
   <u2:SnapToGridInCell/>
   <u2:WrapTextWithPunct/>
   <u2:UseAsianBreakRules/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->
      <DIV>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hi,<U1:P></U1:P></SPAN></FONT><o:p></o:p></P></DIV>
      <DIV>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I think that the =
current SMIME=20
      implementation for labeling is too inflexible.This is probably =
because it=20
      is modeled on a military world where a Top Secret message stays =
Top Secret=20
      for ever.However, in the commercial world a "Commercially =
Sensitive"=20
      document may become "Public" overtime or because of a change of=20
      circumstances (details released to Stock Markets, document signed =
off by=20
      marketing etc.).<U1:P></U1:P></SPAN></FONT><o:p></o:p></P></DIV>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Since, =
in SMIME,=20
      the label of a message is signed with the content of the document =
it is=20
      impossible for the label to be changed without re-computing a =
signature on=20
      the content of the document.This is erroneous since the person =
changing=20
      the label may not be the original creator of the document =
contents.Hence=20
      the proof-of-origin of the document will be=20
      lost.<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Have I =
missed a=20
      way to do this in the current CMS/SMIME model? If not, I would =
propose a=20
      scheme as follows:<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>a new =
MIME entity=20
      application/pkcs7-labeled that has 2 =
parts:<U1:P></U1:P></SPAN></FONT>=20
      <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>application/pkcs7-document=20
      that contains the document part of a multipart/signed entity=20
      and<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>application/pkcs7-label=20
      - a MIME entity that contains a signed CMS object containing the =
label and=20
      the original document's detached signature.The latter signature is =

      provided by the person who creates the message.The outer signed =
CMS object=20
      is signed by the labeler of the document.Typically, the =
signatories will=20
      be the same person.<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>This =
approach=20
      allows labeled documents to be re-classified over time but keeps =
the=20
      original document signature.<U1:P></U1:P></SPAN></FONT> =
<o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Any=20
      thoughts?</SPAN></FONT><U1:P></U1:P> <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>Thanks,<U1:P></U1:P></SPAN></FONT>=20
      <o:p></o:p></P>
      <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3DArial size=3D2><SPAN=20
      style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Piers<U1:P></U1:P></SPAN></FONT>=20
      <o:p></o:p></P>
      <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><st1:PersonName=20
      style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><FONT=20
      face=3D"Times New Roman" size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes"><U1:P></U1:P>Piers=20
      Chivers</SPAN></FONT></st1:PersonName><SPAN =
lang=3DEN-GB><U1:P></U1:P>=20
      </SPAN><o:p></o:p></P>
      <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
      size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">Product=20
      Architect</SPAN></FONT><SPAN lang=3DEN-GB><U1:P></U1:P>=20
      </SPAN><o:p></o:p></P>
      <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
      size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">Protek=20
      Network Security<U1:P></U1:P></SPAN></FONT><SPAN lang=3DEN-GB>=20
      </SPAN><o:p></o:p></P>
      <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
      size=3D2><SPAN lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">+44=20
      (0)1270 507800<U1:P></U1:P></SPAN></FONT><SPAN lang=3DEN-GB>=20
      </SPAN><o:p></o:p></P>
      <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><U><FONT=20
      face=3D"Times New Roman" color=3D#0080ff size=3D2><SPAN =
lang=3DEN-GB=20
      style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: =
EN-GB; mso-no-proof: yes"><A=20
      =
href=3D"http://www.protek.com">www.protek.com</A></SPAN></FONT></U><SPAN =

      lang=3DEN-GB><U1:P></U1:P>=20
</SPAN><o:p></o:p></P></BLOCKQUOTE></DIV></BLOCKQUOTE></BLOCKQUOTE><U1:P>=
</U1:P></BODY></HTML>

------_=_NextPart_001_01C1D102.5D72D0F0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LGGFl16551 for ietf-smime-bks; Thu, 21 Mar 2002 08:16:15 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2LGGD416547 for <[e-mail]>; Thu, 21 Mar 2002 08:16:13 -0800 (PST)
Received: from revelation (unknown [166.63.186.201]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 5FC316A911; Thu, 21 Mar 2002 10:16:14 -0600 (CST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Piers Chivers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Labeling and SMIME
Date: Thu, 21 Mar 2002 10:14:00 -0600
Message-ID: <000901c1d0f3$699a6140$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01C1D0C1.1EFFF140"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01C1D0C1.1EFFF140
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Piers,
 
There is another way that this can be handled depending on the order of
evalution of security labels by your software.  It would be possible to
add a new security label in a wrapping layer which both 1) gave the new
label to be used and 2) overrode the inner label.  
 
This method does have a number of possible pitfalls to be considered, 1)
the label evaluation needs to ensure that the new label applier has the
right to apply the label and 2) the change in label corresponds to some
type of policy.  This does mean that a single engine with the ability to
save state needs to be used to evaluate the labels.  This is not going
to be supported by some software, and is done purely in the label engine
there needs to be a way of making sure that all of the labels apply to a
single message (inclusion of a message id as a label parameter would be
one method).
 
This allows for the concept of both lowering and upping the security
level needed to view a document.
 
jim
-----Original Message-----
From: [e-mail]
[mailto:[e-mail]] On Behalf Of Piers Chivers
Sent: Thursday, March 21, 2002 9:11 AM
To: 'Sean P. Turner'
Cc: [e-mail]
Subject: RE: Labeling and SMIME


Sean,
Thanks for the response.  Whether or not a label is part of a document
and hence changing the label changes the document is a philosophical
debate.  Nevertheless, it is an important one.  I think that in a
business world the person who signs the content of a document could be
different from the person who labels a document.  Business policy should
dictate who is allowed to sign documents.  Similarly, policy should
dictate who is allowed to set or change a label.  The CMS spec doesn't
allow for this.  
 
Further to my earlier suggestion, I would suggest that this should be
addressed at the CMS level.  One possibility is a signedMetaAttributes
field in the SignerInfo with a metaSignature field that is a signature
of the signedMetaAttributes.  signedMetaAttributes should always contain
the message digest attribute similar to signedAttrs.  This way the
document and the label attribute are cryptographically bound.
 
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com
 
-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]] 
Sent: 20 March 2002 21:22
To: Piers Chivers
Cc: [e-mail]
Subject: Re: Labeling and SMIME
 
Piers, 
One way to allow a message to change label values over time would be to
have the message (say it's marked A, where A is higher than B) include
not only the marking A in the security label but also include an
indication of when it should be considered to be marked B.  You could do
this with a security category. 
To me you always want to link the message/document, label, and signature
in the same blob.  Firstly, if you have a document I hope you've got the
marking in the document's contents.  Then, if you have to change the
classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature
wouldn't be valid anymore anyway.  To me when you change the label's
values you're essentially changing the message/document and hence it
ought to be treated as a new message/document. 
spt 
Piers Chivers wrote: 
Hi,
I think that the current SMIME implementation for labeling is too
inflexible.This is probably because it is modeled on a military world
where a Top Secret message stays Top Secret for ever.However, in the
commercial world a "Commercially Sensitive" document may become "Public"
overtime or because of a change of circumstances (details released to
Stock Markets, document signed off by marketing etc.).
Since, in SMIME, the label of a message is signed with the content of
the document it is impossible for the label to be changed without
re-computing a signature on the content of the document.This is
erroneous since the person changing the label may not be the original
creator of the document contents.Hence the proof-of-origin of the
document will be lost. 
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows: 
a new MIME entity application/pkcs7-labeled that has 2 parts: 
application/pkcs7-document that contains the document part of a
multipart/signed entity and 
application/pkcs7-label - a MIME entity that contains a signed CMS
object containing the label and the original document's detached
signature.The latter signature is provided by the person who creates the
message.The outer signed CMS object is signed by the labeler of the
document.Typically, the signatories will be the same person. 
This approach allows labeled documents to be re-classified over time but
keeps the original document signature. 
Any thoughts? 
Thanks, 
Piers 
Piers Chivers 
Product Architect 
Protek Network Security 
[phone] 
www.protek.com 

------=_NextPart_000_000A_01C1D0C1.1EFFF140
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word" xmlns:st1 =3D=20
"urn:schemas-microsoft-com:office:smarttags"><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3DWord.Document name=3DProgId>
<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR>
<META content=3D"Microsoft Word 10" name=3DOriginator><LINK=20
href=3D"cid:filelist.xml@01C1D0EB.024B0F10" =
rel=3DFile-List><o:SmartTagType=20
name=3D"PersonName"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<STYLE>st1\:* {
	BEHAVIOR: url(#default#ieooui)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Tahoma;
}
@page Section1 {size: 612.0pt 792.0pt; margin: 72.0pt 90.0pt 72.0pt =
90.0pt; mso-header-margin: 35.4pt; mso-footer-margin: 35.4pt; =
mso-paper-source: 0; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-style-parent: ""; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline; text-underline: single
}
A:visited {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
SPAN.MsoHyperlinkFollowed {
	COLOR: purple; TEXT-DECORATION: underline; text-underline: single
}
P.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
LI.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
DIV.MsoAutoSig {
	FONT-SIZE: 12pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; =
mso-pagination: widow-orphan; mso-fareast-font-family: "Times New Roman"
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0cm; MARGIN-RIGHT: 0cm; FONT-FAMILY: =
"Times New Roman"; mso-pagination: widow-orphan; =
mso-fareast-font-family: "Times New Roman"; mso-margin-top-alt: auto; =
mso-margin-bottom-alt: auto
}
SPAN.EmailStyle20 {
	COLOR: windowtext; FONT-FAMILY: Arial; mso-style-type: personal; =
mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; mso-bidi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
SPAN.EmailStyle21 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply; =
mso-style-noshow: yes; mso-ansi-font-size: 10.0pt; mso-bidi-font-size: =
10.0pt; mso-ascii-font-family: Arial; mso-hansi-font-family: Arial; =
mso-bidi-font-family: Arial
}
SPAN.SpellE {
	mso-style-name: ""; mso-spl-e: yes
}
SPAN.GramE {
	mso-style-name: ""; mso-gram-e: yes
}
DIV.Section1 {
	page: Section1
}
</STYLE>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]--></HEAD>
<BODY lang=3DEN-US style=3D"tab-interval: 36.0pt" vLink=3Dpurple =
link=3Dblue>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002>Piers,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D565370916-21032002>There=20
is another way that this can be handled depending on the order of =
evalution of=20
security labels by your software.&nbsp; It would be possible to add a =
new=20
security label in a wrapping layer which both 1) gave the new label to =
be used=20
and 2) overrode the inner label.&nbsp; </SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D565370916-21032002>This=20
method does have a number of possible pitfalls to be considered, 1) the =
label=20
evaluation needs to ensure that the new label applier has the right to =
apply the=20
label and 2) the change in label corresponds to some type of =
policy.&nbsp; This=20
does mean that a single engine with the ability to save state needs to =
be used=20
to evaluate the labels.&nbsp; This is not going to be supported by some=20
software, and is done purely in the label engine there needs to be a way =
of=20
making sure that all of the labels apply to a single message (inclusion =
of a=20
message id as a label parameter would be one =
method).</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D565370916-21032002>This=20
allows for the concept of both lowering and upping the security level =
needed to=20
view a document.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D565370916-21032002>jim</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Piers Chivers<BR><B>Sent:</B> Thursday, March 21, 2002 =
9:11=20
  AM<BR><B>To:</B> 'Sean P. Turner'<BR><B>Cc:</B>=20
  [e-mail]<BR><B>Subject:</B> RE: Labeling and=20
  SMIME<BR><BR></FONT></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Sean,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Thanks for =
the=20
  response.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>Whether or =
not a label=20
  is part of a document and hence changing the label changes the =
document is a=20
  philosophical debate.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN>Nevertheless, it is an important one.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>I think that in a business =
world the=20
  person who signs the content of a document could be different from the =
person=20
  who labels a document.<SPAN style=3D"mso-spacerun: yes">&nbsp; =
</SPAN>Business=20
  policy should dictate who is allowed to sign documents.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN>Similarly, policy should =
dictate who=20
  is allowed to set or change a label. <SPAN=20
  style=3D"mso-spacerun: yes">&nbsp;</SPAN>The CMS spec doesn't allow =
for=20
  this.<SPAN style=3D"mso-spacerun: yes">&nbsp;=20
  </SPAN><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Further to =
my earlier=20
  suggestion, I would suggest that this should be addressed at the CMS=20
  level.<SPAN style=3D"mso-spacerun: yes">&nbsp; </SPAN>One possibility =
is a <SPAN=20
  class=3DSpellE>signedMetaAttributes</SPAN> field in the <SPAN=20
  class=3DSpellE>SignerInfo</SPAN> with a <SPAN =
class=3DSpellE>metaSignature</SPAN>=20
  field that is a signature of the <SPAN=20
  class=3DSpellE>signedMetaAttributes</SPAN>.<SPAN=20
  style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN class=3DSpellE><SPAN=20
  class=3DGramE>signedMetaAttributes</SPAN></SPAN> should always contain =
the=20
  message digest attribute similar to <SPAN=20
  class=3DSpellE>signedAttrs</SPAN>.<SPAN style=3D"mso-spacerun: =
yes">&nbsp;=20
  </SPAN>This way the document and the label attribute are =
cryptographically=20
  bound.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Piers<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <P class=3DMsoAutoSig><st1:PersonName=20
  style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><FONT=20
  face=3D"Times New Roman" color=3Dnavy size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Piers=20
  Chivers</SPAN></FONT></st1:PersonName><FONT color=3Dnavy =
size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Product=20
  Architect</SPAN></FONT><FONT color=3Dnavy><SPAN=20
  style=3D"COLOR: navy; mso-no-proof: yes"><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">Protek=20
  Network Security<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><FONT face=3D"Times New Roman" color=3Dnavy =
size=3D2><SPAN=20
  lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; mso-ansi-language: EN-GB; =
mso-no-proof: yes">+44=20
  (0)1270 507800<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoAutoSig><U><FONT face=3D"Times New Roman" =
color=3D#0080ff size=3D2><SPAN=20
  lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><A=20
  =
href=3D"http://www.protek.com">www.protek.com</A></SPAN></FONT></U><FONT =

  color=3D#0080ff size=3D2><SPAN lang=3DEN-GB=20
  style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DTahoma =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma">-----Original=20
  Message-----<BR><B><SPAN style=3D"FONT-WEIGHT: bold">From:</SPAN></B> =
Sean P.=20
  Turner [mailto:[e-mail]] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> 20 March 2002 =
21:22<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Piers Chivers<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B> =
[e-mail]<BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Subject:</SPAN></B> Re: Labeling and=20
  SMIME</SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: =
12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times =
New Roman"=20
  size=3D3><SPAN style=3D"FONT-SIZE: 12pt">Piers, =
<o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">One way to allow a message to change label =
values over=20
  time would be to have the message (say it's marked A, where A is =
higher than=20
  B) include not only the marking A in the security label but also =
include an=20
  indication of when it should be considered to be marked B.&nbsp; You =
could do=20
  this with a security category. <o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">To me you always want to link the =
message/document,=20
  label, and signature in the same blob.&nbsp; Firstly, if you have a =
document I=20
  hope you've got the marking in the document's contents.&nbsp; Then, if =
you=20
  have to change the classification you'd also have to change the =
marking in the=20
  document; thereby, changing the document's contents and the original =
signature=20
  wouldn't be valid anymore anyway.&nbsp; To me when you change the =
label's=20
  values you're essentially changing the message/document and hence it =
ought to=20
  be treated as a new message/document. <o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">spt <o:p></o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-LEFT: 36pt"><FONT face=3D"Times New Roman" =
size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt">Piers Chivers wrote: =
<o:p></o:p></SPAN></FONT></P>
  <BLOCKQUOTE style=3D"MARGIN-TOP: 5pt; MARGIN-BOTTOM: 5pt"=20
    TYPE=3D"CITE"><U1:SMARTTAGTYPE name=3D"PersonName"=20
    namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
/><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:BreakWrappedTables/>
   <u2:SnapToGridInCell/>
   <u2:WrapTextWithPunct/>
   <u2:UseAsianBreakRules/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Hi,<U1:P></U1:P></SPAN></FONT><o:p></o:p></P></DIV>
    <DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial">I think that the =
current SMIME=20
    implementation for labeling is too inflexible.This is probably =
because it is=20
    modeled on a military world where a Top Secret message stays Top =
Secret for=20
    ever.However, in the commercial world a "Commercially Sensitive" =
document=20
    may become "Public" overtime or because of a change of circumstances =

    (details released to Stock Markets, document signed off by marketing =

    etc.).<U1:P></U1:P></SPAN></FONT><o:p></o:p></P></DIV>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Since, in =
SMIME,=20
    the label of a message is signed with the content of the document it =
is=20
    impossible for the label to be changed without re-computing a =
signature on=20
    the content of the document.This is erroneous since the person =
changing the=20
    label may not be the original creator of the document contents.Hence =
the=20
    proof-of-origin of the document will be =
lost.<U1:P></U1:P></SPAN></FONT>=20
    <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Have I =
missed a way=20
    to do this in the current CMS/SMIME model? If not, I would propose a =
scheme=20
    as follows:<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>a new =
MIME entity=20
    application/pkcs7-labeled that has 2 =
parts:<U1:P></U1:P></SPAN></FONT>=20
    <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>application/pkcs7-document=20
    that contains the document part of a multipart/signed entity=20
    and<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>application/pkcs7-label=20
    - a MIME entity that contains a signed CMS object containing the =
label and=20
    the original document's detached signature.The latter signature is =
provided=20
    by the person who creates the message.The outer signed CMS object is =
signed=20
    by the labeler of the document.Typically, the signatories will be =
the same=20
    person.<U1:P></U1:P></SPAN></FONT> <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>This =
approach=20
    allows labeled documents to be re-classified over time but keeps the =

    original document signature.<U1:P></U1:P></SPAN></FONT> =
<o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Arial"><U1:P></U1:P>Any=20
    thoughts?</SPAN></FONT><U1:P></U1:P> <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial"><U1:P></U1:P>Thanks,<U1:P></U1:P></SPAN></FONT>=20
    <o:p></o:p></P>
    <P class=3DMsoNormal style=3D"MARGIN-LEFT: 36pt"><FONT face=3DArial =
size=3D2><SPAN=20
    style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Arial">Piers<U1:P></U1:P></SPAN></FONT>=20
    <o:p></o:p></P>
    <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><st1:PersonName=20
    style=3D"BACKGROUND-POSITION: left bottom; BACKGROUND-IMAGE: =
url(res://ietag.dll/#34/#1001); BACKGROUND-REPEAT: repeat-x"><FONT=20
    face=3D"Times New Roman" size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes"><U1:P></U1:P>Piers=20
    Chivers</SPAN></FONT></st1:PersonName><SPAN =
lang=3DEN-GB><U1:P></U1:P>=20
    </SPAN><o:p></o:p></P>
    <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
    size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">Product=20
    Architect</SPAN></FONT><SPAN lang=3DEN-GB><U1:P></U1:P> =
</SPAN><o:p></o:p></P>
    <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
    size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">Protek=20
    Network Security<U1:P></U1:P></SPAN></FONT><SPAN lang=3DEN-GB>=20
    </SPAN><o:p></o:p></P>
    <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><FONT =
face=3D"Times New Roman"=20
    size=3D2><SPAN lang=3DEN-GB=20
    style=3D"FONT-SIZE: 10pt; mso-ansi-language: EN-GB; mso-no-proof: =
yes">+44=20
    (0)1270 507800<U1:P></U1:P></SPAN></FONT><SPAN lang=3DEN-GB>=20
    </SPAN><o:p></o:p></P>
    <P class=3DMsoAutoSig style=3D"MARGIN-LEFT: 36pt"><U><FONT=20
    face=3D"Times New Roman" color=3D#0080ff size=3D2><SPAN lang=3DEN-GB =

    style=3D"FONT-SIZE: 10pt; COLOR: #0080ff; mso-ansi-language: EN-GB; =
mso-no-proof: yes"><A=20
    =
href=3D"http://www.protek.com">www.protek.com</A></SPAN></FONT></U><SPAN =

    lang=3DEN-GB><U1:P></U1:P>=20
</SPAN><o:p></o:p></P></BLOCKQUOTE></DIV></BLOCKQUOTE><U1:P></U1:P></BODY=
></HTML>

------=_NextPart_000_000A_01C1D0C1.1EFFF140--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2LFDi414336 for ietf-smime-bks; Thu, 21 Mar 2002 07:13:44 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2LFDf414331 for <[e-mail]>; Thu, 21 Mar 2002 07:13:42 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Thu, 21 Mar 2002 15:15:22 -0000
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <HABZK32J>; Thu, 21 Mar 2002 15:10:49 -0000
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: "'Sean P. Turner'" <[e-mail]>
cc: [e-mail]
Subject: RE: Labeling and SMIME
Date: Thu, 21 Mar 2002 15:10:46 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 10872680682876-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01C1D0EA.94CCF30E"
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_01C1D0EA.94CCF30E
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Sean,
Thanks for the response.  Whether or not a label is part of a document and
hence changing the label changes the document is a philosophical debate.
Nevertheless, it is an important one.  I think that in a business world the
person who signs the content of a document could be different from the
person who labels a document.  Business policy should dictate who is allowed
to sign documents.  Similarly, policy should dictate who is allowed to set
or change a label.  The CMS spec doesn't allow for this.  
 
Further to my earlier suggestion, I would suggest that this should be
addressed at the CMS level.  One possibility is a signedMetaAttributes field
in the SignerInfo with a metaSignature field that is a signature of the
signedMetaAttributes.  signedMetaAttributes should always contain the
message digest attribute similar to signedAttrs.  This way the document and
the label attribute are cryptographically bound.
 
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 
-----Original Message-----
From: Sean P. Turner [mailto:[e-mail]] 
Sent: 20 March 2002 21:22
To: Piers Chivers
Cc: [e-mail]
Subject: Re: Labeling and SMIME
 
Piers, 
One way to allow a message to change label values over time would be to have
the message (say it's marked A, where A is higher than B) include not only
the marking A in the security label but also include an indication of when
it should be considered to be marked B.  You could do this with a security
category. 
To me you always want to link the message/document, label, and signature in
the same blob.  Firstly, if you have a document I hope you've got the
marking in the document's contents.  Then, if you have to change the
classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature
wouldn't be valid anymore anyway.  To me when you change the label's values
you're essentially changing the message/document and hence it ought to be
treated as a new message/document. 
spt 
Piers Chivers wrote: 
Hi,
I think that the current SMIME implementation for labeling is too
inflexible.This is probably because it is modeled on a military world where
a Top Secret message stays Top Secret for ever.However, in the commercial
world a "Commercially Sensitive" document may become "Public" overtime or
because of a change of circumstances (details released to Stock Markets,
document signed off by marketing etc.).
Since, in SMIME, the label of a message is signed with the content of the
document it is impossible for the label to be changed without re-computing a
signature on the content of the document.This is erroneous since the person
changing the label may not be the original creator of the document
contents.Hence the proof-of-origin of the document will be lost. 
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows: 
a new MIME entity application/pkcs7-labeled that has 2 parts: 
application/pkcs7-document that contains the document part of a
multipart/signed entity and 
application/pkcs7-label - a MIME entity that contains a signed CMS object
containing the label and the original document's detached signature.The
latter signature is provided by the person who creates the message.The outer
signed CMS object is signed by the labeler of the document.Typically, the
signatories will be the same person. 
This approach allows labeled documents to be re-classified over time but
keeps the original document signature. 
Any thoughts? 
Thanks, 
Piers 
Piers Chivers 
Product Architect 
Protek Network Security 
[phone] 
www.protek.com <http://www.protek.com>  

------_=_NextPart_001_01C1D0EA.94CCF30E
Content-Type: text/html; 
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1D0EB.024B0F10">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:553679495 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
p
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle20
	{mso-style-type:personal;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:navy;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Sean,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Thanks for the response.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Whether or not a label is part =
of a
document and hence changing the label changes the document is a =
philosophical
debate.<span style=3D'mso-spacerun:yes'>&nbsp; </span>Nevertheless, it =
is an
important one.<span style=3D'mso-spacerun:yes'>&nbsp; </span>I think =
that in a
business world the person who signs the content of a document could be =
different
from the person who labels a document.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>Business policy should dictate who is allowed to sign =
documents.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Similarly, policy should =
dictate who is
allowed to set or change a label. <span
style=3D'mso-spacerun:yes'>&nbsp;</span>The CMS spec doesn't allow for
this.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Further to my earlier suggestion, =
I would suggest
that this should be addressed at the CMS level.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>One possibility is a <span =
class=3DSpellE>signedMetaAttributes</span>
field in the <span class=3DSpellE>SignerInfo</span> with a <span =
class=3DSpellE>metaSignature</span>
field that is a signature of the <span =
class=3DSpellE>signedMetaAttributes</span>.<span
style=3D'mso-spacerun:yes'>&nbsp; </span><span class=3DSpellE><span =
class=3DGramE>signedMetaAttributes</span></span>
should always contain the message digest attribute similar to <span
class=3DSpellE>signedAttrs</span>.<span =
style=3D'mso-spacerun:yes'>&nbsp;
</span>This way the document and the label attribute are =
cryptographically
bound.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'>Piers<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<div>

<p class=3DMsoAutoSig><st1:PersonName><font size=3D2 color=3Dnavy
 face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
 mso-ansi-language:EN-GB;mso-no-proof:yes'>Piers =
Chivers</span></font></st1:PersonName><font
size=3D2 color=3Dnavy><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>Product Architect</span></font><font =
color=3Dnavy><span
style=3D'color:navy;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>Protek Network Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 color=3Dnavy face=3D"Times New =
Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:navy;mso-ansi-language:EN-GB;
mso-no-proof:yes'>[phone]<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><u><font size=3D2 color=3D"#0080ff" face=3D"Times =
New Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

</div>

<p class=3DMsoNormal><font size=3D2 color=3Dnavy face=3DArial><span =
style=3D'font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>=


<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:Tahoma'>-----Original =
Message-----<br>
<b><span style=3D'font-weight:bold'>From:</span></b> Sean P. Turner
[mailto:[e-mail]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> 20 March 2002 =
21:22<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Piers Chivers<br>
<b><span style=3D'font-weight:bold'>Cc:</span></b> =
[e-mail]<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Labeling =
and SMIME</span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span =
style=3D'font-size:12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D3
face=3D"Times New Roman"><span style=3D'font-size:12.0pt'>Piers, =
<o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>One way to allow a message to change label =
values over
time would be to have the message (say it's marked A, where A is higher =
than B)
include not only the marking A in the security label but also include =
an
indication of when it should be considered to be marked B.&nbsp; You =
could do
this with a security category. <o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>To me you always want to link the =
message/document,
label, and signature in the same blob.&nbsp; Firstly, if you have a =
document I
hope you've got the marking in the document's contents.&nbsp; Then, if =
you have
to change the classification you'd also have to change the marking in =
the
document; thereby, changing the document's contents and the original =
signature
wouldn't be valid anymore anyway.&nbsp; To me when you change the =
label's
values you're essentially changing the message/document and hence it =
ought to
be treated as a new message/document. <o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>spt <o:p></o:p></span></font></p>

<p style=3D'margin-left:36.0pt'><font size=3D3 face=3D"Times New =
Roman"><span
style=3D'font-size:12.0pt'>Piers Chivers wrote: =
<o:p></o:p></span></font></p>

<blockquote style=3D'margin-top:5.0pt;margin-bottom:5.0pt' =
TYPE=3DCITE><u1:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags" =
name=3D"PersonName"/><!--[if gte mso 9]><xml>
 <u1:OfficeDocumentSettings>
  <u1:DoNotRelyOnCSS/>
 </u1:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <u2:WordDocument>
  <u2:SpellingState>Clean</u2:SpellingState>
  <u2:GrammarState>Clean</u2:GrammarState>
  <u2:DocumentKind>DocumentEmail</u2:DocumentKind>
  <u2:EnvelopeVis/>
  <u2:Compatibility>
   <u2:BreakWrappedTables/>
   <u2:SnapToGridInCell/>
   <u2:WrapTextWithPunct/>
   <u2:UseAsianBreakRules/>
  </u2:Compatibility>
  <u2:BrowserLevel>MicrosoftInternetExplorer4</u2:BrowserLevel>
 </u2:WordDocument>
</xml><![endif]-->

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Hi,<u1:p></u1:p></span></fo=
nt><o:p></o:p></p>

</div>

<div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>I think that the current =
SMIME
implementation for labeling is too inflexible.This is probably because =
it is
modeled on a military world where a Top Secret message stays Top Secret =
for
ever.However, in the commercial world a &quot;Commercially =
Sensitive&quot;
document may become &quot;Public&quot; overtime or because of a change =
of
circumstances (details released to Stock Markets, document signed off =
by
marketing etc.).<u1:p></u1:p></span></font><o:p></o:p></p>

</div>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Since, in =
SMIME, the
label of a message is signed with the content of the document it is =
impossible
for the label to be changed without re-computing a signature on the =
content of
the document.This is erroneous since the person changing the label may =
not be
the original creator of the document contents.Hence the proof-of-origin =
of the
document will be lost.<u1:p></u1:p></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Have I missed =
a way to
do this in the current CMS/SMIME model? If not, I would propose a =
scheme as
follows:<u1:p></u1:p></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>a new MIME =
entity
application/pkcs7-labeled that has 2 parts:<u1:p></u1:p></span></font> =
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>application/pk=
cs7-document
that contains the document part of a multipart/signed entity =
and<u1:p></u1:p></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>application/pk=
cs7-label
- a MIME entity that contains a signed CMS object containing the label =
and the
original document's detached signature.The latter signature is provided =
by the
person who creates the message.The outer signed CMS object is signed by =
the
labeler of the document.Typically, the signatories will be the same =
person.<u1:p></u1:p></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>This approach =
allows
labeled documents to be re-classified over time but keeps the original =
document
signature.<u1:p></u1:p></span></font> <o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Any =
thoughts?</span></font><u1:p></u1:p>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'><u1:p></u1:p>Thanks,<u1:p><=
/u1:p></span></font>
<o:p></o:p></p>

<p class=3DMsoNormal style=3D'margin-left:36.0pt'><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Piers<u1:p></u1:p></span></=
font> <o:p></o:p></p>

<p class=3DMsoAutoSig =
style=3D'margin-left:36.0pt'><st1:PersonName><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'><u1:p></u1:p>Piers =
Chivers</span></font></st1:PersonName><span
lang=3DEN-GB><u1:p></u1:p> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>Product Architect</span></font><span =
lang=3DEN-GB><u1:p></u1:p>
</span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>Protek Network =
Security<u1:p></u1:p></span></font><span
lang=3DEN-GB> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><font size=3D2
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:
EN-GB;mso-no-proof:yes'>+44 (0)1270 =
507800<u1:p></u1:p></span></font><span
lang=3DEN-GB> </span><o:p></o:p></p>

<p class=3DMsoAutoSig style=3D'margin-left:36.0pt'><u><font size=3D2 =
color=3D"#0080ff"
face=3D"Times New Roman"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><span=

lang=3DEN-GB><u1:p></u1:p> </span><o:p></o:p></p>

</blockquote>

</div>

<u1:p></u1:p>
</body>

</html>

------_=_NextPart_001_01C1D0EA.94CCF30E--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KLLYA11192 for ietf-smime-bks; Wed, 20 Mar 2002 13:21:34 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2KLLV411187 for <[e-mail]>; Wed, 20 Mar 2002 13:21:32 -0800 (PST)
Received: from ieca.com (tweety.ietf53.cw.net [166.63.189.52]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 0584A6A911; Wed, 20 Mar 2002 15:21:33 -0600 (CST)
Message-ID: <[e-mail]>
Date: Wed, 20 Mar 2002 15:21:38 -0600
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Piers Chivers <[e-mail]>
Cc: [e-mail]
Subject: Re: Labeling and SMIME
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body link="#0000FF" vlink="#800080" lang="EN-US" style="tab-interval:36.0pt">
Piers,
<p>One way to allow a message to change label values over time would be
to have the message (say it's marked A, where A is higher than B) include
not only the marking A in the security label but also include an indication
of when it should be considered to be marked B.&nbsp; You could do this
with a security category.
<p>To me you always want to link the message/document, label, and signature
in the same blob.&nbsp; Firstly, if you have a document I hope you've got
the marking in the document's contents.&nbsp; Then, if you have to change
the classification you'd also have to change the marking in the document;
thereby, changing the document's contents and the original signature wouldn't
be valid anymore anyway.&nbsp; To me when you change the label's values
you're essentially changing the message/document and hence it ought to
be treated as a new message/document.
<p>spt
<p>Piers Chivers wrote:
<blockquote TYPE=CITE><link rel=File-List href="cid:filelist.xml@01C1D000.F268B3D0"><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="PersonName"/><!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]--><style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */ 
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
<div class=Section1>
<div class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>Hi,</font></font><o:p></o:p></span></div>

<div class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>I
think that the current SMIME implementation for labeling is too inflexible.<span style='mso-spacerun:yes'></span>This
is probably because it is modeled on a military world where a Top Secret
message stays Top Secret for ever.<span style='mso-spacerun:yes'></span>However,
in the commercial world a "Commercially Sensitive" document may become
"Public" overtime or because of a change of circumstances (details released
to Stock Markets, document signed off by marketing etc.).</font></font><o:p></o:p></span></div>


<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>Since,
in SMIME, the label of a message is signed with the content of the document
it is impossible for the label to be changed without re-computing a signature
on the content of the document.<span 
style='mso-spacerun:yes'></span>This
is erroneous since the person changing the label may not be the original
creator of the document contents.<span 
style='mso-spacerun:yes'></span>Hence
the proof-of-origin of the document will be lost.</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>Have
I missed a way to do this in the current CMS/SMIME model? If not, I would
propose a scheme as follows:</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span class=GramE><span 
style='font-size:10.0pt;font-family:Arial'><font face="Arial"><font size=-1>a</span></span><span style='font-size:10.0pt;font-family:Arial'>
new MIME entity application/pkcs7-labeled that has 2 parts:</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span class=GramE><span 
style='font-size:10.0pt;font-family:Arial'><font face="Arial"><font size=-1>application/pkcs7-document</span></span><span style='font-size:10.0pt;font-family:Arial'>
that contains the document part of a multipart/signed entity and</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span class=GramE><span 
style='font-size:10.0pt;font-family:Arial'><font face="Arial"><font size=-1>application/pkcs7-label</span></span><span style='font-size:10.0pt;font-family:Arial'>
- a MIME entity that contains a signed CMS object containing the label
and the original document's detached signature.<span style='mso-spacerun:yes'></span>The
latter signature is provided by the person who creates the message.<span style='mso-spacerun:yes'></span>The
outer signed CMS object is signed by the labeler of the document.<span 
style='mso-spacerun:yes'></span>Typically,
the signatories will be the same person.</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>This
approach allows labeled documents to be re-classified over time but keeps
the original document signature.</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span class=GramE><span 
style='font-size:10.0pt;font-family:Arial'><font face="Arial"><font size=-1>Any
thoughts?</font></font></span></span><span style='font-size:10.0pt;font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>Thanks,</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><font face="Arial"><font size=-1>Piers</font></font><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:10.0pt;
font-family:Arial'><o:p></o:p></span>

<p class="MsoAutoSig"><st1:PersonName><span 
 lang=EN-GB style='font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><font face="Times New Roman"><font size=-1>Piers
Chivers</font></font></span></st1:PersonName><span lang=EN-GB
style='font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span>

<p class="MsoAutoSig"><span lang=EN-GB
style='font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><font face="Times New Roman"><font size=-1>Product
Architect</font></font></span><span style='mso-no-proof:yes'><o:p></o:p></span>

<p class="MsoAutoSig"><span lang=EN-GB
style='font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><font face="Times New Roman"><font size=-1>Protek
Network Security</font></font><o:p></o:p></span>

<p class="MsoAutoSig"><span lang=EN-GB
style='font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><font face="Times New Roman"><font size=-1>+44
(0)1270 507800</font></font><o:p></o:p></span>

<p class="MsoAutoSig"><span 
lang=EN-GB style='font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><u><font face="Times New Roman"><font color="#0080FF"><font size=-1><a href="http://www.protek.com">www.protek.com</a></font></font></font></u></span><span lang=EN-GB style='font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span>

<p class="MsoNormal"><span style='font-size:
12.0pt'><o:p></o:p></span></div>
</blockquote>

</body>
</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KCY4v29122 for ietf-smime-bks; Wed, 20 Mar 2002 04:34:04 -0800 (PST)
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 g2KCY3429118 for <[e-mail]>; Wed, 20 Mar 2002 04:34:04 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Wed, 20 Mar 2002 04:43:22 -0800
Message-ID: <1389308.1016628204312.JavaMail.administrator@highland>
From: "Blake Ramsdell" <[e-mail]>
To: "Piers Chivers" <[e-mail]>, <[e-mail]>
References: <3315058.1016626368062.JavaMail.administrator@highland>
Subject: Re: Comments on RFC2633bis
Date: Wed, 20 Mar 2002 04:39:49 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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>

Thanks for taking the time to comment -- please find my responses inline,
marked with [bcr].  Sorry about the somewhat confusing formatting -- some
mail clients are better at doing quoting than others.

----- Original Message -----
From: Piers Chivers
To: [e-mail]
Sent: Wednesday, March 20, 2002 2:49 AM
Subject: Comments on RFC2633bis


Section 3.1.2 - This section is very confusing for somebody (like myself)
who is using the spec to generate SMIME "things" in a non-mail environment.
I'm quite happy with binary transfer encoding since my SMIME things never
see SMTP environments.  I would prefer to see a section headed "Transfer
Encoding considerations in SMTP or 7-bit worlds".  All the transfer encoding
considerations for those environments can be listed there.  Otherwise the
spec should say that _any_ transfer encoding is permitted.

[bcr] I might argue that a non-mail environment is more of a CMS environment
than an S/MIME one, so most of the rules that are imposed by the S/MIME
profile need not apply.  You can use CMS directly and apply whatever rules
are appropriate in your environment, which may be a better idea.  The reason
why there are various restrictions on content transfer encoding are based on
the need to be compatible with the least common denominator MIME
environment.  If there is consensus that having a separate S/MIME profile
for SMTP and non-SMTP environments is useful, then maybe we should discuss
it further.  Another reason for the restriction was based on client support
for binary encoding, even outside of SMTP.  I think this was a topic of some
controversy at one point, but certainly it might bear revisiting.


Section 3.2.2 Bullet point 1. - I simply don't understand this para! I think
it should be re-written so that I can understand it!!  An example is worth a
thousand pictures.

[bcr] I agree, and I will try to clarify this.  I think that the point is
that a receipt could be either enveloped or signed, so therefore it could be
"signed-receipt" or "enveloped-receipt".  Jim or John might be able to chime
in here with some insight, since I suspect that one of them submitted the
language that's confusing to you ;).


Section 3.3 Step 3 - the sentence says that the CMS object from the previous
step (envelopedData) is inserted into the MIME entity.  In fact a CMS object
of ContentInfo containing the envelopedData object should be inserted.  The
same comment applies to Section 3.4.2.  My thanks to Russ Housley for
confirming my understanding of this.

[bcr] Agreed.


Section 3.4.3.1 first sentence - is this true?  Or should it be a
ContentInfo containing a signedData object?

[bcr] Same problem as above.  It should be a ContentInfo containing a
SignedData object.


Section 3.5 - it would have helped me greatly if this section had
(re-)stated that in SMIME the CMS secured stuff is always a MIME entity.  I
wasn't sure if a signed then encrypted message needed to have the MIME
encoding around the inner ContentInfo/SignedData object.

[bcr] How about changing the paragraph:

To achieve signing and enveloping, any of the signed-only and
encrypted-only formats may be nested. This is allowed because the
above formats are all MIME entities, and because they all secure MIME
entities.

To read:

To achieve signing and enveloping, any of the signed-only and encrypted-only
MIME formats listed above may be nested. This is allowed because the above
formats are all MIME entities, and because they all secure MIME entities.

Is that sufficient?

Thanks again for the comments.

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KBHUO24767 for ietf-smime-bks; Wed, 20 Mar 2002 03:17:30 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2KBHS424762 for <[e-mail]>; Wed, 20 Mar 2002 03:17:28 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 20 Mar 2002 11:18:24 -0000
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <HABZKLRX>; Wed, 20 Mar 2002 11:14:56 -0000
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: [e-mail]
Subject: Labeling and SMIME
Date: Wed, 20 Mar 2002 11:14:55 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1086AF8A659000-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01C1D000.76D24F1A"
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_01C1D000.76D24F1A
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,
I think that the current SMIME implementation for labeling is too
inflexible.  This is probably because it is modeled on a military world
where a Top Secret message stays Top Secret for ever.  However, in the
commercial world a "Commercially Sensitive" document may become "Public"
overtime or because of a change of circumstances (details released to Stock
Markets, document signed off by marketing etc.).
 
Since, in SMIME, the label of a message is signed with the content of the
document it is impossible for the label to be changed without re-computing a
signature on the content of the document.  This is erroneous since the
person changing the label may not be the original creator of the document
contents.  Hence the proof-of-origin of the document will be lost.
 
Have I missed a way to do this in the current CMS/SMIME model? If not, I
would propose a scheme as follows:
 
a new MIME entity application/pkcs7-labeled that has 2 parts:
 
application/pkcs7-document that contains the document part of a
multipart/signed entity and
 
application/pkcs7-label - a MIME entity that contains a signed CMS object
containing the label and the original document's detached signature.  The
latter signature is provided by the person who creates the message.  The
outer signed CMS object is signed by the labeler of the document.
Typically, the signatories will be the same person.
 
This approach allows labeled documents to be re-classified over time but
keeps the original document signature.
 
Any thoughts?
 
Thanks,
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 

------_=_NextPart_001_01C1D000.76D24F1A
Content-Type: text/html; 
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1D000.F268B3D0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I think that the current SMIME implementation for =
labeling
is too inflexible.<span style=3D'mso-spacerun:yes'>&nbsp; </span>This =
is probably
because it is modeled on a military world where a Top Secret message =
stays Top
Secret for ever.<span style=3D'mso-spacerun:yes'>&nbsp; </span>However, =
in the commercial
world a "Commercially Sensitive" document may become "Public"
overtime or because of a change of circumstances (details released to =
Stock
Markets, document signed off by marketing =
etc.).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Since, in SMIME, the label of a message is signed =
with the
content of the document it is impossible for the label to be changed =
without
re-computing a signature on the content of the document.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>This is erroneous since the =
person
changing the label may not be the original creator of the document =
contents.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Hence the proof-of-origin of =
the
document will be lost.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Have I missed a way to do this in the current =
CMS/SMIME
model? If not, I would propose a scheme as =
follows:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>a</span></font></span><font=
 size=3D2
face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'> new =
MIME entity
application/pkcs7-labeled that has 2 =
parts:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>application/pkcs7-document<=
/span></font></span><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> that
contains the document part of a multipart/signed entity =
and<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>application/pkcs7-label</sp=
an></font></span><font
size=3D2 face=3DArial><span style=3D'font-size:10.0pt;font-family:Arial'=
> - a MIME
entity that contains a signed CMS object containing the label and the =
original
document's detached signature.<span style=3D'mso-spacerun:yes'>&nbsp;
</span>The latter signature is provided by the person who creates the
message.<span style=3D'mso-spacerun:yes'>&nbsp; </span>The outer signed =
CMS
object is signed by the labeler of the document.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Typically, the signatories =
will be the
same person.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>This approach allows labeled documents to be =
re-classified
over time but keeps the original document =
signature.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Any =
thoughts?</span></font></span><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'><o:p></o:p></span></font></=
p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Piers<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><st1:PersonName><font size=3D2 face=3D"Times New =
Roman"><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Pier=
s
 Chivers</span></font></st1:PersonName><font size=3D2><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p=
></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prod=
uct
Architect</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prot=
ek
Network Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>+44 =
(0)1270
507800<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><u><font size=3D2 color=3D"#0080ff" face=3D"Times =
New Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1D000.76D24F1A--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2KAqcj21427 for ietf-smime-bks; Wed, 20 Mar 2002 02:52:38 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2KAqZ421420 for <[e-mail]>; Wed, 20 Mar 2002 02:52:36 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Wed, 20 Mar 2002 10:53:27 -0000
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <HABZKLP3>; Wed, 20 Mar 2002 10:49:59 -0000
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: [e-mail]
Subject: Comments on RFC2633bis
Date: Wed, 20 Mar 2002 10:49:58 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1086B5AD658403-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01C1CFFC.FA7002BC"
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_01C1CFFC.FA7002BC
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Some comments on RFC2633bis:
 
Section 1.1 3rd para - remove all of the "also"s.
 
Section 3.1.2 - This section is very confusing for somebody (like myself)
who is using the spec to generate SMIME "things" in a non-mail environment.
I'm quite happy with binary transfer encoding since my SMIME things never
see SMTP environments.  I would prefer to see a section headed "Transfer
Encoding considerations in SMTP or 7-bit worlds".  All the transfer encoding
considerations for those environments can be listed there.  Otherwise the
spec should say that _any_ transfer encoding is permitted.
 
Section 3.2.2 Bullet point 1. - I simply don't understand this para! I think
it should be re-written so that I can understand it!!  An example is worth a
thousand pictures.
 
Section 3.3 Step 3 - the sentence says that the CMS object from the previous
step (envelopedData) is inserted into the MIME entity.  In fact a CMS object
of ContentInfo containing the envelopedData object should be inserted.  The
same comment applies to Section 3.4.2.  My thanks to Russ Housley for
confirming my understanding of this.
 
Section 3.4.3.1 first sentence - is this true?  Or should it be a
ContentInfo containing a signedData object?
 
Section 3.5 - it would have helped me greatly if this section had
(re-)stated that in SMIME the CMS secured stuff is always a MIME entity.  I
wasn't sure if a signed then encrypted message needed to have the MIME
encoding around the inner ContentInfo/SignedData object.
 
Thanks,
Piers
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 

------_=_NextPart_001_01C1CFFC.FA7002BC
Content-Type: text/html; 
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1CFFD.75EC4AE0">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Some comments on =
RFC2633bis:<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 1.1 3<sup>rd</sup> <span =
class=3DSpellE>para</span> -
remove all of the "<span =
class=3DSpellE>also"s</span>.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 3.1.2 - This section is very confusing for
somebody (like <span class=3DGramE>myself</span>) who is using the spec =
to
generate SMIME "things" in a non-mail environment.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I'm quite happy with binary
transfer encoding since my SMIME things never see SMTP =
environments.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>I would prefer to see a =
section headed "Transfer
Encoding considerations in SMTP or 7-bit worlds".<span
style=3D'mso-spacerun:yes'>&nbsp; </span>All the transfer encoding =
considerations
for those environments can be listed there.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Otherwise the spec should say =
that _<i><span
style=3D'font-style:italic'>any</span></i>_ transfer encoding is =
permitted.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><span class=3DGramE><font size=3D2 =
face=3DArial><span
style=3D'font-size:10.0pt;font-family:Arial'>Section 3.2.2 Bullet point =
1.</span></font></span><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'> - I simply
don't understand this <span class=3DSpellE>para</span>! I think it =
should
be re-written so that I can understand it!!<span
style=3D'mso-spacerun:yes'>&nbsp; </span>An example is worth a thousand =
pictures.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 3.3 Step 3 - the sentence says that the CMS
object from the previous step (<span =
class=3DSpellE>envelopedData</span>) is
inserted into the MIME entity.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>In
fact a CMS object of <span class=3DSpellE>ContentInfo</span> containing =
the <span
class=3DSpellE>envelopedData</span> object should be inserted.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>The same comment applies to =
Section
3.4.2.<span style=3D'mso-spacerun:yes'>&nbsp; </span>My thanks to Russ =
Housley
for confirming my understanding of this.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 3.4.3.1 first sentence - is this true?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Or should it be a <span =
class=3DSpellE>ContentInfo</span>
containing a <span class=3DSpellE>signedData</span> =
object?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Section 3.5 - it would have helped me greatly if =
this
section had (re-)stated that in SMIME the CMS secured stuff is always a =
MIME
entity.<span style=3D'mso-spacerun:yes'>&nbsp; </span>I wasn't sure if =
a
signed then encrypted message needed to have the MIME encoding around =
the inner
<span class=3DSpellE>ContentInfo/SignedData</span> =
object.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Thanks,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Piers<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><st1:PersonName><font size=3D2 face=3D"Times New =
Roman"><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Pier=
s
 Chivers</span></font></st1:PersonName><font size=3D2><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p=
></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prod=
uct
Architect</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prot=
ek
Network Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>+44 =
(0)1270
507800<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><u><font size=3D2 color=3D"#0080ff" face=3D"Times =
New Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C1CFFC.FA7002BC--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2JCfm206941 for ietf-smime-bks; Tue, 19 Mar 2002 04:41:48 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g2JCfk406936 for <[e-mail]>; Tue, 19 Mar 2002 04:41:47 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 19 Mar 2002 12:42:44 -0000
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <HABZKJW5>; Tue, 19 Mar 2002 12:39:18 -0000
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
cc: [e-mail], [e-mail]
Subject: RE: Order of signing and compression operations.
Date: Tue, 19 Mar 2002 12:39:15 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1089EDCE641738-01-01
Content-Type: text/plain;  charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

Doesn't it depend on the purpose of the signature?  If it's just data
integrity then the order is probably application specific.  However, if
non-repudiation is required then I think the signature must be applied
before the compression.  This is mandated by EU Directive on Signatures, for
example, where

"the data used for verifying the signature correspond to the data displayed
to the verifier;"

I suspect a compressed blob won't make much sense to most verifiers.  Then
again, nor does a MIME encoding.

Piers

Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com
 

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: 17 March 2002 23:44
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Order of signing and compression operations.


Peter:

I understand your points.  In general, I prefer to sign what I said, not 
what I transmitted.  It just means that there are fewer software steps 
after signature validation to introduce mistakes.  I am sure that you 
consider this to be more hand waving.

Russ

At 03:52 PM 3/16/2002 +1300, Peter Gutmann wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >A general rule of thumb: sign before compress.
>
>Is there any strong argument for this?  The only place where I've seen this
>requirement is in RFC 2440, where the justification is some vague
handwaving
>which fails to convince [0].  I suspect the main reason it's done that way
is
>because Phil did it that way originally and it just ended up in the
standard
>like that.
>
>There are two good arguments against signing first, which are that it
really
>screws up the compression and that it slows down signing since you have to 
>hash
>all the data and not just the compressed form, but apart from vague
misgivings
>about not signing plaintext directly I don't know of a good argument
against
>it.  For that reason I deliberately didn't mandate either option in the RFC
>except to point out that compressing first would be faster.
>
>Peter.
>
>[0] Having scanned 2440 I can't even find the handwaving I thought was
there,
>         although another reason for doing is is that if you compress 
> first, the
>         whole PGP format breaks down when you add multiple signatures.



Received: by above.proper.com (8.11.6/8.11.3) id g2J3m7P20339 for ietf-smime-bks; Mon, 18 Mar 2002 19:48:07 -0800 (PST)
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 g2J3m5420335 for <[e-mail]>; Mon, 18 Mar 2002 19:48:05 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Mar 2002 03:47:31 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 WAA26643; Mon, 18 Mar 2002 22:47:30 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g2J3m8G12331; Mon, 18 Mar 2002 22:48:08 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVMB95>; Mon, 18 Mar 2002 22:45:50 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.16.58 [10.3.16.58]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRVMB9W; Mon, 18 Mar 2002 22:45:38 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail] (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sun, 17 Mar 2002 18:43:32 -0500
Subject: Re: Order of signing and compression operations.
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter:

I understand your points.  In general, I prefer to sign what I said, not 
what I transmitted.  It just means that there are fewer software steps 
after signature validation to introduce mistakes.  I am sure that you 
consider this to be more hand waving.

Russ

At 03:52 PM 3/16/2002 +1300, Peter Gutmann wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >A general rule of thumb: sign before compress.
>
>Is there any strong argument for this?  The only place where I've seen this
>requirement is in RFC 2440, where the justification is some vague handwaving
>which fails to convince [0].  I suspect the main reason it's done that way is
>because Phil did it that way originally and it just ended up in the standard
>like that.
>
>There are two good arguments against signing first, which are that it really
>screws up the compression and that it slows down signing since you have to 
>hash
>all the data and not just the compressed form, but apart from vague misgivings
>about not signing plaintext directly I don't know of a good argument against
>it.  For that reason I deliberately didn't mandate either option in the RFC
>except to point out that compressing first would be faster.
>
>Peter.
>
>[0] Having scanned 2440 I can't even find the handwaving I thought was there,
>         although another reason for doing is is that if you compress 
> first, the
>         whole PGP format breaks down when you add multiple signatures.


Received: by above.proper.com (8.11.6/8.11.3) id g2IMqYM13236 for ietf-smime-bks; Mon, 18 Mar 2002 14:52:34 -0800 (PST)
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 g2IMqX413232 for <[e-mail]>; Mon, 18 Mar 2002 14:52:34 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Mon, 18 Mar 2002 15:01:58 -0800
Message-ID: <1075059.1016492519390.JavaMail.administrator@highland>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <2057774.1016489211109.JavaMail.administrator@highland>
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Mon, 18 Mar 2002 14:59:30 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>; <[e-mail]>
Sent: Monday, March 18, 2002 1:55 PM
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt


> There is a difference between what we consider to be good practice and
> how backwards compability works.  I think that making it a MAY (or
> omitting entirely) and adding a note that this is a common algorithm
> still (is that really true? 11 out of 108 with what types of experation
> dates) is sufficent to address your needs without having an endorsement
> of this as a good algorithm on our (the WG) part.

This was 11 of 108 certificates that ship with Windows XP.  Since everyone
seems to be treating expiration dates in self-signed root certificates as a
joke (2028, 2039, etc.), then I presume that this isn't really relevant.

> Remember that md2 is not an acceptable PKIX algorithm.  I think we
> should follow that lead.

My point is that current, deployed, popular roots are using MD2.  I agree
that new signatures SHOULD/MUST NOT be created using MD2, but I can't say
that you shouldn't support verification with it.

Perhaps a separation of verifying vs. creating in this case would be in
order?

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2ILvPh11916 for ietf-smime-bks; Mon, 18 Mar 2002 13:57:25 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2ILvO411912 for <[e-mail]>; Mon, 18 Mar 2002 13:57:24 -0800 (PST)
Received: from revelation (unknown [166.63.190.57]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 751896A90E; Mon, 18 Mar 2002 15:57:26 -0600 (CST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Blake Ramsdell'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Mon, 18 Mar 2002 15:55:15 -0600
Message-ID: <000e01c1cec7$9632f420$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <2640579.1016485832703.JavaMail.administrator@highland>
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>

MD2 is is known to have pseudo collisions.  In the previous version of
the draft md2 was a SHOULD (along with the rest of the RSA algorithms).
You have promoted it when I consider it to be a suspect algorithm.  

There is a difference between what we consider to be good practice and
how backwards compability works.  I think that making it a MAY (or
omitting entirely) and adding a note that this is a common algorithm
still (is that really true? 11 out of 108 with what types of experation
dates) is sufficent to address your needs without having an endorsement
of this as a good algorithm on our (the WG) part.

Remember that md2 is not an acceptable PKIX algorithm.  I think we
should follow that lead.

jim

> -----Original Message-----
> From: Blake Ramsdell [mailto:[e-mail]] 
> Sent: Monday, March 18, 2002 3:10 PM
> To: [e-mail]; [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> 
> 
> Thanks for the comments, Jim -- one quick question below.
> 
> ----- Original Message -----
> From: "Jim Schaad" <[e-mail]>
> To: <[e-mail]>; "'Blake Ramsdell'" 
> <[e-mail]>
> Sent: Monday, March 18, 2002 10:27 AM
> Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
> 
> 
> > 1.  I strongly disagree that md2-with-RSA is a MUST.  I think this
> > should be a MAY or omitted.
> 
> On what basis you you disagree?
> 
> For compatibility, dropping MD2 may not be the best idea.  
> Based on a quick
> evaluation of the root self-signed certificates that I have, 
> I found 108
> total certificates, 11 of which were signed with MD2 (44 were 
> signed with
> MD5, the rest with SHA-1).
> 
> Blake
> 



Received: by above.proper.com (8.11.6/8.11.3) id g2IL19v10825 for ietf-smime-bks; Mon, 18 Mar 2002 13:01:09 -0800 (PST)
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 g2IL18410821 for <[e-mail]>; Mon, 18 Mar 2002 13:01:08 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Mon, 18 Mar 2002 13:10:31 -0800
Message-ID: <2640579.1016485832703.JavaMail.administrator@highland>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
References: <809551.1016479153187.JavaMail.administrator@highland>
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Mon, 18 Mar 2002 13:10:29 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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>

Thanks for the comments, Jim -- one quick question below.

----- Original Message -----
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>; "'Blake Ramsdell'" <[e-mail]>
Sent: Monday, March 18, 2002 10:27 AM
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt


> 1.  I strongly disagree that md2-with-RSA is a MUST.  I think this
> should be a MAY or omitted.

On what basis you you disagree?

For compatibility, dropping MD2 may not be the best idea.  Based on a quick
evaluation of the root self-signed certificates that I have, I found 108
total certificates, 11 of which were signed with MD2 (44 were signed with
MD5, the rest with SHA-1).

Blake



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IJkrL07708 for ietf-smime-bks; Mon, 18 Mar 2002 11:46:53 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IJkp407704 for <[e-mail]>; Mon, 18 Mar 2002 11:46:51 -0800 (PST)
Received: from ieca.com (tweety.ietf53.cw.net [166.63.189.120]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 311B86A90A for <[e-mail]>; Mon, 18 Mar 2002 09:31:23 -0600 (CST)
Message-ID: <[e-mail]>
Date: Mon, 18 Mar 2002 13:47:08 +1200
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
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>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Some minor comments:
<p>Para 1.1 - Attribute Certificate - I don't want to open a can of worms
but should we point to the PKIX AC profile instead of X.509?&nbsp; Also
please add period to last sentence.
<p>Para 2.1 and 4,1 - I'm confused by the sentence "All agents MUST perform
revocation status checking in accordance with [KEYM]."&nbsp; I thought
PKIX didn't mandate any particular revocation status checking scheme like
CRLs, OCSP, SCVP, etc..&nbsp; Are you trying to say if you use CRLs as
the revocation status check scheme then you have to use the process in
PKIX?
<p>Cheers,
<p>spt
<p>[e-mail] wrote:
<blockquote TYPE=CITE>A New Internet-Draft is available from the on-line
Internet-Drafts directories.
<br>This draft is a work item of the S/MIME Mail Security Working Group
of the IETF.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: S/MIME Version 3.1 Certificate Handling
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: B. Ramsdell
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: draft-ietf-smime-rfc2632bis-00.txt
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 11-Feb-02
<p>S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
<br>[SMIME-MSG], provides a method to send and receive secure MIME
<br>messages. Before using a public key to provide security services, the
<br>S/MIME agent MUST certify that the public key is valid. S/MIME agents
<br>MUST use PKIX certificates to validate public keys as described in
the
<br>Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
<br>Profile [KEYM]. S/MIME agents MUST meet the certificate processing
<br>requirements documented in this document in addition to those stated
<br>in [KEYM].
<p>A URL for this Internet-Draft is:
<br><a href="http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2632bis-00.txt</a>
<p>To remove yourself from the IETF Announcement list, send a message to
<br>ietf-announce-request with the word unsubscribe in the body of the
message.
<p>Internet-Drafts are also available by anonymous FTP. Login with the
username
<br>"anonymous" and a password of your e-mail address. After logging in,
<br>type "cd internet-drafts" and then
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get draft-ietf-smime-rfc2632bis-00.txt".
<p>A list of Internet-Drafts directories can be found in
<br><a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>
<br>or <a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>
<p>Internet-Drafts can also be obtained by e-mail.
<p>Send a message to:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [e-mail].
<br>In the body type:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE /internet-drafts/draft-ietf-smime-rfc2632bis-00.txt".
<p>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document
in
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using
the "mpack" utility.&nbsp; To use this
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command
"ENCODING mime" before the "FILE"
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode
the response(s), you will need "munpack" or
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp;
Different MIME-compliant mail readers
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior,
especially when dealing with
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "multipart" MIME messages
(i.e. documents which have been split
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages),
so check your local documentation on
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these
messages.
<br>&nbsp;
<p>Below is the data which will enable a MIME compliant mail reader
<br>implementation to automatically retrieve the ASCII version of the
<br>Internet-Draft.
<p>&nbsp; ------------------------------------------------------------------------
<br>Content-Type: text/plain
<br>Content-ID:&nbsp;&nbsp;&nbsp;&nbsp; &lt;[e-mail]></blockquote>
</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2IIpiw05472 for ietf-smime-bks; Mon, 18 Mar 2002 10:51:44 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IIph405468 for <[e-mail]>; Mon, 18 Mar 2002 10:51:43 -0800 (PST)
Received: from revelation (unknown [166.63.190.57]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id F09CB6A90A; Mon, 18 Mar 2002 14:36:14 +0000 (GMT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: Comments on rfc2632bis-00.txt
Date: Mon, 18 Mar 2002 12:49:34 -0600
Message-ID: <000b01c1cead$a5482f80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.  Formatting lost in section 2.5 on attributes in a message.

2.  OID in appendix A for md5 has a pair of "=" that should be spaces.

3.  Appendix A - rsaEncryption OID has the final digit commented out -
ditto for md2WithRSAEncryption, md5WithRSAEncryption,
sha-1WithRSAEncryption and signingTime.

4.  Section 2.2 - The NOTE: does not make sense anymore.  Please remove.

5.  Section 2.4.1 - I can't get the first sentence to parse well.
First, I think that it's sense needs to be change to say this is true
for MIME content, not for general content.

Jim



Received: by above.proper.com (8.11.6/8.11.3) id g2IIThK04239 for ietf-smime-bks; Mon, 18 Mar 2002 10:29:43 -0800 (PST)
Received: from noc-e.ietf53.cw.net (noc-e.ietf53.cw.net [166.63.177.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2IITf404233 for <[e-mail]>; Mon, 18 Mar 2002 10:29:41 -0800 (PST)
Received: from revelation (unknown [166.63.190.57]) by noc-e.ietf53.cw.net (Postfix) with ESMTP id 593586A901; Mon, 18 Mar 2002 14:14:03 +0000 (GMT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, "'Blake Ramsdell'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-rfc2632bis-00.txt
Date: Mon, 18 Mar 2002 12:27:22 -0600
Message-ID: <000a01c1ceaa$8b927d00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

1.  I strongly disagree that md2-with-RSA is a MUST.  I think this
should be a MAY or omitted.

2.  English:  "no Internet mail addresses in a certificate match the
sender of a message"  change match to matches.

3.  TBD - PKCS #v1.5 warning - yes the problem needs to be mentioned and
a reference to the informational document given.

Jim



Received: by above.proper.com (8.11.6/8.11.3) id g2I787e00857 for ietf-smime-bks; Sun, 17 Mar 2002 23:08:07 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I784400843 for <[e-mail]>; Sun, 17 Mar 2002 23:08:05 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz ([e-mail] [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id TAA03225; Mon, 18 Mar 2002 19:07:52 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA103146; Mon, 18 Mar 2002 19:07:50 +1200 (NZST) (sender [e-mail])
Date: Mon, 18 Mar 2002 19:07:50 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Order of signing and compression operations.
Cc: [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>

I wrote:

>There are two good arguments against signing first,

Make that three.  The current zlib bug is rather less worrying if the
integrity-protection is applied outside the compression (although this is a
rather artificial reason).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2I2lrp23557 for ietf-smime-bks; Sun, 17 Mar 2002 18:47:53 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2I2lp423551 for <[e-mail]>; Sun, 17 Mar 2002 18:47:51 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz ([e-mail] [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA28897; Mon, 18 Mar 2002 14:46:47 +1200 (NZST) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA89487; Mon, 18 Mar 2002 14:46:45 +1200 (NZST) (sender [e-mail])
Date: Mon, 18 Mar 2002 14:46:45 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Cc: [e-mail], [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]> writes:

>Once the key is unwrapped, we want the recipient to know that it is
>appropriate for use with the intended algorithm.

Why is this needed for KEK when it's never been needed before for any other key
transport type?  Like Jim, I can't see what the point of this is...

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g2G2rPW21353 for ietf-smime-bks; Fri, 15 Mar 2002 18:53:25 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g2G2rN421348 for <[e-mail]>; Fri, 15 Mar 2002 18:53:23 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz ([e-mail] [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA16824; Sat, 16 Mar 2002 15:53:00 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA39532; Sat, 16 Mar 2002 15:52:59 +1300 (NZDT) (sender [e-mail])
Date: Sat, 16 Mar 2002 15:52:59 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Order of signing and compression operations.
Cc: [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]> writes:

>A general rule of thumb: sign before compress.

Is there any strong argument for this?  The only place where I've seen this
requirement is in RFC 2440, where the justification is some vague handwaving
which fails to convince [0].  I suspect the main reason it's done that way is
because Phil did it that way originally and it just ended up in the standard
like that.

There are two good arguments against signing first, which are that it really
screws up the compression and that it slows down signing since you have to hash
all the data and not just the compressed form, but apart from vague misgivings
about not signing plaintext directly I don't know of a good argument against
it.  For that reason I deliberately didn't mandate either option in the RFC
except to point out that compressing first would be faster.

Peter.

[0] Having scanned 2440 I can't even find the handwaving I thought was there,
	although another reason for doing is is that if you compress first, the
	whole PGP format breaks down when you add multiple signatures.


Received: by above.proper.com (8.11.6/8.11.3) id g28Nbhl12236 for ietf-smime-bks; Fri, 8 Mar 2002 15:37:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g28Nbg812230 for <[e-mail]>; Fri, 8 Mar 2002 15:37:42 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA11349; Fri, 8 Mar 2002 18:37:40 -0500 (EST)
Message-Id: <[e-mail]>
To: IETF-Announce: ;
Cc: RFC Editor <[e-mail]>, Internet Architecture Board <[e-mail]>, [e-mail]
From: The IESG <[e-mail]>
Subject: Protocol Action: Compressed Data Content Type for S/MIME to Proposed Standard
Date: Fri, 08 Mar 2002 18:37:39 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the Internet-Draft 'Compressed Data Content Type
for S/MIME' <draft-ietf-smime-compression-07.txt> as a Proposed
Standard.  This document is the product of the S/MIME Mail Security
Working Group.  The IESG contact persons are Jeffrey Schiller and
Marcus Leech.

 
Technical Summary
 
  The Cryptographic Message Syntax (CMS) data format which is used by
  SMIME does not provide for compression of content prior to
  encryption. Because encrypted data is incompressible, compression
  applied to an enciphered SMIME message will not prove helpful
  (whether done at the IP layer, or at a lower layer such as in a
  modem).

  Compressing data prior to encryption provides two important
  benefits.

  1) It decreases the size of a message.
  2) It makes cryptographic analysis of the contained message more
     difficult for compressed data has less redundancy for the
     cryptanalyst to exploit.

  This document provide a mechanism for adding compression prior to
  encryption in SMIME by being applied at the CMS layer.

Working Group Summary

  This document has the consensus of the SMIME Working Group.

Protocol Quality

 This document has been reviewed for the IESG by Jeffrey I. Schiller.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g28GC6v25770 for ietf-smime-bks; Fri, 8 Mar 2002 08:12:06 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g28GBw825761 for <[e-mail]>; Fri, 8 Mar 2002 08:11:58 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Mar 2002 16:11:33 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 LAA21773; Fri, 8 Mar 2002 11:11:37 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g28GBvr21735; Fri, 8 Mar 2002 11:11:57 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRV2GVQ>; Fri, 8 Mar 2002 11:09:44 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.55]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRV2GVK; Fri, 8 Mar 2002 11:09:35 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 08 Mar 2002 10:50:30 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
In-Reply-To: <000601c1c67b$0b694550$[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>

Jim:

>By this argument are you saying that RSA Labs has incorrectly defined
>RSA-OAEP?  Remember this method of transporting keys does not make any
>statements about their indended usage.  Additionally, if this is to be a
>check that needs to be made by programs it needs to be placed in the
>documents as as explicit step.  I.e. part of the key unwrap algorithm
>should be that the CEK algorithm and the KEK algorithm identifiers are
>consistant with each other.  I don't believe that the Microsoft
>implementations do this check, I can't say if others do or do not, but I
>would not be supprised if they do not.

No.  Neither PKCS#1 v1.5 nor OAEP provides key type information inside the 
wrapping.  My understanding is that this was done to avoid structure that 
would be helpful to in a cryptanalytic attack.  This does not bean that the 
unwrapped key should not be checked for consistency with the expected 
outcome.  I was suggesting that key size and parity (for Triple-DES) are 
reasonable checks.

Perhaps I was confusing in my comments about the HMAC key wrap 
algorithm.  Right now, no other key wrap algorithm has the same structure, 
so if the unwrap is successful, the recipient cane be sure that the 
originator intended that the wrapped key be used with HMAC.

>Also please address the question I raised in #3 - should the CEK (hmac)
>or KEK bulk algorithm (3DES, AES...) be the one used in the key
>derivation process.

I do not know what the working group consensus will be yet.  Once the 
consensus in clear, then we can figure out what documents need to address it.

This whole issue surfaced when trying to address AuthenticatedData with 
Static-Static Diffie-Hellman (S-S D-H) key agreement.  S-S D-H is used 
since it provides data origin authentication when the originator's public 
keys is certified.  Let me summarize the steps (assuming one recipient for 
simplicity).  These steps come from rfc2630bis, section 9.

1.  Originator generates a random HMAC key.

2.  Originator generates a random value.  It will be transferred to the 
recipient in the ukm field.  Originator uses the random value, her private 
D-H key and the Recipient's D-H public key to compute a pairwise 
key-encryption key (KEK).  The random value ensures that unique KEK is 
generated for this operation.  In this case, the KEK is a Triple-DES 
key.  Next, the originator wraps the HMAC key generated in step 1 with the KEK.

3.  The originator uses the recipient's certificate identification 
information, the wrapped HMAC key, the ukm, the appropriate algorithm 
identifiers, and so on are collected into a RecipientInfo value.

4.  Using the HMAC key, the originator computes a MAC value on the content 
or the authenticated attributes.  If the HMAC is computed on authenticated 
attributes, then one of them must be a message digest of the content.

Now, given this context, all of the issues raised by this thread are 
associated with step 2 (and perhaps the algorithm identifiers that are 
selected for step 3.

Jim, you seem to be looking for parallel situations in the RSA and D-H 
cases.  However, they do not exist in the AuthenticatedData 
context.  Neither RSA nor Ephemeral-Static D-H (E-S D-H) provides data 
origin authentication.  Anyone can wrap an HMAC key with the recipient' 
public key.  The whole point of AuthenticatedData is to know the origin of 
the content, and you cannot know the origin of the content unless you know 
the origin of the HMAC key.

I hope this helps clarify the situation.

> > Sent: Wednesday, March 06, 2002 2:09 PM
> > To: [e-mail]
> > Cc: [e-mail]; [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> >
> >
> >
> > Jim:
> >
> > Once the key is unwrapped, we want the recipient to know that it is
> > appropriate for use with the intended algorithm.  Some checks are
> > obvious.  In Triple-DES, the key size must be either 128 bits or 192
> > bits.  In AES, the the key size must be either 128 bits, 192 bits, or 256
> > bits.  Such checks are not so obvious with algorithms that allow a 
> variable
> > key size, like RC2 and HMAC.
> >
> > The key wrap algorithm provides integrity of the keying material, so the
> > recipient knows that the received key has not been modified.  The way that
> > the HMAC key wrap algorithms are defined, the recipient should know that
> > the wrapped key is intended for use with HMAC.  I suppose that this 
> feature
> > could be lost if the structure that we have defined is copied for many
> > other purposes.
> >
> > Russ
> >
> >
> > >After long discussions with Russ and Peter over the last week, I have
> > >come up with the following list of items that need clarification.
> > >
> > >1. How OIDs are assigned for key wrap algorithms.  Under the current
> > >naming scheme the following items are identified by the assigned OID:
> > >1) The exact key wrap algorithm to be used (including padding done to
> > >the data), 2) The block encryption cipher applied during the key wrap
> > >algorithm and 3) The purpose for which the embedded key is to be used.
> > >
> > >2. Should a common key algorithm (including padding) be used for all
> > >128-bit block cipher algorithms.  (i.e. should the AES and the HMAC key
> > >wrap algorithm be identical including padding).
> > >
> > >3. Should we update any current or existing documents based on any new
> > >understandings that we arrive at.
> > >
> > >COMMENTARY:
> > >
> > >1.  I find that the third item in assign a key OID to be at present
> > >insecure and and not really enforcable.  It is a feature which is not
> > >currently present in PKCS#1 v1.5 and is far better covered for the DH
> > >case by the fact that the CEK (i.e. destination) algorithm is used for
> > >the KEK derivation process.  I was not really aware until I spoke to
> > >Russ that the third item was even present in the OID definition and have
> > >therefore never even thought to enforce it in my code in any way.
> > >
> > >2.  Russ, please address the following for me.  Is it really the CEK not
> > >the KEK block encryption algorithm that should be protected during the
> > >DH key derivation process?  If they are the same as is presently true it
> > >is not an issue, but is of interest if you use an HMAC algorithm rather
> > >than a CEK algorithm.
> > >
> > >3.  I believe that there is an element of simplicity gained from having
> > >a common key wrap algorithm for the AES key sizes.  I do not currently
> > >believe that there is a benefit to breaking backwards compatablility to
> > >achive the same effect with the 64-bit block size algorithms.
> > >
> > >Conclusions:
> > >
> > >I think that changing the OID assignment method should be looked at for
> > >the 128-bit block algorithms, but we should not change our current
> > >course for 64-bit block algorithms.  This does mean that we need to
> > >change both AES-keywrap and HMAC-keywrap, but need input from the list,
> > >from Russ and Peter and from NIST (the current AES key wrap algorithm
> > >definers).
> > >
> > >jim
> > >
>[SNIP]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g288TId17178 for ietf-smime-bks; Fri, 8 Mar 2002 00:29:18 -0800 (PST)
Received: from frankenstein.nwlink.com (pop.nwlink.com [209.20.130.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g288TD817157 for <[e-mail]>; Fri, 8 Mar 2002 00:29:13 -0800 (PST)
Received: from revelation (ip20.pm3-2.eli.du.nwlink.com [209.20.135.20]) by frankenstein.nwlink.com (8.11.3/8.11.3) with ESMTP id g288Sx204954; Fri, 8 Mar 2002 00:28:59 -0800 (PST) (envelope-from [e-mail])
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
Date: Fri, 8 Mar 2002 00:26:56 -0800
Message-ID: <000601c1c67b$0b694550$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
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>

Russ,

By this argument are you saying that RSA Labs has incorrectly defined
RSA-OAEP?  Remember this method of transporting keys does not make any
statements about their indended usage.  Additionally, if this is to be a
check that needs to be made by programs it needs to be placed in the
documents as as explicit step.  I.e. part of the key unwrap algorithm
should be that the CEK algorithm and the KEK algorithm identifiers are
consistant with each other.  I don't believe that the Microsoft
implementations do this check, I can't say if others do or do not, but I
would not be supprised if they do not.  

Also please address the question I raised in #3 - should the CEK (hmac)
or KEK bulk algorithm (3DES, AES...) be the one used in the key
derivation process.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Housley, Russ
> Sent: Wednesday, March 06, 2002 2:09 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> 
> 
> 
> Jim:
> 
> Once the key is unwrapped, we want the recipient to know that it is 
> appropriate for use with the intended algorithm.  Some checks are 
> obvious.  In Triple-DES, the key size must be either 128 bits or 192 
> bits.  In AES, the the key size must be either 128 bits, 192 
> bits, or 256 
> bits.  Such checks are not so obvious with algorithms that 
> allow a variable 
> key size, like RC2 and HMAC.
> 
> The key wrap algorithm provides integrity of the keying 
> material, so the 
> recipient knows that the received key has not been modified.  
> The way that 
> the HMAC key wrap algorithms are defined, the recipient 
> should know that 
> the wrapped key is intended for use with HMAC.  I suppose 
> that this feature 
> could be lost if the structure that we have defined is copied 
> for many 
> other purposes.
> 
> Russ
> 
> 
> >After long discussions with Russ and Peter over the last week, I have
> >come up with the following list of items that need clarification.
> >
> >1. How OIDs are assigned for key wrap algorithms.  Under the current
> >naming scheme the following items are identified by the assigned OID:
> >1) The exact key wrap algorithm to be used (including padding done to
> >the data), 2) The block encryption cipher applied during the key wrap
> >algorithm and 3) The purpose for which the embedded key is 
> to be used.
> >
> >2. Should a common key algorithm (including padding) be used for all
> >128-bit block cipher algorithms.  (i.e. should the AES and 
> the HMAC key
> >wrap algorithm be identical including padding).
> >
> >3. Should we update any current or existing documents based 
> on any new
> >understandings that we arrive at.
> >
> >COMMENTARY:
> >
> >1.  I find that the third item in assign a key OID to be at present
> >insecure and and not really enforcable.  It is a feature which is not
> >currently present in PKCS#1 v1.5 and is far better covered for the DH
> >case by the fact that the CEK (i.e. destination) algorithm 
> is used for
> >the KEK derivation process.  I was not really aware until I spoke to
> >Russ that the third item was even present in the OID 
> definition and have
> >therefore never even thought to enforce it in my code in any way.
> >
> >2.  Russ, please address the following for me.  Is it really 
> the CEK not
> >the KEK block encryption algorithm that should be protected 
> during the
> >DH key derivation process?  If they are the same as is 
> presently true it
> >is not an issue, but is of interest if you use an HMAC 
> algorithm rather
> >than a CEK algorithm.
> >
> >3.  I believe that there is an element of simplicity gained 
> from having
> >a common key wrap algorithm for the AES key sizes.  I do not 
> currently
> >believe that there is a benefit to breaking backwards 
> compatablility to
> >achive the same effect with the 64-bit block size algorithms.
> >
> >Conclusions:
> >
> >I think that changing the OID assignment method should be 
> looked at for
> >the 128-bit block algorithms, but we should not change our current
> >course for 64-bit block algorithms.  This does mean that we need to
> >change both AES-keywrap and HMAC-keywrap, but need input 
> from the list,
> >from Russ and Peter and from NIST (the current AES key wrap algorithm
> >definers).
> >
> >jim
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Peter Gutmann
> > > Sent: Saturday, February 16, 2002 12:08 AM
> > > To: [e-mail]
> > > Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> > >
> > >
> > >
> > > "Jim Schaad" <[e-mail]> writes:
> > >
> > > >It is true that the wrapping algorithm in RFC 3211 exists
> > > and could be used
> > > >for the HMAC wrapping process.  However the pure Triple-DES
> > > wrap algorithm was
> > > >required to implement CMS, and it is still a required 
> algorithm for
> > > >impliementing Diffie-Hellman key management in the cmsalg.
> > >
> > > ... which virtually nothing implements.  Hardly a strong
> > > argument for using it.
> > >
> > > >Given that it is a required algorithm, it seems to be a good
> > > base to expand
> > > >on.
> > >
> > > But it still has the problem that every single little
> > > variation requires a
> > > completely new RFC to handle it, whereas the RFC 3211 wrap
> > > covers any algorithm
> > > type and key combination.  You implement it once, and it
> > > works for everything.
> > >
> > > (In fact the 3211 wrap is parameterised, something I added at
> > > your insistence,
> > >  so there's no reason it can't be adapted to do whatever 
> you need).
> > >
> > > >The AES key wrap algorithm is currently on track to become
> > > the standard key
> > > >wrap algorithm for use with AES.  Again, given that it is
> > > expected to be the
> > > >standard algorithm, it seems to be a good base to expand on.
> > >
> > > It's yet another special-case variation which people have to
> > > implement.
> > >
> > > >I personally have some security reservations about the key
> > > wrap algorithm
> > > >given in RFC 3211. Triple-DES key wrap received significant
> > > peer review.
> > > >[etc]
> > >
> > > See my private reply.
> > >
> > > Peter.
> > >
> 



Received: by above.proper.com (8.11.6/8.11.3) id g270H1E27764 for ietf-smime-bks; Wed, 6 Mar 2002 16:17:01 -0800 (PST)
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 g270H0827760 for <[e-mail]>; Wed, 6 Mar 2002 16:17:00 -0800 (PST)
Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Wed, 6 Mar 2002 16:25:45 -0800
Message-ID: <1544168.1015460747437.JavaMail.administrator@highland>
From: "Blake Ramsdell" <[e-mail]>
To: <[e-mail]>
Subject: CompressedData examples
Date: Wed, 6 Mar 2002 16:16:38 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 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>

If anyone has any CompressedData examples, I could use some.  I'm running
low and the weekend's coming up.

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 g26MAHk24325 for ietf-smime-bks; Wed, 6 Mar 2002 14:10:17 -0800 (PST)
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 g26MA6824311 for <[e-mail]>; Wed, 6 Mar 2002 14:10:07 -0800 (PST)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 6 Mar 2002 22:09: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 RAA16755; Wed, 6 Mar 2002 17:09:49 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g26MA4v10117; Wed, 6 Mar 2002 17:10:07 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <GNRVHL4F>; Wed, 6 Mar 2002 17:07:52 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id GNRVHL4C; Wed, 6 Mar 2002 17:07:46 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 06 Mar 2002 17:09:23 -0500
Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
In-Reply-To: <001d01c1bf27$3c3ceca0$[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>

Jim:

Once the key is unwrapped, we want the recipient to know that it is 
appropriate for use with the intended algorithm.  Some checks are 
obvious.  In Triple-DES, the key size must be either 128 bits or 192 
bits.  In AES, the the key size must be either 128 bits, 192 bits, or 256 
bits.  Such checks are not so obvious with algorithms that allow a variable 
key size, like RC2 and HMAC.

The key wrap algorithm provides integrity of the keying material, so the 
recipient knows that the received key has not been modified.  The way that 
the HMAC key wrap algorithms are defined, the recipient should know that 
the wrapped key is intended for use with HMAC.  I suppose that this feature 
could be lost if the structure that we have defined is copied for many 
other purposes.

Russ


>After long discussions with Russ and Peter over the last week, I have
>come up with the following list of items that need clarification.
>
>1. How OIDs are assigned for key wrap algorithms.  Under the current
>naming scheme the following items are identified by the assigned OID:
>1) The exact key wrap algorithm to be used (including padding done to
>the data), 2) The block encryption cipher applied during the key wrap
>algorithm and 3) The purpose for which the embedded key is to be used.
>
>2. Should a common key algorithm (including padding) be used for all
>128-bit block cipher algorithms.  (i.e. should the AES and the HMAC key
>wrap algorithm be identical including padding).
>
>3. Should we update any current or existing documents based on any new
>understandings that we arrive at.
>
>COMMENTARY:
>
>1.  I find that the third item in assign a key OID to be at present
>insecure and and not really enforcable.  It is a feature which is not
>currently present in PKCS#1 v1.5 and is far better covered for the DH
>case by the fact that the CEK (i.e. destination) algorithm is used for
>the KEK derivation process.  I was not really aware until I spoke to
>Russ that the third item was even present in the OID definition and have
>therefore never even thought to enforce it in my code in any way.
>
>2.  Russ, please address the following for me.  Is it really the CEK not
>the KEK block encryption algorithm that should be protected during the
>DH key derivation process?  If they are the same as is presently true it
>is not an issue, but is of interest if you use an HMAC algorithm rather
>than a CEK algorithm.
>
>3.  I believe that there is an element of simplicity gained from having
>a common key wrap algorithm for the AES key sizes.  I do not currently
>believe that there is a benefit to breaking backwards compatablility to
>achive the same effect with the 64-bit block size algorithms.
>
>Conclusions:
>
>I think that changing the OID assignment method should be looked at for
>the 128-bit block algorithms, but we should not change our current
>course for 64-bit block algorithms.  This does mean that we need to
>change both AES-keywrap and HMAC-keywrap, but need input from the list,
>from Russ and Peter and from NIST (the current AES key wrap algorithm
>definers).
>
>jim
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Peter Gutmann
> > Sent: Saturday, February 16, 2002 12:08 AM
> > To: [e-mail]
> > Subject: RE: I-D ACTION:draft-ietf-smime-hmac-key-wrap-00.txt
> >
> >
> >
> > "Jim Schaad" <[e-mail]> writes:
> >
> > >It is true that the wrapping algorithm in RFC 3211 exists
> > and could be used
> > >for the HMAC wrapping process.  However the pure Triple-DES
> > wrap algorithm was
> > >required to implement CMS, and it is still a required algorithm for
> > >impliementing Diffie-Hellman key management in the cmsalg.
> >
> > ... which virtually nothing implements.  Hardly a strong
> > argument for using it.
> >
> > >Given that it is a required algorithm, it seems to be a good
> > base to expand
> > >on.
> >
> > But it still has the problem that every single little
> > variation requires a
> > completely new RFC to handle it, whereas the RFC 3211 wrap
> > covers any algorithm
> > type and key combination.  You implement it once, and it
> > works for everything.
> >
> > (In fact the 3211 wrap is parameterised, something I added at
> > your insistence,
> >  so there's no reason it can't be adapted to do whatever you need).
> >
> > >The AES key wrap algorithm is currently on track to become
> > the standard key
> > >wrap algorithm for use with AES.  Again, given that it is
> > expected to be the
> > >standard algorithm, it seems to be a good base to expand on.
> >
> > It's yet another special-case variation which people have to
> > implement.
> >
> > >I personally have some security reservations about the key
> > wrap algorithm
> > >given in RFC 3211. Triple-DES key wrap received significant
> > peer review.
> > >[etc]
> >
> > See my private reply.
> >
> > Peter.
> >


Received: by above.proper.com (8.11.6/8.11.3) id g26BnXS25166 for ietf-smime-bks; Wed, 6 Mar 2002 03:49:33 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g26BnV825161 for <[e-mail]>; Wed, 6 Mar 2002 03:49:31 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02650; Wed, 6 Mar 2002 06:49:29 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-08.txt
Date: Wed, 06 Mar 2002 06:49:29 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-08.txt
	Pages		: 23
	Date		: 01-Mar-02
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  The CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary message
contents.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cmsalg-08.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g267Pa622360 for ietf-smime-bks; Tue, 5 Mar 2002 23:25:36 -0800 (PST)
Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g267PZ822350 for <[e-mail]>; Tue, 5 Mar 2002 23:25:35 -0800 (PST)
Received: from mailrelay01.cce.cpqcorp.net (mailrelay01.cce.cpqcorp.net [16.47.68.171]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 7E6CA5B97 for <[e-mail]>; Wed,  6 Mar 2002 02:25:29 -0500 (EST)
Received: from diexch01.xko.dec.com (diexch01.xko.dec.com [16.138.244.57]) by mailrelay01.cce.cpqcorp.net (Postfix) with ESMTP id 074BFE6D for <[e-mail]>; Wed,  6 Mar 2002 01:25:27 -0600 (CST)
Received: by diexch01.xko.dec.com with Internet Mail Service (5.5.2650.21) id <GC5GQW85>; Wed, 6 Mar 2002 12:51:19 +0530
Message-ID: <[e-mail]>
From: "Muzumdar, Hari" <[e-mail]>
To: "'SMIME, IETF'" <[e-mail]>
Subject: Example BER messages?
Date: Wed, 6 Mar 2002 12:51:18 +0530 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
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>

Hello,

Are there any examples (i.e. BER-messages) of x400-transport?

Would any of you be willing to share such messages (complete
ones, with X.411 envelopes and all)?

They're not in draft-ietf-smime-examples-07, and I didn't find
any references in the 2000-present archive.

Best Regards,

	Hari.


Received: by above.proper.com (8.11.6/8.11.3) id g24C9Bv10460 for ietf-smime-bks; Mon, 4 Mar 2002 04:09:11 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24C9A810456 for <[e-mail]>; Mon, 4 Mar 2002 04:09:10 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20936; Mon, 4 Mar 2002 07:09:08 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-cmsalg-08.txt
Date: Mon, 04 Mar 2002 07:09:08 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax (CMS) Algorithms
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-cmsalg-08.txt
	Pages		: 23
	Date		: 01-Mar-02
	
This document describes several cryptographic algorithms for use with
the Cryptographic Message Syntax (CMS) [CMS].  The CMS is used to
digitally sign, digest, authenticate, or encrypt arbitrary message
contents.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-cmsalg-08.txt".

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


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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g24C95410454 for ietf-smime-bks; Mon, 4 Mar 2002 04:09:05 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g24C94810450 for <[e-mail]>; Mon, 4 Mar 2002 04:09:04 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20923; Mon, 4 Mar 2002 07:09:02 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-smime-rfc2630bis-07.txt
Date: Mon, 04 Mar 2002 07:09:02 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Cryptographic Message Syntax
	Author(s)	: R. Housley
	Filename	: draft-ietf-smime-rfc2630bis-07.txt
	Pages		: 52
	Date		: 01-Mar-02
	
This document describes the Cryptographic Message Syntax (CMS).  This
syntax is used to digitally sign, digest, authenticate, or encrypt
arbitrary messages.

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-rfc2630bis-07.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-smime-rfc2630bis-07.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g21CqPV18341 for ietf-smime-bks; Fri, 1 Mar 2002 04:52:25 -0800 (PST)
Received: from yuha.menta.net (yuha.menta.net [212.78.128.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g21CqLi18333; Fri, 1 Mar 2002 04:52:22 -0800 (PST)
Received: from gibson.menta.net ([212.78.128.22]) by yuha.menta.net (Netscape Messaging Server 4.15) with ESMTP id GSAP7H03.MMN; Fri, 1 Mar 2002 13:54:53 +0100 
Received: from bcn.safelayer.com ([212.78.132.129]) by gibson.menta.net (Netscape Messaging Server 4.15) with ESMTP id GSAOVU01.J9T; Fri, 1 Mar 2002 13:47:54 +0100 
Subject: Comment on draft-ietf-smime-examples-07
To: [e-mail]
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.4  June 8, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 1 Mar 2002 13:54:58 +0100
X-MIMETrack: Serialize by Router on Bcn/SFLY(Release 5.0.9a |January 7, 2002) at 01/03/2002 13:54:58
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g21CqOi18336
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>

Mr. Hoffman:
There is a mismatch in the definition of Bob´s RSA public key: the fields
"privateKey modulus" in BobPrivRSAEncrypt (1) , and "subjectPublicKey
modulus" in BobRSASignByCarl (2) should be the same.

BobPrivRSAEncrypt =
     0 30  630: SEQUENCE {
     4 02    1:   INTEGER 0
     7 30   13:   SEQUENCE {
     9 06    9:     OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1 1)
              :       (PKCS #1)
    20 05    0:     NULL
              :     }
    22 04  608:   OCTET STRING, encapsulates {
    26 30  604:       SEQUENCE {
    30 02    1:         INTEGER 0
    33 02  129:         INTEGER
              :           00 E4 4B FF 18 B8 24 57 F4 77 FF 6E 73 7B 93 71
<---- ( 1 )
              :           5C BC ...


BobRSASignByCarl =
     0 30  520: SEQUENCE {
     4 30  369:   SEQUENCE {
     8 A0    3:     [0] {
    10 02    1:       INTEGER 2
              :       }
  [...]

   117 30  159:     SEQUENCE {
   120 30   13:       SEQUENCE {
   122 06    9:         OBJECT IDENTIFIER rsaEncryption (1 2 840 113549 1 1
1)
              :           (PKCS #1)
   133 05    0:         NULL
              :         }
   135 03  141:       BIT STRING 0 unused bits, encapsulates {
   139 30  137:           SEQUENCE {
   142 02  129:             INTEGER
              :               00 CA 5C E1 2E EC CF C1 3B 5D 10 1B DF 54 35
71   <--- ( 2 )
              :               99 0A ...

Luciano Medina