DRAFT Agenda for S/MIME meeting in Atlanta

"Housley, Russ" <rhousley@rsasecurity.com> Thu, 31 October 2002 20:58 UTC

Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14489 for <smime-archive@lists.ietf.org>; Thu, 31 Oct 2002 15:58:14 -0500 (EST)
Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VKjtD11875 for ietf-smime-bks; Thu, 31 Oct 2002 12:45:55 -0800 (PST)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9VKjqW11866 for <ietf-smime@imc.org>; Thu, 31 Oct 2002 12:45:52 -0800 (PST)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Oct 2002 20:46:56 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g9VKpkq28538 for <ietf-smime@imc.org>; Fri, 1 Nov 2002 06:51:47 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QPRAHY20>; Fri, 1 Nov 2002 06:44:23 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWHXL3; Thu, 31 Oct 2002 15:45:30 -0500
Message-Id: <5.1.0.14.2.20021031153937.03655468@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Oct 2002 15:41:09 -0500
To: ietf-smime@imc.org
From: "Housley, Russ" <rhousley@rsasecurity.com>
Subject: DRAFT Agenda for S/MIME meeting in Atlanta
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Dear S/MIME WG:

Here is the draft agenda for the meeting in Atlanta.  Please send comment 
to me.

Russ

= = = = = = =

Introductions				Russ Housley
Working Group Status			Russ Housley
CMS and ESS Examples Update	Paul Hoffman
MSGbis and CERTbis Update		Blake Ramsdell
X400wrap & X400transport Update 	Chris Bonatti
Interoperability Matrix Update		Jim Schaad
AES Encryption Algorithm Update	Jim Schaad
Camilla Encryption Algorithm		Kato Akihiro
SIP and SIPPING			Rohan Mahy
Wrap up				Russ Housley



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9VKjtD11875 for ietf-smime-bks; Thu, 31 Oct 2002 12:45:55 -0800 (PST)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9VKjqW11866 for <ietf-smime@imc.org>; Thu, 31 Oct 2002 12:45:52 -0800 (PST)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 31 Oct 2002 20:46:56 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g9VKpkq28538 for <ietf-smime@imc.org>; Fri, 1 Nov 2002 06:51:47 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QPRAHY20>; Fri, 1 Nov 2002 06:44:23 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWHXL3; Thu, 31 Oct 2002 15:45:30 -0500
Message-Id: <5.1.0.14.2.20021031153937.03655468@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Oct 2002 15:41:09 -0500
To: ietf-smime@imc.org
From: "Housley, Russ" <rhousley@rsasecurity.com>
Subject: DRAFT Agenda for S/MIME meeting in Atlanta
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Dear S/MIME WG:

Here is the draft agenda for the meeting in Atlanta.  Please send comment 
to me.

Russ

= = = = = = =

Introductions				Russ Housley
Working Group Status			Russ Housley
CMS and ESS Examples Update	Paul Hoffman
MSGbis and CERTbis Update		Blake Ramsdell
X400wrap & X400transport Update 	Chris Bonatti
Interoperability Matrix Update		Jim Schaad
AES Encryption Algorithm Update	Jim Schaad
Camilla Encryption Algorithm		Kato Akihiro
SIP and SIPPING			Rohan Mahy
Wrap up				Russ Housley


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9UIRMe04534 for ietf-smime-bks; Wed, 30 Oct 2002 10:27:22 -0800 (PST)
Received: from [165.227.249.21] (165-227-249-21.client.dsl.net [165.227.249.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9UIRLW04528 for <ietf-smime@imc.org>; Wed, 30 Oct 2002 10:27:21 -0800 (PST)
Mime-Version: 1.0
X-Sender: phoffman@mail.imc.org
Message-Id: <p05200e06b9e5d4eda3d6@[165.227.249.21]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Wed, 30 Oct 2002 10:27:18 -0800
To: ietf-smime@imc.org
From: Paul Hoffman / IMC <phoffman@imc.org>
Subject: Fwd: I-D ACTION:draft-peterson-sip-smime-aes-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Of interest to this WG.

>To: IETF-Announce: ;
>CC: sip@ietf.org
>From: Internet-Drafts@ietf.org
>Reply-to: Internet-Drafts@ietf.org
>Subject: I-D ACTION:draft-peterson-sip-smime-aes-00.txt
>Date: Wed, 30 Oct 2002 06:19:11 -0500
>Sender: nsyracus@cnri.reston.va.us
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>
>	Title		: S/MIME AES Requirement for SIP
>	Author(s)	: J. Peterson
>	Filename	: draft-peterson-sip-smime-aes-00.txt
>	Pages		: 11
>	Date		: 2002-10-29
>
>RFC3261 currently specifies 3DES as the required minimum ciphersuite
>for implementations of S/MIME in SIP.  This document updates the
>normative guidance of RFC3261 to require the Advanced Encryption
>Standard (AES) for S/MIME.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-peterson-sip-smime-aes-00.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-peterson-sip-smime-aes-00.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:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-peterson-sip-smime-aes-00.txt".
>
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>
>[The following attachment must be fetched by mail. Command-click the 
>URL below and send the resulting message to get the attachment.]
><mailto:mailserv@ietf.org?body=ENCODING%20mime%0D%0AFILE%20/internet-drafts/draft-peterson-sip-smime-aes-00.txt>
>[The following attachment must be fetched by ftp.  Command-click the 
>URL below to ask your ftp client to fetch it.]
><ftp://ftp.ietf.org/internet-drafts/draft-peterson-sip-smime-aes-00.txt>



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9TA0rC08440 for ietf-smime-bks; Tue, 29 Oct 2002 02:00:53 -0800 (PST)
Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9TA0pW08431; Tue, 29 Oct 2002 02:00:51 -0800 (PST)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id KAA01737; Tue, 29 Oct 2002 10:00:42 GMT
From: malek.bechlaghem@belgacom.be
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Tue, 29 Oct 2002 11:00:36 +0100
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <VYQQ5CT1>; Tue, 29 Oct 2002 11:00:36 +0100
Message-ID: <95C94B2F0094D21180710008C75DD6A40B9AB43C@apl541.bc>
To: Denis.Pinkas@bull.net
Cc: ietf-pkix@imc.org, ietf-smime@imc.org
Subject: RE: delegation attribute within a signed message
Date: Tue, 29 Oct 2002 11:00:30 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Denis,

I understand that when adding the signature polcy as a signed attribute, the signer explicitely indicates that he agrees and applied the policy contents.

I also understand that when adding a commitemnt text as a signed attribute, the signer indicates that he is endorsing a particular act or will.

To be honest i didn't understand what it does express to add an attribute certificate as signed attribute within a CMS signed data? 

Of course, we may consider a closed community having its own dedicated or outsourced AC authority implementing a "signature delegation" having the following functioning:

- The AC receives a request from the "SUPERIOR" (namely the person who will delegates his signature to the end-entity) requesting an AC for the end-entity. This AC will contain propriatary attributes for signature delegation (attributes not defined within RFC 3281).
- The end-entity receives its AC and may hence include it as signed attribute within messages it signs.

The above scheme seems to work but it suffers from my point of view from several questions must be explicitely addressed:

- The superior shall have the privileges to provide "the signature delegation" privilege (attribute) to the end entity (via the AC authority)

- The AC provided to the end-entity should address the problem of a SUPERIOR denying having provided a particular signature delegation privilege (attribute) to the end-entity.

- A signature policy must explicitely specify the context of signature delegation so that bothe the superior and the end-entity are liable and cannot deny a particular signing act

- When the end-entity signs by delegation a particular message, a signature receiving and verifying agent shall be able to adequately verify the signature. This verifying agent, unless within the closed community, won't be able to verify the CMS signed data in a standard way.


So leads me conclude my argumentation by saying:

- An attribute certificate chain constituted from at least 3 AC's shall be provided to the signing and verifying entity. 
	- The first AC in the chain should be the AC authority root key 
	- The second one should be the SUPERIOR AC where the signature delegation capabilities of 	- the superior will be expressed.
	- The last AC is the end-entity AC.

- A "signature delegation policy" is needed. It may live in its own dedicated contex of may be included in a more general "signature policy". 

- The definition od standard attributes for signature delegation. 

When i will have more time i will write a short document containing a solution to the "signature delgation" with non-repudiation and in a standard way.

Regards,

malek.

-----Original Message-----
From: Denis Pinkas [mailto:Denis.Pinkas@bull.net]
Sent: 25 October 2002 16:11
To: malek.bechlaghem@belgacom.be
Cc: ietf-pkix@imc.org; S-MIME / IETF
Subject: Re: delegation attribute within a signed message


Malek,

I have presented some slides on that topic at the IETF meeting in Salt Lake
City in December 2001. The presentation is called "Signature delegation".

The main idea is to use an Attribute Certificate. Since Attribute 
Certificates may incorporated in a CMS structure (see RFC 3126),
then no addition to the signature format is necessary.

In such a case, there would be two documents to produce:

1) a profile for an Attribute Certificate usable for delegation,
    (a PKIW work item),

2) a document saying how such an Attribute Cetificate is verified when
    present in the CMS structure defined in RFC 3126, (an S-MIME work item).

Hence why I am posting this document to the S-MIME working group too.

Denis

 > I am trying to investigate the possibility to implement a delegated 
electronic signature. I mean implement the fact that a signer has the 
necessary attributes to sign on behalf of some-one else.
 >
 > My understanding is that we should address this question from 2 angles:
 > 	1. The signer should express in his signed message the fact that he is 
