Subject: DRAFT Agenda for S/MIME meeting in Atlanta

From: "Housley, Russ" <[email-masked]>
Date: Thu, 31 Oct 2002 15:41:09 -0500

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

Date: Thu, 31 Oct 2002 15:41:09 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: DRAFT Agenda for S/MIME meeting in Atlanta
Sender: [email-masked]

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

Date: Wed, 30 Oct 2002 10:27:18 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Fwd: I-D ACTION:draft-peterson-sip-smime-aes-00.txt
Sender: [email-masked]

Of interest to this WG.

>To: IETF-Announce: ;
>CC: [email-masked]
>From: [email-masked]
>Reply-to: [email-masked]
>Subject: I-D ACTION:draft-peterson-sip-smime-aes-00.txt
>Date: Wed, 30 Oct 2002 06:19:11 -0500
>Sender: [email-masked]
>
>
>
>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:
>	[email-masked].
>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:[email-masked]?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>

From: [email-masked]
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: RE: delegation attribute within a signed message
Date: Tue, 29 Oct 2002 11:00:30 +0100
Sender: [email-masked]

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:[email-masked]]
Sent: 25 October 2002 16:11
To: [email-masked]
Cc: [email-masked]; 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: [email-masked]
 >
 > 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."

Date: Fri, 25 Oct 2002 16:10:48 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: [email-masked]
CC: [email-masked], S-MIME / IETF <[email-masked]>
Subject: Re: delegation attribute within a signed message
Sender: [email-masked]

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: [email-masked]
 >
 > 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."

Date: Fri, 25 Oct 2002 08:31:31 -0400
From: "David P. Kemp" <[email-masked]>
To: Blake Ramsdell <[email-masked]>
CC: [email-masked]
Subject: Re: Summary of current nonRepudiation situation
Sender: [email-masked]

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

--------------ms1F594D4ADB84370C8F4122ED--

Reply-To: =?Windows-1252?Q?Miguel_Angel_D=EDaz?= <[email-masked]>
From: =?Windows-1252?Q?Miguel_Angel_D=EDaz?= <[email-masked]>
To: "smime List" <[email-masked]>
Cc: "Miguel Angel Morales" <[email-masked]>
Subject: Problems with ciphered e-mail messages
Date: Fri, 25 Oct 2002 12:51:55 +0200
Organization: Consulintel
Sender: [email-masked]

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 [email-masked]

------=_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 [email-masked]</html>

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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: Summary of current nonRepudiation situation
Date: Thu, 24 Oct 2002 18:06:34 -0700
Importance: Normal
Sender: [email-masked]

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 

Content-class: urn:content-classes:message
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Tue, 22 Oct 2002 11:05:30 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Hallam-Baker, Phillip" <[email-masked]>, "Housley, Russ" <[email-masked]>, "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]=20
Sent: Monday, October 21, 2002 2:50 PM
To: Trevor Freeman; Housley, Russ; Blake Ramsdell
Cc: [email-masked]
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:[email-masked]]
> Sent: Monday, October 21, 2002 5:21 PM
> To: Housley, Russ; Blake Ramsdell
> Cc: [email-masked]
> 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:[email-masked]]=20
> Sent: Monday, October 21, 2002 7:02 AM
> To: Blake Ramsdell
> Cc: [email-masked]
> 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:[email-masked]">mailto:[email-masked]</A>]<BR>
Sent: Monday, October 21, 2002 2:50 PM<BR>
To: Trevor Freeman; Housley, Russ; Blake Ramsdell<BR>
Cc: [email-masked]<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:[email-masked]">mailto:[email-masked]=
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: [email-masked]</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:[email-masked]">mailto:[email-masked]<=
/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: [email-masked]</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--

From: "Blake Ramsdell" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 15:16:10 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Housley, Russ
> Sent: Monday, October 21, 2002 4:43 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

From: "Hallam-Baker, Phillip" <[email-masked]>
To: Trevor Freeman <[email-masked]>, "Housley, Russ" <[email-masked]>, Blake Ramsdell <[email-masked]>
Cc: [email-masked]
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Mon, 21 Oct 2002 14:50:16 -0700
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, October 21, 2002 5:21 PM
> To: Housley, Russ; Blake Ramsdell
> Cc: [email-masked]
> 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:[email-masked]] 
> Sent: Monday, October 21, 2002 7:02 AM
> To: Blake Ramsdell
> Cc: [email-masked]
> 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
> 

