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> </DIV> <DIV> I've detected the follow strange behaviour = with=20 Outlook Express (and maybe all e-mail applications) and ciphered = messages with=20 key public certificates (KPC):</DIV> <DIV> </DIV> <DIV> 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 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> </DIV> <DIV>I think the problem is that the message is locally = ciphered=20 in the host, and then this ciphered message is = modified when=20 the mail server add the footer. When the client mail = application tries to open it at the destination, it detect that = the=20 original ciphered message was modified and don't show the ciphered = part.</DIV> <DIV> </DIV> <DIV>Am I wrong?</DIV> <DIV> </DIV> <DIV>If I'm rigth I have some questions:</DIV> <DIV> </DIV> <DIV> <DIV>1.- Doesn't the mail client application be able to show the message = ciphered part?. </DIV></DIV> <DIV> </DIV> <DIV>2.- How can I see the message ciphered part.</DIV> <DIV> </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 footer) are=20 incompatibles?</DIV> <DIV> </DIV> <DIV>4.- Is there any way to solve this and to allow all ciphered = messages=20 with footers can be shown in the client mail application?</DIV> <DIV> </DIV> <DIV> </DIV> <DIV>Thanks in advance.</DIV> <DIV> </DIV> <DIV>Best regards.</DIV> <DIV>Miguel A. D=EDaz</DIV> <DIV> </DIV> <DIV> </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"> = <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">> -----Original Message-----</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> To: Housley, Russ; Blake Ramsdell</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> Cc: ietf-smime@imc.org</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> significance. I</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> tied to some</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> good for NR,</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> which case</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> -----Original Message-----</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> To: Blake Ramsdell</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> Cc: ietf-smime@imc.org</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> Blake:</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> recipient of</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> a </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> signed message. Here is my proposal.</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> extension without either the = digitalSignature or </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> nonRepudiation bit</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> set.</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> 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">> 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">> keyUsage certificate = extension.</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> specifies a clear </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> 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">> requirements on these bits.</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> Anyone have other thoughts?</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> Russ</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> 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">> </FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> usage</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> current -CERT.</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >Where this would go is the rather brilliant language = "interpretation</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> and</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> specified</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >here".</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> [KEYM] is not</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> used to sign</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >an S/MIME message? 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">> >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">> either be</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> >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">> used for a</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >signature. 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">> either</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >(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">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> ></FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >Blake</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >--</FONT></SPAN></P> <P ALIGN=3DLEFT><SPAN LANG=3D"en-gb"><FONT SIZE=3D2 FACE=3D"Courier = New">> >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">> </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--
- DRAFT Agenda for S/MIME meeting in Atlanta Housley, Russ