signing on behalf of some-one else (fopr the sake of
 >                 simplicity, let's say the superior).
 > 	2. The signer should have the necessary privleges to sign on behalf of 
the superior
 >
 > If we take into consideration CMS signatures, a possible implementation 
of the above two points can be summarized as follows:
 >
 > - Defining an additional attribute: "Detegated Signature". The fields of 
this attributes may be a reference to the document where the
 >   privilege of signing on behalf someone else are expressed. It may 
simply be teh hash of the superior signing certificate.
 > - Adding this additional attribute as a signed attribute in the SigneInfo 
of the signed data within the CMS signature.
 > - Having a reference to the signature policy added a signed attribute. 
Within the sigature policy, we should exress the fact that when a "delegated 
signature" signature is added as a signed attribute, this mens that the 
signatory is signing on behalf a "superior".
 > - The document highlighting the privileges can be expressed within an 
X509 Attribute certificate. This means that the SUPERIOR will have its own 
ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute 
certificate can be expressed as follows:
 > 	Privilege type: OID describing the privilege of signature delegation
 > 	Superior reference: Signing certificate of teh superior.
 >
 > This solution doesn't seem to be simple to express but provided that the 
necessary ASN.1 structures exist, it is intuitive to implement.
 >
 > I have in mind several solutions but can you please tell me if signature 
delegation has already been specified within some standard or RCF (up to my 
knowledge, no such functionality has already been expressed in ETSI or PKIX 
standards). And if it doen't exist, what do you think about the solution i 
summarized above.
 >
 > regards,
 >
 > ___________________________________________________________
 > Malek Bechlaghem
 > e-Security Product Development Manager
 > Strategy, Business Development and Product Management (SBP)
 > Internet Business Unit (IBU)
 > Belgacom SA/NV
 > Bd du Roi Albert II, 27, B-1030 Brussels
 >
 > Tel.: +32 2 202 79 02
 > Fax: +32 2 202 41 06
 > E-mail: malek.bechlaghem@belgacom.be
 >
 > We bring security to the e-world : www.e-trust.be
 >
 >
 >
 >
 > **** DISCLAIMER ****
 > "This e-mail and any attachments thereto may contain information
 > which is confidential and/or protected by intellectual property
 > rights and are intended for the sole use of the recipient(s) named above.
 > Any use of the information contained herein (including, but not limited to,
 > total or partial reproduction, communication or distribution in any form)
 > by persons other than the designated recipient(s) is prohibited.
 > If you have received this e-mail in error, please notify the sender either
 > by telephone or by e-mail and delete the material from any computer.
 > Thank you for your cooperation."


**** DISCLAIMER **** 
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PEBfk29572 for ietf-smime-bks; Fri, 25 Oct 2002 07:11:41 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PEAnW29525; Fri, 25 Oct 2002 07:10:49 -0700 (PDT)
Received: from clbull.frcl.bull.fr (clbull.frcl.bull.fr [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA12248; Fri, 25 Oct 2002 16:11:12 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.2/8.9.1) with ESMTP id QAA23988; Fri, 25 Oct 2002 16:11:05 +0200
Message-ID: <3DB950E8.9010800@bull.net>
Date: Fri, 25 Oct 2002 16:10:48 +0200
From: Denis Pinkas <Denis.Pinkas@bull.net>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: malek.bechlaghem@belgacom.be
CC: ietf-pkix@imc.org, S-MIME / IETF <ietf-smime@imc.org>
Subject: Re: delegation attribute within a signed message
References: <95C94B2F0094D21180710008C75DD6A40B9AB436@apl541.bc>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Malek,

I have presented some slides on that topic at the IETF meeting in Salt Lake
City in December 2001. The presentation is called "Signature delegation".

The main idea is to use an Attribute Certificate. Since Attribute 
Certificates may incorporated in a CMS structure (see RFC 3126),
then no addition to the signature format is necessary.

In such a case, there would be two documents to produce:

1) a profile for an Attribute Certificate usable for delegation,
    (a PKIW work item),

2) a document saying how such an Attribute Cetificate is verified when
    present in the CMS structure defined in RFC 3126, (an S-MIME work item).

Hence why I am posting this document to the S-MIME working group too.

Denis

 > I am trying to investigate the possibility to implement a delegated 
electronic signature. I mean implement the fact that a signer has the 
necessary attributes to sign on behalf of some-one else.
 >
 > My understanding is that we should address this question from 2 angles:
 > 	1. The signer should express in his signed message the fact that he is 
signing on behalf of some-one else (fopr the sake of
 >                 simplicity, let's say the superior).
 > 	2. The signer should have the necessary privleges to sign on behalf of 
the superior
 >
 > If we take into consideration CMS signatures, a possible implementation 
of the above two points can be summarized as follows:
 >
 > - Defining an additional attribute: "Detegated Signature". The fields of 
this attributes may be a reference to the document where the
 >   privilege of signing on behalf someone else are expressed. It may 
simply be teh hash of the superior signing certificate.
 > - Adding this additional attribute as a signed attribute in the SigneInfo 
of the signed data within the CMS signature.
 > - Having a reference to the signature policy added a signed attribute. 
Within the sigature policy, we should exress the fact that when a "delegated 
signature" signature is added as a signed attribute, this mens that the 
signatory is signing on behalf a "superior".
 > - The document highlighting the privileges can be expressed within an 
X509 Attribute certificate. This means that the SUPERIOR will have its own 
ATTRIBUTE AUTHORITY. And the privilege withine the X509 attribute 
certificate can be expressed as follows:
 > 	Privilege type: OID describing the privilege of signature delegation
 > 	Superior reference: Signing certificate of teh superior.
 >
 > This solution doesn't seem to be simple to express but provided that the 
necessary ASN.1 structures exist, it is intuitive to implement.
 >
 > I have in mind several solutions but can you please tell me if signature 
delegation has already been specified within some standard or RCF (up to my 
knowledge, no such functionality has already been expressed in ETSI or PKIX 
standards). And if it doen't exist, what do you think about the solution i 
summarized above.
 >
 > regards,
 >
 > ___________________________________________________________
 > Malek Bechlaghem
 > e-Security Product Development Manager
 > Strategy, Business Development and Product Management (SBP)
 > Internet Business Unit (IBU)
 > Belgacom SA/NV
 > Bd du Roi Albert II, 27, B-1030 Brussels
 >
 > Tel.: +32 2 202 79 02
 > Fax: +32 2 202 41 06
 > E-mail: malek.bechlaghem@belgacom.be
 >
 > We bring security to the e-world : www.e-trust.be
 >
 >
 >
 >
 > **** DISCLAIMER ****
 > "This e-mail and any attachments thereto may contain information
 > which is confidential and/or protected by intellectual property
 > rights and are intended for the sole use of the recipient(s) named above.
 > Any use of the information contained herein (including, but not limited to,
 > total or partial reproduction, communication or distribution in any form)
 > by persons other than the designated recipient(s) is prohibited.
 > If you have received this e-mail in error, please notify the sender either
 > by telephone or by e-mail and delete the material from any computer.
 > Thank you for your cooperation."




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PCb7W23452 for ietf-smime-bks; Fri, 25 Oct 2002 05:37:07 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PCb3W23447 for <ietf-smime@imc.org>; Fri, 25 Oct 2002 05:37:03 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g9PCcV707194; Fri, 25 Oct 2002 08:38:31 -0400 (EDT)
Message-ID: <200210251238.g9PCcVK07190@stingray.missi.ncsc.mil>
Date: Fri, 25 Oct 2002 08:31:31 -0400
From: "David P. Kemp" <dpkemp@missi.ncsc.mil>
X-Mailer: Mozilla 4.79 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Blake Ramsdell <blake@brutesquadlabs.com>
CC: ietf-smime@imc.org
Subject: Re: Summary of current nonRepudiation situation
References: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAzb6SYYioA0KtSxKXYq6tPwEAAAAA@brutesquadlabs.com>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms1F594D4ADB84370C8F4122ED"
X-H-S-Loop-Check-Ejzfr: 
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms1F594D4ADB84370C8F4122ED
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Blake,

I agree with the general principle outlined by Russ and Trevor, that
treatment of the digitalSignature and nonRepudiation bits for purposes
beyond mechanical use of the digital signature algorithm may depend
on application-specific policy.

However, I am concerned that the proposed language does not give
developers any guidance on what code to write to handle these bits,
and does not give purchasers of applications any knowledge of what
they are buying.  The S/MIME standard should allow the existence
of additional requirements, but should state that an S/MIME
application MUST either:
  1) explicitly cite a policy/specification/document/profile
     describing the additional treatement of these bits, or
  2) treat the digitalSignature and nonRepudiation bits identically


Dave



