Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UBapr25817 for ietf-smime-bks; Thu, 30 Jan 2003 03:36:51 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UBano25813; Thu, 30 Jan 2003 03:36:50 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0UBakMc018754; Thu, 30 Jan 2003 12:36:46 +0100 (CET) X-Original-Recipient: ietf-smime@imc.org Message-ID: <016801c2c853$837ccc30$0500a8c0@arport> From: "Anders Rundgren" To: "Peter Gutmann" , , References: <200301301028.h0UASqD14780@medusa01.cs.auckland.ac.nz> Subject: Re: Encrypted mail in Limbo Date: Thu, 30 Jan 2003 12:34:12 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Peter, Actually I have some doubts about encrypted mail as a mass- activity in general. It far too complex to handle. DOMSEC would have been much better for the majority of messages. Anyway, in order to aquire encryption keys in a reasonable way from somebody you only have (an hopefully working) e-mail address to, you should be able to search pre-defined places using CertStore or go through DNS. But I don't think that this will be a killer due to the privacy issues, as well as to the fact that the user may have a TTP- issued certificate. Therefore I suggest a number of possible additions: 1. a new URL-type: signed internet mail address (SIMA) 2. a new optional SMTP header: SIMA 3. a new SubjectAltName OtherName: SIMA Then you have three ways of distributing (indirect) keys, automagically in ordinary mail, as explicit URL text in mails etc., and automagically through digitally signed messages. Without any _MAJOR_ improvements in this area, I feel that encryption certificate lookup will never become mainstream exactly in the way as encrypted mail is not today. Anders ----- Original Message ----- From: "Peter Gutmann" To: ; ; ; ; Sent: Thursday, January 30, 2003 11:28 Subject: Re: Encrypted mail in Limbo "Anders Rundgren" writes: >As you probably have noticed, "authenticated" URLs are very common in many >places like for verifying e-mail addresses, often in connection to a certain >registration event. > >In order to use other peoples' public keys for e-mail encryption, I claim >that none of the proposed systems [1] work well except in very local (or very >open) places due to privacy issues [2]. > >The problem is how to distribute "semi-secret" information in a simple way. >It seems like a signed mail-address MIME-type could be required for out-of- >band distribution using a client "click" only. > > 566655fe76adr5fyyeed655:bob@bobcorp.test Oh, I see what you mean now. Hmm, I thought I had something in the text about people using the HTTP-access thing as a static URL to identify a cert, but I can't find any trace of it. What I mean here is that a CA or helpdesk could mail a user their cert URL (say certificates.blah.com/search.cgi?email= luser%40blah.com) and all they have to do is click on it and they're done, rather than hunt around some CA's web pages for it. Since every browser and most mail software can do an HTTP GET, this gets them their cert automatically. What you're proposing could easily go in the implementation notes as another suggested way to do things, it's a nice variation on the mailed-URL idea. Or you could do your own RFC if you preferred that. I assume what you're proposing is that the user gets told to fetch: certificates.blah.com/search.cgi?x-certMAC=qwertyuiop (using the 'x-' extension mechanism) by the CA, and the CA can map that to the required cert, thus providing the privacy/authenticated-URL feature. Or: certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop That's a cool idea, thanks for suggesting it. Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0UAYYw22330 for ietf-smime-bks; Thu, 30 Jan 2003 02:34:34 -0800 (PST) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0UARAo22040; Thu, 30 Jan 2003 02:27:10 -0800 (PST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.60]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id h0UAR5VJ005886; Thu, 30 Jan 2003 23:27:05 +1300 Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h0UASqD14780; Thu, 30 Jan 2003 23:28:52 +1300 Date: Thu, 30 Jan 2003 23:28:52 +1300 Message-Id: <200301301028.h0UASqD14780@medusa01.cs.auckland.ac.nz> From: pgut001@cs.aucKland.ac.nz (Peter Gutmann) To: anders.rundgren@telia.com, ietf-pkix@imc.org, ietf-smime@imc.org, pbaker@verisign.com, pgut001@cs.aucKland.ac.nz Subject: Re: Encrypted mail in Limbo Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Anders Rundgren" writes: >As you probably have noticed, "authenticated" URLs are very common in many >places like for verifying e-mail addresses, often in connection to a certain >registration event. > >In order to use other peoples' public keys for e-mail encryption, I claim >that none of the proposed systems [1] work well except in very local (or very >open) places due to privacy issues [2]. > >The problem is how to distribute "semi-secret" information in a simple way. >It seems like a signed mail-address MIME-type could be required for out-of- >band distribution using a client "click" only. > > 566655fe76adr5fyyeed655:bob@bobcorp.test Oh, I see what you mean now. Hmm, I thought I had something in the text about people using the HTTP-access thing as a static URL to identify a cert, but I can't find any trace of it. What I mean here is that a CA or helpdesk could mail a user their cert URL (say certificates.blah.com/search.cgi?email= luser%40blah.com) and all they have to do is click on it and they're done, rather than hunt around some CA's web pages for it. Since every browser and most mail software can do an HTTP GET, this gets them their cert automatically. What you're proposing could easily go in the implementation notes as another suggested way to do things, it's a nice variation on the mailed-URL idea. Or you could do your own RFC if you preferred that. I assume what you're proposing is that the user gets told to fetch: certificates.blah.com/search.cgi?x-certMAC=qwertyuiop (using the 'x-' extension mechanism) by the CA, and the CA can map that to the required cert, thus providing the privacy/authenticated-URL feature. Or: certificates.blah.com/search.cgi?x-encryptedCertID=qwertyuiop That's a cool idea, thanks for suggesting it. Peter. Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0U9O2x12993 for ietf-smime-bks; Thu, 30 Jan 2003 01:24:02 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0U9Jwo12886; Thu, 30 Jan 2003 01:19:58 -0800 (PST) Received: from arport (h220n2fls31o1122.telia.com [212.181.142.220]) by maile.telia.com (8.12.5/8.12.5) with SMTP id h0U9Jt7n002980; Thu, 30 Jan 2003 10:19:55 +0100 (CET) X-Original-Recipient: ietf-pkix@imc.org Message-ID: <00f401c2c840$6539e3b0$0500a8c0@arport> From: "Anders Rundgren" To: , , "Peter Gutmann" , "Hallam-Baker, Phillip" References: <200301300847.h0U8lvc24242@medusa01.cs.auckland.ac.nz> Subject: Encrypted mail in Limbo Date: Thu, 30 Jan 2003 10:17:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: As you probably have noticed, "authenticated" URLs are very common in many places like for verifying e-mail addresses, often in connection to a certain registration event. In order to use other peoples' public keys for e-mail encryption, I claim that none of the proposed systems [1] work well except in very local (or very open) places due to privacy issues [2]. The problem is how to distribute "semi-secret" information in a simple way. It seems like a signed mail-address MIME-type could be required for out-of-band distribution using a client "click" only. 566655fe76adr5fyyeed655:bob@bobcorp.test Anders R 1] LDAP, XKMS, HTTP CertStore 2] X.500 directories is a bad idea from a privacy point of view. That is, you typically have a limited set of trusted parties that you may need to send encrypted messages to. These partnerships have been established in ad-hoc out-of-band ways. However, to distribute passwords, client certificates for partners to use for accessing your public key would be awfully complicated. "Authenticated" (hmac-signed lookup data) represent a reasonable compromise between security and privacy. Semi-secret data... Or do you think that corporatations will publish keys for anybody to access? I'm doubt they will, except for a few contact "persons" like info@acme.com :-) Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0P56Fb11792 for ietf-smime-bks; Fri, 24 Jan 2003 21:06:15 -0800 (PST) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0P56Eo11787 for ; Fri, 24 Jan 2003 21:06:14 -0800 (PST) Received: from sesione ([12.242.154.153]) by sccrmhc03.attbi.com (sccrmhc03) with SMTP id <200301250506130030008682e>; Sat, 25 Jan 2003 05:06:13 +0000 From: "Khaja Ahmed" To: Subject: S/MIME interoperability tests Date: Fri, 24 Jan 2003 21:07:48 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <5.2.0.9.2.20030123092647.02c1a5c8@mail.binhost.com> Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I am curious about the state of interoperability between clients as regards basic s/mime capabilities like sending clear singed messages. Could some kindly soul direct me to the latest S/MIME interoperability test results? I know NIST had done a while back but not sure if one was done more recently and where the report would be. One document discussing the 'Characteristics that affect interoperability' is more the 4 years old. I suspect things have improved at least a bit since then. Can a simple clear signed message created by any client be processed (1. message understood/parsed successfully and 2. signature verified correctly) by every other major client? Any answers that can separately deal with the message parsing aspect of this vs. the certificate processing part would be great. I'll be grateful for any light that can be shed on this subject. Khaja Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0P01J604327 for ietf-smime-bks; Fri, 24 Jan 2003 16:01:19 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0P01Io04323 for ; Fri, 24 Jan 2003 16:01:18 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05728; Fri, 24 Jan 2003 18:57:50 -0500 (EST) Message-Id: <200301242357.SAA05728@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Wrapping an HMAC key with a Triple-DES Key or an AES Key to Proposed Standard Reply-to: iesg@ietf.org Date: Fri, 24 Jan 2003 18:57:50 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider Wrapping an HMAC key with a Triple-DES Key or an AES Key as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-2-7. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-hmac-key-wrap-00.txt Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0NEXMv10485 for ietf-smime-bks; Thu, 23 Jan 2003 06:33:22 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0NEXLo10480 for ; Thu, 23 Jan 2003 06:33:21 -0800 (PST) Received: (qmail 8606 invoked from network); 23 Jan 2003 14:32:55 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.217.109) by woodstock.binhost.com with SMTP; 23 Jan 2003 14:32:55 -0000 Message-Id: <5.2.0.9.2.20030123092647.02c1a5c8@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 23 Jan 2003 09:30:10 -0500 To: ietf-smime@imc.org, rfc-editor@rfc-editor.org From: Russ Housley 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: List-ID: List-Unsubscribe: RFC 3369 contains the following reference: [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3269, August 2002. The RFC number is incorrect. The correct RFC number is 3370. Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M7jms03171 for ietf-smime-bks; Tue, 21 Jan 2003 23:45:48 -0800 (PST) Received: from mx3.pacifier.net (mx3.pacifier.net [64.255.237.183]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M7jlo03164 for ; Tue, 21 Jan 2003 23:45:47 -0800 (PST) Received: from smtp2.pacifier.net (smtp2 [64.255.237.172]) by mx3.pacifier.net (Postfix) with ESMTP id 9A8F26A86B; Tue, 21 Jan 2003 23:27:43 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 8508D6A436; Tue, 21 Jan 2003 23:45:38 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Elanor Foley'" , Subject: RE: Multiple signers and changing receipt requests Date: Tue, 21 Jan 2003 23:44:38 -0800 Message-ID: <001201c2c1ea$1e1a18d0$0a0000c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C2C1A7.0FFB6CB0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C2C1A7.0FFB6CB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Elanor, Congratulations, I believe you have uncovered a flow in ESS that requires an update to be made to the document. If you have two people signing at the same time, then it would be possible to construct the ReceiptRequest so that it goes to both signers. This means that it could be copied by the second signing operation and the same data would be in both signatures. If you have a mail list agent adding a signing layer, it can use the mlReciptPolicy and modify the requested receipt from the inside. We do not however have an adequate response for the workflow case. That is a person at a later date wants to sign the object and modify the RecieptRequest. This person cannot use a ReceiptRequest attribute since the first person would not know who to include in the receiptRequest (and indeed should not until that person processes the item in the workflow). If the secondary person were to use an mlReceiptPolicy, the receipt would be re-directed properly, however any MLAs or equivalent items would strip the secondary person's signature as the rules state you strip all signature layers with the mlReceiptPolicy attribute. This means that the secondary persons signature would be lost. Is there anyone other than myself that feels this issue needs to be addressed properly? jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Elanor Foley Sent: Tuesday, January 07, 2003 8:39 AM To: 'ietf-smime@imc.org' Subject: Multiple signers and changing receipt requests Hello, As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a SignedData with multiple signers (one signedData with multiple signerInfos). Say one of these signers has included a ReceiptRequest in his signedAttributes. How would another (subsequent) signer also add a ReceiptRequest or modify the existing one? It looks like there is no provision for this. The first signer to request a receipt pre-empts any other signer who may wish a different receipt request. The receipt request itself cannot be modified because it is a signed attribute. Can subsequent signers pretend to be an MLAgent and add a mlReceiptPolicy? Also, I find myself confused by statements in sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by asterisks below ESS 2.1 Signed Receipt Concepts The originator of a message may request a signed receipt from the message's recipients. ESS 2.2 Receipt Request Creation Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo. ESS 2.2.1 Multiple Receipt Requests There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. Each recipient SHOULD return only one signed receipt. /***Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.***/ But ESS 2.3 Receipt Request Processing A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. /***This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.***/ The "different people" are not making different requests? They're just copying the first person's receipt request? Thanks for your help, - Lnr ____________________________________________ Lnr Foley Baltimore Technologies Web: http://www.baltimore.com _____________________________________________ ------=_NextPart_000_0013_01C2C1A7.0FFB6CB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Elanor,
 
Congratulations,  I believe you have uncovered a flow in = ESS that=20 requires an update to be made to the document.
 
If you=20 have two people signing at the same time, then it would be possible to = construct=20 the ReceiptRequest so that it goes to both signers.  This means = that it=20 could be copied by the second signing operation and the same data would = be in=20 both signatures.
 
If you=20 have a mail list agent adding a signing layer, it can use the = mlReciptPolicy and=20 modify the requested receipt from the inside.
 
We do=20 not however have an adequate response for the workflow case.  That = is a=20 person at a later date wants to sign the object and modify the=20 RecieptRequest.  This person cannot use a ReceiptRequest attribute = since=20 the first person would not know who to include in the receiptRequest = (and indeed=20 should not until that person processes the item in the workflow).  = If the=20 secondary person were to use an mlReceiptPolicy, the receipt would be=20 re-directed properly, however any MLAs or equivalent items would strip = the=20 secondary person's signature as the rules state you strip all signature = layers=20 with the mlReceiptPolicy attribute.  This means that the secondary = persons=20 signature would be lost.
 
Is=20 there anyone other than myself that feels this issue needs to be = addressed=20 properly?
 
jim
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Elanor Foley
Sent: Tuesday, January 07, 2003 = 8:39=20 AM
To: 'ietf-smime@imc.org'
Subject: Multiple = signers and=20 changing receipt requests

Hello,
 
As I understand CMS rfc2630 and ESS = rfc2634, it is=20 possible to create a SignedData with multiple signers (one signedData = with=20 multiple signerInfos). Say one of these signers has included a = ReceiptRequest=20 in his signedAttributes. How would another (subsequent) signer also = add a=20 ReceiptRequest or modify the existing = one? It looks like there is no provision for this. The first = signer to=20 request a receipt pre-empts any other signer who may wish a different = receipt=20 request. The receipt request = itself cannot=20 be modified because it is a signed = attribute. Can subsequent=20 signers pretend to be an MLAgent and add a mlReceiptPolicy?
 
Also, I find myself confused by statements = in=20 sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by = asterisks=20 below
ESS 2.1 = Signed=20 Receipt Concepts

   The originator of a message may = request a=20 signed receipt from the
   message's recipients.=20
 
ESS 2.2 = Receipt=20 Request Creation

   = <snip>
Only = one=20 receiptRequest attribute can be included in the
  =20 signedAttributes of a SignerInfo.
ESS = 2.2.1 Multiple=20 Receipt Requests

   There can be multiple SignerInfos = within=20 a SignedData object, and
   each SignerInfo may include=20 signedAttributes. Therefore, a single
   SignedData = object may=20 include multiple SignerInfos, each SignerInfo
   having a = receiptRequest attribute. For example, an originator = can
   send=20 a signed message with two SignerInfos, one containing a = DSS
  =20 signature, the other containing an RSA signature.

   = Each=20 recipient SHOULD return only one signed receipt.

   = /***Not=20 all of the SignerInfos need to include receipt requests, but=20 in
   all of the SignerInfos that do contain receipt = requests,=20 the receipt
   requests MUST be=20 identical.***/
 
 
But
 
ESS 2.3 Receipt Request=20 Processing

   A receiptRequest is associated only = with the=20 SignerInfo object to
   which the receipt request = attribute is=20 directly attached. Receiving
   software SHOULD examine = the=20 signedAttributes field of each of the
   SignerInfos for = which it=20 verifies a signature in the innermost
   signedData = object to=20 determine if a receipt is requested. /***This may
   result in the receiving = agent=20 processing multiple receiptRequest
   attributes included = in a=20 single SignedData object, such as requests
   made from = different=20 people who signed the object in=20 parallel.***/
The = "different people"=20 are not making different requests? They're just copying the first = person's=20 receipt request?
 
Thanks for = your=20 help,
 -=20   =20 Lnr

____________________________________________
Lnr=20 Foley 
Baltimore Technologies
Web: http://www.baltimore.com=20
_____________________________________________ =


 
------=_NextPart_000_0013_01C2C1A7.0FFB6CB0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M6kOe22947 for ietf-smime-bks; Tue, 21 Jan 2003 22:46:24 -0800 (PST) Received: from mx2.pacifier.net (mx2.pacifier.net [64.255.237.182]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0M6kHo22943 for ; Tue, 21 Jan 2003 22:46:18 -0800 (PST) Received: from smtp4.pacifier.net (smtp4 [64.255.237.174]) by mx2.pacifier.net (Postfix) with ESMTP id 316F26AB6A; Tue, 21 Jan 2003 22:46:22 -0800 (PST) Received: from revelation (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp4.pacifier.net (Postfix) with ESMTP id 1726D6A43D; Tue, 21 Jan 2003 22:30:41 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Ryan Koh'" , Subject: RE: Multiple symmetric algo-encrypted data in single S/MIME message Date: Tue, 21 Jan 2003 22:45:19 -0800 Message-ID: <000801c2c1e1$d524db40$0a0000c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C2C19E.C70321E0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal In-Reply-To: <20030122060231.63832.qmail@web14510.mail.yahoo.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C2C19E.C70321E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Ryan, The current CMS format used by S/MIME allows for only a single algorithm to be used for encrypting the content. While there are several different ways around this, the only ones that I consider to be practical are to either 1) send two messages as you presently do or 2) install a Domain boundry server (ala RFC 3183) to change the build encryption algorithm. jim -----Original Message----- From: owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] On Behalf Of Ryan Koh Sent: Tuesday, January 21, 2003 10:03 PM To: ietf-smime@imc.org Subject: Multiple symmetric algo-encrypted data in single S/MIME message Hi My organisation users need to communicate with 2 groups of users, on different S/MIME secure mail systems. The problem lies in them using different symmetric algorithms for data encryption. I am assessing possibility of building a single mail client to compose and send S/MIME messages to selected users on both nets, at the same time (i.e. at one sending operation). This means that there would logically be 2 sets of encrypted blobs in the S/MIME message sent out, but I am not sure if this is supported in S/MIME format. The easy way out of course is to send out the same mails twice separately, to users of each group, as what we are doing now. This however is neither efficient nor elegant. Any suggestion/recommendation would be greatly appreciated. Thanks Ryan Koh _____ With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs ------=_NextPart_000_0009_01C2C19E.C70321E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Ryan,
 
The=20 current CMS format used by S/MIME allows for only a single algorithm to = be used=20 for encrypting the content.  While there are several different ways = around=20 this, the only ones that I consider to be practical are to either 1) = send two=20 messages as you presently do or 2) install a Domain boundry server (ala = RFC=20 3183) to change the build encryption algorithm.
 
jim
-----Original Message-----
From:=20 owner-ietf-smime@mail.imc.org [mailto:owner-ietf-smime@mail.imc.org] = On=20 Behalf Of Ryan Koh
Sent: Tuesday, January 21, 2003 10:03 = PM
To: ietf-smime@imc.org
Subject: Multiple = symmetric=20 algo-encrypted data in single S/MIME message

Hi

My organisation users need to communicate with 2 groups of users, = on=20 different S/MIME secure mail systems.  The problem lies in them = using=20 different symmetric algorithms for data encryption.  I am = assessing=20 possibility of building a single mail client to compose and send = S/MIME=20 messages to selected users on both nets, at the same time (i.e. at one = sending=20 operation).  This means that there would logically be 2 sets of = encrypted=20 blobs in the S/MIME message sent out, but I am not sure if this is = supported=20 in S/MIME format.

The easy way out of course is to send out the same mails twice = separately,=20 to users of each group, as what we are doing now.  This = however is=20 neither efficient nor elegant.

Any suggestion/recommendation would be greatly appreciated.

Thanks

Ryan Koh


With Yahoo! Mail you can get a bigger mailbox -- = choose a=20 size that fits your = needs
------=_NextPart_000_0009_01C2C19E.C70321E0-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0M62Sm22072 for ietf-smime-bks; Tue, 21 Jan 2003 22:02:28 -0800 (PST) Received: from web14510.mail.yahoo.com (web14510.mail.yahoo.com [216.136.224.169]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0M62Ro22068 for ; Tue, 21 Jan 2003 22:02:27 -0800 (PST) Message-ID: <20030122060231.63832.qmail@web14510.mail.yahoo.com> Received: from [192.169.41.36] by web14510.mail.yahoo.com via HTTP; Wed, 22 Jan 2003 06:02:31 GMT Date: Wed, 22 Jan 2003 06:02:31 +0000 (GMT) From: =?iso-8859-1?q?Ryan=20Koh?= Subject: Multiple symmetric algo-encrypted data in single S/MIME message To: ietf-smime@imc.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1176889413-1043215351=:62897" Content-Transfer-Encoding: 8bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --0-1176889413-1043215351=:62897 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi My organisation users need to communicate with 2 groups of users, on different S/MIME secure mail systems. The problem lies in them using different symmetric algorithms for data encryption. I am assessing possibility of building a single mail client to compose and send S/MIME messages to selected users on both nets, at the same time (i.e. at one sending operation). This means that there would logically be 2 sets of encrypted blobs in the S/MIME message sent out, but I am not sure if this is supported in S/MIME format. The easy way out of course is to send out the same mails twice separately, to users of each group, as what we are doing now. This however is neither efficient nor elegant. Any suggestion/recommendation would be greatly appreciated. Thanks Ryan Koh --------------------------------- With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs --0-1176889413-1043215351=:62897 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

Hi

My organisation users need to communicate with 2 groups of users, on different S/MIME secure mail systems.  The problem lies in them using different symmetric algorithms for data encryption.  I am assessing possibility of building a single mail client to compose and send S/MIME messages to selected users on both nets, at the same time (i.e. at one sending operation).  This means that there would logically be 2 sets of encrypted blobs in the S/MIME message sent out, but I am not sure if this is supported in S/MIME format.

The easy way out of course is to send out the same mails twice separately, to users of each group, as what we are doing now.  This however is neither efficient nor elegant.

Any suggestion/recommendation would be greatly appreciated.

Thanks

Ryan Koh


With Yahoo! Mail you can get a bigger mailbox -- choose a size that fits your needs
--0-1176889413-1043215351=:62897-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KJgIb24873 for ietf-smime-bks; Mon, 20 Jan 2003 11:42:18 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0KJgHo24868 for ; Mon, 20 Jan 2003 11:42:17 -0800 (PST) Received: (qmail 28708 invoked from network); 20 Jan 2003 19:41:52 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.184.18) by woodstock.binhost.com with SMTP; 20 Jan 2003 19:41:52 -0000 Message-Id: <5.2.0.9.2.20030120144009.028ea570@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 20 Jan 2003 14:42:15 -0500 To: smb@research.att.com, jis@mit.edu From: Russ Housley Subject: draft-ietf-smime-aes-alg-06.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The S/MIME WG is finished with this document, and we believe that it is ready for IETF-wide Last Call and subsequent publication as a standards-track RFC. Title : Use of the AES Encryption Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-aes-alg-06.txt Pages : 12 Date : 2003-1-17 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt Thanks, Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0KCpUm07444 for ietf-smime-bks; Mon, 20 Jan 2003 04:51:30 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0KCpRo07439 for ; Mon, 20 Jan 2003 04:51:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA18148; Mon, 20 Jan 2003 07:48:01 -0500 (EST) Message-Id: <200301201248.HAA18148@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-aes-alg-06.txt Date: Mon, 20 Jan 2003 07:48:00 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the AES Encryption Algorithm in CMS Author(s) : J. Schaad Filename : draft-ietf-smime-aes-alg-06.txt Pages : 12 Date : 2003-1-17 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-aes-alg-06.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-ietf-smime-aes-alg-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-17121523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-17121523.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0HCQxa06988 for ietf-smime-bks; Fri, 17 Jan 2003 04:26:59 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0HCQwo06984 for ; Fri, 17 Jan 2003 04:26:58 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19439; Fri, 17 Jan 2003 07:23:35 -0500 (EST) Message-Id: <200301171223.HAA19439@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-rfc2633bis-03.txt Date: Fri, 17 Jan 2003 07:23:35 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Version 3.1 Message Specification Author(s) : B. Ramsdell Filename : draft-ietf-smime-rfc2633bis-03.txt Pages : 0 Date : 2003-1-16 S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a consistent way to send and receive secure MIME data. Based on the popular Internet MIME standard, S/MIME provides the following cryptographic security services for electronic messaging applications: authentication, message integrity and non-repudiation of origin (using digital signatures) and data confidentiality (using encryption). S/MIME can be used by traditional mail user agents (MUAs) to add cryptographic security services to mail that is sent, and to interpret cryptographic security services in mail that is received. However, S/MIME is not restricted to mail; it can be used with any transport mechanism that transports MIME data, such as HTTP. As such, S/MIME takes advantage of the object-based features of MIME and allows secure messages to be exchanged in mixed-transport systems. Further, S/MIME can be used in automated message transfer agents that use cryptographic security services that do not require any human intervention, such as the signing of software-generated documents and the encryption of FAX messages sent over the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2633bis-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-rfc2633bis-03.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-ietf-smime-rfc2633bis-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-16122703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-rfc2633bis-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-rfc2633bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-16122703.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FGDr616418 for ietf-smime-bks; Wed, 15 Jan 2003 08:13:53 -0800 (PST) Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FGDpo16408 for ; Wed, 15 Jan 2003 08:13:51 -0800 (PST) Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Wed, 15 Jan 2003 10:56:43 -0500 Message-ID: <3E2584B9.1020608@ieca.com> Date: Wed, 15 Jan 2003 10:56:41 -0500 From: "Sean P. Turner" Organization: IECA, Inc. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20021120 Netscape/7.01 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-smime@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-symkeydist-09.txt References: <200301151258.HAA24482@ietf.org> Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All,

The changes to this draft were making transactionId, senderNonce, and recipientNonce mandtory for origination and reception by the GLA.  CMC and this spec both said they had to be returned if included in a request by the server, which makes them mandatory.  This just wasn't reflected in the attribute conformance table.

spt

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

	Title		: CMS Symmetric Key Management and Distribution
	Author(s)	: S. Turner
	Filename	: draft-ietf-smime-symkeydist-09.txt
	Pages		: 81
	Date		: 2003-1-14
	
This document describes a mechanism to manage (i.e., setup,
distribute, and rekey) keys used with symmetric cryptographic
algorithms. Also defined herein is a mechanism to organize users
into groups to support distribution of encrypted content using
symmetric cryptographic algorithms. The mechanisms use the
Cryptographic Message Syntax (CMS) protocol [2] and Certificate
Management Message over CMS (CMC) protocol [3] to manage the
symmetric keys. Any member of the group can then later use this
distributed shared key to decrypt other CMS encrypted objects with
the symmetric key. This mechanism has been developed to support
S/MIME Mail List Agents (MLAs).

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

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

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-smime-symkeydist-09.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-ietf-smime-symkeydist-09.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.

Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0FD2Hh05710 for ietf-smime-bks; Wed, 15 Jan 2003 05:02:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h0FD2Go05706 for ; Wed, 15 Jan 2003 05:02:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24482; Wed, 15 Jan 2003 07:58:54 -0500 (EST) Message-Id: <200301151258.HAA24482@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-09.txt Date: Wed, 15 Jan 2003 07:58:53 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS Symmetric Key Management and Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-09.txt Pages : 81 Date : 2003-1-14 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. Also defined herein is a mechanism to organize users into groups to support distribution of encrypted content using symmetric cryptographic algorithms. The mechanisms use the Cryptographic Message Syntax (CMS) protocol [2] and Certificate Management Message over CMS (CMC) protocol [3] to manage the symmetric keys. Any member of the group can then later use this distributed shared key to decrypt other CMS encrypted objects with the symmetric key. This mechanism has been developed to support S/MIME Mail List Agents (MLAs). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-symkeydist-09.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-09.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-ietf-smime-symkeydist-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-1-14151129.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-1-14151129.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h0AJCPv18465 for ietf-smime-bks; Fri, 10 Jan 2003 11:12:25 -0800 (PST) Received: from woodstock.binhost.com (woodstock.binhost.com [207.228.252.5]) by above.proper.com (8.11.6/8.11.3) with SMTP id h0AJCOo18461 for ; Fri, 10 Jan 2003 11:12:24 -0800 (PST) Received: (qmail 10468 invoked from network); 10 Jan 2003 19:12:03 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.178.141) by woodstock.binhost.com with SMTP; 10 Jan 2003 19:12:03 -0000 Message-Id: <5.2.0.9.2.20030110140028.00b82a70@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 10 Jan 2003 14:11:40 -0500 To: Elanor Foley , ietf-smime@imc.org From: Russ Housley Subject: Re: Multiple signers and changing receipt requests In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Elanor: First, I want to point out that RFC 2630 has been superceded by RFC 3369. >As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a >SignedData with multiple signers (one signedData with multiple signerInfos). >Say one of these signers has included a ReceiptRequest in his >signedAttributes. How would another (subsequent) signer also add a >ReceiptRequest or modify the existing one? It looks like there is no >provision for this. The first signer to request a receipt pre-empts any >other signer who may wish a different receipt request. The receipt request >itself cannot be modified because it is a signed attribute. Can subsequent >signers pretend to be an MLAgent and add a mlReceiptPolicy? A subsequent signer cannot (and should not be able to) make any change to the information covered by the first signer. So, more information is needed to understand the context of your question. By reading between the lines, it appears that all of the signatures are not equal in your application. That being the case, you might consider countersignatures or further nesting (SignedData encapsulating another SignedData). >Also, I find myself confused by statements in sections 2.2.1 and 2.3 from >the ESS rfc. These are highlighted by asterisks below >ESS 2.1 Signed Receipt Concepts > >The originator of a message may request a signed receipt from the >message's recipients. >ESS 2.2 Receipt Request Creation > > >Only one receiptRequest attribute can be included in the >signedAttributes of a SignerInfo. >ESS 2.2.1 Multiple Receipt Requests > >There can be multiple SignerInfos within a SignedData object, and >each SignerInfo may include signedAttributes. Therefore, a single >SignedData object may include multiple SignerInfos, each SignerInfo >having a receiptRequest attribute. For example, an originator can >send a signed message with two SignerInfos, one containing a DSS >signature, the other containing an RSA signature. > >Each recipient SHOULD return only one signed receipt. > >/***Not all of the SignerInfos need to include receipt requests, but in >all of the SignerInfos that do contain receipt requests, the receipt >requests MUST be identical.***/ This is because clients are expected to process one signerInfo, not all of them. >But >ESS 2.3 Receipt Request Processing > >A receiptRequest is associated only with the SignerInfo object to >which the receipt request attribute is directly attached. Receiving >software SHOULD examine the signedAttributes field of each of the >SignerInfos for which it verifies a signature in the innermost >signedData object to determine if a receipt is requested. /***This may >result in the receiving agent processing multiple receiptRequest >attributes included in a single SignedData object, such as requests >made from different people who signed the object in parallel.***/ >The "different people" are not making different requests? They're just >copying the first person's receipt request? You are right this should not happen. The receipt requests MUST be identical. Russ Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07GwwZ09169 for ietf-smime-bks; Tue, 7 Jan 2003 08:58:58 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Gwuo09165 for ; Tue, 7 Jan 2003 08:58:56 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h07GohU30978 for ; Tue, 7 Jan 2003 16:50:43 GMT Received: from ([10.153.25.53]) by Baltimore-FW1; Tue, 07 Jan 2003 16:55:41 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 7 Jan 2003 16:50:31 +0000 Received: from ([10.153.25.10]) by Baltimore-FW1; Tue, 07 Jan 2003 16:55:39 +0000 (GMT) Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA27359 for ; Tue, 7 Jan 2003 16:58:54 GMT Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <49PDM2JM>; Tue, 7 Jan 2003 17:05:36 -0000 Message-ID: From: Elanor Foley To: ietf-smime@imc.org Subject: Multiple signers and changing receipt requests Date: Tue, 7 Jan 2003 16:52:02 -0000 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: List-ID: List-Unsubscribe: Hello, As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a SignedData with multiple signers (one signedData with multiple signerInfos). Say one of these signers has included a ReceiptRequest in his signedAttributes. How would another (subsequent) signer also add a ReceiptRequest or modify the existing one? It looks like there is no provision for this. The first signer to request a receipt pre-empts any other signer who may wish a different receipt request. The receipt request itself cannot be modified because it is a signed attribute. Can subsequent signers pretend to be an MLAgent and add a mlReceiptPolicy? Also, I find myself confused by statements in sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by asterisks below ESS 2.1 Signed Receipt Concepts The originator of a message may request a signed receipt from the message's recipients. ESS 2.2 Receipt Request Creation Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo. ESS 2.2.1 Multiple Receipt Requests There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. Each recipient SHOULD return only one signed receipt. /***Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.***/ But ESS 2.3 Receipt Request Processing A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. /***This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.***/ The "different people" are not making different requests? They're just copying the first person's receipt request? Thanks for your help, - Lnr ____________________________________________ Lnr Foley Baltimore Technologies Web: _____________________________________________ ----------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Gm6U07980 for ietf-smime-bks; Tue, 7 Jan 2003 08:48:06 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Gm5o07974 for ; Tue, 7 Jan 2003 08:48:05 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h07GdqU30675 for ; Tue, 7 Jan 2003 16:39:52 GMT Received: from ([10.153.25.53]) by Baltimore-FW1; Tue, 07 Jan 2003 16:44:50 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 7 Jan 2003 16:39:39 +0000 Received: from ([10.153.25.10]) by Baltimore-FW1; Tue, 07 Jan 2003 16:44:48 +0000 (GMT) Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA27160 for ; Tue, 7 Jan 2003 16:48:03 GMT Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <49PDM2H3>; Tue, 7 Jan 2003 16:54:45 -0000 Message-ID: From: Elanor Foley To: "'ietf-smime@imc.org'" Subject: Recall: Multiple signers and changing receipt requests Date: Tue, 7 Jan 2003 16:41:09 -0000 Expiry-Date: Thu, 9 Jan 2003 16:48:46 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Elanor Foley would like to recall the message, "Multiple signers and changing receipt requests". ----------------------------------------------------------------------------- The information contained in this message is confidential and is intended for the addressee(s) only. If you have received this message in error or there are any problems please notify the originator immediately. The unauthorised use, disclosure, copying or alteration of this message is strictly forbidden. Baltimore Technologies plc will not be liable for direct, special, indirect or consequential damages arising from alteration of the contents of this message by a third party or as a result of any virus being passed on. This footnote confirms that this email message has been swept for Content Security threats, including computer viruses. http://www.baltimore.com Received: (from majordomo@localhost) by above.proper.com (8.11.6/8.11.3) id h07Gjx907731 for ietf-smime-bks; Tue, 7 Jan 2003 08:45:59 -0800 (PST) Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id h07Gjvo07724 for ; Tue, 7 Jan 2003 08:45:58 -0800 (PST) Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id h07GbgU30607 for ; Tue, 7 Jan 2003 16:37:42 GMT Received: from ([10.153.25.53]) by Baltimore-FW1; Tue, 07 Jan 2003 16:42:39 +0000 (GMT) Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Tue, 7 Jan 2003 16:37:29 +0000 Received: from ([10.153.25.10]) by Baltimore-FW1; Tue, 07 Jan 2003 16:42:37 +0000 (GMT) Received: from emeairlbh1.ie.baltimore.com (emeairlbh1.ie.baltimore.com [10.153.25.54]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA27121 for ; Tue, 7 Jan 2003 16:45:52 GMT Received: by emeairlbh1.ie.baltimore.com with Internet Mail Service (5.5.2653.19) id <49PDM2G6>; Tue, 7 Jan 2003 16:52:34 -0000 Message-ID: From: Elanor Foley To: "'ietf-smime@imc.org'" Subject: Multiple signers and changing receipt requests Date: Tue, 7 Jan 2003 16:38:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2B66B.469745B0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2B66B.469745B0 Content-Type: text/plain; charset="iso-8859-1" Hello, As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a SignedData with multiple signers (one signedData with multiple signerInfos). Say one of these signers has included a ReceiptRequest in his signedAttributes. How would another (subsequent) signer also add a ReceiptRequest or modify the existing one? It looks like there is no provision for this. The first signer to request a receipt pre-empts any other signer who may wish a different receipt request. The receipt request itself cannot be modified because it is a signed attribute. Can subsequent signers pretend to be an MLAgent and add a mlReceiptPolicy? Also, I find myself confused by statements in sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by asterisks below ESS 2.1 Signed Receipt Concepts The originator of a message may request a signed receipt from the message's recipients. ESS 2.2 Receipt Request Creation Only one receiptRequest attribute can be included in the signedAttributes of a SignerInfo. ESS 2.2.1 Multiple Receipt Requests There can be multiple SignerInfos within a SignedData object, and each SignerInfo may include signedAttributes. Therefore, a single SignedData object may include multiple SignerInfos, each SignerInfo having a receiptRequest attribute. For example, an originator can send a signed message with two SignerInfos, one containing a DSS signature, the other containing an RSA signature. Each recipient SHOULD return only one signed receipt. /***Not all of the SignerInfos need to include receipt requests, but in all of the SignerInfos that do contain receipt requests, the receipt requests MUST be identical.***/ But ESS 2.3 Receipt Request Processing A receiptRequest is associated only with the SignerInfo object to which the receipt request attribute is directly attached. Receiving software SHOULD examine the signedAttributes field of each of the SignerInfos for which it verifies a signature in the innermost signedData object to determine if a receipt is requested. /***This may result in the receiving agent processing multiple receiptRequest attributes included in a single SignedData object, such as requests made from different people who signed the object in parallel.***/ The "different people" are not making different requests? They're just copying the first person's receipt request? Thanks for your help, - Lnr ____________________________________________ Lnr Foley Baltimore Technologies Web: http://www.baltimore.com _____________________________________________ ------_=_NextPart_001_01C2B66B.469745B0 Content-Type: text/html; charset="iso-8859-1"
Hello,
 
As I understand CMS rfc2630 and ESS rfc2634, it is possible to create a SignedData with multiple signers (one signedData with multiple signerInfos). Say one of these signers has included a ReceiptRequest in his signedAttributes. How would another (subsequent) signer also add a ReceiptRequest or modify the existing one? It looks like there is no provision for this. The first signer to request a receipt pre-empts any other signer who may wish a different receipt request. The receipt request itself cannot be modified because it is a signed attribute. Can subsequent signers pretend to be an MLAgent and add a mlReceiptPolicy?
 
Also, I find myself confused by statements in sections 2.2.1 and 2.3 from the ESS rfc. These are highlighted by asterisks below
ESS 2.1 Signed Receipt Concepts

   The originator of a message may request a signed receipt from the
   message's recipients.
 
ESS 2.2 Receipt Request Creation

   <snip>
Only one receiptRequest attribute can be included in the
   signedAttributes of a SignerInfo.
ESS 2.2.1 Multiple Receipt Requests

   There can be multiple SignerInfos within a SignedData object, and
   each SignerInfo may include signedAttributes. Therefore, a single
   SignedData object may include multiple SignerInfos, each SignerInfo
   having a receiptRequest attribute. For example, an originator can
   send a signed message with two SignerInfos, one containing a DSS
   signature, the other containing an RSA signature.

   Each recipient SHOULD return only one signed receipt.

   /***Not all of the SignerInfos need to include receipt requests, but in
   all of the SignerInfos that do contain receipt requests, the receipt
   requests MUST be identical.***/
 
 
But
 
ESS 2.3 Receipt Request Processing

   A receiptRequest is associated only with the SignerInfo object to
   which the receipt request attribute is directly attached. Receiving
   software SHOULD examine the signedAttributes field of each of the
   SignerInfos for which it verifies a signature in the innermost
   signedData object to determine if a receipt is requested. /***This may
   result in the receiving agent processing multiple receiptRequest
   attributes included in a single SignedData object, such as requests
   made from different people who signed the object in parallel.***/
The "different people" are not making different requests? They're just copying the first person's receipt request?
 
Thanks for your help,
 -    Lnr

____________________________________________
Lnr Foley 
Baltimore Technologies
Web: http://www.baltimore.com
_____________________________________________


 
------_=_NextPart_001_01C2B66B.469745B0--