Content-class: urn:content-classes:message
Subject: RE: The Great nonRepudiation vs. digitalSignature Debate
Date: Mon, 21 Oct 2002 14:21:03 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Housley, Russ" <[email-masked]>, "Blake Ramsdell" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, October 21, 2002 7:02 AM
To: Blake Ramsdell
Cc: [email-masked]
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

From: "Housley, Russ" <[email-masked]>
To: Blake Ramsdell <[email-masked]>
Cc: [email-masked]
Date: Mon, 21 Oct 2002 10:02:06 -0400
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
Sender: [email-masked]

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

Date: Mon, 21 Oct 2002 08:17:04 -0700
From: Aram Perez <[email-masked]>
Subject: Re: The Great nonRepudiation vs. digitalSignature Debate
To: [email-masked]
Sender: [email-masked]

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
> 

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 15:09:12 +0200
Sender: [email-masked]

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:[email-masked]]
Sent: 21 October 2002 11:45
To: [email-masked]'
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."

Date: Mon, 21 Oct 2002 14:33:29 +0200
From: Thomas Hueske <[email-masked]>
To: Antoine Alberti <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, Blake Ramsdell <[email-masked]>
Subject: Re: encryptCerts
Sender: [email-masked]

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: [email-masked]               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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Mon, 21 Oct 2002 07:43:15 -0400
Subject: RE: Ordering of encryption and signing of a S/MIME message
Sender: [email-masked]

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:[email-masked]]
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

From: Antoine Alberti <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 11:44:57 +0200
Organization: Axway Software
Sender: [email-masked]

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

From: [email-masked]
To: [email-masked], [email-masked]
Subject: RE: Ordering of encryption and signing of a S/MIME message
Date: Mon, 21 Oct 2002 10:13:23 +0200
Sender: [email-masked]

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: [email-masked]

-----Original Message-----
From: Bernd Matthes [mailto:[email-masked]]
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."

From: "Blake Ramsdell" <[email-masked]>
To: "'Antoine Alberti'" <[email-masked]>, <[email-masked]>
Subject: RE: encryptCerts
Date: Fri, 18 Oct 2002 15:38:58 -0700
Importance: Normal
Sender: [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Antoine Alberti
> Sent: Thursday, October 17, 2002 6:37 AM
> To: [email-masked]'
> 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

From: "Blake Ramsdell" <[email-masked]>
To: <[email-masked]>
Subject: The Great nonRepudiation vs. digitalSignature Debate
Date: Thu, 17 Oct 2002 15:30:41 -0700
Importance: Normal
Sender: [email-masked]

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 

Date: Thu, 17 Oct 2002 16:21:33 +0200
From: Bernd Matthes <[email-masked]>
To: ietf smime <[email-masked]>
Cc: Matthias Genkel <[email-masked]>, "Dr. Stephen Henson" <[email-masked]>
Subject: Q: Ordering of encryption and signing of a S/MIME message
Sender: [email-masked]

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

--------------ms5B1C4365507E44C7B1F65CDB--

From: Antoine Alberti <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: encryptCerts
Date: Thu, 17 Oct 2002 15:36:44 +0200
Organization: Axway Software
Sender: [email-masked]

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: [email-masked]		92807 Puteaux Cedex - France

Date: Fri, 11 Oct 2002 16:06:40 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: S/MIME Agenda for Atlanta
Sender: [email-masked]

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

Date: Mon, 07 Oct 2002 11:04:56 -0400
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Error in RFC 3369
Sender: [email-masked]

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

To: IETF-Announce: ;
Subject: RFC 3394 on Advanced Encryption Standard (AES) Key Wrap Algorithm
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Tue, 01 Oct 2002 16:42:12 -0700
Sender: [email-masked]

--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:    [email-masked], [email-masked]
        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 [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

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

        To: [email-masked]
        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 [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.echo 
Submissions for Requests for Comments should be sent to
[email-masked].  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="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

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: <[email-masked]>

--OtherAccess--
--NextPart--