Blake Ramsdell wrote:
> 
> As it stands right now, I am putting the language in -CERT as Russ has
> presented it:
> 
>     S/MIME receiving agents MUST NOT accept the signature of a message
>     if it was verified using a certificate which contains the keyUsage
>     extension without either the digitalSignature or nonRepudiation bit
> set.
>     Sometimes S/MIME is used as a secure message transport for
>     applications beyond interpersonal messaging. In such cases, the
>     S/MIME-enabled application can specify additional requirements
>     concerning the digitalSignature or nonRepudiation bits within the
>     keyUsage certificate extension.
> 
> I believe that this is not contrary to any of the opinions voiced so far
> about nonRepudiation semantics, and it does a fine job of offloading the
> actual meaning and interpretation of this bit to good ol' "application
> defined behavior".
> 
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
--------------ms1F594D4ADB84370C8F4122ED
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIOhgYJKoZIhvcNAQcCoIIOdzCCDnMCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
DIkwggQxMIIDmqADAgECAgMDOtQwDQYJKoZIhvcNAQEFBQAwZDELMAkGA1UEBhMCVVMxGDAW
BgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxHzAd
BgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwHhcNMDIwNDI1MTQ1ODQyWhcNMDUwNDI1
MTQ1ODQyWjB3MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEQMA4GA1UECxMHTlNBL0NTUzEgMB4GA1UEAxMXS2Vt
cC5EYXZpZC5QLjA1MTQxMDE0MDQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOrsDFPo
087+VZ15OuyrJedIwjkRXWrtqRBzEpkk6Ct+Bkn/uiKzLn7AZ5IxbGDnZvjbvmEzPYkA/tm8
ng0IVxNpKEjdw7O1TbNLnwLSDkckcmq8AzW6se/Dm5nZ7l3ggVx8XuYifnr9E163atD9JxjR
nVM1vcPx262lVck4wTXrAgMBAAGjggHcMIIB2DAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgw
FoAU7BNbvCGMZpsKi38HXyWwFPkQ9ZswHQYDVR0OBBYEFIs+vTwgtAcXc7Wa3lN5TOdFB2v4
MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQsFMCAGA1UdEQQZMBeBFWRwa2VtcEBtaXNzaS5uY3Nj
Lm1pbDCBjwYDVR0SBIGHMIGEhoGBbGRhcDovL2VtYWlsLWRzLTMuYzNwa2kuY2hhbWIuZGlz
YS5taWwvY24lM2RET0QlMjBDTEFTUyUyMDMlMjBFTUFJTCUyMENBLTMlMmNvdSUzZFBLSSUy
Y291JTNkRG9EJTJjbyUzZFUuUy4lMjBHb3Zlcm5tZW50JTJjYyUzZFVTMIG5BgNVHR8EgbEw
ga4wgauggaiggaWGgaJsZGFwOi8vZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9j
biUzZERPRCUyMENMQVNTJTIwMyUyMEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2RE
b0QlMmNvJTNkVS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVM/Y2VydGlmaWNhdGVyZXZvY2F0
aW9ubGlzdDtiaW5hcnkwDQYJKoZIhvcNAQEFBQADgYEA0kEbsqISaLdMPsBZSuefbL8k2fU2
V6nAVrq890J8s7Sf2vlm+Z9SkRqo+KebaeHRCS8Pg5S8YhxRHz6jmvGV9+CqOBhJp/DsW2Iu
tHXUMy46iPxLQfFT75LIjOAGXk929TSgnqk/3ygIVP6/E+6culxD7hTKh4FFa/Dto/V4T6ww
ggQbMIIDhKADAgECAgETMA0GCSqGSIb3DQEBBQUAMGExCzAJBgNVBAYTAlVTMRgwFgYDVQQK
Ew9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRwwGgYDVQQD
ExNEb0QgQ0xBU1MgMyBSb290IENBMB4XDTAwMDgxMTE3NDUyOVoXDTA2MDgxMDE3NDUyOVow
ZDELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E
MQwwCgYDVQQLEwNQS0kxHzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMwgZ8wDQYJ
KoZIhvcNAQEBBQADgY0AMIGJAoGBAO98vchr6/EuN4Vw2h1ovziIBzOml88LKtiNQxMFN07J
V04JFR2kZtuOxlCcvNnL2fXv9lRG4teiwqBldt36ekVY/1LDkW6xDecvHnS4BuJhQPnmMdnu
HF47TwK7O/bxvevAKpKeS1/sw1wuyKJN9Bi7jezH36gY+CdT9VwfP4QJAgMBAAGjggHeMIIB
2jAdBgNVHQ4EFgQU7BNbvCGMZpsKi38HXyWwFPkQ9ZswDgYDVR0PAQH/BAQDAgGGMA8GA1Ud
EwEB/wQFMAMBAf8wDAYDVR0kBAUwA4ABADAfBgNVHSMEGDAWgBRsnKXwXI9tQY3EFzuQV8IP
o81t/jAwBgNVHSAEKTAnMAsGCWCGSAFlAgELBTALBglghkgBZQIBCwkwCwYJYIZIAWUCAQsK
MIGDBgNVHRIEfDB6hnhsZGFwOi8vZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERv
RCUyMENMQVNTJTIwMyUyMFJvb3QlMjBDQSUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNk
VS5TLiUyMEdvdmVybm1lbnQlMmNjJTNkVVMwgbAGA1UdHwSBqDCBpTCBoqCBn6CBnIaBmWxk
YXA6Ly9kcy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRG9EJTIwQ0xBU1MlMjAzJTIw
Um9vdCUyMENBJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVu
dCUyY2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0B
AQUFAAOBgQAmpY01OHZr/vRBJsgxGUX7diGsCGrzYM1C0fhrJknH4L7Lm61Nt1bSZ4/obHjl
QxBQyDx9ovISBAi//TVUd1UKbdqNW7Inso2enmK9beG9eK5M0ZfEdj3S0UxmJAgRXSgVsnE7
xzP3uZ1/mJx++gSwcpd+/NPBVJNjFJPf8RvL4DCCBDEwggOaoAMCAQICAwM61jANBgkqhkiG
9w0BAQUFADBkMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYD
VQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEfMB0GA1UEAxMWRE9EIENMQVNTIDMgRU1BSUwgQ0Et
MzAeFw0wMjA0MjUxNDU5NDZaFw0wNTA0MjUxNDU5NDZaMHcxCzAJBgNVBAYTAlVTMRgwFgYD
VQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRAwDgYD
VQQLEwdOU0EvQ1NTMSAwHgYDVQQDExdLZW1wLkRhdmlkLlAuMDUxNDEwMTQwNDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEApfaxUWfMcxUPKtb9p7FeItF5DkWiDmO8i0uiC0VpUPoz
t+9gx4pUo4lOeqcSGMRfFwv7llBtPte7NqtbDefDW2tIFIzzFrv07VPrq0MNCo6rRK/IGCK/
Zmrf/UOfx8Hzvn6dIF+S9YktXZsFpbtJT49v6+E2nmKLpO7OCtW582kCAwEAAaOCAdwwggHY
MA4GA1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTsE1u8IYxmmwqLfwdfJbAU+RD1mzAdBgNV
HQ4EFgQUYrtZ7SslM3nXtC47SpLr4YEu02AwFgYDVR0gBA8wDTALBglghkgBZQIBCwUwIAYD
VR0RBBkwF4EVZHBrZW1wQG1pc3NpLm5jc2MubWlsMIGPBgNVHRIEgYcwgYSGgYFsZGFwOi8v
ZW1haWwtZHMtMy5jM3BraS5jaGFtYi5kaXNhLm1pbC9jbiUzZERPRCUyMENMQVNTJTIwMyUy
MEVNQUlMJTIwQ0EtMyUyY291JTNkUEtJJTJjb3UlM2REb0QlMmNvJTNkVS5TLiUyMEdvdmVy
bm1lbnQlMmNjJTNkVVMwgbkGA1UdHwSBsTCBrjCBq6CBqKCBpYaBomxkYXA6Ly9lbWFpbC1k
cy0zLmMzcGtpLmNoYW1iLmRpc2EubWlsL2NuJTNkRE9EJTIwQ0xBU1MlMjAzJTIwRU1BSUwl
MjBDQS0zJTJjb3UlM2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUy
Y2MlM2RVUz9jZXJ0aWZpY2F0ZXJldm9jYXRpb25saXN0O2JpbmFyeTANBgkqhkiG9w0BAQUF
AAOBgQDIzhLKkB3qMsN45svSI+hEJN0hjuhiz7hGNFOUco1YnyoyfwvShlJHrl85ptr9mt/L
hMuLunqBCS2tfTKTLWAK9RjR20MRI7evK0qu/OxpxfMI9TFPwHPXSOINrgILbIVvuwOkIYcm
IBcfD2OReXE7+WcRoZDUjZGD4X+80lIm4jGCAcUwggHBAgEBMGswZDELMAkGA1UEBhMCVVMx
GDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kx
HzAdBgNVBAMTFkRPRCBDTEFTUyAzIEVNQUlMIENBLTMCAwM61DAJBgUrDgMCGgUAoIGxMBgG
CSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAyNTEyMzEzMlow
IwYJKoZIhvcNAQkEMRYEFAiyo1/uN9gaR9gSjaM6PuECDhcFMFIGCSqGSIb3DQEJDzFFMEMw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0G
CCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAIwLAReXdd/BimBMSP995v7Jy80gvW3vt
C48lYfJnufGU0sfyxY1Gqa6FwJQC8me0O1dXf1NEEhsUCLMBP3IPMX6PvgDAim4LoPxUbZnB
n++nlX5r7sfsV4YGyi7XTjuueUYX2x6gIgnZX+PNlo/qjOxHe/Vuz6HO4Q18xzy7JzI=
--------------ms1F594D4ADB84370C8F4122ED--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9PAn8913952 for ietf-smime-bks; Fri, 25 Oct 2002 03:49:08 -0700 (PDT)
Received: from consulintel.es (mail.consulintel.es [213.172.48.142]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9PAn6W13948 for <ietf-smime@imc.org>; Fri, 25 Oct 2002 03:49:06 -0700 (PDT)
Received: from CESAR01 ([10.0.0.33]) by consulintel.es ([127.0.0.1]) with SMTP (MDaemon.PRO.v6.0.7.R) for <ietf-smime@imc.org>; Fri, 25 Oct 2002 12:53:28 +0200
Message-ID: <01b201c27c14$88b41a90$2100000a@consulintel.es>
Reply-To: =?Windows-1252?Q?Miguel_Angel_D=EDaz?= <miguelangel.diaz@consulintel.es>
From: =?Windows-1252?Q?Miguel_Angel_D=EDaz?= <miguelangel.diaz@consulintel.es>
To: "smime List" <ietf-smime@imc.org>
Cc: "Miguel Angel Morales" <miguelangel.morales@consulintel.es>
Subject: Problems with ciphered e-mail messages
Date: Fri, 25 Oct 2002 12:51:55 +0200
Organization: Consulintel
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AF_01C27C25.4C1B58D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
X-MDRemoteIP: 10.0.0.33
X-Return-Path: miguelangel.diaz@consulintel.es
X-MDaemon-Deliver-To: ietf-smime@imc.org
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_01AF_01C27C25.4C1B58D0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi folks,

 I've detected the follow strange behaviour with Outlook Express (and =
maybe all e-mail applications) and ciphered messages with key public =
certificates (KPC):

 I want to send a message wich is ciphered using the KPC of the destined =
person. The out mail server (smtp) is configured to add all outing =
messages a footer (like one is added to the end of this messages) with =
data of my company like company name, address, phone, etc. When the =
message is received by the destined person, it is open whith Outlook =
Express (several releases are tested) and this message can't be shown. =
Instead, a message with the footer is shown in the body's message and a =
file is attached with name "smime.p7m". The content of this file is =
ciphered and can't be shown.

I think the problem is that the message is locally ciphered in the host, =
and then this ciphered message is modified when the mail server add the =
footer. When the client mail application tries to open it at the =
destination, it detect that  the original ciphered message was modified =
and don't show the ciphered part.

Am I wrong?

If I'm rigth I have some questions:

1.- Doesn't the mail client application be able to show the message =
ciphered part?.=20

2.- How can I see the message ciphered part.

3.- Does this behaviour mean that e-mail securited with KPC and this =
kind of service provided by the mail servers (addition of  footer) are =
incompatibles?

4.- Is there any way to solve this and to allow all ciphered messages =
with footers can be shown in the client mail application?


Thanks in advance.

Best regards.
Miguel A. D=EDaz




***********************************
Madrid 2003 Global IPv6 Summit
12-14 May 2003 - Soon on line at:
http://www.ipv6-es.com
Interested in participating or sponsoring ?
Contact us at ipv6@consulintel.es

------=_NextPart_000_01AF_01C27C25.4C1B58D0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-1252">
<META content=3D"MSHTML 5.50.4913.1100" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi folks,</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;I've detected&nbsp;the follow&nbsp;strange&nbsp;behaviour =
with=20
Outlook Express (and maybe all e-mail applications) and ciphered =
messages with=20
key public certificates (KPC):</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;I want to send a message wich is ciphered using the KPC of =
the=20
destined person. The out mail server (smtp) is configured to add all =
outing=20
messages a footer (like one is added to the end of this messages) with =
data=20
of&nbsp;my company like company name, address, phone, etc. When the =
message is=20
received by the destined person, it is open whith Outlook Express =
(several=20
releases are tested) and this message can't be shown. Instead, a message =
with=20
the footer is shown in the body's message and a file is attached with =
name=20
"smime.p7m". The content of this file is ciphered and can't be =
shown.</DIV>
<DIV>&nbsp;</DIV>
<DIV>I think the&nbsp;problem is that the message is&nbsp;locally =
ciphered=20
in&nbsp;the host, and&nbsp;then this&nbsp;ciphered message is =
modified&nbsp;when=20
the&nbsp;mail server add the footer. When&nbsp;the&nbsp;client&nbsp;mail =

application tries to open it at the destination, it&nbsp;detect that =
&nbsp;the=20
original ciphered message was modified and don't show the ciphered =
part.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Am I wrong?</DIV>
<DIV>&nbsp;</DIV>
<DIV>If I'm rigth I have some questions:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV>1.- Doesn't the mail client application be able to show the message =

ciphered part?. </DIV></DIV>
<DIV>&nbsp;</DIV>
<DIV>2.- How can I see the message ciphered part.</DIV>
<DIV>&nbsp;</DIV>
<DIV>3.- Does this behaviour mean that e-mail securited with KPC and =
this kind=20
of service provided by the mail servers (addition of &nbsp;footer) are=20
incompatibles?</DIV>
<DIV>&nbsp;</DIV>
<DIV>4.- Is there any way to solve this and to&nbsp;allow all ciphered =
messages=20
with footers can be shown in the client mail application?</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Thanks in advance.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Best regards.</DIV>
<DIV>Miguel A. D=EDaz</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>


<html>
<br>
<br>
***********************************<br>
Madrid 2003 Global IPv6 Summit<br>
12-14 May 2003 - Soon on line at:<br>
http://www.ipv6-es.com<br>
Interested in participating or sponsoring ?<br>
Contact us at ipv6@consulintel.es</html>

------=_NextPart_000_01AF_01C27C25.4C1B58D0--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9P16fB11428 for ietf-smime-bks; Thu, 24 Oct 2002 18:06:41 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9P16eW11423 for <ietf-smime@imc.org>; Thu, 24 Oct 2002 18:06:40 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with ESMTP ; Thu, 24 Oct 2002 18:06:34 -0700
From: "Blake Ramsdell" <blake@brutesquadlabs.com>
To: <ietf-smime@imc.org>
Subject: Summary of current nonRepudiation situation
Date: Thu, 24 Oct 2002 18:06:34 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAzb6SYYioA0KtSxKXYq6tPwEAAAAA@brutesquadlabs.com>
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.2800.1106
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

As it stands right now, I am putting the language in -CERT as Russ has
presented it:

    S/MIME receiving agents MUST NOT accept the signature of a message
    if it was verified using a certificate which contains the keyUsage
    extension without either the digitalSignature or nonRepudiation bit
set.
    Sometimes S/MIME is used as a secure message transport for
    applications beyond interpersonal messaging. In such cases, the
    S/MIME-enabled application can specify additional requirements
    concerning the digitalSignature or nonRepudiation bits within the
    keyUsage certificate extension.

I believe that this is not contrary to any of the opinions voiced so far
about nonRepudiation semantics, and it does a fine job of offloading the
actual meaning and interpretation of this bit to good ol' "application
defined behavior".

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9MI64M12776 for ietf-smime-bks; Tue, 22 Oct 2002 11:06:04 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9MI5kW12761 for <ietf-smime@imc.org>; Tue, 22 Oct 2002 11:05:46 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 22 Oct 2002 11:05:43 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 22 Oct 2002 11:05:43 -0700
Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 22 Oct 2002 11:05:43 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Tue, 22 Oct 2002 11:05:42 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Tue, 22 Oct 2002 11:05:34 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Tue, 22 Oct 2002 11:05:30 -0700
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD063C4307@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The Great nonRepudiation vs. digitalSignature Debate
Thread-Index: AcJ5S5Xckh3lvYDwQgapC/Zc/AnezAApYVfA
From: "Trevor Freeman" <trevorf@windows.microsoft.com>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>, "Housley, Russ" <rhousley@rsasecurity.com>, "Blake Ramsdell" <blake@brutesquadlabs.com>
Cc: <ietf-smime@imc.org>
X-OriginalArrivalTime: 22 Oct 2002 18:05:34.0496 (UTC) FILETIME=[9E065A00:01C279F5]
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

This is a multi-part message in MIME format.

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C279F5.9BAC97C4"

------_=_NextPart_001_01C279F5.9BAC97C4
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I think we can take it as read that only a few Eskimos or Indonesian
head hunters are unaware of the nonRepudiation bit issue, but since it
won't die we are trying to patch things up so we can get of with our
lives.

How about this wording to cover the subject.=20

S/MIME receiving agents MUST only accept the signature of a message
where the certificate used to verify the signature has either no key
usage extension or if the extension is present, has either the
digitalSignature or nonRepudiation bit set. It is a matter of local
policy if the S/MIME client wants to add additional requirements to the
acceptability of the signing certificate such as the set of valid
policies associated with the signing certificate.

It is also a matter of local policy if the S/MIME client wants to
ascribe any status beyond message integrity assonated with the digital
signature if the nonRepudiation bit is asserted or the key usage
extension is absent. S/MIME clients MUST NOT ascribe as special stats to
the message solely based on the assertion of the nonRepudiation bit in
the key usage extension or the absence of the extesnion. If clients want
to ascribe special status beyond message integrity to messages signed
with certificates where the nonRepudiation bit is asserted or the key
usage extension is absent, it MUST do so in conjunction with other
factors such as the set of valid certificate policies of the signing
certificate.


-----Original Message-----
From: Hallam-Baker, Phillip [mailto:pbaker@verisign.com]=20
Sent: Monday, October 21, 2002 2:50 PM
To: Trevor Freeman; Housley, Russ; Blake Ramsdell
Cc: ietf-smime@imc.org
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate


No, the non repudiation bit is in fact the number of the beast.

That is at least the conclusion we came to after the argument in=20
PKIX...

I think the problem here is that the only thing we can get agreement on
is what a repudiation bit would be - I make no undertaking to take
care of this key. A non repudiation _bit_ is like a solvency
bit, completely inadequate.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@windows.microsoft.com]
> Sent: Monday, October 21, 2002 5:21 PM
> To: Housley, Russ; Blake Ramsdell
> Cc: ietf-smime@imc.org
> Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
>=20
>=20
>=20
> It's definitely a matter of local client policy what you accept. Even
> with interpersonal messaging - the email may have legal=20
> significance. I
> would have thought that the use of the NR bit would be also=20
> tied to some
> certificate policy. The issuer may think that the policy is=20
> good for NR,
> hence is OK to set the NR bit. I as the relying party I may not agree
> and mapped the policy to one which excludes the use of NR in=20
> which case
> I have implicitly mapped NR to plain DS.
>=20
> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@rsasecurity.com]=20
> Sent: Monday, October 21, 2002 7:02 AM
> To: Blake Ramsdell
> Cc: ietf-smime@imc.org
> Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
>=20
>=20
> Blake:
>=20
> I think that the language in RFC 3280 is fine for CA certificates.
>=20
> I do think that additional guidance should be given to the=20
> recipient of
> a=20
> signed message.  Here is my proposal.
>=20
>     S/MIME receiving agents MUST NOT accept the signature of a message
>     if it was verified using a certificate which contains the keyUsage
>     extension without either the digitalSignature or=20
> nonRepudiation bit
> set.
>     Sometimes S/MIME is used as a secure message transport for
>     applications beyond interpersonal messaging. In such cases, the
>     S/MIME-enabled application can specify additional requirements
>     concerning the digitalSignature or nonRepudiation bits within the
>     keyUsage certificate extension.
>=20
> I think that this is a reasonable approach because it=20
> specifies a clear=20
> behavior for an S/MIME library (such as SFL), but it does not prevent=20
> application that might use such a library from imposing additional=20
> requirements on these bits.
>=20
> Anyone have other thoughts?
>=20
> Russ
>=20
>=20
> At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:
>=20
> >The use of the digitalSignature and nonRepudiation bits in the key
> usage
> >certificate extension are not explicitly covered in the=20
> current -CERT.
> >Where this would go is the rather brilliant language "interpretation
> and
> >syntax for all extensions MUST follow [KEYM], unless otherwise
> specified
> >here".
> >
> >However, there has been some concern that the wording in=20
> [KEYM] is not
> >sufficient, and that this should be addressed specifically in -CERT.
> >
> >1. Which bits should be set for an end-entity certificate=20
> used to sign
> >an S/MIME message?  Is there a difference in this application between
> >nonRepudiation and digitalSignature, or can the assertion of=20
> either be
> >sufficient to convey the proper signing authority?
> >
> >2. Which bits should be set in CA certificates?
> >
> >The current thinking is that if the extension is present, either (or
> >both) bits MUST be asserted on end-entity certificates when=20
> used for a
> >signature.  If the extension is present in a CA certificate, then
> either
> >(or both) bits MUST be asserted also.
> >
> >I'll be hiding under my bed if anyone needs me.
> >
> >Blake
> >--
> >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
>=20

------_=_NextPart_001_01C279F5.9BAC97C4
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.6771.8">
<TITLE>RE: The Great nonRepudiation vs. digitalSignature Debate</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">I</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">think</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> we can take it as read that only a =
few</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">Eskimos</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> or</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">Indonesian</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier New">head hunters are =
unaware of the nonRepudiation</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> bit</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">issue</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New">, but since it</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">won't</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> die =
we</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">a</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">re trying to patch things up so we can get of with our =
lives.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">How about</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">this</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> wording to cover the =
subject.</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> </SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">S/MIME receiving agents MUST</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">only</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> accept the signature =
of a message</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">where the</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">certificate used to verify the =
signature</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> has</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">either</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier New">no key usage =
extension or if the</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">extension</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">is</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">present</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">, has =
either</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New"> the digitalSignature or</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> n</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New">onRepudiation</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">bit</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">set.</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">It is a</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">matter</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> of local policy if =
the S</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">/</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">MIME client wa</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New">nts</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">to add</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">additional</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">requirements</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> to =
the</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">acceptability</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> of the</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">signing certificate</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> such as =
the</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">set of valid policies associated with</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">the</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> signing certificate.</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">It is</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">also</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">a</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">matter</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> of local policy if =
the S</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">/</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">MIME client wa</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New">nts</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> to</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">ascribe</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> =
any</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New"> status</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">beyond</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">me</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New">ss</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New">age</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">integrity</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">assonated</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> wit</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New">h</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">the</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> =
digital</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">signature if the nonR</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">e</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">pudiation bit is =
asserted</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> or</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">the</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> =
key</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">usage</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">extension</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> is absent</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">.</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier New">S/MIME =
clients</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">MUST</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> NOT ascribe</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> as special stats =
to</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">the</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"></FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">message</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> solely based on the</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">assertion</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> of the nonRepudiation bit in</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">the</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> key usage extension</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> or the absence of =
the extesnion</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New">.</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> If clients want to</FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier New">a</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">scribe</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 =
FACE=3D"Courier New">special</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> status</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> =
beyond</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">message</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> integrity</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> to</FONT></SPAN><SPAN LANG=3D"en-gb"> =
<FONT SIZE=3D2 FACE=3D"Courier New">messages</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier New">signed =
with</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">certificates</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> where the nonR</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">e</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New">pudiation bit =
is</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">asserted</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> or</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT =
SIZE=3D2 FACE=3D"Courier New">the</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> key =
usage</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">extension</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> is absent</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New">,</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT =
SIZE=3D2 FACE=3D"Courier New"> it</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"></FONT></SPAN><SPAN =
LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">MUST</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> do so in conjunction with other factors such as =
the set of valid certificate policies</FONT></SPAN><SPAN =
LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier New"> =
of</FONT></SPAN><SPAN LANG=3D"en-gb"> <FONT SIZE=3D2 FACE=3D"Courier =
New">the</FONT></SPAN><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 =
FACE=3D"Courier New"> signing certificate.</FONT></SPAN><SPAN =
LANG=3D"en-gb"></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-us"><FONT SIZE=3D2 FACE=3D"Courier =
New">-----Original Message-----<BR>
From: Hallam-Baker, Phillip [<A =
HREF=3D"mailto:pbaker@verisign.com">mailto:pbaker@verisign.com</A>]<BR>
Sent: Monday, October 21, 2002 2:50 PM<BR>
To: Trevor Freeman; Housley, Russ; Blake Ramsdell<BR>
Cc: ietf-smime@imc.org<BR>
Subject: RE: The Great nonRepudiation vs. digitalSignature =
Debate</FONT></SPAN><SPAN LANG=3D"en-gb"></SPAN></P>
<BR>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">No, the non repudiation bit is in fact the number of the =
beast.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">That is at least the conclusion we came to after the argument in =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">PKIX...</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">I think the problem here is that the only thing we can get =
agreement on</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">is what a repudiation bit would be - I make no undertaking to =
take</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">care of this key. A non repudiation _bit_ is like a =
solvency</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">bit, completely inadequate.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN =
LANG=3D"en-gb">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Courier New">Phill</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; -----Original Message-----</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; From: Trevor Freeman [<A =
HREF=3D"mailto:trevorf@windows.microsoft.com">mailto:trevorf@windows.micr=
osoft.com</A>]</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Sent: Monday, October 21, 2002 5:21 PM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; To: Housley, Russ; Blake Ramsdell</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Cc: ietf-smime@imc.org</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Subject: RE: The Great nonRepudiation vs. digitalSignature =
Debate</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; It's definitely a matter of local client policy what you =
accept. Even</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; with interpersonal messaging - the email may have legal =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; significance. I</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; would have thought that the use of the NR bit would be also =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; tied to some</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; certificate policy. The issuer may think that the policy is =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; good for NR,</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; hence is OK to set the NR bit. I as the relying party I may =
not agree</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; and mapped the policy to one which excludes the use of NR in =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; which case</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; I have implicitly mapped NR to plain DS.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; -----Original Message-----</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; From: Housley, Russ [<A =
HREF=3D"mailto:rhousley@rsasecurity.com">mailto:rhousley@rsasecurity.com<=
/A>] </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Sent: Monday, October 21, 2002 7:02 AM</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; To: Blake Ramsdell</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Cc: ietf-smime@imc.org</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Subject: Re: The Great nonRepudiation vs. digitalSignature =
Debate</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Blake:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; I think that the language in RFC 3280 is fine for CA =
certificates.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; I do think that additional guidance should be given to the =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; recipient of</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; a </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; signed message.&nbsp; Here is my proposal.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; S/MIME receiving agents MUST NOT =
accept the signature of a message</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; if it was verified using a certificate =
which contains the keyUsage</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; extension without either the =
digitalSignature or </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; nonRepudiation bit</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; set.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; Sometimes S/MIME is used as a secure =
message transport for</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; applications beyond interpersonal =
messaging. In such cases, the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; S/MIME-enabled application can specify =
additional requirements</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; concerning the digitalSignature or =
nonRepudiation bits within the</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt;&nbsp;&nbsp;&nbsp;&nbsp; keyUsage certificate =
extension.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; I think that this is a reasonable approach because it =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; specifies a clear </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; behavior for an S/MIME library (such as SFL), but it does not =
prevent </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; application that might use such a library from imposing =
additional </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; requirements on these bits.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Anyone have other thoughts?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; Russ</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; At 03:30 PM 10/17/2002 -0700, Blake Ramsdell =
wrote:</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;The use of the digitalSignature and nonRepudiation bits in =
the key</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; usage</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;certificate extension are not explicitly covered in the =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; current -CERT.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;Where this would go is the rather brilliant language =
&quot;interpretation</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; and</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;syntax for all extensions MUST follow [KEYM], unless =
otherwise</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; specified</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;here&quot;.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;However, there has been some concern that the wording in =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; [KEYM] is not</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;sufficient, and that this should be addressed specifically =
in -CERT.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;1. Which bits should be set for an end-entity certificate =
</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; used to sign</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;an S/MIME message?&nbsp; Is there a difference in this =
application between</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;nonRepudiation and digitalSignature, or can the assertion =
of </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; either be</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;sufficient to convey the proper signing =
authority?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;2. Which bits should be set in CA =
certificates?</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;The current thinking is that if the extension is present, =
either (or</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;both) bits MUST be asserted on end-entity certificates =
when </FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; used for a</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;signature.&nbsp; If the extension is present in a CA =
certificate, then</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; either</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;(or both) bits MUST be asserted also.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;I'll be hiding under my bed if anyone needs =
me.</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;Blake</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;--</FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; &gt;Blake Ramsdell | Brute Squad Labs | <A =
HREF=3D"http://www.brutesquadlabs.com">http://www.brutesquadlabs.com</A><=
/FONT></SPAN></P>

<P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier =
New">&gt; </FONT></SPAN></P>

</BODY>
</HTML>
------_=_NextPart_001_01C279F5.9BAC97C4--

--------------InterScan_NT_MIME_Boundary--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LMG9419749 for ietf-smime-bks; Mon, 21 Oct 2002 15:16:09 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LMG8W19744 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 15:16:09 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with ESMTP ; Mon, 21 Oct 2002 15:16:10 -0700
From: "Blake Ramsdell" <blake@brutesquadlabs.com>
To: "'Housley, Russ'" <rhousley@rsasecurity.com>, <bernd.matthes@gemplus.com>
Cc: <ietf-smime@imc.org>
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 15:16:10 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAATZKU3EVUgkikXaEoVv0AYQEAAAAA@brutesquadlabs.com>
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.2800.1106
In-Reply-To: <5.1.0.14.2.20021021073712.032089b8@exna07.securitydynamics.com>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org 
> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Housley, Russ
> Sent: Monday, October 21, 2002 4:43 AM
> To: bernd.matthes@gemplus.com
> Cc: ietf-smime@imc.org
> Subject: RE: Ordering of encryption and signing of a S/MIME message
> 
> An attacker can strip the SignedData encapsulation, making 
> the recipient 
> think that the originator sent an encrypted-only message.  
> However, this 
> construct is safe if the recipient will disregard any 
> unsigned messages.

Another argument in the early days was that "encrypt and then sign"
would allow an opponent to collect the signature information from the
message.

>From a client perspective, it might be interesting to see how well they
behave when presented with a signature around encryption.  The "What
Would Outlook Do" argument.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LLmLe19061 for ietf-smime-bks; Mon, 21 Oct 2002 14:48:21 -0700 (PDT)
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LLmJW19057 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 14:48:19 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by pigeon.verisign.com (8.12.1/) with ESMTP id g9LLlq47012716; Mon, 21 Oct 2002 14:47:52 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2656.59) id <VLKZJMPB>; Mon, 21 Oct 2002 14:50:19 -0700
Message-ID: <CE541259607DE94CA2A23816FB49F4A3A449@vhqpostal6.verisign.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Trevor Freeman <trevorf@windows.microsoft.com>, "Housley, Russ" <rhousley@rsasecurity.com>, Blake Ramsdell <blake@brutesquadlabs.com>
Cc: ietf-smime@imc.org
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Mon, 21 Oct 2002 14:50:16 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2656.59)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

No, the non repudiation bit is in fact the number of the beast.

That is at least the conclusion we came to after the argument in 
PKIX...

I think the problem here is that the only thing we can get agreement on
is what a repudiation bit would be - I make no undertaking to take
care of this key. A non repudiation _bit_ is like a solvency
bit, completely inadequate.

		Phill

> -----Original Message-----
> From: Trevor Freeman [mailto:trevorf@windows.microsoft.com]
> Sent: Monday, October 21, 2002 5:21 PM
> To: Housley, Russ; Blake Ramsdell
> Cc: ietf-smime@imc.org
> Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
> 
> 
> 
> It's definitely a matter of local client policy what you accept. Even
> with interpersonal messaging - the email may have legal 
> significance. I
> would have thought that the use of the NR bit would be also 
> tied to some
> certificate policy. The issuer may think that the policy is 
> good for NR,
> hence is OK to set the NR bit. I as the relying party I may not agree
> and mapped the policy to one which excludes the use of NR in 
> which case
> I have implicitly mapped NR to plain DS.
> 
> -----Original Message-----
> From: Housley, Russ [mailto:rhousley@rsasecurity.com] 
> Sent: Monday, October 21, 2002 7:02 AM
> To: Blake Ramsdell
> Cc: ietf-smime@imc.org
> Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
> 
> 
> Blake:
> 
> I think that the language in RFC 3280 is fine for CA certificates.
> 
> I do think that additional guidance should be given to the 
> recipient of
> a 
> signed message.  Here is my proposal.
> 
>     S/MIME receiving agents MUST NOT accept the signature of a message
>     if it was verified using a certificate which contains the keyUsage
>     extension without either the digitalSignature or 
> nonRepudiation bit
> set.
>     Sometimes S/MIME is used as a secure message transport for
>     applications beyond interpersonal messaging. In such cases, the
>     S/MIME-enabled application can specify additional requirements
>     concerning the digitalSignature or nonRepudiation bits within the
>     keyUsage certificate extension.
> 
> I think that this is a reasonable approach because it 
> specifies a clear 
> behavior for an S/MIME library (such as SFL), but it does not prevent 
> application that might use such a library from imposing additional 
> requirements on these bits.
> 
> Anyone have other thoughts?
> 
> Russ
> 
> 
> At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:
> 
> >The use of the digitalSignature and nonRepudiation bits in the key
> usage
> >certificate extension are not explicitly covered in the 
> current -CERT.
> >Where this would go is the rather brilliant language "interpretation
> and
> >syntax for all extensions MUST follow [KEYM], unless otherwise
> specified
> >here".
> >
> >However, there has been some concern that the wording in 
> [KEYM] is not
> >sufficient, and that this should be addressed specifically in -CERT.
> >
> >1. Which bits should be set for an end-entity certificate 
> used to sign
> >an S/MIME message?  Is there a difference in this application between
> >nonRepudiation and digitalSignature, or can the assertion of 
> either be
> >sufficient to convey the proper signing authority?
> >
> >2. Which bits should be set in CA certificates?
> >
> >The current thinking is that if the extension is present, either (or
> >both) bits MUST be asserted on end-entity certificates when 
> used for a
> >signature.  If the extension is present in a CA certificate, then
> either
> >(or both) bits MUST be asserted also.
> >
> >I'll be hiding under my bed if anyone needs me.
> >
> >Blake
> >--
> >Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
> 


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LLLA018396 for ietf-smime-bks; Mon, 21 Oct 2002 14:21:10 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LLL7W18392 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 14:21:07 -0700 (PDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:21:05 -0700
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 14:21:04 -0700
Received: from RED-IMC-02.redmond.corp.microsoft.com ([157.54.9.107]) by INET-HUB-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:21:04 -0700
Received: from WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by RED-IMC-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.5600); Mon, 21 Oct 2002 14:21:04 -0700
Received: from WIN-MSG-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by WIN-IMC-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3663.0); Mon, 21 Oct 2002 14:21:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6771.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Mon, 21 Oct 2002 14:21:03 -0700
Message-ID: <4AEE3169443CDD4796CA8A00B02191CD063C4305@win-msg-01.wingroup.windeploy.ntdev.microsoft.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: The Great nonRepudiation vs. digitalSignature Debate
Thread-Index: AcJ5I2r2cs3WJltKSNaAcyFZ3Z8XpQAIs/vg
From: "Trevor Freeman" <trevorf@windows.microsoft.com>
To: "Housley, Russ" <rhousley@rsasecurity.com>, "Blake Ramsdell" <blake@brutesquadlabs.com>
Cc: <ietf-smime@imc.org>
X-OriginalArrivalTime: 21 Oct 2002 21:21:04.0179 (UTC) FILETIME=[C30C3030:01C27947]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g9LLL8W18393
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

It's definitely a matter of local client policy what you accept. Even
with interpersonal messaging - the email may have legal significance. I
would have thought that the use of the NR bit would be also tied to some
certificate policy. The issuer may think that the policy is good for NR,
hence is OK to set the NR bit. I as the relying party I may not agree
and mapped the policy to one which excludes the use of NR in which case
I have implicitly mapped NR to plain DS.

-----Original Message-----
From: Housley, Russ [mailto:rhousley@rsasecurity.com] 
Sent: Monday, October 21, 2002 7:02 AM
To: Blake Ramsdell
Cc: ietf-smime@imc.org
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate


Blake:

I think that the language in RFC 3280 is fine for CA certificates.

I do think that additional guidance should be given to the recipient of
a 
signed message.  Here is my proposal.

    S/MIME receiving agents MUST NOT accept the signature of a message
    if it was verified using a certificate which contains the keyUsage
    extension without either the digitalSignature or nonRepudiation bit
set.
    Sometimes S/MIME is used as a secure message transport for
    applications beyond interpersonal messaging. In such cases, the
    S/MIME-enabled application can specify additional requirements
    concerning the digitalSignature or nonRepudiation bits within the
    keyUsage certificate extension.

I think that this is a reasonable approach because it specifies a clear 
behavior for an S/MIME library (such as SFL), but it does not prevent 
application that might use such a library from imposing additional 
requirements on these bits.

Anyone have other thoughts?

Russ


At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:

>The use of the digitalSignature and nonRepudiation bits in the key
usage
>certificate extension are not explicitly covered in the current -CERT.
>Where this would go is the rather brilliant language "interpretation
and
>syntax for all extensions MUST follow [KEYM], unless otherwise
specified
>here".
>
>However, there has been some concern that the wording in [KEYM] is not
>sufficient, and that this should be addressed specifically in -CERT.
>
>1. Which bits should be set for an end-entity certificate used to sign
>an S/MIME message?  Is there a difference in this application between
>nonRepudiation and digitalSignature, or can the assertion of either be
>sufficient to convey the proper signing authority?
>
>2. Which bits should be set in CA certificates?
>
>The current thinking is that if the extension is present, either (or
>both) bits MUST be asserted on end-entity certificates when used for a
>signature.  If the extension is present in a CA certificate, then
either
>(or both) bits MUST be asserted also.
>
>I'll be hiding under my bed if anyone needs me.
>
>Blake
>--
>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LGrZ704939 for ietf-smime-bks; Mon, 21 Oct 2002 09:53:35 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9LGrXW04935 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 09:53:33 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 16:53:35 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 MAA25426 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 12:53:34 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LGox110703 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 12:50:59 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWC0WB>; Mon, 21 Oct 2002 12:53:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.23]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWC0V5; Mon, 21 Oct 2002 12:53:27 -0400
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: Blake Ramsdell <blake@brutesquadlabs.com>
Cc: ietf-smime@imc.org
Message-Id: <5.1.0.14.2.20021021094956.02f43c30@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 21 Oct 2002 10:02:06 -0400
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
In-Reply-To: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50S wK3EZjypY2MKAAAAQAAAAJ0+6nPDBFUGIth996Sr4AQEAAAAA@brutesquadlabs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Blake:

I think that the language in RFC 3280 is fine for CA certificates.

I do think that additional guidance should be given to the recipient of a 
signed message.  Here is my proposal.

    S/MIME receiving agents MUST NOT accept the signature of a message
    if it was verified using a certificate which contains the keyUsage
    extension without either the digitalSignature or nonRepudiation bit set.
    Sometimes S/MIME is used as a secure message transport for
    applications beyond interpersonal messaging. In such cases, the
    S/MIME-enabled application can specify additional requirements
    concerning the digitalSignature or nonRepudiation bits within the
    keyUsage certificate extension.

I think that this is a reasonable approach because it specifies a clear 
behavior for an S/MIME library (such as SFL), but it does not prevent 
application that might use such a library from imposing additional 
requirements on these bits.

Anyone have other thoughts?

Russ


At 03:30 PM 10/17/2002 -0700, Blake Ramsdell wrote:

>The use of the digitalSignature and nonRepudiation bits in the key usage
>certificate extension are not explicitly covered in the current -CERT.
>Where this would go is the rather brilliant language "interpretation and
>syntax for all extensions MUST follow [KEYM], unless otherwise specified
>here".
>
>However, there has been some concern that the wording in [KEYM] is not
>sufficient, and that this should be addressed specifically in -CERT.
>
>1. Which bits should be set for an end-entity certificate used to sign
>an S/MIME message?  Is there a difference in this application between
>nonRepudiation and digitalSignature, or can the assertion of either be
>sufficient to convey the proper signing authority?
>
>2. Which bits should be set in CA certificates?
>
>The current thinking is that if the extension is present, either (or
>both) bits MUST be asserted on end-entity certificates when used for a
>signature.  If the extension is present in a CA certificate, then either
>(or both) bits MUST be asserted also.
>
>I'll be hiding under my bed if anyone needs me.
>
>Blake
>--
>Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LFH8p28272 for ietf-smime-bks; Mon, 21 Oct 2002 08:17:08 -0700 (PDT)
Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LFH3W28262 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 08:17:03 -0700 (PDT)
Received: from [192.168.0.244] ([64.165.71.170]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May  7 2001)) with ESMTP id <0H4C00L037SGS2@mta6.snfc21.pbi.net> for ietf-smime@imc.org; Mon, 21 Oct 2002 08:17:04 -0700 (PDT)
Date: Mon, 21 Oct 2002 08:17:04 -0700
From: Aram Perez <aram@pacbell.net>
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
In-reply-to:  <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAJ0+6nPDBFUGIth996Sr4AQEAAAAA@brutesquadlabs.com>
To: ietf-smime@imc.org
Message-id: <B9D96880.6B0C%aram@pacbell.net>
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
User-Agent: Microsoft-Entourage/10.1.0.2006
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Hi Blake,

Since no one seems to have answered, I'll give you my very unbiased opinion
;-)  The NR bit should never be set in any certificate as it doesn't mean
anything. It's my understanding that there is already work at X.509 on at
least renaming the bit to something more meaningful.

My dos centavos,
Aram


Blake Ramsdell wrote:

> 
> The use of the digitalSignature and nonRepudiation bits in the key usage
> certificate extension are not explicitly covered in the current -CERT.
> Where this would go is the rather brilliant language "interpretation and
> syntax for all extensions MUST follow [KEYM], unless otherwise specified
> here".
> 
> However, there has been some concern that the wording in [KEYM] is not
> sufficient, and that this should be addressed specifically in -CERT.
> 
> 1. Which bits should be set for an end-entity certificate used to sign
> an S/MIME message?  Is there a difference in this application between
> nonRepudiation and digitalSignature, or can the assertion of either be
> sufficient to convey the proper signing authority?
> 
> 2. Which bits should be set in CA certificates?
> 
> The current thinking is that if the extension is present, either (or
> both) bits MUST be asserted on end-entity certificates when used for a
> signature.  If the extension is present in a CA certificate, then either
> (or both) bits MUST be asserted also.
> 
> I'll be hiding under my bed if anyone needs me.
> 
> Blake
> --
> Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com
> 



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LD9Lg21194 for ietf-smime-bks; Mon, 21 Oct 2002 06:09:21 -0700 (PDT)
Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LD9JW21190 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 06:09:19 -0700 (PDT)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id NAA23927; Mon, 21 Oct 2002 13:09:17 GMT
From: malek.bechlaghem@belgacom.be
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 15:09:17 +0200
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <VKALF79Y>; Mon, 21 Oct 2002 15:09:16 +0200
Message-ID: <95C94B2F0094D21180710008C75DD6A40B9AB412@apl541.bc>
To: aalberti@axway.com
Cc: ietf-smime@imc.org
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 15:09:12 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Antoine,

Paul Syverson's paper, "Limitations on the design of public key protocols", discusses several attack scenarios regarding the order of operations within the flow of a cryptographic protocol (sign and encrypt, encrypt and sign, ...). If you are interested, you can download it from 

http://citeseer.nj.nec.com/syverson96limitation.html

Going back to your remark, indeed, unless you avoid such threat at application level (having for instance a list of trusted signatory), it is difficult to avoid to be immune from such treats especially when the signature verifier is an automatic process that performs dedicated operations  after a successful signature verification.

Best regards,

malek.

-----Original Message-----
From: Antoine Alberti [mailto:aalberti@axway.com]
Sent: 21 October 2002 11:45
To: 'ietf-smime@imc.org'
Subject: RE: Ordering of encryption and signing of a S/MIME message



> For security reasons, you should first sign your message and then encrypt 
it with the recipient's public key. If you
> perform the the reverse operation (encrypt then sign), then a threat 
agent may
> intercept you message, skip your signature and sign "your encrypted" 
message. So the recipient will hence receive a
> signed message from the threat agent and no more from you.

And how can the threat agent do this using the expected private key? And if 
it can't, wouldn't the receving agent have a serious security hole if it 
accepted such a message?

Curiously yours.


**** DISCLAIMER **** 
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LCUK218762 for ietf-smime-bks; Mon, 21 Oct 2002 05:30:20 -0700 (PDT)
Received: from mail.src-gmbh.lan ([194.175.98.188]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9LCUGW18758 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 05:30:17 -0700 (PDT)
Received: from src-gmbh.de (dhcp1203.src-gmbh.lan [192.168.12.203]) by mail.src-gmbh.lan (Mailexpress) with ESMTP id D7E2614001C; Mon, 21 Oct 2002 14:29:48 +0200 (CEST)
Message-ID: <3DB3F419.E5B50F8D@src-gmbh.de>
Date: Mon, 21 Oct 2002 14:33:29 +0200
From: Thomas Hueske <thomas.hueske@src-gmbh.de>
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Antoine Alberti <aalberti@axway.com>
Cc: "'ietf-smime@imc.org'" <ietf-smime@imc.org>, Blake Ramsdell <blake@brutesquadlabs.com>
Subject: Re: encryptCerts
References: <E732E8C298BFCF4194C0B008D920EFEE87EB80@nt102.pa.sopra>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Hi,

the attribute is defined in  "Certificate Distribution Specification"
<draft-ietf-smime-certdist-05.txt> written by J. Schaad (November 19, 2000).

See   http://www.ietf.org/proceedings/00jul/I-D/smime-certdist-05.txt

Regards,
Thomas Hueske


Antoine Alberti wrote:

> I found the following OID in a SignedData SignedAttribute:
> 1.2.840.113549.1.9.16.2.13, which appears to be the OID for encryptCerts,
> as I could see in http://www.imc.org/ietf-smime/sm-oid.asn.
> My problem is I could not find any RFC/draft, or anything reference to this
> attribute, neither in the standards the working group manages, nor in PKCS
> #9.
> As 1.2.840.113549.1.9.16 stands for S/MIME, and, I suppose, the .2.13
> suffix will not be the only one I can't find, can anyone help me to find a
> description for the encryptCerts field, its meaning, and, if possible, some
> ideas for finding the other S/MIME extensions I could not find through
> IETF?
>
> Thanks in advance.
>
>
>
>         Antoine Alberti                 Axway.  a Sopra Group company
>         Tel  : +33 (0)1 47 17 24 37             XFB R&D
>         Fax : +33 (0)1 47 17 21 23              26 Rue des Pavillons
>         email: aalberti@axway.com               92807 Puteaux Cedex - France

--

________________________________________________________________

SRC Security Research & Consulting GmbH
Leipziger Str. 35             Tel: +49-611-5066-2504
65191 Wiesbaden               Fax: +49-611-5066-2508
http://www.src-gmbh.de        mob: +49-160-8866051

Fingerprint: D767 FDB1 1097 F595 D4A7  9C87 0E15 A850 FC55 56A6




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9LBrot17502 for ietf-smime-bks; Mon, 21 Oct 2002 04:53:50 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9LBrmW17498 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 04:53:48 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 21 Oct 2002 11:53:49 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 HAA26295 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 07:53:48 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g9LBpDI07061 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 07:51:13 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <3TPWC5Z9>; Mon, 21 Oct 2002 07:53:47 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.8]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPWC5Z7; Mon, 21 Oct 2002 07:53:41 -0400
From: "Housley, Russ" <rhousley@rsasecurity.com>
To: bernd.matthes@gemplus.com
Cc: ietf-smime@imc.org
Message-Id: <5.1.0.14.2.20021021073712.032089b8@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 21 Oct 2002 07:43:15 -0400
Subject: RE: Ordering of encryption and signing of a S/MIME message
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Bernd:

In most situations, I recommend sign then encrypt.  This provides signature 
on the plaintext.

There are application-environment reasons to deviation from this 
approach.  However, one must take care.  If one does encrypt then sign, the 
resulting structure is:
	ContentInfo
	  SignedData
	    EnvelopedData
	      Content

An attacker can strip the SignedData encapsulation, making the recipient 
think that the originator sent an encrypted-only message.  However, this 
construct is safe if the recipient will disregard any unsigned messages.

Russ

-----Original Message-----
From: Bernd Matthes [mailto:bernd.matthes@gemplus.com]
Sent: 17 October 2002 16:22
To: ietf smime
Cc: Matthias Genkel; Dr. Stephen Henson
Subject: Q: Ordering of encryption and signing of a S/MIME message


Hi to all!

My Question is:
Is it useful a message as first to encrypt and
then to sign the encrypted result,
in example the encapsulatedData of a pkcs7SignedData structure
is a pkcs7encrypted data structure?
I know, it's senseless... ;-) but i found nothing in the standards.
Is there any sensible reason against this procedure(i hope so)?

thanks in advance.

with kind regards
-- 
Bernd Matthes                   Gemplus mids GmbH --
Senior Software Engineer    	   formerly Celo Communications GmbH
Dipl.-Ing.(FH)                  R&D Center Germany


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L9j4E05791 for ietf-smime-bks; Mon, 21 Oct 2002 02:45:04 -0700 (PDT)
Received: from sopragroup.com (mailer@smpt1.zpar1.sopragroup.com [213.223.36.98] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g9L9j3W05787 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 02:45:03 -0700 (PDT)
Received: (qmail 15723 invoked from network); 21 Oct 2002 09:44:59 -0000
Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 21 Oct 2002 09:44:59 -0000
Received: by localhost with Microsoft MAPI; Mon, 21 Oct 2002 11:45:27 +0200
Message-ID: <E732E8C298BFCF4194C0B008D920EFEE87EB8F@nt102.pa.sopra>
From: Antoine Alberti <aalberti@axway.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 11:44:57 +0200
Organization: Axway Software
X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

> For security reasons, you should first sign your message and then encrypt 
it with the recipient's public key. If you
> perform the the reverse operation (encrypt then sign), then a threat 
agent may
> intercept you message, skip your signature and sign "your encrypted" 
message. So the recipient will hence receive a
> signed message from the threat agent and no more from you.

And how can the threat agent do this using the expected private key? And if 
it can't, wouldn't the receving agent have a serious security hole if it 
accepted such a message?

Curiously yours.




Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9L8DXW27117 for ietf-smime-bks; Mon, 21 Oct 2002 01:13:33 -0700 (PDT)
Received: from mail1.belgacom.be (mail1.belgacom.be [195.13.15.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9L8DTW27113 for <ietf-smime@imc.org>; Mon, 21 Oct 2002 01:13:30 -0700 (PDT)
Received: from exhub01.bc (exchange.bc [45.34.4.231]) by mail1.belgacom.be  with SMTP id IAA28023; Mon, 21 Oct 2002 08:13:28 GMT
From: malek.bechlaghem@belgacom.be
Received: from 127.0.0.1 by exhub01.bc (InterScan E-Mail VirusWall NT); Mon, 21 Oct 2002 10:13:27 +0200
Received: by exhub01.bc with Internet Mail Service (5.5.2653.19) id <VKAL17QZ>; Mon, 21 Oct 2002 10:13:27 +0200
Message-ID: <95C94B2F0094D21180710008C75DD6A40B9AB40F@apl541.bc>
To: bernd.matthes@gemplus.com, ietf-smime@imc.org
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 10:13:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Bernd,

For security reasons, you should first sign your message and then encrypt it with the recipient's public key. If you perform the the reverse operation (encrypt then sign), then a threat agent may  
intercept you message, skip your signature and sign "your encrypted" message. So the recipient will hence receive a signed message from the threat agent and no more from you.

malek

___________________________________________________________
Malek Bechlaghem
e-Security Product Development Manager
Tel.: +32 2 202 79 02
Fax: +32 2 202 41 06
E-mail: malek.bechlaghem@belgacom.be



-----Original Message-----
From: Bernd Matthes [mailto:bernd.matthes@gemplus.com]
Sent: 17 October 2002 16:22
To: ietf smime
Cc: Matthias Genkel; Dr. Stephen Henson
Subject: Q: Ordering of encryption and signing of a S/MIME message


Hi to all!

My Question is:
Is it useful a message as first to encrypt and 
then to sign the encrypted result,
in example the encapsulatedData of a pkcs7SignedData structure 
is a pkcs7encrypted data structure?
I know, it's senseless... ;-) but i found nothing in the standards.
Is there any sensible reason against this procedure(i hope so)?

thanks in advance.

with kind regards
-- 
Bernd Matthes                   Gemplus mids GmbH --
Senior Software Engineer    	   formerly Celo Communications GmbH
Dipl.-Ing.(FH)                  R&D Center Germany
--------------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption, lack of" \
"adoption results in death. Death not good." "Life sucks."

**** DISCLAIMER **** 
"This e-mail and any attachments thereto may contain information 
which is confidential and/or protected by intellectual property 
rights and are intended for the sole use of the recipient(s) named above. 
Any use of the information contained herein (including, but not limited to, 
total or partial reproduction, communication or distribution in any form) 
by persons other than the designated recipient(s) is prohibited. 
If you have received this e-mail in error, please notify the sender either 
by telephone or by e-mail and delete the material from any computer. 
Thank you for your cooperation."



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9IMcvN22257 for ietf-smime-bks; Fri, 18 Oct 2002 15:38:57 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9IMcuW22252 for <ietf-smime@imc.org>; Fri, 18 Oct 2002 15:38:56 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with ESMTP ; Fri, 18 Oct 2002 15:38:59 -0700
From: "Blake Ramsdell" <blake@brutesquadlabs.com>
To: "'Antoine Alberti'" <aalberti@axway.com>, <ietf-smime@imc.org>
Subject: RE: encryptCerts
Date: Fri, 18 Oct 2002 15:38:58 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAhCScot1fekiR5rkudgxxswEAAAAA@brutesquadlabs.com>
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.2800.1106
In-Reply-To: <E732E8C298BFCF4194C0B008D920EFEE87EB80@nt102.pa.sopra>
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

> -----Original Message-----
> From: owner-ietf-smime@mail.imc.org 
> [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Antoine Alberti
> Sent: Thursday, October 17, 2002 6:37 AM
> To: 'ietf-smime@imc.org'
> Subject: encryptCerts
> 
> I found the following OID in a SignedData SignedAttribute: 
> 1.2.840.113549.1.9.16.2.13, which appears to be the OID for 
> encryptCerts, 
> as I could see in http://www.imc.org/ietf-smime/sm-oid.asn.
> My problem is I could not find any RFC/draft, or anything 
> reference to this 
> attribute, neither in the standards the working group 
> manages, nor in PKCS 
> #9.
> As 1.2.840.113549.1.9.16 stands for S/MIME, and, I suppose, the .2.13 
> suffix will not be the only one I can't find, can anyone help 
> me to find a 
> description for the encryptCerts field, its meaning, and, if 
> possible, some 
> ideas for finding the other S/MIME extensions I could not 
> find through 
> IETF?

That's a good point.  I just took a quick look at ESS, MSG and CERT and
didn't see it in any obvious way.  I think the intent was to communicate
a hint for encrypting certificate in a signed attribute.

Should this go in -MSG?  I'm making a note of it and will research it
further.

Blake



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9HMUdQ05731 for ietf-smime-bks; Thu, 17 Oct 2002 15:30:39 -0700 (PDT)
Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9HMUcW05727 for <ietf-smime@imc.org>; Thu, 17 Oct 2002 15:30:38 -0700 (PDT)
Received: from DEXTER ([192.168.0.7]) by brutesquadlabs.com with ESMTP ; Thu, 17 Oct 2002 15:30:41 -0700
From: "Blake Ramsdell" <blake@brutesquadlabs.com>
To: <ietf-smime@imc.org>
Subject: The Great nonRepudiation vs. digitalSignature Debate
Date: Thu, 17 Oct 2002 15:30:41 -0700
Message-ID: <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAARMPfbnbp50SwK3EZjypY2MKAAAAQAAAAJ0+6nPDBFUGIth996Sr4AQEAAAAA@brutesquadlabs.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

The use of the digitalSignature and nonRepudiation bits in the key usage
certificate extension are not explicitly covered in the current -CERT.
Where this would go is the rather brilliant language "interpretation and
syntax for all extensions MUST follow [KEYM], unless otherwise specified
here".

However, there has been some concern that the wording in [KEYM] is not
sufficient, and that this should be addressed specifically in -CERT.

1. Which bits should be set for an end-entity certificate used to sign
an S/MIME message?  Is there a difference in this application between
nonRepudiation and digitalSignature, or can the assertion of either be
sufficient to convey the proper signing authority?

2. Which bits should be set in CA certificates?

The current thinking is that if the extension is present, either (or
both) bits MUST be asserted on end-entity certificates when used for a
signature.  If the extension is present in a CA certificate, then either
(or both) bits MUST be asserted also.

I'll be hiding under my bed if anyone needs me.

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



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9HEM3C09210 for ietf-smime-bks; Thu, 17 Oct 2002 07:22:03 -0700 (PDT)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g9HEM1W09206 for <ietf-smime@imc.org>; Thu, 17 Oct 2002 07:22:02 -0700 (PDT)
Message-ID: <3DAEC76D.55EB40F0@gemplus.com>
Date: Thu, 17 Oct 2002 16:21:33 +0200
From: Bernd Matthes <bernd.matthes@gemplus.com>
X-Mailer: Mozilla 4.8 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: ietf smime <ietf-smime@imc.org>
Cc: Matthias Genkel <matthias.genkel@gemplus.com>, "Dr. Stephen Henson" <stephen.henson@gemplus.com>
Subject: Q: Ordering of encryption and signing of a S/MIME message
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms5B1C4365507E44C7B1F65CDB"
X-Virus-Scanned: by AMaViS 20020531 mailhub C
X-Virus-Scanned: by AMaViS 20020531 mailhub B
X-Virus-Scanned: by AMaViS 20020531 mailhub A
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms5B1C4365507E44C7B1F65CDB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi to all!

My Question is:
Is it useful a message as first to encrypt and 
then to sign the encrypted result,
in example the encapsulatedData of a pkcs7SignedData structure 
is a pkcs7encrypted data structure?
I know, it's senseless... ;-) but i found nothing in the standards.
Is there any sensible reason against this procedure(i hope so)?

thanks in advance.

with kind regards
-- 
Bernd Matthes                   Gemplus mids GmbH --
Senior Software Engineer    	   formerly Celo Communications GmbH
Dipl.-Ing.(FH)                  R&D Center Germany
--------------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption, lack of" \
"adoption results in death. Death not good." "Life sucks."
--------------ms5B1C4365507E44C7B1F65CDB
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH+QYJKoZIhvcNAQcCoIIH6jCCB+YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BcwwggKMMIIB9aADAgECAgMHA+kwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjAzMTgxNzIxMzRaFw0wMzAzMTgxNzIxMzRa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANLH
Ug0UXihUAGRuILAJAZhyok9Oj2UG5HcQXVgAK8Q1MJOTs3XKzdimgxdKdl1C6GBj+XUDhyin
6EM0/nrgpIg+abWtjmz1U4XXOhmqDz7qLRP/wu/FZefkM/QRbgrBXZh/NTOr1m0sMThKGTgs
ZCiwc6HebSh43HNgwE74QTHhAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQDK4ZRCCCV5wytZ
NmCxQfoGRljKsUxU4L5gztN0ni6ibvlDeDfg6A2+Hsv5JqhNq1EoujkRAKAry4jcSDY/pI+7
D4zhyMxx4eH+vEIGq3z1Jvukx9Tm/wKGyW504SKWCBo5LI0jMnfydBY7gQd1wyGlRuYDm77f
mzOXD2VfcMy87jCCAzgwggKhoAMCAQICEGZFcrfMdPXPY3ZFhNAukQEwDQYJKoZIhvcNAQEE
BQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNh
cGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmlj
YXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl
bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAe
Fw0wMDA4MzAwMDAwMDBaFw0wNDA4MjcyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UE
CBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEd
MBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVt
YWlsIFJTQSAyMDAwLjguMzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwkl
RT7SbngnZ4HF2ogZgpcO40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx
1t1hpfmFzVWaNRqdknWoJ67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5ud
SWYALQmJ7JRr6aFpAgMBAAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRl
TGFiZWwxLTI5NzASBgNVHRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0B
AQQFAAOBgQAxsUtHXfkBceX1U2xdedY9mMAmE2KBIqcS+CKV6BtJtyd7BDm6/ObyJOuR+r3s
DSo491BVqGz3Da1MG7wD9LXrokefbKIMWI0xQgkRbLAaadErErJAXWr5edDqLiXdiuT82w0f
nQLzWtvKPPZE6iZph39Ins6ln+eE2MliYq0FxjGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQG
EwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNV
BAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1Bl
cnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjguMzACAwcD6TAJBgUrDgMCGgUAoIGxMBgGCSqG
SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMTAxNzE0MjEzNVowIwYJ
KoZIhvcNAQkEMRYEFGlf1Rs7H93UlJgkFSVEF52j0ptDMFIGCSqGSIb3DQEJDzFFMEMwCgYI
KoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqG
SIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAQFuIftL5g6k7FVzuPiCznHhjCo8v9Vsf4FtT
PQL6X+P7HlORWJdC592GNCvgd7+DBl7bmBBTE/SBngwm+OlRWIpNzp58kFhXX+SR/suF6psJ
gmlJYOePdV1H5oXqvxrBBoHFKM+kTpKK5k5rnArhbagratZeFYxIVNgK48Zw8gQ=
--------------ms5B1C4365507E44C7B1F65CDB--



Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9HDaqN07172 for ietf-smime-bks; Thu, 17 Oct 2002 06:36:52 -0700 (PDT)
Received: from sopragroup.com (mailer@smpt1.zpar1.sopragroup.com [213.223.36.98] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g9HDapW07167 for <ietf-smime@imc.org>; Thu, 17 Oct 2002 06:36:51 -0700 (PDT)
Received: (qmail 28109 invoked from network); 17 Oct 2002 13:36:46 -0000
Received: from Antivirus (HELO Antivirus) (Antivirus@Antivirus) by smtp1.sopragroup.com with SMTP; 17 Oct 2002 13:36:46 -0000
Received: by localhost with Microsoft MAPI; Thu, 17 Oct 2002 15:37:00 +0200
Message-ID: <E732E8C298BFCF4194C0B008D920EFEE87EB80@nt102.pa.sopra>
From: Antoine Alberti <aalberti@axway.com>
To: "'ietf-smime@imc.org'" <ietf-smime@imc.org>
Subject: encryptCerts
Date: Thu, 17 Oct 2002 15:36:44 +0200
Organization: Axway Software
X-Mailer: Messagerie Internet de Microsoft/MAPI - 8.0.0.4211
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

I found the following OID in a SignedData SignedAttribute: 
1.2.840.113549.1.9.16.2.13, which appears to be the OID for encryptCerts, 
as I could see in http://www.imc.org/ietf-smime/sm-oid.asn.
My problem is I could not find any RFC/draft, or anything reference to this 
attribute, neither in the standards the working group manages, nor in PKCS 
#9.
As 1.2.840.113549.1.9.16 stands for S/MIME, and, I suppose, the .2.13 
suffix will not be the only one I can't find, can anyone help me to find a 
description for the encryptCerts field, its meaning, and, if possible, some 
ideas for finding the other S/MIME extensions I could not find through 
IETF?

Thanks in advance.

	 
   
	Antoine Alberti			Axway.  a Sopra Group company	
	Tel  : +33 (0)1 47 17 24 37		XFB R&D
	Fax : +33 (0)1 47 17 21 23		26 Rue des Pavillons
	email: aalberti@axway.com		92807 Puteaux Cedex - France






Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g9BKhkG20151 for ietf-smime-bks; Fri, 11 Oct 2002 13:43:46 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g9BKhhv20146 for <ietf-smime@imc.org>; Fri, 11 Oct 2002 13:43:43 -0700 (PDT)
Received: from grover by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Oct 2002 20:44:42 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g9BKnTq05203 for <ietf-smime@imc.org>; Sat, 12 Oct 2002 06:49:30 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <QPRAHCV5>; Sat, 12 Oct 2002 06:41:47 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.16]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV0T46; Fri, 11 Oct 2002 16:43:24 -0400
Message-Id: <5.1.0.14.2.20021011160518.0347ca28@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 11 Oct 2002 16:06:40 -0400
To: ietf-smime@imc.org
From: "Housley, Russ" <rhousley@rsasecurity.com>
Subject: S/MIME Agenda for Atlanta
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

Dear S/MIME WG:

It is time to put together the agenda for the two hour time slot that we 
have in Atlanta.  Please send me a message if you want to make a 
presentation or lead a discussion.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g97F5D908009 for ietf-smime-bks; Mon, 7 Oct 2002 08:05:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (mail.rsasecurity.com [204.167.114.123]) by above.proper.com (8.11.6/8.11.3) with SMTP id g97F5Bv08002 for <ietf-smime@imc.org>; Mon, 7 Oct 2002 08:05:11 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 7 Oct 2002 15:05:13 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 LAA25953 for <ietf-smime@imc.org>; Mon, 7 Oct 2002 11:05:12 -0400 (EDT)
Received: from exno02.eu.rsa.net (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.10.2) with ESMTP id g97F2f905485 for <ietf-smime@imc.org>; Mon, 7 Oct 2002 11:02:41 -0400 (EDT)
Received: by exno02.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <3KDZ7LWC>; Mon, 7 Oct 2002 17:08:52 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.9.22]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 3TPV8G4X; Mon, 7 Oct 2002 11:05:01 -0400
Message-Id: <5.1.0.14.2.20021007110209.033788d8@exna07.securitydynamics.com>
X-Sender: rhousley@exna07.securitydynamics.com
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 07 Oct 2002 11:04:56 -0400
To: ietf-smime@imc.org
From: "Housley, Russ" <rhousley@rsasecurity.com>
Subject: Error in RFC 3369
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

There is an error in Section 12.2, the ASN.1 module for version 1 attribute 
certificates.  The tagging should be EXPLICIT instead of IMPLICIT.

Russ


Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id g91NgCR10283 for ietf-smime-bks; Tue, 1 Oct 2002 16:42:12 -0700 (PDT)
Received: from gamma.isi.edu (gamma.isi.edu [128.9.144.145]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g91NgBv10278 for <ietf-smime@imc.org>; Tue, 1 Oct 2002 16:42:11 -0700 (PDT)
Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id g91NgCD13755; Tue, 1 Oct 2002 16:42:12 -0700 (PDT)
Message-Id: <200210012342.g91NgCD13755@gamma.isi.edu>
To: IETF-Announce: ;
Subject: RFC 3394 on Advanced Encryption Standard (AES) Key Wrap Algorithm
Cc: rfc-editor@rfc-editor.org, ietf-smime@imc.org
From: rfc-editor@rfc-editor.org
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary=NextPart
Date: Tue, 01 Oct 2002 16:42:12 -0700
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>

--NextPart


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


        RFC 3394

        Title:      Advanced Encryption Standard (AES) Key Wrap
                    Algorithm
        Author(s):  J. Schaad, R. Housley
        Status:     Informational
        Date:       September 2002
        Mailbox:    jimsch@exmsft.com, rhousley@rsasecurity.com
        Pages:      40
        Characters: 73072
        Updates/Obsoletes/SeeAlso:    None
                                                          
        I-D Tag:    draft-ietf-smime-aes-keywrap-00.txt

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


The purpose of this document is to make the Advanced Encryption
Standard (AES) Key Wrap algorithm conveniently available to the
Internet community.  The United States of America has adopted AES
as the new encryption standard.  The AES Key Wrap algorithm will
probably be adopted by the USA for encryption of AES keys.
The authors took most of the text in this document from the draft
AES Key Wrap posted by NIST.

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

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

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST@IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info@RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

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


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

...

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

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

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="RFC-INFO@RFC-EDITOR.ORG"

Content-Type: text/plain
Content-ID: <021001163900.RFC@RFC-EDITOR.ORG>

RETRIEVE: rfc
DOC-ID: rfc3394

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

Content-Type: text/plain
Content-ID: <021001163900.RFC@RFC-EDITOR.ORG>

--OtherAccess--
--NextPart--