From owner-ietf-smime-examples Tue Jul 27 12:02:37 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA29807 for ietf-smime-examples-bks; Tue, 27 Jul 1999 12:02:37 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA29803 for ; Tue, 27 Jul 1999 12:02:35 -0700 (PDT) Message-Id: <4.2.0.58.19990727120302.009dddb0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Jul 1999 12:04:38 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Starting the ietf-smime-examples list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.imc.org Precedence: bulk List-Archive: List-Unsubscribe: Greetings. So, the next step is for people to start sending in examples of keys and certs and objects. Please send these to me directly, so I can encode them and tell the list what we have. I believe that this message will be followed by Andrew Farrell who has a question about some of the key wrapping we have in the current doc. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Tue Jul 27 13:16:09 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id NAA01317 for ietf-smime-examples-bks; Tue, 27 Jul 1999 13:16:09 -0700 (PDT) Received: from puma.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01313 for ; Tue, 27 Jul 1999 13:16:07 -0700 (PDT) Received: by puma.baltimore.ie; id WAA04274; Tue, 27 Jul 1999 22:11:31 +0100 (GMT/IST) Received: from bobcat.baltimore.ie(192.168.20.10) by puma.baltimore.ie via smap (4.1) id xma004267; Tue, 27 Jul 99 22:10:34 +0100 Received: from ocelot.baltimore.ie (IDENT:root@ocelot.baltimore.ie [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id VAA08823 for ; Tue, 27 Jul 1999 21:18:57 +0100 Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id VAA01981 for ; Tue, 27 Jul 1999 21:18:11 +0100 Message-Id: <199907272018.VAA01981@ocelot.baltimore.ie> To: ietf-smime-examples@imc.org Subject: Re: Starting the ietf-smime-examples list In-Reply-To: Your message of "Tue, 27 Jul 1999 12:04:38 PDT." <4.2.0.58.19990727120302.009dddb0@mail.imc.org> Date: Tue, 27 Jul 1999 21:18:11 +0100 From: Andrew Farrell Sender: owner-ietf-smime-examples@imc.imc.org Precedence: bulk List-Archive: List-Unsubscribe: Paul wrote: >Greetings. So, the next step is for people to start sending in examples of >keys and certs and objects. Please send these to me directly, so I can >encode them and tell the list what we have. Unclear: Do you mean the ietf-smime list? Because if so, I'd rather send examples and so on to this list. >I believe that this message will be followed by Andrew Farrell who has >a question about some of the key wrapping we have in the current doc. 'sright. Firstly, I agree with Alexy Shamov's observation that the example in the document only makes sense if the RC2 encryptions are done at 40bit effective length, and note that the results he gets for 128-bit effective length are identical to the ones I mailed around at Oslo (which went to Jim, and Paul, and Bob Colestock, I think). Secondly, these are what I'd consider the relevant references in the S/MIME RFCs: CMS 12.3.1: For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2]. CMS 12.3.3.2: Only 128-bit RC2 keys may be used as key-encryption keys, and they must be used with the RC2ParameterVersion parameter set to 58. CMS 12.6: The key-encryption key is generated by the key agreement algorithm or distributed out of band. For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2]. CMS Security Considerations: When using key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, a message content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms. X942 2.1.4 RC2 effective key lengths are equal to RC2 real key lengths. So, apart from a potentially misleading sentence in the security considerations, I don't see any evidence that the effective length of the RC2 KEK in 12.6.4 can be anything other that 128 bits, in a S/MIME context. Thirdly, I can verify Jim's Triple-DES keywrapping that Russ already verified:) Any thoughts? Andrew. From owner-ietf-smime-examples Tue Jul 27 13:28:53 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA01597 for ietf-smime-examples-bks; Tue, 27 Jul 1999 13:28:53 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01592; Tue, 27 Jul 1999 13:28:49 -0700 (PDT) Message-Id: <4.2.0.58.19990727132910.0234c150@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Jul 1999 13:30:49 -0700 To: Andrew Farrell , ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Triple-wrap exampes (was: Re: Starting the ietf-smime-examples list ) In-Reply-To: <199907272018.VAA01981@ocelot.baltimore.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:18 PM 7/27/1999 +0100, Andrew Farrell wrote: >'sright. Firstly, I agree with Alexy Shamov's observation that the >example in the document only makes sense if the RC2 encryptions are done >at 40bit effective length, and note that the results he gets for >128-bit effective length are identical to the ones I mailed around at >Oslo (which went to Jim, and Paul, and Bob Colestock, I think). From this, I take it that you believe that the examples in the -01 draft are wrong. This is bad, although it is good because we can then use this as an example of doing it wrong. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Tue Jul 27 13:28:54 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA01603 for ietf-smime-examples-bks; Tue, 27 Jul 1999 13:28:54 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA01590; Tue, 27 Jul 1999 13:28:49 -0700 (PDT) Message-Id: <4.2.0.58.19990727132800.02572c90@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 27 Jul 1999 13:29:08 -0700 To: Andrew Farrell , ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: Starting the ietf-smime-examples list In-Reply-To: <199907272018.VAA01981@ocelot.baltimore.ie> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 09:18 PM 7/27/1999 +0100, Andrew Farrell wrote: >Paul wrote: > > >Greetings. So, the next step is for people to start sending in examples of > >keys and certs and objects. Please send these to me directly, so I can > >encode them and tell the list what we have. > >Unclear: Do you mean the ietf-smime list? Because if so, I'd rather send >examples and so on to this list. I mean on this list. Again, the purpose of this list is to vet the actual binary things we put into the draft. Any suggestions such as "let's add an example of foo" should be done on the main ietf-smime list. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Wed Aug 11 13:36:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id NAA16379 for ietf-smime-examples-bks; Wed, 11 Aug 1999 13:36:39 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id NAA16375 for ; Wed, 11 Aug 1999 13:36:38 -0700 (PDT) Message-Id: <4.2.0.58.19990811133053.0097ef00@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 11 Aug 1999 13:35:30 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: First submissions Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi there. Blake Ramsdell was the first to submit potential examples to be used in the examples draft. Please see for links to the binaries that Blake made for the RSA-based certs. If you can analyze Blake's certs, please do so, and comment on this list. If any you have other things to contribute (like DH examples, hmmm?), please start the work on those now. I'm leaving for ten days of vacation with no computer access, so I won't be able to post them until I get back, but you all can start posting some guesses on your own sites and passing them around by hand. Please do *not* mail binaries to this list, given the number of people who are just watching. As soon as I get back, I'll get any other contributions up on the site. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Wed Aug 11 16:08:52 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA18378 for ietf-smime-examples-bks; Wed, 11 Aug 1999 16:08:52 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA18374 for ; Wed, 11 Aug 1999 16:08:51 -0700 (PDT) Message-Id: <4.2.0.58.19990811160633.00b63280@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 11 Aug 1999 16:07:31 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: First submissions In-Reply-To: <4.2.0.58.19990811133053.0097ef00@mail.imc.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I misunderstood Blake when he gave me the certs, and I didn't realize he had used Anderew Farrell's keys. So, I've added the RSA keys that Andrew generated that Blake used on the site as well. Please do check that Andrew's keys are good as well. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Aug 16 12:00:55 1999 Received: by mail.proper.com (8.9.3/8.9.3) id MAA02666 for ietf-smime-examples-bks; Mon, 16 Aug 1999 12:00:55 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id MAA02661 for ; Mon, 16 Aug 1999 12:00:54 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.14) id ; Mon, 16 Aug 1999 11:58:05 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB610B@DINO> From: "Jim Schaad (Exchange)" To: "'Andrew Farrell'" , ietf-smime-examples@imc.org Subject: RE: Starting the ietf-smime-examples list Date: Mon, 16 Aug 1999 11:57:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I agree that the example for RC2 128bit encryption is incorrect. I will verify Andrew's vectors later today. -----Original Message----- From: Andrew Farrell [mailto:afarrell@baltimore.ie] Sent: Tuesday, July 27, 1999 1:18 PM To: ietf-smime-examples@imc.org Subject: Re: Starting the ietf-smime-examples list Paul wrote: >Greetings. So, the next step is for people to start sending in examples of >keys and certs and objects. Please send these to me directly, so I can >encode them and tell the list what we have. Unclear: Do you mean the ietf-smime list? Because if so, I'd rather send examples and so on to this list. >I believe that this message will be followed by Andrew Farrell who has >a question about some of the key wrapping we have in the current doc. 'sright. Firstly, I agree with Alexy Shamov's observation that the example in the document only makes sense if the RC2 encryptions are done at 40bit effective length, and note that the results he gets for 128-bit effective length are identical to the ones I mailed around at Oslo (which went to Jim, and Paul, and Bob Colestock, I think). Secondly, these are what I'd consider the relevant references in the S/MIME RFCs: CMS 12.3.1: For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2]. CMS 12.3.3.2: Only 128-bit RC2 keys may be used as key-encryption keys, and they must be used with the RC2ParameterVersion parameter set to 58. CMS 12.6: The key-encryption key is generated by the key agreement algorithm or distributed out of band. For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2]. CMS Security Considerations: When using key agreement algorithms or previously distributed symmetric key-encryption keys, a key-encryption key is used to encrypt the content-encryption key. If the key-encryption and content-encryption algorithms are different, the effective security is determined by the weaker of the two algorithms. If, for example, a message content is encrypted with 168-bit Triple-DES and the Triple-DES content-encryption key is wrapped with a 40-bit RC2 key, then at most 40 bits of protection is provided. A trivial search to determine the value of the 40-bit RC2 key can recover Triple-DES key, and then the Triple-DES key can be used to decrypt the content. Therefore, implementers must ensure that key-encryption algorithms are as strong or stronger than content-encryption algorithms. X942 2.1.4 RC2 effective key lengths are equal to RC2 real key lengths. So, apart from a potentially misleading sentence in the security considerations, I don't see any evidence that the effective length of the RC2 KEK in 12.6.4 can be anything other that 128 bits, in a S/MIME context. Thirdly, I can verify Jim's Triple-DES keywrapping that Russ already verified:) Any thoughts? Andrew. From owner-ietf-smime-examples Mon Aug 16 15:41:03 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA05810 for ietf-smime-examples-bks; Mon, 16 Aug 1999 15:41:03 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA05806 for ; Mon, 16 Aug 1999 15:41:02 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 15:39:02 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB6114@DINO> From: "Jim Schaad (Exchange)" To: ietf-smime-examples@imc.org Subject: RE: First submissions Date: Mon, 16 Aug 1999 15:39:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I really think that there are two things I would like to change about Carl's certificate. 1. The CN should reflect the algorithm so we don't end up with cn=carl for both the RSA and DSS root certificates. 2. The Key Usage needs to include CRL issuence as well. jim -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Wednesday, August 11, 1999 1:36 PM To: ietf-smime-examples@imc.org Subject: First submissions Hi there. Blake Ramsdell was the first to submit potential examples to be used in the examples draft. Please see for links to the binaries that Blake made for the RSA-based certs. If you can analyze Blake's certs, please do so, and comment on this list. If any you have other things to contribute (like DH examples, hmmm?), please start the work on those now. I'm leaving for ten days of vacation with no computer access, so I won't be able to post them until I get back, but you all can start posting some guesses on your own sites and passing them around by hand. Please do *not* mail binaries to this list, given the number of people who are just watching. As soon as I get back, I'll get any other contributions up on the site. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Aug 16 15:53:39 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA06016 for ietf-smime-examples-bks; Mon, 16 Aug 1999 15:53:39 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id PAA06012 for ; Mon, 16 Aug 1999 15:53:37 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Mon, 16 Aug 99 15:54:02 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 15:54:02 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6D8@mail.deming.com> From: "Blake Ramsdell" To: "'Jim Schaad (Exchange)'" , ietf-smime-examples@imc.org Subject: RE: First submissions Date: Mon, 16 Aug 1999 15:54:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA649009195-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] > Sent: Monday, August 16, 1999 3:39 PM > To: ietf-smime-examples@imc.org > Subject: RE: First submissions > > 1. The CN should reflect the algorithm so we don't end up > with cn=carl for > both the RSA and DSS root certificates. Agree. Recommend that this be changed to CarlRSASelf and CarlDSSSelf. While we're on the subject, should the EE certificates have the full name in the CN also? For instance, cn=AliceRSASignByCarl (currently it is cn=Alice). > 2. The Key Usage needs to include CRL issuence as well. Agree -- just so that we're on the same page, do you agree that it currently indicates that keyCertSign is asserted? I will add cRLSign to the next version. Blake From owner-ietf-smime-examples Mon Aug 16 16:27:50 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA06393 for ietf-smime-examples-bks; Mon, 16 Aug 1999 16:27:50 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA06389 for ; Mon, 16 Aug 1999 16:27:49 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 16:25:49 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB6115@DINO> From: "Jim Schaad (Exchange)" To: "'Blake Ramsdell'" , "Jim Schaad (Exchange)" , ietf-smime-examples@imc.org Subject: RE: First submissions Date: Mon, 16 Aug 1999 16:25:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Blake Ramsdell [mailto:BlakeR@deming.com] > Sent: Monday, August 16, 1999 3:54 PM > To: 'Jim Schaad (Exchange)'; ietf-smime-examples@imc.org > Subject: RE: First submissions > > > > -----Original Message----- > > From: Jim Schaad (Exchange) [mailto:jimsch@EXCHANGE.MICROSOFT.com] > > Sent: Monday, August 16, 1999 3:39 PM > > To: ietf-smime-examples@imc.org > > Subject: RE: First submissions > > > > 1. The CN should reflect the algorithm so we don't end up > > with cn=carl for > > both the RSA and DSS root certificates. > > Agree. Recommend that this be changed to CarlRSASelf and CarlDSSSelf. > > While we're on the subject, should the EE certificates have > the full name in > the CN also? For instance, cn=AliceRSASignByCarl (currently it is > cn=Alice). Yes -- I think that both the cn= and the email address in the subject-alt-name should also be changed. > > > 2. The Key Usage needs to include CRL issuence as well. > > Agree -- just so that we're on the same page, do you agree > that it currently > indicates that keyCertSign is asserted? Yes it currently is --- Certificate Signing (04) > > I will add cRLSign to the next version. > > Blake > From owner-ietf-smime-examples Mon Aug 16 17:21:56 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA06906 for ietf-smime-examples-bks; Mon, 16 Aug 1999 17:21:56 -0700 (PDT) Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA06902 for ; Mon, 16 Aug 1999 17:21:54 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 11GX1c-000NYe-0B for ietf-smime-examples@imc.org; Tue, 17 Aug 1999 00:22:48 +0000 Message-ID: <37B8AAD8.A8B2DD67@celocom.com> Date: Tue, 17 Aug 1999 01:20:40 +0100 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win95; U) MIME-Version: 1.0 To: ietf-smime-examples@imc.org Subject: Re: First submissions References: <2FBF98FC7852CF11912A0000000000010ECB6114@DINO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jim Schaad (Exchange) wrote: > > I really think that there are two things I would like to change about Carl's > certificate. > > 1. The CN should reflect the algorithm so we don't end up with cn=carl for > both the RSA and DSS root certificates. > 2. The Key Usage needs to include CRL issuence as well. > Yes I'd agree with that. What are the thoughts about having E-mail protection in extended key usage for the end user certificate examples? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Mon Aug 16 17:32:10 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA07030 for ietf-smime-examples-bks; Mon, 16 Aug 1999 17:32:10 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id RAA07026 for ; Mon, 16 Aug 1999 17:32:10 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Mon, 16 Aug 99 17:32:35 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 17:32:35 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6D9@mail.deming.com> From: "Blake Ramsdell" To: "'Dr Stephen Henson'" , ietf-smime-examples@imc.org Subject: RE: First submissions Date: Mon, 16 Aug 1999 17:32:33 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA672299553-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Dr Stephen Henson [mailto:drh@celocom.com] > Sent: Monday, August 16, 1999 5:21 PM > To: ietf-smime-examples@imc.org > Subject: Re: First submissions > > What are the thoughts about having E-mail protection in extended key > usage for the end user certificate examples? I don't have any objection to this, though I'll say that this is "optional stuff you might find in a cert". It also doesn't necessarily need to be in all of the EE certificates, so it might get left out of the DSS / DH certificates just for variety. If no one objects, then I will include id-kp-emailProtection in an extended key usage field in the RSA EE certificates when I do the next cut. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Mon Aug 16 17:37:06 1999 Received: by mail.proper.com (8.9.3/8.9.3) id RAA07140 for ietf-smime-examples-bks; Mon, 16 Aug 1999 17:37:06 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id RAA07136 for ; Mon, 16 Aug 1999 17:37:05 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id ; Mon, 16 Aug 1999 17:37:22 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB6116@DINO> From: "Jim Schaad (Exchange)" To: "'Dr Stephen Henson'" , ietf-smime-examples@imc.org Subject: RE: First submissions Date: Mon, 16 Aug 1999 17:37:21 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I would just as soon keep the certificates as clean as possible while still matching the 2459 profile. jim -----Original Message----- From: Dr Stephen Henson [mailto:drh@celocom.com] Sent: Monday, August 16, 1999 5:21 PM To: ietf-smime-examples@imc.org Subject: Re: First submissions Jim Schaad (Exchange) wrote: > > I really think that there are two things I would like to change about Carl's > certificate. > > 1. The CN should reflect the algorithm so we don't end up with cn=carl for > both the RSA and DSS root certificates. > 2. The Key Usage needs to include CRL issuence as well. > Yes I'd agree with that. What are the thoughts about having E-mail protection in extended key usage for the end user certificate examples? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Tue Aug 17 14:22:59 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA27111 for ietf-smime-examples-bks; Tue, 17 Aug 1999 14:22:59 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA27107 for ; Tue, 17 Aug 1999 14:22:58 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 17 Aug 99 14:23:27 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Tue, 17 Aug 1999 14:23:27 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6E2@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime-examples@imc.org'" Subject: Sample keys format Date: Tue, 17 Aug 1999 14:23:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA70D4513580-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: I have two questions about the key formats that should be used for the public and private keys. 1. Should the public keys be in RFC2459 SubjectPublicKeyInfo format (that is, the AlgorithmIdentifier followed by BIT STRING wrapping the public key). 2. Should the private keys be in PKCS #8 PrivateKeyInfo format: PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER -- 0 for this PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute The problem that I have (and that I suspect that other people might have) is that the keys need to be in this format in order to "inject" them into my code. Granted it is trivial to add packaging around the keys, I just wanted to see if there was any preference. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Tue Aug 17 14:29:36 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA27155 for ietf-smime-examples-bks; Tue, 17 Aug 1999 14:29:36 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA27151 for ; Tue, 17 Aug 1999 14:29:35 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.14) id ; Tue, 17 Aug 1999 14:30:04 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB6121@DINO> From: "Jim Schaad (Exchange)" To: "'Blake Ramsdell'" , "'ietf-smime-examples@imc.org'" Subject: RE: Sample keys format Date: Tue, 17 Aug 1999 14:29:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Gee -- I have a BIG preference on this agruement. 1. Public keys are in certificates and I don't really need to have a public key by itself as the SubjectPublicKeyInfo format is in the certificate anyway. 2. I want private keys to be in PKCS#12 objects since that is the only way I can deal with them at all, however I think that representing them as PKCS#8 PrivateKeyInfo is fine as this rather directly can feed into a PKCS#12 object. jim -----Original Message----- From: Blake Ramsdell [mailto:BlakeR@deming.com] Sent: Tuesday, August 17, 1999 2:23 PM To: 'ietf-smime-examples@imc.org' Subject: Sample keys format I have two questions about the key formats that should be used for the public and private keys. 1. Should the public keys be in RFC2459 SubjectPublicKeyInfo format (that is, the AlgorithmIdentifier followed by BIT STRING wrapping the public key). 2. Should the private keys be in PKCS #8 PrivateKeyInfo format: PrivateKeyInfo ::= SEQUENCE { version Version, privateKeyAlgorithm PrivateKeyAlgorithmIdentifier, privateKey PrivateKey, attributes [0] IMPLICIT Attributes OPTIONAL } Version ::= INTEGER -- 0 for this PrivateKeyAlgorithmIdentifier ::= AlgorithmIdentifier PrivateKey ::= OCTET STRING Attributes ::= SET OF Attribute The problem that I have (and that I suspect that other people might have) is that the keys need to be in this format in order to "inject" them into my code. Granted it is trivial to add packaging around the keys, I just wanted to see if there was any preference. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Tue Aug 17 14:53:21 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA28167 for ietf-smime-examples-bks; Tue, 17 Aug 1999 14:53:21 -0700 (PDT) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA28153 for ; Tue, 17 Aug 1999 14:53:11 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 11GrB7-000E6k-0A for ietf-smime-examples@imc.org; Tue, 17 Aug 1999 21:53:58 +0000 Message-ID: <37B9D991.F72C0BAF@celocom.com> Date: Tue, 17 Aug 1999 22:52:17 +0100 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win95; U) MIME-Version: 1.0 To: "'ietf-smime-examples@imc.org'" Subject: Re: Sample keys format References: <01FF24001403D011AD7B00A024BC53C563E6E2@mail.deming.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Blake Ramsdell wrote: > > I have two questions about the key formats that should be used for the > public and private keys. > > 1. Should the public keys be in RFC2459 SubjectPublicKeyInfo format (that > is, the AlgorithmIdentifier followed by BIT STRING wrapping the public key). > As with Jim, no preference as long as its in the certificate. > 2. Should the private keys be in PKCS #8 PrivateKeyInfo format: > For DSA and DH is there any other format? For RSA there is PKCS#1 as an alternative. The other problem is whether there is a X9.42 DH private key format specified anywhere at all? There is a fairly obvious extension of PKCS#3 DH PrivateKeyInfo format though. Personally it doesn't matter, I can handle or convert any format. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Tue Aug 17 14:55:16 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA28365 for ietf-smime-examples-bks; Tue, 17 Aug 1999 14:55:16 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA28361 for ; Tue, 17 Aug 1999 14:55:15 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.14) id ; Tue, 17 Aug 1999 14:55:45 -0700 Message-ID: <2FBF98FC7852CF11912A0000000000010ECB6122@DINO> From: "Jim Schaad (Exchange)" To: "'ietf-smime-examples@imc.org'" Subject: RE: Sample keys format Date: Tue, 17 Aug 1999 14:55:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.14) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: One possible X9.42 DH private key format is specified in the CMC draft currently in Last Call. jim -----Original Message----- From: Dr Stephen Henson [mailto:drh@celocom.com] Sent: Tuesday, August 17, 1999 2:52 PM To: 'ietf-smime-examples@imc.org' Subject: Re: Sample keys format Blake Ramsdell wrote: > > I have two questions about the key formats that should be used for the > public and private keys. > > 1. Should the public keys be in RFC2459 SubjectPublicKeyInfo format (that > is, the AlgorithmIdentifier followed by BIT STRING wrapping the public key). > As with Jim, no preference as long as its in the certificate. > 2. Should the private keys be in PKCS #8 PrivateKeyInfo format: > For DSA and DH is there any other format? For RSA there is PKCS#1 as an alternative. The other problem is whether there is a X9.42 DH private key format specified anywhere at all? There is a fairly obvious extension of PKCS#3 DH PrivateKeyInfo format though. Personally it doesn't matter, I can handle or convert any format. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Tue Aug 17 14:58:40 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA28438 for ietf-smime-examples-bks; Tue, 17 Aug 1999 14:58:40 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id OAA28433 for ; Tue, 17 Aug 1999 14:58:39 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 17 Aug 99 14:59:08 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Tue, 17 Aug 1999 14:59:08 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6E4@mail.deming.com> From: "Blake Ramsdell" To: "'Dr Stephen Henson'" , "'ietf-smime-examples@imc.org'" Subject: RE: Sample keys format Date: Tue, 17 Aug 1999 14:59:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA704A613847-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: > -----Original Message----- > From: Dr Stephen Henson [mailto:drh@celocom.com] > Sent: Tuesday, August 17, 1999 2:52 PM > To: 'ietf-smime-examples@imc.org' > Subject: Re: Sample keys format > > Blake Ramsdell wrote: > > > > 1. Should the public keys be in RFC2459 > SubjectPublicKeyInfo format (that > > is, the AlgorithmIdentifier followed by BIT STRING wrapping > the public key). > > > > As with Jim, no preference as long as its in the certificate. I agree. > > 2. Should the private keys be in PKCS #8 PrivateKeyInfo format: > > > > For DSA and DH is there any other format? For RSA there is > PKCS#1 as an > alternative. I actually didn't know much about the "official" private key formats for DSA and DH. The original DSA keys from afarrell had just the bare INTEGER for DSA and the PKCS #1 format for RSA. I personally think that PKCS #8 is the right way to go for everything, but I wonder whether or not we should do something about making this "more formal" (that is, get the PKCS #8 definition into an RFC somewhere). I may be behind the times, and this effort is underway or completed. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Tue Aug 17 16:02:27 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA00129 for ietf-smime-examples-bks; Tue, 17 Aug 1999 16:02:27 -0700 (PDT) Received: from letterbox.cs.auckland.ac.nz (letterbox.cs.auckland.ac.nz [130.216.35.1]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA00125 for ; Tue, 17 Aug 1999 16:02:24 -0700 (PDT) Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by letterbox.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id LAA07744 for ; Wed, 18 Aug 1999 11:03:22 +1200 (sender pgut001@cs.auckland.ac.nz) Received: (from pgut001@localhost) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-slave) id LAA21116 for ietf-smime-examples@imc.org; Wed, 18 Aug 1999 11:03:16 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Date: Wed, 18 Aug 1999 11:03:16 +1200 (NZST) Message-ID: <199908172303.LAA21116@kakapo.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime-examples@imc.org Subject: Re: Sample keys format Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: "Blake Ramsdell" writes: >The problem that I have (and that I suspect that other people might have) is >that the keys need to be in this format in order to "inject" them into my >code. Granted it is trivial to add packaging around the keys, I just wanted >to see if there was any preference. What's probably easiest is to represent them as byte[] + length, it should be possible to tie this into any implementation with a minimum of code. If you use any non-generic format and you end up making it simple for one or two people and really painful for a lot of others. If there was some widely- accepted simple format (the former rules out PKCS #8, the latter PKCS #12) then it'd be better to use that. An RFC specifying PKCS #8 formats for common algorithms (which you currently have to scrape together from PKCS #8, PKCS #11, PKCS #15, and some expired RFC drafts held in a disused toilet in the basement in a box marked "Beware of the leopard") would be useful. I guess I could volunteer for it if pressed. Peter. From owner-ietf-smime-examples Tue Aug 17 16:11:27 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA00230 for ietf-smime-examples-bks; Tue, 17 Aug 1999 16:11:27 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA00224 for ; Tue, 17 Aug 1999 16:11:26 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 17 Aug 99 16:11:55 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Tue, 17 Aug 1999 16:11:55 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6E8@mail.deming.com> From: "Blake Ramsdell" To: "'ietf-smime-examples@imc.org'" cc: "Jim Schaad (E-mail)" Subject: More examples Date: Tue, 17 Aug 1999 16:11:54 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA733B114398-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Jim Schaad has created some more examples. I have put these up at: Please take a look and make any comments. I have also used Peter Gutmann's dumpasn1 program to create text dumps for them, which may make it easier to do a quick once over for the armchair ASN.1 crowd. Any problems with the keys / certs are Jim's fault. Any problems with the HTML is my fault. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Tue Aug 17 16:16:13 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA00302 for ietf-smime-examples-bks; Tue, 17 Aug 1999 16:16:13 -0700 (PDT) Received: from cane.deming.com (mail.deming.com [208.236.41.137]) by mail.proper.com (8.9.3/8.9.3) with SMTP id QAA00297; Tue, 17 Aug 1999 16:16:12 -0700 (PDT) Received: from 208.236.41.137 by cane.deming.com with ESMTP (WorldSecure Server SMTP Relay(WSS) v3.6.2); Tue, 17 Aug 99 16:16:42 -0700 X-Server-Uuid: 1a012586-24e9-11d1-adae-00a024bc53c5 Received: by mail.deming.com with Internet Mail Service (5.5.2232.9) id ; Tue, 17 Aug 1999 16:16:42 -0700 Message-ID: <01FF24001403D011AD7B00A024BC53C563E6E9@mail.deming.com> From: "Blake Ramsdell" To: "Paul E. Hoffman (E-mail)" , "'ietf-smime-examples@imc.org'" Subject: A couple of missing keys Date: Tue, 17 Aug 1999 16:16:41 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) X-WSS-ID: 1BA732D014441-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: The current examples draft does not list DianePrivDHEncrypt or DianePrivDSSSign as private keys in section 3.2. Recommend that these be added. Blake -- Blake C. Ramsdell Worldtalk Corporation For current info, check http://www.deming.com/users/blaker Voice +1 425 376 0225 x103 Fax +1 425 376 0915 From owner-ietf-smime-examples Sat Aug 21 14:49:38 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA22784 for ietf-smime-examples-bks; Sat, 21 Aug 1999 14:49:38 -0700 (PDT) Received: from aum (ip11.proper.com [165.227.249.11]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA22780 for ; Sat, 21 Aug 1999 14:49:36 -0700 (PDT) Message-Id: <4.2.0.58.19990821144708.00b72980@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 21 Aug 1999 14:49:42 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: A couple of missing keys In-Reply-To: <01FF24001403D011AD7B00A024BC53C563E6E9@mail.deming.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 04:16 PM 8/17/1999 -0700, Blake Ramsdell wrote: >The current examples draft does not list DianePrivDHEncrypt or >DianePrivDSSSign as private keys in section 3.2. Recommend that these be >added. Done. OK, I'm back from vacation (which was lovely), and I see y'all did a bit of work. Blake: do you have new certs based on the discussion? Everybody: did you look at the new material Blake announced on Tuesday? Comments? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Thu Aug 26 12:07:27 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id MAA13496 for ietf-smime-examples-bks; Thu, 26 Aug 1999 12:07:27 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id MAA13490 for ; Thu, 26 Aug 1999 12:07:25 -0700 (PDT) Received: id PAA08967; Thu, 26 Aug 1999 15:04:43 -0400 Received: by gateway id ; Thu, 26 Aug 1999 15:07:20 -0400 Message-ID: From: Tom Kung To: "'ietf-smime-examples@imc.org'" Subject: interop testing data Date: Thu, 26 Aug 1999 15:07:10 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEEFF6.38A11D4E" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: 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_000_01BEEFF6.38A11D4E Content-Type: text/plain > Goodays, > > I would like to conduct some interoperability testing with the SMIMEv3 > spec and as such I have attached the following files: > > conInfo.txt > * ContentInfo structure that contains a SignedData item > * SignedData item contains CA, signing and encryption > certificates > * SHA1-RSA digitally signed > attribs.txt > * lists the attributes and its values contained in conInfo.txt > > > Please do not hesitate to contact me if there are any problems with > decoding this file. > > <> <> > > ------_=_NextPart_000_01BEEFF6.38A11D4E Content-Type: text/plain; name="conInfo.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="conInfo.txt" MIINTAYJKoZIhvcNAQcCoIINPTCCDTkCAQExCzAJBgUrDgMCGgUAMCkGCSqGSIb3DQEHAaAcBBpU aGlzIGlzIGEgZHVtbXkgdGVzdCBmaWxlLqCCCPkwggMaMIICg6ADAgECAgQySDF6MA0GCSqGSIb3 DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBE MB4XDTk5MDgxMDE4MTYxOVoXDTAwMDIxMDE4NDYxOVowVDELMAkGA1UEBhMCQ0ExEDAOBgNVBAoT B0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxITAOBgNVBAUTBzFFVFhLMDEwDwYDVQQDEwhUb20g S3VuZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpLWizU7lyBx10WngOvfQoHiKoN+XIdh jOuFzSnCFZVd6eQZTGmXKPgnKo/vJOGgE/2QVTM1CTHNqAyRnbR8AuH3x3p/nnWcAWug4EJBGIk4 vKkbaTNNN0jBUvXnF6HweHMNonQ/XU5v/eguxRHf1LwncRVB9nw342058W577JkCAwEAAaOCARow ggEWMB8GA1UdEQQYMBaBFHRvbS5rdW5nQGVudHJ1c3QuY29tMFMGA1UdHwRMMEowSKBGoESkQjBA MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDENMAsGA1UE AxMEQ1JMODArBgNVHRAEJDAigA8xOTk5MDgxMDE4MTYxOVqBDzE5OTkxMjE3MTMxNjE5WjALBgNV HQ8EBAMCB4AwHwYDVR0jBBgwFoAUWFzTdvBmCxICvAnGYyj6yzb7GLQwHQYDVR0OBBYEFHSJxph3 9WcQgCXWIJy2HniOtsFTMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJ KoZIhvcNAQEFBQADgYEAkDfthodx/rNST9oNB71WxrUdoF/XTBY8Nlg2R5Q/BrzvFDNiZZk/Pi7/ GMKKl9vJqE9n+D62/YksCeUdroWXw4HCs6sfnwgCmto/F3PN3Cwyki9E9IValEnqfjV2DvFFbBAp n/uto7kmGzX5DVh+po7niMjsa38ll0KKAoDjZBUwggLpMIICUqADAgECAgQySCnfMA0GCSqGSIb3 DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBE MB4XDTk5MDYwNzEzMTEwMloXDTk5MTIwNzEzNDEwMlowVDELMAkGA1UEBhMCQ0ExEDAOBgNVBAoT B0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxITAOBgNVBAUTBzFFVFhLMDEwDwYDVQQDEwhUb20g S3VuZzCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAk4JNUYrVZjeorrcxIvkWjJNphcFakp4d ThiKvkaf4bi4R+8lopQrW3FYeITDQRn3DJer/pdblJa5x+eOPXAH842U/iREMGMp5s0bhJE5gVPh irWytLjAyqCh7b/RSRcJC2eet7Dk/EEGS7enJ+Be/iTf/fSAp7oa/VW7qGXZmjcCAQOjgewwgekw HwYDVR0RBBgwFoEUdG9tLmt1bmdAZW50cnVzdC5jb20wUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJ BgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRD Ukw3MAsGA1UdDwQEAwIFIDAfBgNVHSMEGDAWgBRYXNN28GYLEgK8CcZjKPrLNvsYtDAdBgNVHQ4E FgQUuxHvKH3BcR7RgLg8Oi3Xp959WZQwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNC4w AwIEkDANBgkqhkiG9w0BAQUFAAOBgQClRrRHpfTppx2L5N2DG5JT5iaeKp7UjfnjzhXW9MAcMw4V TJscqf4zHo/bmRlLm+nGfVCbsPiasK8JaAuSEHzce6lcharyk1HQDU0Zk1fU5z0YqZD1ps6nfFl6 C/oLzQgQkb2clhCDJXxcmGwcmbtdHQoF2mtbeU04IcRjiZDrMDCCAuowggJToAMCAQICBDJIDggw DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsT B1IgYW5kIEQwHhcNOTgwNTE1MTcxNzEyWhcNMTgwNTE1MTc0NzEyWjAxMQswCQYDVQQGEwJDQTEQ MA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCBnTANBgkqhkiG9w0BAQEFAAOBiwAw gYcCgYEAs54ayHV4JJh8VEoRwl4kcbeJAia+cWfg1bkjFBygDoe0tGKM5Tfql/f+pln2UOSO9Z0U HS0auPKCVcxV/Ah5BFrkrvOc8RzRHUC64FNq+bqbdaLgpVWc6wxHgsVk/9rUNfVKjh7NN5uHC4jB aDfRSZH4m11WOnw9MaEe4c+LEB8CAQOjggEPMIIBCzARBglghkgBhvhCAQEEBAMCAAcwUwYDVR0f BEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdS IGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKADzE5OTgwNTE1MTcxNzEyWoEPMjAxODA1 MTUxNzQ3MTJaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRYXNN28GYLEgK8CcZjKPrLNvsYtDAd BgNVHQ4EFgQUWFzTdvBmCxICvAnGYyj6yzb7GLQwDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAE DDAKGwRWNC4wAwIEkDANBgkqhkiG9w0BAQUFAAOBgQBaUlJ6/LGSqTsuEAW+itNlGggTWd6n8WuC LXXHjM4D3AwQXU8PCwcf9IrRKdvazqirctq/IG55VFgeLq6hbbUNpYSh/nAxhQqpUdsxwzSY8KSy PZPeegeGwi2jTRQfs/vNaPUNKXBCfgpvvhG5xKXmHl4mSqh/BVBLXxWi4uN/yjGCA/0wggP5AgEB MDkwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBDJI MXowCQYFKw4DAhoFAKCCAxowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNOTkwODI2MTU1MzI4WjAjBgkqhkiG9w0BCQQxFgQULOjrwfpE3WawZuDTFUQbeKSFIt0wKAYL KoZIhvcNAQkQAgIxGTEXBgEpAgEBEw9wcml2YWN5TWFyayBPbmUwNwYLKoZIhvcNAQkQAgExKDAm BAChETAPgQ1yZWNlaXB0c0Zyb20xMA8wDYELcmVjZWlwdHNUbzEwQAYBWzE7oDkwMTELMAkGA1UE BhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBDJIKd8wQwYLKoZIhvcN AQkQAgkxNDAyMRcGASkCAQETD3ByaXZhY3lNYXJrIE9uZTEXBgFSAgECEw9wcml2YWN5TWFyayBU d28wRwYLKoZIhvcNAQkQAgcxOAQ2MkgxelRodSBBdWcgMjYgMTE6NTM6MjggMTk5OQpXSytxnAns 3eZfTWnHmED14JX/yrWB2GICMIGMBgsqhkiG9w0BCRACAzF9MHsweTA5MDExCzAJBgNVBAYTAkNB MRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEAgQySDF6GA8xOTk5MDgyNjE1NTMy OFqiKzAPgQ1yZWNlaXB0c0Zyb20xMBiBDXJlY2VpcHRzRnJvbTGBB2luQWRkVG8wgfgGCSqGSIb3 DQEJDzGB6jCB5zAPBgkqhkiG9n0HQgoCAgCAMA4GCSqGSIb2fQdCCgIBKDANBggqhkiG9w0DAgIB OjAOBggqhkiG9w0DAgICAKAwCgYIKoZIhvcNAwcwBwYFKw4DAgcwDQYLKwYBBAGBPAcBAQIwBwYF Kw4DAhowCgYIKoZIhvcNAgUwCwYJKoZIhvcNAQEBMAsGCSqGSIb3DQEBBzAJBgcqhkjOOAQBMAkG ByqGSM49AgEwCwYJKoZIhvcNAQEFMAsGCSqGSIb3DQEBBDAJBgcqhkjOOAQDMAkGByqGSM49BAEw DAYKKoZIhvcNAQkPATANBgkqhkiG9w0BAQEFAASBgG/vSRIYr4QIJ5Jtm3trQIYc8KQbGWTdxkgq XO/3R+QIse6Mn6aDaTWrLH6c9cr7uDxYu0F6jAa8nb0A3gsNhzBBn4Psa0dim6arNPMJtypyFv9w wLpxYtbBhpq9EvYjEHx6hAlt8y3ShWSG8srDsKTq5Q6y68ih34oPLOs9MH1K ------_=_NextPart_000_01BEEFF6.38A11D4E Content-Type: text/plain; name="attribs.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="attribs.txt" Originator: serialNumber=3D1ETXK01+cn=3DTom Kung,ou=3DR and D = o=3DEntrust,c=3DCA =09 Unprotect Sequence Attributes: =09 CONTENTTYPE (oid): 1.2.840.113549.1.7.1 =09 SIGNINGTIME: Thu Aug 26 11:53:28 1999 =09 MESSAGEDIGEST (HEX): 2CE8EBC1FA44DD66B066E0D315441B78A48522DD =09 ESSECURITYLABEL ---- PolicyID: 1.1 ---- PrivacyMark: privacyMark One ---- Classification: 1 =09 RECEIPTREQUEST: -- AllOrFirstTier: -1 -- ReceiptsFrom: =20 ---- (0, 0): 'receiptsFrom1' of type: 1 -- ReceiptsTo: =20 ---- (0, 0): 'receiptsFrom1' of type: 1 ---- (0, 1): 'receiptsTo1' of type: 1 -- Originator Content Identifier (HEX): = 3248317A546875204175672032362031313A35333A323820313939390A574B2B719C09EC= DDE65F4D69C79840F5E095FFCAB581D86202 -- Originator DER Attribs (HEX): = 3182031A301806092A864886F70D010903310B06092A864886F70D010701301C06092A86= 4886F70D010905310F170D3939303832363135353332385A302306092A864886F70D0109= 04311604142CE8EBC1FA44DD66B066E0D315441B78A48522DD3028060B2A864886F70D01= 0910020231193117060129020101130F707269766163794D61726B204F6E653037060B2A= 864886F70D0109100201312830260400A111300F810D726563656970747346726F6D3130= 0F300D810B7265636569707473546F31304006015B313BA0393031310B30090603550406= 130243413110300E060355040A1307456E74727573743110300E060355040B1307522061= 6E6420440204324829DF3043060B2A864886F70D01091002093134303231170601290201= 01130F707269766163794D61726B204F6E653117060152020102130F707269766163794D= 61726B2054776F3047060B2A864886F70D0109100207313804363248317A546875204175= 672032362031313A35333A323820313939390A574B2B719C09ECDDE65F4D69C79840F5E0= 95FFCAB581D8620230818C060B2A864886F70D0109100203317D307B307930393031310B= 30090603550406130243413110300E060355040A1307456E74727573743110300E060355= 040B13075220616E64204402043248317A180F31393939303832363135353332385AA22B= 300F810D726563656970747346726F6D313018810D726563656970747346726F6D318107= 696E416464546F3081F806092A864886F70D01090F3181EA3081E7300F06092A864886F6= 7D07420A02020080300E06092A864886F67D07420A020128300D06082A864886F70D0302= 02013A300E06082A864886F70D0302020200A0300A06082A864886F70D0307300706052B= 0E030207300D060B2B06010401813C07010102300706052B0E03021A300A06082A864886= F70D0205300B06092A864886F70D010101300B06092A864886F70D010107300906072A86= 48CE380401300906072A8648CE3D0201300B06092A864886F70D010105300B06092A8648= 86F70D010104300906072A8648CE380403300906072A8648CE3D0401300C060A2A864886= F70D01090F01 =09 KEYENCRYPTIONPREFERENCE -- Issuer: ou=3DR and D,o=3DEntrust,c=3DCA -- Serial Number: 843590111 =09 EQUIVALENTLABELS -- Label 0: ---- PolicyID: 1.1 ---- PrivacyMark: privacyMark One ---- Classification: 1 -- Label 1: ---- PolicyID: 2.2 ---- PrivacyMark: privacyMark Two ---- Classification: 2 =09 CONTENTIDENTIFIER (HEX): = 3248317A546875204175672032362031313A35333A323820313939390A574B2B719C09EC= DDE65F4D69C79840F5E095FFCAB581D86202 =09 MLEXPANSIONHISTORY: -- Entity: serialNumber=3D1ETXK01+cn=3DTom Kung,ou=3DR and = D,o=3DEntrust,c=3DCA -- Expansion Time: Thu Aug 26 11:53:28 1999 -- In Addition To: ---- AltName: 'receiptsFrom1' of type: 1 ---- AltName: 'receiptsFrom1' of type: 1 ---- AltName: 'inAddTo' of type: 1 SMIMECAPABILITIES (keyLength of -1 means not encoded): -- CapabilityOid: 1.2.840.113533.7.66.10 -- Key Length: 128 -- CapabilityOid: 1.2.840.113533.7.66.10 -- Key Length: 40 -- CapabilityOid: 1.2.840.113549.3.2 -- Key Length: 128 -- CapabilityOid: 1.2.840.113549.3.2 -- Key Length: 40 -- CapabilityOid: 1.2.840.113549.3.7 -- Key Length: -1 -- CapabilityOid: 1.3.14.3.2.7 -- Key Length: -1 -- CapabilityOid: 1.3.6.1.4.1.188.7.1.1.2 -- Key Length: -1 -- CapabilityOid: 1.3.14.3.2.26 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.2.5 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.7 -- Key Length: -1 -- CapabilityOid: 1.2.840.10040.4.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.10045.2.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.5 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.4 -- Key Length: -1 -- CapabilityOid: 1.2.840.10040.4.3 -- Key Length: -1 -- CapabilityOid: 1.2.840.10045.4.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.9.15.1 -- Key Length: -1 ------_=_NextPart_000_01BEEFF6.38A11D4E-- From owner-ietf-smime-examples Thu Aug 26 14:23:57 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA16458 for ietf-smime-examples-bks; Thu, 26 Aug 1999 14:23:57 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16454 for ; Thu, 26 Aug 1999 14:23:56 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id ; Thu, 26 Aug 1999 17:26:46 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31360AE7@WFHQEX03> From: "Pawling, John" To: "'Tom Kung'" , "'ietf-smime-examples@imc.org'" Subject: RE: interop testing data Date: Thu, 26 Aug 1999 17:26:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All, We were able to use the S/MIME Freeware Library (SFL) to verify the signature of Tom's signedData object. We successfully decoded all of the signed attributes described in Tom's attrib.txt file except that we still need to add support in the SFL for the sMIMEEncryptionKeyPreference attribute, so the SFL did not fully decode that attribute (it ignored it). ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc., a Wang Government Services Company jsp@jgvandyke.com ============================================ -----Original Message----- From: Tom Kung [mailto:Tom.Kung@entrust.com] Sent: Thursday, August 26, 1999 3:07 PM To: 'ietf-smime-examples@imc.org' Subject: interop testing data > Goodays, > > I would like to conduct some interoperability testing with the SMIMEv3 > spec and as such I have attached the following files: > > conInfo.txt > * ContentInfo structure that contains a SignedData item > * SignedData item contains CA, signing and encryption > certificates > * SHA1-RSA digitally signed > attribs.txt > * lists the attributes and its values contained in conInfo.txt > > > Please do not hesitate to contact me if there are any problems with > decoding this file. > > <> <> > > From owner-ietf-smime-examples Thu Aug 26 14:34:44 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id OAA16547 for ietf-smime-examples-bks; Thu, 26 Aug 1999 14:34:44 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA16543 for ; Thu, 26 Aug 1999 14:34:42 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id ; Thu, 26 Aug 1999 17:37:32 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31360AE8@WFHQEX03> From: "Pawling, John" To: "'ietf-smime-examples@imc.org'" Subject: SHA1-WITH-DSA SignedData Date: Thu, 26 Aug 1999 17:37:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEF00B.32DD9DE6" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: 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_000_01BEF00B.32DD9DE6 Content-Type: text/plain; charset="iso-8859-1" All, Attached is a signedData object (MIME wrapped (.eml) and just ASN.1 encoded (.out)) produced using the S/MIME Freeware Library. The signedData was hashed using SHA-1 and signed using DSA. It includes a variety of signed attributes. It includes the complete cert path for the signer. The cert path includes the self-signed root (i.e. PAA) certificate which contains the DSA parameters. As stated in RFC 2459, if the DSA parameters are absent from a subject's cert, then the DSA parameters of the issuer's cert are used in conjunction with the subject's public DSA key to verify signatures signed using the subject's private DSA key (i.e. the subject inherits the parameters of the issuer). You can use the signer's DSA public key from the signer's certificate in conjunction with the DSA parameters from the PAA cert to verify the signature of the attached signedData object. We don't normally include the self-signed root in signedData objects that we produce, but it is included here for convenience of the testing. An extra cert (Key Exchange Algorithm) is also included in the signedData. More test messages will follow. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc., a Wang Government Services Company jsp@jgvandyke.com ============================================ ------_=_NextPart_000_01BEF00B.32DD9DE6 Content-Type: application/octet-stream; name="SignedData1.eml" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="SignedData1.eml" MIME-Version: 1.0 Message-Id: <99081616430401.00232@ajpc45.jgvandyke.com> Content-Type: = Application/x-pkcs7-mime;name=3Dsmime.p7m;filename=3Dsmime.p7m; micalg=3D"SHA-1"; protocol=3D"application/x-pkcs7-signature" Date: Mon, 16 Aug 1999 16:43:04 -0400 (Eastern Daylight Time) From: Pierce Leonberger To: Jim Schaad Subject: Fortezza SignedData MIME Wrap test. Content-Transfer-Encoding: base64 Content-Description: attachment;filename=3Dsmime.p7m MIIVjwYJKoZIhvcNAQcCoIIVgDCCFXwCAQExCTAHBgUrDgMCGjBdBgkqhkiG9w0BBwGgUARO= VGhp cyBpcyB0aGUgdGltZSBmb3IgYWxsIGdvb2QgbWVuIChhbmQgd29tZW4pIHRvIGNvbWUgdG8g= dGhl IGFpZCBvZiB0aGUgcGFydHkuoIITXDCCAmYwggIloAMCAQICAgeCMAkGByqGSM44BAMwNTEL= MAkG A1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxETAPBgNVBAMTCFRFU1QgQ0EyMB4XDTk1= MTIz MDIzNTk1OVoXDTA1MDEyODE2MzAzNFowUTELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJ= IFRF U1QxFzAVBgNVBAsTDk1JU1NJIFRFU1QgRE9EMRQwEgYDVQQDEwtUZXN0IFVzZXIgMzCBkzAJ= Bgcq hkjOOAQBA4GFAAKBgQCVwU+CDs3egiCwiIeFcWJ9hNjzZiAlnsF7gGNuGM4ZptwP1/B/jkOo= M2aX hTgNFuQs8q+BS0oUKSplLeQ0XeZUfR+zArpKuDS/dw2KPXtm/RDKoVThLt4Y6ciKUsNz29dl= yohi oH6dwB5EQ9PStk1X+Wn26q6qv6WmIln63JMAY6OBzjCByzATBgNVHSMEDDAKgAgHdgAAAAAA= ADAR BgNVHQ4ECgQIB4IAAAAAAAAwDgYDVR0PAQH/BAQDAgbAMBYGA1UdIAQPMA0wCwYJYIZIAWUC= AQMP MBwGA1UdCQQVMBMwEQYJYIZIAWUCAQU4MQQDAgD/MFsGA1UdHwRUMFIwUIECBWCiSqRIMEYx= CzAJ BgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMSIwIAYDVQQDExlNSVNTSSBURVNUIElD= Ukwg QXV0aG9yaXR5MAkGByqGSM44BAMDMAAwLQIVAI8oJlKBLixvol+yW1XshtE1MQdqAhQhZ+ll= rpjS OvcYhgEMaJ/wIIb8QDCCA1cwggMbAgEAMAsGCWCGSAFlAgEBEzBOMQswCQYDVQQGEwJVUzEh= MB8G A1UEChMYTUlTU0kgVEVTVCBVLlMuIE5hdGlvbmFsMRwwGgYDVQQDExNNSVNTSSBURVNUIFUu= Uy4g UEFBMBoXCzk2MTAxMTE0MjBaFwsyNzEwMDkxMjAwWjBOMQswCQYDVQQGEwJVUzEhMB8GA1UE= ChMY TUlTU0kgVEVTVCBVLlMuIE5hdGlvbmFsMRwwGgYDVQQDExNNSVNTSSBURVNUIFUuUy4gUEFB= MIIC SzCCAS8GCWCGSAFlAgEBFKGCASAwggEcBIGA1DgCxTV71Quhfl1yWWNV00VW6uIlGmvFpKuq= C9Ri tNIhsZWixgHJw/oBb3mGgz0DYeHxkqy8A06Jo8lTSvfipkjPQh4hsVwrOn+6vmta9wom2I4b= 6+y/ Hlo/RcC9MSO+aXGnwpD+pdaAtSTcRJzrTfna8MjookyZB1yONSt9V40EFKeDm/O9LCAH/Ezn= 6J/z OYNRDdzdBIGADjtGMYoKWIZAhOOhIg2IypCIV2SfASHgFQWUJILiEJDZ4U4QXOdUa9QMKxtZ= CqC1 oX21B+NlfOqQ2I4wQuSFu6z6TnZLeA7fbOWm4b1Zd32ml1nFKaezP5U+nfFZLfdCh2I/8bhv= xz1L uI10xMpEkM9n294UYJdK0fdtngmUxA0DggEUAAABAAQAAAAAAAAAAACAgvpXZy5hXo46JMXz= IpT2 1R6oNz9bvzVaP/N8lFJFReOfW/Cree3YsqetoB+eKgjPLTx1Ev9n0nABoP5LLFfDNHKinwe5= WANV 0M4/Ba7+fHn4NKuiLQ33XRwhz/zo3MB1X/lwPxlT+hK4MJY/apUpCZoJygGCpm5yPT20cFJ0= z9MA AjAAgEBp4IFEyqSKu8m3nZsZ2vJUn/lBJ7duo9maFcjIhUMCrIoJkGxDnfcCBDRBj7kvIJOn= WD4n DSJujoEsqvn2ZaoL2p03GUIzhsEARxPokG3VXhwUSkvtI/DAvcxNM4Xrnlfk2S2ud7Ouj3cE= VyFE vDDXhEnVtK9NPhfkRHp2+OR5MAsGCWCGSAFlAgEBEwMpABCxg91AAEenRNgYldRRStmUFfju= Kxrj 8n0DHe+NBZY5tkfZ8hBGwwQwggNbMIIDG6ADAgECAgIHgDAJBgcqhkjOOAQDMDUxCzAJBgNV= BAYT AlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMREwDwYDVQQDEwhURVNUIENBMjAeFw05NTEyMzAy= MzU5 NTlaFw0wNTAxMjgxNjMwMzRaMFExCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNU= MRcw FQYDVQQLEw5NSVNTSSBURVNUIERPRDEUMBIGA1UEAxMLVGVzdCBVc2VyIDEwgZ0wFwYJYIZI= AWUC AQEWBAou9UFudkMXSkRwA4GBAFD8MvGG8ZDAMoME39oRH9LK12r36b4oZZxR92IjyY9CwUXm= vgNN Ue5CaQ1a0kHQwPnfrmmxRVq8qvDv+kpa4Lj+AKSnahvYXlN/STBpPTw4+HUuhqN/vduKT3HR= 0pzI ikuqI0lmDUI5Wv/lzinugymYt46awB6u0PnWRFTKfGJPo4IBuTCCAbUwEwYDVR0jBAwwCoAI= B3YA AAAAAAAwDgYDVR0PAQH/BAQDAgMoMBEGA1UdDgQKBAgHgAAAAAAAADCCAQQGA1UdCQSB/DCB= +TAR BglghkgBZQIBBTgxBAMCAP8wgeMGA1UENzGB2zCB2IAKYIZIAWUCAQwAAYEDAP//ooHEMIHB= gAlg hkgBZQIBCAKhgbMxgbAwGgYMYIZIAWUCAQwAAQACMAqiCAICWE0CAlhOMCIGDGCGSAFlAgEM= AAEA ATASgQIB/qIIAgJYWQICWFqGAgbAMG4GDGCGSAFlAgEMAAEAADBegQUF////4KJQAgJYQQIC= WEIC AlhDAgJYRAICWEUCAlhGAgJYRwICWEgCAlhJAgJYSgICWEsCAlhMAgJYTQICWE4CAlhPAgJY= UAIC WFECAlhSAgJYUwICWFSGAwT/8DAWBgNVHSAEDzANMAsGCWCGSAFlAgEDDzBbBgNVHR8EVDBS= MFCB AgVgokqkSDBGMQswCQYDVQQGEwJVUzETMBEGA1UEChMKTUlTU0kgVEVTVDEiMCAGA1UEAxMZ= TUlT U0kgVEVTVCBJQ1JMIEF1dGhvcml0eTAJBgcqhkjOOAQDAy8AMCwCFCLQsbgk5BCjhy1x//Fl= JCZO QJChAhQ/qAU0eT8Hu6oxyJYqWbky+kySRjCCBIswggRLoAMCAQICAgd2MAkGByqGSM44BAMw= PDEL MAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxGDAWBgNVBAMTD01JU1NJIFRFU1Qg= UENB MjAeFw05NzExMTAyMzU5NTlaFw0wNTAxMjgxNjMwMzRaMDUxCzAJBgNVBAYTAlVTMRMwEQYD= VQQK EwpNSVNTSSBURVNUMREwDwYDVQQDEwhURVNUIENBMjCBkjAJBgcqhkjOOAQBA4GEAAKBgH6C= lOn7 iosLMBZOv8Ou/JXvSfsEQ08QTzlRR+i1YetBzAitMFE84/E6Sk31IjoXvgPqbtcEP6/0e09v= 1pxB nh9U5ZgVlb/akswW+pqvQyOb994BsS2ThKvc9tWfyMz6BthO00FQtbHlJI4IjUEItqQ0nM8K= 2AJJ spsqOepR0t4Oo4IDCTCCAwUwEwYDVR0jBAwwCoAIB3UAAAAAAAAwDgYDVR0PAQH/BAQDAgGG= MBIG A1UdEwEB/wQIMAYBAf8CAQAwEQYDVR0OBAoECAd2AAAAAAAAMIGrBgNVHR4BAf8EgaAwgZ2g= gYUw QqQ9MDsxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMRcwFQYDVQQLEw5NSVNT= SSBU RVNUIERPRIEBCjAppCQwIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1SAAQEw= FKQP MA0xCzAJBgNVBAYTAlVTgAECoRMwEaQPMA0xCzAJBgNVBAYTAlVLMFsGA1UdHwRUMFIwUIEC= BWCi SqRIMEYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMSIwIAYDVQQDExlNSVNT= SSBU RVNUIElDUkwgQXV0aG9yaXR5MDAGA1UdIAQpMCcwCwYJYIZIAWUCAQMPMAsGCWCGSAFlAgED= EDAL BglghkgBZQIBAxEwggF4BgNVHQkEggFvMIIBazCCAVQGCWCGSAFlAgEFPDGCAUUwggFBMIHj= BgNV BDcxgdswgdiACmCGSAFlAgEMAAGBAwD//6KBxDCBwYAJYIZIAWUCAQgCoYGzMYGwMBoGDGCG= SAFl AgEMAAEAAjAKoggCAlhNAgJYTjAiBgxghkgBZQIBDAABAAEwEoECAf6iCAICWFkCAlhahgIG= wDBu BgxghkgBZQIBDAABAAAwXoEFBf///+CiUAICWEECAlhCAgJYQwICWEQCAlhFAgJYRgICWEcC= AlhI AgJYSQICWEoCAlhLAgJYTAICWE0CAlhOAgJYTwICWFACAlhRAgJYUgICWFMCAlhUhgME//Aw= EQYJ YIZIAWUCAQU4MQQDAgD/MCUGCWCGSAFlAgEFNzEYoBYGCWCGSAFlAgEKATAJAgEAAgEDAgEI= MB8G CWCGSAFlAgEFNzESoRAGCWCGSAFlAgEKAjADAgEBMBEGCWCGSAFlAgEFODEEAwIA/zAJBgcq= hkjO OAQDAy8AMCwCFGpsPjrdsUnGzkfRj/YbOA2Am4wcAhQy/VzyF4FAZ1waTavakwQO2EQ8QDCC= BaUw ggVloAMCAQICAgd1MAkGByqGSM44BAMwTjELMAkGA1UEBhMCVVMxITAfBgNVBAoTGE1JU1NJ= IFRF U1QgVS5TLiBOQVRJT05BTDEcMBoGA1UEAxMTTUlTU0kgVEVTVCBVLlMuIFBBQTAeFw05NTEy= MzAy MzU5NTlaFw0wNTAxMjgxNjMwMzRaMDwxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBU= RVNU MRgwFgYDVQQDEw9NSVNTSSBURVNUIFBDQTIwgZIwCQYHKoZIzjgEAQOBhAACgYB+/iFaXw0+= l8O0 EF9yjLFae5Dk/AGGnVRCB/NXlRPSTkj02cHgN8Kvwev5/BwbHSNDhjxXFYwlZEwiv9vQgfYe= T4tU A4Z4WxFrMPNZsJmhnA5P5uytBh+qXFCqKnU9S06V5zJnQmDbf2b0GX7crHSNYiXhMX5mEx13= geqK Y9yAdaOCBAowggQGMBMGA1UdIwQMMAqACAAEAAAAAAAAMA4GA1UdDwEB/wQEAwIBxjAJBgNV= HSQE AjAAMBIGA1UdEwEB/wQIMAYBAf8CAQIwEQYDVR0OBAoECAd1AAAAAAAAMIGrBgNVHR4BAf8E= gaAw gZ2ggYUwQqQ9MDsxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMRcwFQYDVQQL= Ew5N SVNTSSBURVNUIERPRIEBCjAppCQwIjELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRF= U1SA AQEwFKQPMA0xCzAJBgNVBAYTAlVTgAECoRMwEaQPMA0xCzAJBgNVBAYTAlVLMFsGA1UdHwRU= MFIw UIECBWCiSqRIMEYxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMSIwIAYDVQQD= ExlN SVNTSSBURVNUIElDUkwgQXV0aG9yaXR5MDAGA1UdIAQpMCcwCwYJYIZIAWUCAQMPMAsGCWCG= SAFl AgEDEDALBglghkgBZQIBAxEwggJuBgNVHQkEggJlMIICYTAfBglghkgBZQIBBTcxEqAQBglg= hkgB ZQIBCgEwAwIBATARBglghkgBZQIBBTgxBAMCAP8wggIpBglghkgBZQIBBTwxggIaMIICFjCB= 4wYD VQQ3MYHbMIHYgApghkgBZQIBDAABgQMA//+igcQwgcGACWCGSAFlAgEIAqGBszGBsDAaBgxg= hkgB ZQIBDAABAAIwCqIIAgJYTQICWE4wIgYMYIZIAWUCAQwAAQABMBKBAgH+oggCAlhZAgJYWoYC= BsAw bgYMYIZIAWUCAQwAAQAAMF6BBQX////golACAlhBAgJYQgICWEMCAlhEAgJYRQICWEYCAlhH= AgJY SAICWEkCAlhKAgJYSwICWEwCAlhNAgJYTgICWE8CAlhQAgJYUQICWFICAlhTAgJYVIYDBP/w= MIHM BgNVBDcxgcQwgcGACmCGSAFlAgEMAAKBAgF+ooGuMIGrgAlghkgBZQIBCAKhgZ0xgZowIgYM= YIZI AWUCAQwAAgACMBKiDAICUUoCAlFLAgJRTIYCBeAwOAYMYIZIAWUCAQwAAgAAMCiBBAb//8Ci= HAIC WEECAlhCAgJYQwICWEQCAlhFAgJYRgICWEeGAgXgMDoGDGCGSAFlAgEMAAIAATAqgQID+KIg= AgJR QQICUUICAlFDAgJRRAICUUUCAlFGAgJRRwICUUiGAgXgMCgGCWCGSAFlAgEFNzEboBkGCWCG= SAFl AgEKATAMAgEAAgEBAgEDAgEIMCIGCWCGSAFlAgEFNzEVoRMGCWCGSAFlAgEKAjAGAgEBAgEF= MBEG CWCGSAFlAgEFODEEAwIA/zAJBgcqhkjOOAQDAy8AMCwCFBhwe5izGNP1SVIjql2Srzy8N03x= AhR1 L0FVA6bTmhcaOCGwPgGV3uwYlaEAMYIBqTCCAaUCAQEwOzA1MQswCQYDVQQGEwJVUzETMBEG= A1UE ChMKTUlTU0kgVEVTVDERMA8GA1UEAxMIVEVTVCBDQTICAgeCMAcGBSsOAwIaoIIBHTAYBgkq= hkiG 9w0BCQMxCwYJKoZIhvcNAQcBMCMGCSqGSIb3DQEJBDEWBBT/dQJym6ubkFquFTihzFeMuCec= gTBU BgsqhkiG9w0BCRACAjFFMUMCAQEGByoDBAUGBwgxNTAzgAgqAwQFBgeGeKEnEyVCT0IgVEhJ= UyBJ UyBBIFRFU1QgU0VDVVJJVFktQ0FURUdPUlkuMIGFBgsqhkiG9w0BCRACATF2MHQEFklEIEZP= UiBW REEgU0ZMIFNNSU1FIDOAAQAwVzBVpFMwUTELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJ= IFRF U1QxFzAVBgNVBAsTDk1JU1NJIFRFU1QgRE9EMRQwEgYDVQQDEwtUZXN0IFVzZXIgMzAJBgcq= hkjO OAQDBC4wLAIUhGUnSrqg/u2J7E6R6z0EujcIoHUCFGSM6Z/U08Mrsduaz2JNSGGwE7SV ------_=_NextPart_000_01BEF00B.32DD9DE6 Content-Type: application/octet-stream; name="SignedData1.out" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SignedData1.out" MIIVfAIBATEJMAcGBSsOAwIaMF0GCSqGSIb3DQEHAaBQBE5UaGlzIGlzIHRoZSB0aW1lIGZvciBh bGwgZ29vZCBtZW4gKGFuZCB3b21lbikgdG8gY29tZSB0byB0aGUgYWlkIG9mIHRoZSBwYXJ0eS6g ghNcMIICZjCCAiWgAwIBAgICB4IwCQYHKoZIzjgEAzA1MQswCQYDVQQGEwJVUzETMBEGA1UEChMK TUlTU0kgVEVTVDERMA8GA1UEAxMIVEVTVCBDQTIwHhcNOTUxMjMwMjM1OTU5WhcNMDUwMTI4MTYz MDM0WjBRMQswCQYDVQQGEwJVUzETMBEGA1UEChMKTUlTU0kgVEVTVDEXMBUGA1UECxMOTUlTU0kg VEVTVCBET0QxFDASBgNVBAMTC1Rlc3QgVXNlciAzMIGTMAkGByqGSM44BAEDgYUAAoGBAJXBT4IO zd6CILCIh4VxYn2E2PNmICWewXuAY24Yzhmm3A/X8H+OQ6gzZpeFOA0W5Czyr4FLShQpKmUt5DRd 5lR9H7MCukq4NL93DYo9e2b9EMqhVOEu3hjpyIpSw3Pb12XKiGKgfp3AHkRD09K2TVf5afbqrqq/ paYiWfrckwBjo4HOMIHLMBMGA1UdIwQMMAqACAd2AAAAAAAAMBEGA1UdDgQKBAgHggAAAAAAADAO BgNVHQ8BAf8EBAMCBsAwFgYDVR0gBA8wDTALBglghkgBZQIBAw8wHAYDVR0JBBUwEzARBglghkgB ZQIBBTgxBAMCAP8wWwYDVR0fBFQwUjBQgQIFYKJKpEgwRjELMAkGA1UEBhMCVVMxEzARBgNVBAoT Ck1JU1NJIFRFU1QxIjAgBgNVBAMTGU1JU1NJIFRFU1QgSUNSTCBBdXRob3JpdHkwCQYHKoZIzjgE AwMwADAtAhUAjygmUoEuLG+iX7JbVeyG0TUxB2oCFCFn6WWumNI69xiGAQxon/AghvxAMIIDVzCC AxsCAQAwCwYJYIZIAWUCAQETME4xCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhNSVNTSSBURVNUIFUu Uy4gTmF0aW9uYWwxHDAaBgNVBAMTE01JU1NJIFRFU1QgVS5TLiBQQUEwGhcLOTYxMDExMTQyMFoX CzI3MTAwOTEyMDBaME4xCzAJBgNVBAYTAlVTMSEwHwYDVQQKExhNSVNTSSBURVNUIFUuUy4gTmF0 aW9uYWwxHDAaBgNVBAMTE01JU1NJIFRFU1QgVS5TLiBQQUEwggJLMIIBLwYJYIZIAWUCAQEUoYIB IDCCARwEgYDUOALFNXvVC6F+XXJZY1XTRVbq4iUaa8Wkq6oL1GK00iGxlaLGAcnD+gFveYaDPQNh 4fGSrLwDTomjyVNK9+KmSM9CHiGxXCs6f7q+a1r3CibYjhvr7L8eWj9FwL0xI75pcafCkP6l1oC1 JNxEnOtN+drwyOiiTJkHXI41K31XjQQUp4Ob870sIAf8TOfon/M5g1EN3N0EgYAOO0YxigpYhkCE 46EiDYjKkIhXZJ8BIeAVBZQkguIQkNnhThBc51Rr1AwrG1kKoLWhfbUH42V86pDYjjBC5IW7rPpO dkt4Dt9s5abhvVl3faaXWcUpp7M/lT6d8Vkt90KHYj/xuG/HPUu4jXTEykSQz2fb3hRgl0rR922e CZTEDQOCARQAAAEABAAAAAAAAAAAAICC+ldnLmFejjokxfMilPbVHqg3P1u/NVo/83yUUkVF459b 8Kt57diyp62gH54qCM8tPHUS/2fScAGg/kssV8M0cqKfB7lYA1XQzj8Frv58efg0q6ItDfddHCHP /OjcwHVf+XA/GVP6Ergwlj9qlSkJmgnKAYKmbnI9PbRwUnTP0wACMACAQGnggUTKpIq7ybedmxna 8lSf+UEnt26j2ZoVyMiFQwKsigmQbEOd9wIENEGPuS8gk6dYPicNIm6OgSyq+fZlqgvanTcZQjOG wQBHE+iQbdVeHBRKS+0j8MC9zE0zheueV+TZLa53s66PdwRXIUS8MNeESdW0r00+F+REenb45Hkw CwYJYIZIAWUCAQETAykAELGD3UAAR6dE2BiV1FFK2ZQV+O4rGuPyfQMd740Fljm2R9nyEEbDBDCC A1swggMboAMCAQICAgeAMAkGByqGSM44BAMwNTELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJ IFRFU1QxETAPBgNVBAMTCFRFU1QgQ0EyMB4XDTk1MTIzMDIzNTk1OVoXDTA1MDEyODE2MzAzNFow UTELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxFzAVBgNVBAsTDk1JU1NJIFRFU1Qg RE9EMRQwEgYDVQQDEwtUZXN0IFVzZXIgMTCBnTAXBglghkgBZQIBARYECi71QW52QxdKRHADgYEA UPwy8YbxkMAygwTf2hEf0srXavfpvihlnFH3YiPJj0LBRea+A01R7kJpDVrSQdDA+d+uabFFWryq 8O/6SlrguP4ApKdqG9heU39JMGk9PDj4dS6Go3+924pPcdHSnMiKS6ojSWYNQjla/+XOKe6DKZi3 jprAHq7Q+dZEVMp8Yk+jggG5MIIBtTATBgNVHSMEDDAKgAgHdgAAAAAAADAOBgNVHQ8BAf8EBAMC AygwEQYDVR0OBAoECAeAAAAAAAAAMIIBBAYDVR0JBIH8MIH5MBEGCWCGSAFlAgEFODEEAwIA/zCB 4wYDVQQ3MYHbMIHYgApghkgBZQIBDAABgQMA//+igcQwgcGACWCGSAFlAgEIAqGBszGBsDAaBgxg hkgBZQIBDAABAAIwCqIIAgJYTQICWE4wIgYMYIZIAWUCAQwAAQABMBKBAgH+oggCAlhZAgJYWoYC BsAwbgYMYIZIAWUCAQwAAQAAMF6BBQX////golACAlhBAgJYQgICWEMCAlhEAgJYRQICWEYCAlhH AgJYSAICWEkCAlhKAgJYSwICWEwCAlhNAgJYTgICWE8CAlhQAgJYUQICWFICAlhTAgJYVIYDBP/w MBYGA1UdIAQPMA0wCwYJYIZIAWUCAQMPMFsGA1UdHwRUMFIwUIECBWCiSqRIMEYxCzAJBgNVBAYT AlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMSIwIAYDVQQDExlNSVNTSSBURVNUIElDUkwgQXV0aG9y aXR5MAkGByqGSM44BAMDLwAwLAIUItCxuCTkEKOHLXH/8WUkJk5AkKECFD+oBTR5Pwe7qjHIlipZ uTL6TJJGMIIEizCCBEugAwIBAgICB3YwCQYHKoZIzjgEAzA8MQswCQYDVQQGEwJVUzETMBEGA1UE ChMKTUlTU0kgVEVTVDEYMBYGA1UEAxMPTUlTU0kgVEVTVCBQQ0EyMB4XDTk3MTExMDIzNTk1OVoX DTA1MDEyODE2MzAzNFowNTELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxETAPBgNV BAMTCFRFU1QgQ0EyMIGSMAkGByqGSM44BAEDgYQAAoGAfoKU6fuKiwswFk6/w678le9J+wRDTxBP OVFH6LVh60HMCK0wUTzj8TpKTfUiOhe+A+pu1wQ/r/R7T2/WnEGeH1TlmBWVv9qSzBb6mq9DI5v3 3gGxLZOEq9z21Z/IzPoG2E7TQVC1seUkjgiNQQi2pDSczwrYAkmymyo56lHS3g6jggMJMIIDBTAT BgNVHSMEDDAKgAgHdQAAAAAAADAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAR BgNVHQ4ECgQIB3YAAAAAAAAwgasGA1UdHgEB/wSBoDCBnaCBhTBCpD0wOzELMAkGA1UEBhMCVVMx EzARBgNVBAoTCk1JU1NJIFRFU1QxFzAVBgNVBAsTDk1JU1NJIFRFU1QgRE9EgQEKMCmkJDAiMQsw CQYDVQQGEwJVUzETMBEGA1UEChMKTUlTU0kgVEVTVIABATAUpA8wDTELMAkGA1UEBhMCVVOAAQKh EzARpA8wDTELMAkGA1UEBhMCVUswWwYDVR0fBFQwUjBQgQIFYKJKpEgwRjELMAkGA1UEBhMCVVMx EzARBgNVBAoTCk1JU1NJIFRFU1QxIjAgBgNVBAMTGU1JU1NJIFRFU1QgSUNSTCBBdXRob3JpdHkw MAYDVR0gBCkwJzALBglghkgBZQIBAw8wCwYJYIZIAWUCAQMQMAsGCWCGSAFlAgEDETCCAXgGA1Ud CQSCAW8wggFrMIIBVAYJYIZIAWUCAQU8MYIBRTCCAUEwgeMGA1UENzGB2zCB2IAKYIZIAWUCAQwA AYEDAP//ooHEMIHBgAlghkgBZQIBCAKhgbMxgbAwGgYMYIZIAWUCAQwAAQACMAqiCAICWE0CAlhO MCIGDGCGSAFlAgEMAAEAATASgQIB/qIIAgJYWQICWFqGAgbAMG4GDGCGSAFlAgEMAAEAADBegQUF ////4KJQAgJYQQICWEICAlhDAgJYRAICWEUCAlhGAgJYRwICWEgCAlhJAgJYSgICWEsCAlhMAgJY TQICWE4CAlhPAgJYUAICWFECAlhSAgJYUwICWFSGAwT/8DARBglghkgBZQIBBTgxBAMCAP8wJQYJ YIZIAWUCAQU3MRigFgYJYIZIAWUCAQoBMAkCAQACAQMCAQgwHwYJYIZIAWUCAQU3MRKhEAYJYIZI AWUCAQoCMAMCAQEwEQYJYIZIAWUCAQU4MQQDAgD/MAkGByqGSM44BAMDLwAwLAIUamw+Ot2xScbO R9GP9hs4DYCbjBwCFDL9XPIXgUBnXBpNq9qTBA7YRDxAMIIFpTCCBWWgAwIBAgICB3UwCQYHKoZI zjgEAzBOMQswCQYDVQQGEwJVUzEhMB8GA1UEChMYTUlTU0kgVEVTVCBVLlMuIE5BVElPTkFMMRww GgYDVQQDExNNSVNTSSBURVNUIFUuUy4gUEFBMB4XDTk1MTIzMDIzNTk1OVoXDTA1MDEyODE2MzAz NFowPDELMAkGA1UEBhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxGDAWBgNVBAMTD01JU1NJIFRF U1QgUENBMjCBkjAJBgcqhkjOOAQBA4GEAAKBgH7+IVpfDT6Xw7QQX3KMsVp7kOT8AYadVEIH81eV E9JOSPTZweA3wq/B6/n8HBsdI0OGPFcVjCVkTCK/29CB9h5Pi1QDhnhbEWsw81mwmaGcDk/m7K0G H6pcUKoqdT1LTpXnMmdCYNt/ZvQZftysdI1iJeExfmYTHXeB6opj3IB1o4IECjCCBAYwEwYDVR0j BAwwCoAIAAQAAAAAAAAwDgYDVR0PAQH/BAQDAgHGMAkGA1UdJAQCMAAwEgYDVR0TAQH/BAgwBgEB /wIBAjARBgNVHQ4ECgQIB3UAAAAAAAAwgasGA1UdHgEB/wSBoDCBnaCBhTBCpD0wOzELMAkGA1UE BhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxFzAVBgNVBAsTDk1JU1NJIFRFU1QgRE9EgQEKMCmk JDAiMQswCQYDVQQGEwJVUzETMBEGA1UEChMKTUlTU0kgVEVTVIABATAUpA8wDTELMAkGA1UEBhMC VVOAAQKhEzARpA8wDTELMAkGA1UEBhMCVUswWwYDVR0fBFQwUjBQgQIFYKJKpEgwRjELMAkGA1UE BhMCVVMxEzARBgNVBAoTCk1JU1NJIFRFU1QxIjAgBgNVBAMTGU1JU1NJIFRFU1QgSUNSTCBBdXRo b3JpdHkwMAYDVR0gBCkwJzALBglghkgBZQIBAw8wCwYJYIZIAWUCAQMQMAsGCWCGSAFlAgEDETCC Am4GA1UdCQSCAmUwggJhMB8GCWCGSAFlAgEFNzESoBAGCWCGSAFlAgEKATADAgEBMBEGCWCGSAFl AgEFODEEAwIA/zCCAikGCWCGSAFlAgEFPDGCAhowggIWMIHjBgNVBDcxgdswgdiACmCGSAFlAgEM AAGBAwD//6KBxDCBwYAJYIZIAWUCAQgCoYGzMYGwMBoGDGCGSAFlAgEMAAEAAjAKoggCAlhNAgJY TjAiBgxghkgBZQIBDAABAAEwEoECAf6iCAICWFkCAlhahgIGwDBuBgxghkgBZQIBDAABAAAwXoEF Bf///+CiUAICWEECAlhCAgJYQwICWEQCAlhFAgJYRgICWEcCAlhIAgJYSQICWEoCAlhLAgJYTAIC WE0CAlhOAgJYTwICWFACAlhRAgJYUgICWFMCAlhUhgME//AwgcwGA1UENzGBxDCBwYAKYIZIAWUC AQwAAoECAX6iga4wgauACWCGSAFlAgEIAqGBnTGBmjAiBgxghkgBZQIBDAACAAIwEqIMAgJRSgIC UUsCAlFMhgIF4DA4BgxghkgBZQIBDAACAAAwKIEEBv//wKIcAgJYQQICWEICAlhDAgJYRAICWEUC AlhGAgJYR4YCBeAwOgYMYIZIAWUCAQwAAgABMCqBAgP4oiACAlFBAgJRQgICUUMCAlFEAgJRRQIC UUYCAlFHAgJRSIYCBeAwKAYJYIZIAWUCAQU3MRugGQYJYIZIAWUCAQoBMAwCAQACAQECAQMCAQgw IgYJYIZIAWUCAQU3MRWhEwYJYIZIAWUCAQoCMAYCAQECAQUwEQYJYIZIAWUCAQU4MQQDAgD/MAkG ByqGSM44BAMDLwAwLAIUGHB7mLMY0/VJUiOqXZKvPLw3TfECFHUvQVUDptOaFxo4IbA+AZXe7BiV oQAxggGpMIIBpQIBATA7MDUxCzAJBgNVBAYTAlVTMRMwEQYDVQQKEwpNSVNTSSBURVNUMREwDwYD VQQDEwhURVNUIENBMgICB4IwBwYFKw4DAhqgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw IwYJKoZIhvcNAQkEMRYEFP91AnKbq5uQWq4VOKHMV4y4J5yBMFQGCyqGSIb3DQEJEAICMUUxQwIB AQYHKgMEBQYHCDE1MDOACCoDBAUGB4Z4oScTJUJPQiBUSElTIElTIEEgVEVTVCBTRUNVUklUWS1D QVRFR09SWS4wgYUGCyqGSIb3DQEJEAIBMXYwdAQWSUQgRk9SIFZEQSBTRkwgU01JTUUgM4ABADBX MFWkUzBRMQswCQYDVQQGEwJVUzETMBEGA1UEChMKTUlTU0kgVEVTVDEXMBUGA1UECxMOTUlTU0kg VEVTVCBET0QxFDASBgNVBAMTC1Rlc3QgVXNlciAzMAkGByqGSM44BAMELjAsAhSEZSdKuqD+7Yns TpHrPQS6NwigdQIUZIzpn9TTwyux25rPYk1IYbATtJU= ------_=_NextPart_000_01BEF00B.32DD9DE6-- From owner-ietf-smime-examples Tue Aug 31 14:23:35 1999 Received: by mail.proper.com (8.9.3/8.9.3) id OAA09110 for ietf-smime-examples-bks; Tue, 31 Aug 1999 14:23:35 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id OAA09106 for ; Tue, 31 Aug 1999 14:23:34 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id ; Tue, 31 Aug 1999 17:27:45 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31360B2F@WFHQEX03> From: "Pawling, John" To: "'Tom Kung'" , "'ietf-smime-examples@imc.org'" Subject: More RE: interop testing data Date: Tue, 31 Aug 1999 17:27:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All, Upon further examination of Tom's data, we found a discrepancy between the receiptRequest signed attribute included in Tom's ASN.1 encoded signedData and the description of that attribute in Tom's attrib.txt file. 1) Entrust's attrib.txt file stated: RECEIPTREQUEST: -- AllOrFirstTier: -1 -- ReceiptsFrom: ---- (0, 0): 'receiptsFrom1' of type: 1 -- ReceiptsTo: ---- (0, 0): 'receiptsFrom1' of type: 1 ---- (0, 1): 'receiptsTo1' of type: 1 The ASN.1 encoded signedData object only includes "receiptsTo1" in the ReceiptsTo field, "receiptsFrom1" is not present in the ReceiptsTo field. - John Pawling -----Original Message----- From: Pawling, John Sent: Thursday, August 26, 1999 5:27 PM To: 'Tom Kung'; 'ietf-smime-examples@imc.org' Subject: RE: interop testing data All, We were able to use the S/MIME Freeware Library (SFL) to verify the signature of Tom's signedData object. We successfully decoded all of the signed attributes described in Tom's attrib.txt file except that we still need to add support in the SFL for the sMIMEEncryptionKeyPreference attribute, so the SFL did not fully decode that attribute (it ignored it). ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc., a Wang Government Services Company jsp@jgvandyke.com ============================================ -----Original Message----- From: Tom Kung [mailto:Tom.Kung@entrust.com] Sent: Thursday, August 26, 1999 3:07 PM To: 'ietf-smime-examples@imc.org' Subject: interop testing data > Goodays, > > I would like to conduct some interoperability testing with the SMIMEv3 > spec and as such I have attached the following files: > > conInfo.txt > * ContentInfo structure that contains a SignedData item > * SignedData item contains CA, signing and encryption > certificates > * SHA1-RSA digitally signed > attribs.txt > * lists the attributes and its values contained in conInfo.txt > > > Please do not hesitate to contact me if there are any problems with > decoding this file. > > <> <> > > From owner-ietf-smime-examples Tue Aug 31 15:14:37 1999 Received: by mail.proper.com (8.9.3/8.9.3) id PAA09846 for ietf-smime-examples-bks; Tue, 31 Aug 1999 15:14:37 -0700 (PDT) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id PAA09842 for ; Tue, 31 Aug 1999 15:14:36 -0700 (PDT) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2448.0) id ; Tue, 31 Aug 1999 18:18:48 -0400 Message-ID: <33BD629222C0D211B6DB0060085ACF31360B32@WFHQEX03> From: "Pawling, John" To: "'ietf-smime-examples@imc.org'" Subject: RE: SHA1-WITH-DSA SignedData Date: Tue, 31 Aug 1999 18:18:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: All, Please ignore the test message that I sent in the attached message. I just realized that the SignedData object that we created includes the PAA (i.e. root) cert obtained from the Fortezza Card used to sign the SignedData object. The PAA cert on the card is a kludge v1 MISSI cert. I believe that we can get an equivalent v3 PAA cert that is properly encoded. There is also a negative INTEGER R value in the SignedData signature value. Once we correct the problems in the message, we will send a new one. Paul: Here is one of those erroneous messages that you were looking for:) Sorry for any inconvenience that this may have caused, - John Pawling -----Original Message----- From: Pawling, John Sent: Thursday, August 26, 1999 5:38 PM To: 'ietf-smime-examples@imc.org' Subject: SHA1-WITH-DSA SignedData All, Attached is a signedData object (MIME wrapped (.eml) and just ASN.1 encoded (.out)) produced using the S/MIME Freeware Library. The signedData was hashed using SHA-1 and signed using DSA. It includes a variety of signed attributes. It includes the complete cert path for the signer. The cert path includes the self-signed root (i.e. PAA) certificate which contains the DSA parameters. As stated in RFC 2459, if the DSA parameters are absent from a subject's cert, then the DSA parameters of the issuer's cert are used in conjunction with the subject's public DSA key to verify signatures signed using the subject's private DSA key (i.e. the subject inherits the parameters of the issuer). You can use the signer's DSA public key from the signer's certificate in conjunction with the DSA parameters from the PAA cert to verify the signature of the attached signedData object. We don't normally include the self-signed root in signedData objects that we produce, but it is included here for convenience of the testing. An extra cert (Key Exchange Algorithm) is also included in the signedData. More test messages will follow. ============================================ John Pawling, Director - Systems Engineering J.G. Van Dyke & Associates, Inc., a Wang Government Services Company jsp@jgvandyke.com ============================================ From owner-ietf-smime-examples Wed Sep 1 07:30:58 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id HAA22520 for ietf-smime-examples-bks; Wed, 1 Sep 1999 07:30:58 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by mail.proper.com (8.9.3/8.9.3) with SMTP id HAA22516 for ; Wed, 1 Sep 1999 07:30:57 -0700 (PDT) Received: id KAA11078; Wed, 1 Sep 1999 10:30:12 -0400 Received: by gateway id ; Wed, 1 Sep 1999 10:32:50 -0400 Message-ID: From: Tom Kung To: Tom Kung , "'ietf-smime-examples@imc.org'" , "'Pawling, John'" Subject: RE: More RE: interop testing data Date: Wed, 1 Sep 1999 10:32:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BEF486.DD9E0BB0" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: 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_000_01BEF486.DD9E0BB0 Content-Type: text/plain Hi John, Thanks for the examination and response. There is indeed a discreptancy and it is now fixed - the ReceiptRequest::ReceiptsTo only contains the one element ("receiptsTo1") as identified in your email. I updated the attribs.txt to reflect this fact. All other attributes are unchanged. Sorry for the inconvenience. <> <> ----------------------------------------------------- Mark your calendars now for Entrust SecureSummit 2000 May 1-4 2000 in Dallas TX > ---------- > From: Pawling, John[SMTP:jsp@jgvandyke.com] > Sent: Tuesday, August 31, 1999 5:27 PM > To: 'Tom Kung'; 'ietf-smime-examples@imc.org' > Subject: More RE: interop testing data > > All, > > Upon further examination of Tom's data, we found a discrepancy between the > receiptRequest signed attribute included in Tom's ASN.1 encoded signedData > and the description of that attribute in Tom's attrib.txt file. > > 1) Entrust's attrib.txt file stated: > > RECEIPTREQUEST: > -- AllOrFirstTier: -1 > -- ReceiptsFrom: > ---- (0, 0): 'receiptsFrom1' of type: 1 > -- ReceiptsTo: > ---- (0, 0): 'receiptsFrom1' of type: 1 > ---- (0, 1): 'receiptsTo1' of type: 1 > > The ASN.1 encoded signedData object only includes "receiptsTo1" in the > ReceiptsTo field, "receiptsFrom1" is not present in the ReceiptsTo field. > > - John Pawling > > > -----Original Message----- > From: Pawling, John > Sent: Thursday, August 26, 1999 5:27 PM > To: 'Tom Kung'; 'ietf-smime-examples@imc.org' > Subject: RE: interop testing data > > > All, > > We were able to use the S/MIME Freeware Library (SFL) to verify the > signature of Tom's signedData object. We successfully decoded all of the > signed attributes described in Tom's attrib.txt file except that we still > need to add support in the SFL for the sMIMEEncryptionKeyPreference > attribute, so the SFL did not fully decode that attribute (it ignored it). > > > ============================================ > John Pawling, Director - Systems Engineering > J.G. Van Dyke & Associates, Inc., > a Wang Government Services Company > jsp@jgvandyke.com > ============================================ > > -----Original Message----- > From: Tom Kung [mailto:Tom.Kung@entrust.com] > Sent: Thursday, August 26, 1999 3:07 PM > To: 'ietf-smime-examples@imc.org' > Subject: interop testing data > > > > > Goodays, > > > > I would like to conduct some interoperability testing with the SMIMEv3 > > spec and as such I have attached the following files: > > > > conInfo.txt > > * ContentInfo structure that contains a SignedData item > > * SignedData item contains CA, signing and encryption > > certificates > > * SHA1-RSA digitally signed > > attribs.txt > > * lists the attributes and its values contained in conInfo.txt > > > > > > Please do not hesitate to contact me if there are any problems with > > decoding this file. > > > > <> <> > > > > > ------_=_NextPart_000_01BEF486.DD9E0BB0 Content-Type: text/plain; name="conInfo.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="conInfo.txt" MIINTAYJKoZIhvcNAQcCoIINPTCCDTkCAQExCzAJBgUrDgMCGgUAMCkGCSqGSIb3DQEHAaAcBBpU aGlzIGlzIGEgZHVtbXkgdGVzdCBmaWxlLqCCCPkwggMaMIICg6ADAgECAgQySDF6MA0GCSqGSIb3 DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBE MB4XDTk5MDgxMDE4MTYxOVoXDTAwMDIxMDE4NDYxOVowVDELMAkGA1UEBhMCQ0ExEDAOBgNVBAoT B0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxITAOBgNVBAUTBzFFVFhLMDEwDwYDVQQDEwhUb20g S3VuZzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAnpLWizU7lyBx10WngOvfQoHiKoN+XIdh jOuFzSnCFZVd6eQZTGmXKPgnKo/vJOGgE/2QVTM1CTHNqAyRnbR8AuH3x3p/nnWcAWug4EJBGIk4 vKkbaTNNN0jBUvXnF6HweHMNonQ/XU5v/eguxRHf1LwncRVB9nw342058W577JkCAwEAAaOCARow ggEWMB8GA1UdEQQYMBaBFHRvbS5rdW5nQGVudHJ1c3QuY29tMFMGA1UdHwRMMEowSKBGoESkQjBA MQswCQYDVQQGEwJDQTEQMA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDENMAsGA1UE AxMEQ1JMODArBgNVHRAEJDAigA8xOTk5MDgxMDE4MTYxOVqBDzE5OTkxMjE3MTMxNjE5WjALBgNV HQ8EBAMCB4AwHwYDVR0jBBgwFoAUWFzTdvBmCxICvAnGYyj6yzb7GLQwHQYDVR0OBBYEFHSJxph3 9WcQgCXWIJy2HniOtsFTMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjQuMAMCBJAwDQYJ KoZIhvcNAQEFBQADgYEAkDfthodx/rNST9oNB71WxrUdoF/XTBY8Nlg2R5Q/BrzvFDNiZZk/Pi7/ GMKKl9vJqE9n+D62/YksCeUdroWXw4HCs6sfnwgCmto/F3PN3Cwyki9E9IValEnqfjV2DvFFbBAp n/uto7kmGzX5DVh+po7niMjsa38ll0KKAoDjZBUwggLpMIICUqADAgECAgQySCnfMA0GCSqGSIb3 DQEBBQUAMDExCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBE MB4XDTk5MDYwNzEzMTEwMloXDTk5MTIwNzEzNDEwMlowVDELMAkGA1UEBhMCQ0ExEDAOBgNVBAoT B0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQxITAOBgNVBAUTBzFFVFhLMDEwDwYDVQQDEwhUb20g S3VuZzCBnTANBgkqhkiG9w0BAQEFAAOBiwAwgYcCgYEAk4JNUYrVZjeorrcxIvkWjJNphcFakp4d ThiKvkaf4bi4R+8lopQrW3FYeITDQRn3DJer/pdblJa5x+eOPXAH842U/iREMGMp5s0bhJE5gVPh irWytLjAyqCh7b/RSRcJC2eet7Dk/EEGS7enJ+Be/iTf/fSAp7oa/VW7qGXZmjcCAQOjgewwgekw HwYDVR0RBBgwFoEUdG9tLmt1bmdAZW50cnVzdC5jb20wUwYDVR0fBEwwSjBIoEagRKRCMEAxCzAJ BgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEMQ0wCwYDVQQDEwRD Ukw3MAsGA1UdDwQEAwIFIDAfBgNVHSMEGDAWgBRYXNN28GYLEgK8CcZjKPrLNvsYtDAdBgNVHQ4E FgQUuxHvKH3BcR7RgLg8Oi3Xp959WZQwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRWNC4w AwIEkDANBgkqhkiG9w0BAQUFAAOBgQClRrRHpfTppx2L5N2DG5JT5iaeKp7UjfnjzhXW9MAcMw4V TJscqf4zHo/bmRlLm+nGfVCbsPiasK8JaAuSEHzce6lcharyk1HQDU0Zk1fU5z0YqZD1ps6nfFl6 C/oLzQgQkb2clhCDJXxcmGwcmbtdHQoF2mtbeU04IcRjiZDrMDCCAuowggJToAMCAQICBDJIDggw DQYJKoZIhvcNAQEFBQAwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsT B1IgYW5kIEQwHhcNOTgwNTE1MTcxNzEyWhcNMTgwNTE1MTc0NzEyWjAxMQswCQYDVQQGEwJDQTEQ MA4GA1UEChMHRW50cnVzdDEQMA4GA1UECxMHUiBhbmQgRDCBnTANBgkqhkiG9w0BAQEFAAOBiwAw gYcCgYEAs54ayHV4JJh8VEoRwl4kcbeJAia+cWfg1bkjFBygDoe0tGKM5Tfql/f+pln2UOSO9Z0U HS0auPKCVcxV/Ah5BFrkrvOc8RzRHUC64FNq+bqbdaLgpVWc6wxHgsVk/9rUNfVKjh7NN5uHC4jB aDfRSZH4m11WOnw9MaEe4c+LEB8CAQOjggEPMIIBCzARBglghkgBhvhCAQEEBAMCAAcwUwYDVR0f BEwwSjBIoEagRKRCMEAxCzAJBgNVBAYTAkNBMRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdS IGFuZCBEMQ0wCwYDVQQDEwRDUkwxMCsGA1UdEAQkMCKADzE5OTgwNTE1MTcxNzEyWoEPMjAxODA1 MTUxNzQ3MTJaMAsGA1UdDwQEAwIBBjAfBgNVHSMEGDAWgBRYXNN28GYLEgK8CcZjKPrLNvsYtDAd BgNVHQ4EFgQUWFzTdvBmCxICvAnGYyj6yzb7GLQwDAYDVR0TBAUwAwEB/zAZBgkqhkiG9n0HQQAE DDAKGwRWNC4wAwIEkDANBgkqhkiG9w0BAQUFAAOBgQBaUlJ6/LGSqTsuEAW+itNlGggTWd6n8WuC LXXHjM4D3AwQXU8PCwcf9IrRKdvazqirctq/IG55VFgeLq6hbbUNpYSh/nAxhQqpUdsxwzSY8KSy PZPeegeGwi2jTRQfs/vNaPUNKXBCfgpvvhG5xKXmHl4mSqh/BVBLXxWi4uN/yjGCA/0wggP5AgEB MDkwMTELMAkGA1UEBhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBDJI MXowCQYFKw4DAhoFAKCCAxowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNOTkwODI2MTU1MzI4WjAjBgkqhkiG9w0BCQQxFgQULOjrwfpE3WawZuDTFUQbeKSFIt0wKAYL KoZIhvcNAQkQAgIxGTEXBgEpAgEBEw9wcml2YWN5TWFyayBPbmUwNwYLKoZIhvcNAQkQAgExKDAm BAChETAPgQ1yZWNlaXB0c0Zyb20xMA8wDYELcmVjZWlwdHNUbzEwQAYBWzE7oDkwMTELMAkGA1UE BhMCQ0ExEDAOBgNVBAoTB0VudHJ1c3QxEDAOBgNVBAsTB1IgYW5kIEQCBDJIKd8wQwYLKoZIhvcN AQkQAgkxNDAyMRcGASkCAQETD3ByaXZhY3lNYXJrIE9uZTEXBgFSAgECEw9wcml2YWN5TWFyayBU d28wRwYLKoZIhvcNAQkQAgcxOAQ2MkgxelRodSBBdWcgMjYgMTE6NTM6MjggMTk5OQpXSytxnAns 3eZfTWnHmED14JX/yrWB2GICMIGMBgsqhkiG9w0BCRACAzF9MHsweTA5MDExCzAJBgNVBAYTAkNB MRAwDgYDVQQKEwdFbnRydXN0MRAwDgYDVQQLEwdSIGFuZCBEAgQySDF6GA8xOTk5MDgyNjE1NTMy OFqiKzAPgQ1yZWNlaXB0c0Zyb20xMBiBDXJlY2VpcHRzRnJvbTGBB2luQWRkVG8wgfgGCSqGSIb3 DQEJDzGB6jCB5zAPBgkqhkiG9n0HQgoCAgCAMA4GCSqGSIb2fQdCCgIBKDANBggqhkiG9w0DAgIB OjAOBggqhkiG9w0DAgICAKAwCgYIKoZIhvcNAwcwBwYFKw4DAgcwDQYLKwYBBAGBPAcBAQIwBwYF Kw4DAhowCgYIKoZIhvcNAgUwCwYJKoZIhvcNAQEBMAsGCSqGSIb3DQEBBzAJBgcqhkjOOAQBMAkG ByqGSM49AgEwCwYJKoZIhvcNAQEFMAsGCSqGSIb3DQEBBDAJBgcqhkjOOAQDMAkGByqGSM49BAEw DAYKKoZIhvcNAQkPATANBgkqhkiG9w0BAQEFAASBgG/vSRIYr4QIJ5Jtm3trQIYc8KQbGWTdxkgq XO/3R+QIse6Mn6aDaTWrLH6c9cr7uDxYu0F6jAa8nb0A3gsNhzBBn4Psa0dim6arNPMJtypyFv9w wLpxYtbBhpq9EvYjEHx6hAlt8y3ShWSG8srDsKTq5Q6y68ih34oPLOs9MH1K ------_=_NextPart_000_01BEF486.DD9E0BB0 Content-Type: text/plain; name="attribs.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="attribs.txt" Originator: serialNumber=3D1ETXK01+cn=3DTom Kung,ou=3DR and D = o=3DEntrust,c=3DCA =09 Unprotect Sequence Attributes: =09 CONTENTTYPE (oid): 1.2.840.113549.1.7.1 =09 SIGNINGTIME: Thu Aug 26 11:53:28 1999 =09 MESSAGEDIGEST (HEX): 2CE8EBC1FA44DD66B066E0D315441B78A48522DD =09 ESSECURITYLABEL ---- PolicyID: 1.1 ---- PrivacyMark: privacyMark One ---- Classification: 1 =09 RECEIPTREQUEST: -- AllOrFirstTier: -1 -- ReceiptsFrom: =20 ---- (0, 0): 'receiptsFrom1' of type: 1 -- ReceiptsTo: =20 ---- (0, 0): 'receiptsTo1' of type: 1 -- Signed Content Identifier (HEX): = 3248317A546875204175672032362031313A35333A323820313939390A574B2B719C09EC= DDE65F4D69C79840F5E095FFCAB581D86202 KEYENCRYPTIONPREFERENCE -- Issuer: ou=3DR and D,o=3DEntrust,c=3DCA -- Serial Number: 843590111 =09 EQUIVALENTLABELS -- Label 0: ---- PolicyID: 1.1 ---- PrivacyMark: privacyMark One ---- Classification: 1 -- Label 1: ---- PolicyID: 2.2 ---- PrivacyMark: privacyMark Two ---- Classification: 2 =09 CONTENTIDENTIFIER (HEX): = 3248317A546875204175672032362031313A35333A323820313939390A574B2B719C09EC= DDE65F4D69C79840F5E095FFCAB581D86202 =09 MLEXPANSIONHISTORY: -- Entity: serialNumber=3D1ETXK01+cn=3DTom Kung,ou=3DR and = D,o=3DEntrust,c=3DCA -- Expansion Time: Thu Aug 26 11:53:28 1999 -- In Addition To: ---- AltName: 'receiptsFrom1' of type: 1 ---- AltName: 'receiptsFrom1' of type: 1 ---- AltName: 'inAddTo' of type: 1 SMIMECAPABILITIES (keyLength of -1 means not encoded): -- CapabilityOid: 1.2.840.113533.7.66.10 -- Key Length: 128 -- CapabilityOid: 1.2.840.113533.7.66.10 -- Key Length: 40 -- CapabilityOid: 1.2.840.113549.3.2 -- Key Length: 128 -- CapabilityOid: 1.2.840.113549.3.2 -- Key Length: 40 -- CapabilityOid: 1.2.840.113549.3.7 -- Key Length: -1 -- CapabilityOid: 1.3.14.3.2.7 -- Key Length: -1 -- CapabilityOid: 1.3.6.1.4.1.188.7.1.1.2 -- Key Length: -1 -- CapabilityOid: 1.3.14.3.2.26 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.2.5 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.7 -- Key Length: -1 -- CapabilityOid: 1.2.840.10040.4.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.10045.2.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.5 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.1.4 -- Key Length: -1 -- CapabilityOid: 1.2.840.10040.4.3 -- Key Length: -1 -- CapabilityOid: 1.2.840.10045.4.1 -- Key Length: -1 -- CapabilityOid: 1.2.840.113549.1.9.15.1 -- Key Length: -1 ------_=_NextPart_000_01BEF486.DD9E0BB0-- From owner-ietf-smime-examples Wed Sep 22 16:53:12 1999 Received: by mail.proper.com (8.9.3/8.9.3) id QAA26868 for ietf-smime-examples-bks; Wed, 22 Sep 1999 16:53:12 -0700 (PDT) Received: from mail.student.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.101]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id QAA26864 for ; Wed, 22 Sep 1999 16:53:09 -0700 (PDT) Received: from cs26.cs.auckland.ac.nz (pgut001@cs26.cs.auckland.ac.nz [130.216.36.9]) by mail.student.auckland.ac.nz (8.8.6/8.8.6/cs-master) with SMTP id LAA20985 for ; Thu, 23 Sep 1999 11:57:05 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by cs26.cs.auckland.ac.nz (relaymail v0.9) id <93804462424667>; Thu, 23 Sep 1999 11:57:04 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime-examples@imc.org Subject: Looking for KEA example message Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on cs26.cs.auckland.ac.nz Date: Thu, 23 Sep 1999 11:57:04 (NZST) Message-ID: <93804462424667@cs26.cs.auckland.ac.nz> Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Does anyone have an example message done using KEA keys (ie one with v3 recipient info, originator info, domain parameters, and all the other weird cruft which goes with it) they can send me? I'd like to check to make sure my implementation isn't going to choke on it if it ever runs into one. Peter. From owner-ietf-smime-examples Wed Sep 22 18:32:46 1999 Received: (from majordomo@localhost) by mail.proper.com (8.9.3/8.9.3) id SAA01714 for ietf-smime-examples-bks; Wed, 22 Sep 1999 18:32:46 -0700 (PDT) Received: from pacific.xeti.com ([208.163.59.155]) by mail.proper.com (8.9.3/8.9.3) with ESMTP id SAA01708 for ; Wed, 22 Sep 1999 18:32:44 -0700 (PDT) Received: (from hemma@localhost) by pacific.xeti.com (8.8.8+Sun/8.8.8) id SAA08514 for ietf-smime-examples@imc.org; Wed, 22 Sep 1999 18:42:41 -0700 (PDT) Date: Wed, 22 Sep 1999 18:42:41 -0700 (PDT) From: Hemma Prafullchandra Message-Id: <199909230142.SAA08514@pacific.xeti.com> To: ietf-smime-examples@imc.org Subject: EnvelopedData/ESDH Content-Type: X-sun-attachment Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Charset: us-ascii X-Sun-Content-Lines: 20 Folks, I'd like to test out my implementation of EnvelopedData with ESDH. I have attached my DH cert and DSA-CA cert. Please send me test messages. Also, send me your DH certs, so that I can generate messages back to you. I have managed to successfully decrypt a message from Jim with ESDH/CMSRC2wrap, but I need alot more test cases :) to complete my interoperability testing. Thanks mucho, Hemma PS. the DSA-CA cert (ca.cer) uses an OIW oid for the DSA key and the ANSI oid for sha-1/dsa signature alg. please let me if this causes a problem. ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: hemmaDH.cer X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 26 begin 600 hemmaDH.cer M,((#X3"" Y^@ P(! @(& -IAC=UN, L&!RJ&2,XX! ,% #!1,0LP"08#500& M$P)54S$1, \& U4$"A,(6$5422!)3F,Q%3 3!@-5! L3#%1E3$8,!8& U4$ Q,/4F]O="!$4T$@5&5S=$-!,!X7#3DY,#DR,3$X-#4U-UH7 M#3DY,3$R,#$X-#4U-UHP5C$+, D& U4$!A,"55,Q$3 /!@-5! H3"%A%5$D@ M26YC,14P$P8#500+$PQ497-T:6YG($]N;'DQ'3 ;!@-5! ,3%$AE;6UA(%!R M869U;&QC:&%N9')A,(("03"" ;8&!RJ&2,X^ @$P@@&I H&! )2$X$5L?VE1 M8CY6@'QHY\6IGIYT=)3MD(P=Q.%*%(+UTI0,&>.Y$+L1N>6E^XXA46,"AJH& MN"$VMG\VW]'6:%MY?!U:%'4?:I-UD\Z[EW**\ \CG4?VU+/'\/3F]BO",N&) M9[Y^!J[XT %KBRKU M>VJ&.4@[ ;,7U2&M[E X4G H& )J8R+%HKU#,K7-P& MAU,_D 9A4#@^TKE]@1P2$,4,4]1DT8XP!PB,W3\*+RS6&W]7AM#:NVXV*ACH MT[QP,7I(MDX8;MT?(@;K/^K406G9F]Y'E7IRD=()?TE<.P,S4)2Q MA0'E:3N'^&FZ^-9SVV=K1A+R'A2PYH M_U,^A]W8<59H1]SW(&-+/%]X<8/F<)[BDC : Q4 '-4Z#1>";0J!=8%&$(X^ MVPGDF#0" 3<#@80 H& 7\\YK6+/28[1SF;BL>:G 4T%PG?(DE)"J06DV^!& M>5"C_)D]/::;J:V\8AQIMQ&AP"KQA2CW:/[6CS%6(DT*$6YR.@*O#B>J^>W. M!>_869+ &-=I;KUPMB'1=SDAX:]Z.L\@"K0L:5_/>6<@,4WRQNTCO\2['M%Q M0"P'UO"/Q1JCQD"C0N6LT[2(># B M!@-5'2,! ?\$&# 6@!2J>#-#QCBM(@C8)86L\ M#:OI>%3 .!@-5'0\! ?\$ M! ," P@P' 8#51T1 0'_!!(P$($.:&5M;6% >&5T:2YC;VTP"P8'*H9(SC@$ M P4 R\ ,"P"%!MND29E9CJ[HYVZ,'.@.!R6JE;= A0'! DSLA7S1G7RIH)T '<7P[:E$,C"P" end ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: ca.cer X-Sun-Encoding-Info: uuencode X-Sun-Content-Lines: 21 begin 600 ca.cer M,((##S"" LV@ P(! @(& -IAB_HP, L&!RJ&2,XX! ,% #!1,0LP"08#500& M$P)54S$1, \& U4$"A,(6$5422!)3F,Q%3 3!@-5! L3#%1E3$8,!8& U4$ Q,/4F]O="!$4T$@5&5S=$-!,!X7#3DY,#DR,3$X-#,U-%H7 M#3 P,#DR,#$X-#,U-%HP43$+, D& U4$!A,"55,Q$3 /!@-5! H3"%A%5$D@ M24YC,14P$P8#500+$PQ497-T:6YG($]N;'DQ&# 6!@-5! ,3#U)O;W0@1%-! M(%1EY>92ON_HZZH+Y5TP+/0>"9U%95XZZU%E/ MYG$'$(& M$D6<2/H3"@6$[?/"3*,R*;A/!9ZBU1\C2C@HZX>*[.F=9%NHW\+ M^B$U8O'[8GH!)#O,I/&^J%&0B:B#W^%:Y9\&DHMF7H![525D 4P[_L])*@.! MA0 "@8$ HNV%.4M=>X8U_< S9PJ$J9@WE(G]IH27_/"\9&.U!S\%6R;A]P9$ M3N =1TNS7!,QN! _!JOL /BN:M(@'#P^I7RK^F9Z"L4$, ZK0'O[W"-NL.[] M"HWR\JT"W"8_QE72.S'!.24\%U(/*>#-#QCBM(@C8)86L\ M#:OI>%3 .!@-5'0\! ?\$ M! ," 08P"P8'*H9(SC@$ P4 R\ ,"P"%'T]XC@V80L(ZOA?I6R9W5>N*)-A 6 A08VGKVJ5^^B_3^WD2X>J++ 8_3]BP" end From owner-ietf-smime-examples Sun Sep 26 12:12:01 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA11868 for ietf-smime-examples-bks; Sun, 26 Sep 1999 12:12:01 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA11858 for ; Sun, 26 Sep 1999 12:11:59 -0700 (PDT) Message-Id: <4.2.0.58.19990926121024.0097f830@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 26 Sep 1999 12:12:28 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Pre-draft of -02 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: OK, we've got stuff to work with now. Jim Schaad give me a whole slew of examples, and I've put together a version of -02 of the draft. I wanted to give this list a few days to look at it before I turned it in, in case there is anything egregiously wrong. It would be grand if some of you could start validating Jim's examples (and turning in more of your own!), but we don't need to wait for that. The pre-draft is at . --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Sep 27 15:58:55 1999 Received: by mail.imc.org (8.9.3/8.9.3) id PAA09641 for ietf-smime-examples-bks; Mon, 27 Sep 1999 15:58:55 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id PAA09636; Mon, 27 Sep 1999 15:58:54 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Sep 1999 15:58:57 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Paul Hoffman / IMC'" , ietf-smime-examples@imc.org Subject: RE: Pre-draft of -02 Date: Mon, 27 Sep 1999 15:58:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: 1. Appears to be missing an exmple for 9.1 2. The BER and DER examples are backward -- could easily be my fault. 3. Sect 5.4 -- replace XXXXXX with "content hint and counter signature" 4. Section 6.1 -- I put some items in twice. Some additional information on this example: 3DES CEK cd 4f 7c 83 73 c4 26 ce 5d b0 cd ea 7c 16 15 cb 2f 8c a8 20 16 0e c8 2a Ephemeral X (reverse the bytes) 2e 92 4e b9 2a bd ab 1e cb 5b d8 3b c5 6c b0 ef 2d 89 7b 0e e7 d6 33 8c 1f 33 81 6d 2d d1 61 4f ZZ de 42 2f c3 fb 44 ab ce 71 3f f6 3a aa dc 09 d1 ca 30 97 22 73 eb de 6a af 87 e1 74 62 60 73 c7 93 1f 2e 26 b3 09 8f 1c 93 31 33 63 5f 0e ad 89 89 f5 1a cb 8c 3f b7 8f 50 b3 9a fe 06 b0 8a 68 c0 f7 b1 fe 20 af 96 f2 a6 cf de 12 1e 74 f9 38 d1 90 da 4d 10 45 b2 6a be 3f f9 3b 61 c0 6d 8f bc 2e c8 a3 e6 d8 e2 a8 52 ea 58 65 b3 93 99 b7 77 91 67 e6 04 e5 ca ce 46 86 b0 83 17 d9 de 1d 3DES KEK (no parity check) 02 1f 67 5c 92 58 e5 5a 2a fb 3b ed 94 6b 39 8a b1 38 a7 8c 63 fc d6 14 wrapped key 51 46 57 41 34 1c d6 c7 cd 36 4b a4 93 b7 16 e6 2e f0 58 24 9c 6d 4b e9 90 8b 0f 46 b8 e5 93 19 ff 7c f0 56 4d 4f fa f5 3DES CEK 1c b6 57 1a 25 bc f8 13 5b 01 1a d5 a2 46 31 7a 85 fe 4f 62 45 4a 2a 43 5. There is going to be a problem getting bob to return receipts -- he does not have a signing key to sign the receipt with. Please change to Diane. -----Original Message----- From: Paul Hoffman / IMC [mailto:phoffman@imc.org] Sent: Sunday, September 26, 1999 12:12 PM To: ietf-smime-examples@imc.org Subject: Pre-draft of -02 OK, we've got stuff to work with now. Jim Schaad give me a whole slew of examples, and I've put together a version of -02 of the draft. I wanted to give this list a few days to look at it before I turned it in, in case there is anything egregiously wrong. It would be grand if some of you could start validating Jim's examples (and turning in more of your own!), but we don't need to wait for that. The pre-draft is at . --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Sep 27 18:19:16 1999 Received: by mail.imc.org (8.9.3/8.9.3) id SAA12140 for ietf-smime-examples-bks; Mon, 27 Sep 1999 18:19:16 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id SAA12133; Mon, 27 Sep 1999 18:19:13 -0700 (PDT) Message-Id: <4.2.0.58.19990927180821.00a1b670@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 27 Sep 1999 18:19:40 -0700 To: "Jim Schaad (Exchange)" , ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: RE: Pre-draft of -02 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 03:58 PM 9/27/99 -0700, Jim Schaad (Exchange) wrote: >1. Appears to be missing an exmple for 9.1 No one has turned one in yet. >2. The BER and DER examples are backward -- could easily be my fault. I have now reversed the contents of these two in the draft. >3. Sect 5.4 -- replace XXXXXX with "content hint and counter signature" Done. >4. Section 6.1 -- I put some items in twice. >Some additional information on this example: > >3DES CEK > cd 4f 7c 83 73 c4 26 ce 5d b0 cd ea 7c 16 15 cb > 2f 8c a8 20 16 0e c8 2a > >Ephemeral X (reverse the bytes) > 2e 92 4e b9 2a bd ab 1e cb 5b d8 3b c5 6c b0 ef > 2d 89 7b 0e e7 d6 33 8c 1f 33 81 6d 2d d1 61 4f > >ZZ > de 42 2f c3 fb 44 ab ce 71 3f f6 3a aa dc 09 d1 > ca 30 97 22 73 eb de 6a af 87 e1 74 62 60 73 c7 > 93 1f 2e 26 b3 09 8f 1c 93 31 33 63 5f 0e ad 89 > 89 f5 1a cb 8c 3f b7 8f 50 b3 9a fe 06 b0 8a 68 > c0 f7 b1 fe 20 af 96 f2 a6 cf de 12 1e 74 f9 38 > d1 90 da 4d 10 45 b2 6a be 3f f9 3b 61 c0 6d 8f > bc 2e c8 a3 e6 d8 e2 a8 52 ea 58 65 b3 93 99 b7 > 77 91 67 e6 04 e5 ca ce 46 86 b0 83 17 d9 de 1d > >3DES KEK (no parity check) > 02 1f 67 5c 92 58 e5 5a 2a fb 3b ed 94 6b 39 8a > b1 38 a7 8c 63 fc d6 14 > >wrapped key > 51 46 57 41 34 1c d6 c7 cd 36 4b a4 93 b7 16 e6 > 2e f0 58 24 9c 6d 4b e9 90 8b 0f 46 b8 e5 93 19 > ff 7c f0 56 4d 4f fa f5 > >3DES CEK > 1c b6 57 1a 25 bc f8 13 5b 01 1a d5 a2 46 31 7a > 85 fe 4f 62 45 4a 2a 43 Done. >5. There is going to be a problem getting bob to return receipts -- he does >not have a signing key to sign the receipt with. Please change to Diane. Fixed in 11.2 and 11.3 --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Thu Sep 30 09:22:03 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id JAA18531 for ietf-smime-examples-bks; Thu, 30 Sep 1999 09:22:03 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA18526 for ; Thu, 30 Sep 1999 09:22:01 -0700 (PDT) Message-Id: <4.2.0.58.19990930092115.00c30b00@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 30 Sep 1999 09:22:53 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Fwd: I-D ACTION:draft-ietf-smime-examples-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: OK, the -02 is officially out. Please, please, start testing the examples NOW. It would be wonderful if I could get -03 out before the draft cutoff and have initials for people who have checked them for many or all of the examples. I still want to see examples for all the places that have XXXXX, too, particularly for ESS. >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-examples-02.txt >Date: Thu, 30 Sep 1999 07:00:20 -0400 >Sender: owner-ietf-smime@imc.org >List-Archive: >List-Unsubscribe: > >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 : Examples of S/MIME Messages > Author(s) : P. Hoffman > Filename : draft-ietf-smime-examples-02.txt > Pages : 8 > Date : 29-Sep-99 > >This document gives examples of message bodies formatted using S/MIME. >Specifically, it has examples of Cryptographic Message Syntax (CMS) >objects, S/MIME messages (including the MIME formatting), and Enhanced >Security Services for S/MIME (ESS). It includes examples of most or all >common CMS and ESS formats; in addition, it gives examples that show >common pitfalls in implementing CMS. The purpose of this document is to >help increase interoperability for S/MIME and other protocols that rely >on CMS. >This draft is being discussed on the 'ietf-smime' mailing list. To >join the list, send a message to with the >single word 'subscribe' in the body of the message. Also, there is a >Web site for the mailing list at . > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-02.txt > >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-examples-02.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-examples-02.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. >Content-Type: text/plain >Content-ID: <19990929141854.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-smime-examples-02.txt > > --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Sat Oct 2 08:57:57 1999 Received: by mail.imc.org (8.9.3/8.9.3) id IAA29744 for ietf-smime-examples-bks; Sat, 2 Oct 1999 08:57:57 -0700 (PDT) Received: from atc.cz (IDENT:root@main.atc.cz [194.212.164.68]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id IAA29740 for ; Sat, 2 Oct 1999 08:57:55 -0700 (PDT) Received: from alexey22 (se5.lviv.net [195.5.34.69]) by atc.cz (8.8.7/8.8.5) with SMTP id RAA19230 for ; Sat, 2 Oct 1999 17:58:36 +0200 Message-ID: <00a801bf0cf7$5fed8400$4c97d4c1@reflex.ua> From: "Alexey Shamov" To: Subject: Re: I-D ACTION:draft-ietf-smime-examples-02.txt Date: Sat, 2 Oct 1999 18:18:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi all, I've tried to verify the examples and found a several points where I think the problems are: 1. [Example 5.1] Signature algorithm identifier should be id-dsa-with-sha1 (1 2 840 10040 4 3) instead of dsa (1 2 840 10040 4 1) (see 12.2.1 / RFC2630) 2. Signature verification of DSS messages without signed attributes [Example 5.1] and [Example 5.6] failed. However the signature in the [Example 5.4] and all RSA signatures were OK. For signature verification I used MS Base DH/DSS Provider. 3. [Example 6.1] KeyEncryptionAlgorithmIdentifier in KeyAgreeRecipientInfo is encoded as dhPublicNumber (1 2 840 10046 2 1) instead of id-alg-ESDH (see 12.3.1.1 / RFC2630) 4. I was not able to decrypt CEKs in [6.2] and [6.3] because BobPrivRSAEncrypt.pri is just a copy of CarlPrivRSASign.pri and of course doesn't match BobRSA public key. Alexey Shamov From owner-ietf-smime-examples Sat Oct 2 09:10:27 1999 Received: by mail.imc.org (8.9.3/8.9.3) id JAA29976 for ietf-smime-examples-bks; Sat, 2 Oct 1999 09:10:27 -0700 (PDT) Received: from atc.cz (IDENT:root@main.atc.cz [194.212.164.68]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA29972 for ; Sat, 2 Oct 1999 09:10:25 -0700 (PDT) Received: from alexey22 (se5.lviv.net [195.5.34.69]) by atc.cz (8.8.7/8.8.5) with SMTP id SAA19431 for ; Sat, 2 Oct 1999 18:11:22 +0200 Message-ID: <000301bf0cf9$26d27520$4c97d4c1@reflex.ua> From: "Alexey Shamov" To: Subject: Re: I-D ACTION:draft-ietf-smime-examples-02.txt Date: Sat, 2 Oct 1999 18:18:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: Hi all, I've tried to verify the examples and found a several points where I think the problems are: 1. [Example 5.1] Signature algorithm identifier should be id-dsa-with-sha1 (1 2 840 10040 4 3) instead of dsa (1 2 840 10040 4 1) (see 12.2.1 / RFC2630) 2. Signature verification of DSS messages without signed attributes [Example 5.1] and [Example 5.6] failed. However the signature in the [Example 5.4] and all RSA signatures were OK. For signature verification I used MS Base DH/DSS Provider. 3. [Example 6.1] KeyEncryptionAlgorithmIdentifier in KeyAgreeRecipientInfo is encoded as dhPublicNumber (1 2 840 10046 2 1) instead of id-alg-ESDH (see 12.3.1.1 / RFC2630) 4. I was not able to decrypt CEKs in [6.2] and [6.3] because BobPrivRSAEncrypt.pri is just a copy of CarlPrivRSASign.pri and of course doesn't match BobRSA public key. Alexey Shamov From owner-ietf-smime-examples Sat Oct 2 09:31:34 1999 Received: by mail.imc.org (8.9.3/8.9.3) id JAA00424 for ietf-smime-examples-bks; Sat, 2 Oct 1999 09:31:34 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id JAA00420; Sat, 2 Oct 1999 09:31:32 -0700 (PDT) Message-Id: <4.2.0.58.19991002092802.00b3d5b0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 02 Oct 1999 09:32:22 -0700 To: "Alexey Shamov" , From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-examples-02.txt In-Reply-To: <00a801bf0cf7$5fed8400$4c97d4c1@reflex.ua> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-Unsubscribe: At 06:18 PM 10/2/99 +0200, Alexey Shamov wrote: >1. [Example 5.1] Signature algorithm identifier should be id-dsa-with-sha1 >(1 2 840 10040 4 3) instead of dsa (1 2 840 10040 4 1) (see 12.2.1 / >RFC2630) This looks like an error to me. >2. Signature verification of DSS messages without signed attributes [Example >5.1] and [Example 5.6] failed. However the signature in the [Example 5.4] >and all RSA signatures were OK. For signature verification I used MS Base >DH/DSS Provider. > >3. [Example 6.1] KeyEncryptionAlgorithmIdentifier in KeyAgreeRecipientInfo >is encoded as dhPublicNumber (1 2 840 10046 2 1) instead of id-alg-ESDH (see >12.3.1.1 / RFC2630) This looks like an error to me. >4. I was not able to decrypt CEKs in [6.2] and [6.3] because >BobPrivRSAEncrypt.pri is just a copy of CarlPrivRSASign.pri and of course >doesn't match BobRSA public key. This is definitely an error. This means that any of the RSA examples with Bob won't work (I have verified that Jim gave me the same RSA key for both). Jim: do you have the correct RSA private key for Bob? I can post it here if you do. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Fri Oct 8 15:51:49 1999 Received: by mail.imc.org (8.9.3/8.9.3) id PAA20651 for ietf-smime-examples-bks; Fri, 8 Oct 1999 15:51:49 -0700 (PDT) Received: from xeti.com ([208.163.59.148]) by mail.imc.org (8.9.3/8.9.3) with SMTP id PAA20645 for ; Fri, 8 Oct 1999 15:51:44 -0700 (PDT) Received: from alaska by xeti.com (SMI-8.6/SMI-SVR4) id PAA28436; Fri, 8 Oct 1999 15:43:17 -0700 Message-Id: <199910082243.PAA28436@xeti.com> Date: Fri, 8 Oct 1999 15:55:39 -0700 (PDT) From: Hemma Prafullchandra Reply-To: Hemma Prafullchandra Subject: BobDHEncryptByCarl.cer To: ietf-smime-examples@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mScUIn6EhQkVsxcukf9uZg== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Has anyone verified the parameters in this cert ? The DH publickey in this certificate is: p: EC 2C CD A4 EF 9A 26 2F 62 A7 BB 23 4D DF 2B 25 C1 68 D2 9E A9 45 5B 36 F1 94 89 1A AF 7D 11 24 9D 3D B9 3C 29 E8 D7 23 80 33 A6 9E 45 02 BB AA CC 9E 28 05 95 A0 B3 17 76 C1 F7 25 35 61 02 41 92 27 0C 5E AE 48 E5 F3 6E 38 EF 91 D1 CF 37 FE 9A 40 97 C8 2D 35 9E 9D 93 C6 F8 15 AF 3F DA 74 3A B7 C4 93 B5 B9 BB 76 6C 1F A8 7E BC 3A AA 43 0A 81 64 FC 63 F0 7B 71 98 FA C0 38 79 10 1A 33 g: BA 0B D7 74 3D E7 34 E5 4C 13 A7 95 96 BB F1 E4 61 37 08 FB 12 C7 FB 9C 91 77 06 99 35 F0 48 24 96 33 12 01 7E 8D EC 0B F6 B2 C0 63 A7 15 C5 5E 95 86 A2 73 C5 49 46 37 79 60 FD 77 05 09 48 9B 70 8D 3C 05 F6 CE 44 2C 7F 7D 1B 2B 15 DD F3 05 2F BE 85 20 8F 8D F9 B4 A0 45 74 2B F4 3B 9D 42 62 34 27 27 81 8E 6F 0F 5E 62 85 89 CC ED 21 C3 91 70 06 54 EE 70 A8 92 55 5B 6E 19 22 4D 62 A7 q: C3 AB 4A 30 79 B3 D3 97 4E CA F5 A2 7D C7 70 A3 45 F3 B3 A2 86 05 D2 3E 49 F9 9F D9 0A B3 BE BD j: 01 34 FE C2 33 48 EB F6 3B 97 D9 E4 97 A7 60 A5 25 69 34 FB FD 46 2A D6 C9 C4 C5 F7 D6 F4 04 19 8D 94 D9 8A 37 68 69 67 55 FB F2 6B 0E 47 C5 5B 0B 4B 0E 1C 1A 8B 7B 75 B7 AA C3 AA D7 EB 3B DA 2A 8D 02 87 37 47 83 D7 31 B4 25 A8 AC BB 11 88 53 1C 11 92 B6 69 E7 2E 90 C1 7A FC 87 F4 F6 D7 1A seed: B9 FF 1C 93 44 67 37 D1 B2 F8 57 9A 32 4A C9 4A FF 3B EC 1E counter: 29 Y: 6fd4f6cd949a6eaf5b57179675bb0fb948e990370d1520c2551e13e2ae 711784c30e74ae8a557f287d8bd728229c7646d73b4f9dd14d1bb2db51 94c56d549640388a3881634a8cc31e098974a658d5c85a3dcfbbb8237f 9c1f7d78fa9ef9909e91e74bc2a4be45067842583d9f632cef84d467e5 fbc66da23629679046db4e48 According to the algorithm in rfc2631 for param generation, m = length of q = 256 then the seed needs to be at least the length of m or greater. In this case the seed is only 160 bits -- is that allowed ? Thanks, Hemma From owner-ietf-smime-examples Sun Oct 10 21:15:34 1999 Received: by mail.imc.org (8.9.3/8.9.3) id VAA21623 for ietf-smime-examples-bks; Sun, 10 Oct 1999 21:15:34 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA21619 for ; Sun, 10 Oct 1999 21:15:33 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCWTW3S>; Sun, 10 Oct 1999 21:16:43 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "Ietf-Smime-Examples (E-mail)" Subject: Bob's RSA key Date: Sun, 10 Oct 1999 21:16:46 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF139F.6CD20336" Sender: owner-ietf-smime-examples@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_000_01BF139F.6CD20336 Content-Type: text/plain; charset="iso-8859-1" <> Here is the correct key for Bob's RSA key. jim ------_=_NextPart_000_01BF139F.6CD20336 Content-Type: application/octet-stream; name="PrivateKey0000.pri" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="PrivateKey0000.pri" MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAMpc4S7sz8E7XRAb31Q1cZkKCdg9 5GG/oL4KvhGkPLU4QUFIBOFbsRccU7X0xRXT/gz7DKzqgBg2A35Bk1PXQHRJ29nGr/7Wyg3KAYSP oemjACEnUdVAGarjwDB4W6Cy5sEtJDbLrkQQgrDddNf261Ensqe2rXjKpxtZURjvKAxTAgMBAAEC gYA0koCl8jvfFY8N2k/gzqmeeq8oEJw+kMwv0xah+qsS4XSCgzVRXsLZIDDXOqnhC9wafzZBzgJN R+sMZ/jgdTF3DgacqExmcFzHTYrADDauU7rOnVacgXN0ImgG5fQoXBQXJbSCwBNpmA1d/h2WVAqP wBiMBEPbFGl6Dnr8/aCt8QJBAPWOJoKJzNRNz+10F9HYTyTh/S4Mdljx4CnvAGfR2wzxATD+9niY YrK7mvLXMV3tjEOIwHAcok4oJOqou0yDPdUCQQDS+GgiLrHNgsWwvLvQuMFWzAoriEhRdZfv2n2H i8CIVSYcgfxDedA7yEH6ri76aPpJ5EF6eKuKOvasaL35xC2HAkEAlc8ewX8unsvGMhkkuxqb1mWl X+WsgkE2wH6WocBPQsr6Lhku544YkPCR7NvKu4JEk6MnvH5LqyEkvKEqe9iJ7QJAFP0RnxT2K3Pv Jv4f0UwQMApsmJgeWbxROVOLWYjVxrpx6DQmXLApv0jVB5N8qPz4qZFD0mNe7YmgMNbaz5Zs0QJB AOkZX4OaDo50o2eiWUX85EoeMjCbSL2T3PZido/mCQPGmidY+RrUO1/N517JqUArAr2dr7dxFyKO M77vgWc9ua4= ------_=_NextPart_000_01BF139F.6CD20336-- From owner-ietf-smime-examples Sun Oct 10 21:27:12 1999 Received: (from majordomo@localhost) by mail.imc.org (8.9.3/8.9.3) id VAA21790 for ietf-smime-examples-bks; Sun, 10 Oct 1999 21:27:12 -0700 (PDT) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by mail.imc.org (8.9.3/8.9.3) with ESMTP id VAA21786 for ; Sun, 10 Oct 1999 21:27:11 -0700 (PDT) Received: by dfssl with Internet Mail Service (5.5.2650.21) id <4RCWTWSJ>; Sun, 10 Oct 1999 21:28:21 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Hemma Prafullchandra'" , ietf-smime-examples@imc.org Subject: RE: BobDHEncryptByCarl.cer Date: Sun, 10 Oct 1999 21:28:23 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It is correct that these keys are not geneated according to RFC 2631. I have a question into our local experts if that is a problem or not. Does the list feel that the keys need to be generate according to that spec, or merely work? This is after all a draft on the message format and not DH key generation. jim -----Original Message----- From: Hemma Prafullchandra [mailto:hemma@chilly.xeti.COM] Sent: Friday, October 08, 1999 3:56 PM To: ietf-smime-examples@imc.org Subject: BobDHEncryptByCarl.cer Has anyone verified the parameters in this cert ? The DH publickey in this certificate is: p: EC 2C CD A4 EF 9A 26 2F 62 A7 BB 23 4D DF 2B 25 C1 68 D2 9E A9 45 5B 36 F1 94 89 1A AF 7D 11 24 9D 3D B9 3C 29 E8 D7 23 80 33 A6 9E 45 02 BB AA CC 9E 28 05 95 A0 B3 17 76 C1 F7 25 35 61 02 41 92 27 0C 5E AE 48 E5 F3 6E 38 EF 91 D1 CF 37 FE 9A 40 97 C8 2D 35 9E 9D 93 C6 F8 15 AF 3F DA 74 3A B7 C4 93 B5 B9 BB 76 6C 1F A8 7E BC 3A AA 43 0A 81 64 FC 63 F0 7B 71 98 FA C0 38 79 10 1A 33 g: BA 0B D7 74 3D E7 34 E5 4C 13 A7 95 96 BB F1 E4 61 37 08 FB 12 C7 FB 9C 91 77 06 99 35 F0 48 24 96 33 12 01 7E 8D EC 0B F6 B2 C0 63 A7 15 C5 5E 95 86 A2 73 C5 49 46 37 79 60 FD 77 05 09 48 9B 70 8D 3C 05 F6 CE 44 2C 7F 7D 1B 2B 15 DD F3 05 2F BE 85 20 8F 8D F9 B4 A0 45 74 2B F4 3B 9D 42 62 34 27 27 81 8E 6F 0F 5E 62 85 89 CC ED 21 C3 91 70 06 54 EE 70 A8 92 55 5B 6E 19 22 4D 62 A7 q: C3 AB 4A 30 79 B3 D3 97 4E CA F5 A2 7D C7 70 A3 45 F3 B3 A2 86 05 D2 3E 49 F9 9F D9 0A B3 BE BD j: 01 34 FE C2 33 48 EB F6 3B 97 D9 E4 97 A7 60 A5 25 69 34 FB FD 46 2A D6 C9 C4 C5 F7 D6 F4 04 19 8D 94 D9 8A 37 68 69 67 55 FB F2 6B 0E 47 C5 5B 0B 4B 0E 1C 1A 8B 7B 75 B7 AA C3 AA D7 EB 3B DA 2A 8D 02 87 37 47 83 D7 31 B4 25 A8 AC BB 11 88 53 1C 11 92 B6 69 E7 2E 90 C1 7A FC 87 F4 F6 D7 1A seed: B9 FF 1C 93 44 67 37 D1 B2 F8 57 9A 32 4A C9 4A FF 3B EC 1E counter: 29 Y: 6fd4f6cd949a6eaf5b57179675bb0fb948e990370d1520c2551e13e2ae 711784c30e74ae8a557f287d8bd728229c7646d73b4f9dd14d1bb2db51 94c56d549640388a3881634a8cc31e098974a658d5c85a3dcfbbb8237f 9c1f7d78fa9ef9909e91e74bc2a4be45067842583d9f632cef84d467e5 fbc66da23629679046db4e48 According to the algorithm in rfc2631 for param generation, m = length of q = 256 then the seed needs to be at least the length of m or greater. In this case the seed is only 160 bits -- is that allowed ? Thanks, Hemma From owner-ietf-smime-examples Sun Oct 24 12:00:15 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id MAA08716 for ietf-smime-examples-bks; Sun, 24 Oct 1999 12:00:15 -0700 (PDT) Received: from Default (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA08712 for ; Sun, 24 Oct 1999 12:00:14 -0700 (PDT) Message-Id: <4.2.1.19991024115850.00be1270@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Sun, 24 Oct 1999 12:03:03 -0700 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: The -03 draft is up Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Greetings again. The latest draft, which includes Jim's changes based on bugs found so far, is available at . If you'd like your name preserved for all time in the eventual RFC, please go through as many examples as you can and verify that they are correct. Run them through your test tool or implementation, then post your results here. BTW, some folks can't read private keys except as PKCS12 files. See this list's web site for a link to a .zip of the private keys used in the current draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Oct 25 04:50:12 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06356 for ietf-smime-examples-bks; Mon, 25 Oct 1999 04:50:12 -0700 (PDT) Received: from l1.lviv.net (root@l1.lviv.net [195.5.34.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06352 for ; Mon, 25 Oct 1999 04:50:09 -0700 (PDT) Received: from alexey22 (se14.lviv.net [195.5.34.78]) by l1.lviv.net (8.9.3/8.9.3) with SMTP id OAA06554 for ; Mon, 25 Oct 1999 14:52:58 +0300 Message-ID: <009401bf1ee7$b6500780$4897d4c1@alexey22> From: "Alexey Shamov" To: Subject: Issues on -03 draft Date: Mon, 25 Oct 1999 14:50:10 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_008D_01BF1EF8.3CC10A70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_008D_01BF1EF8.3CC10A70 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Hi all, I've tried to verify digital signatures on examples 5.1-5.7. Verification of AliceDSS signature on message without signed attributes [example 5.1] failed with both MS DSS Base cryptoprovider and Crypto++ cryptolibrary. AliceDSS signature on [example 5.4] with signed attributes was ok though. MS Outlook 2000 that is partially able to verify DSA signatures also failed to verify 5.1's signature. All RSA's signatures were verified successfully. Another issue on [example 5.1] - there is one extra zero byte in the encoded signature (octet string should be 47, not 48 bytes long): 881 04 48: . . . . . OCTET STRING : . . . . . . 30 2D 02 14 08 D0 45 7D 63 E1 39 EC 62 B0 30 C2 : . . . . . . 29 AD 42 EA 96 4F 91 86 02 15 00 A6 86 EE 8A 7A : . . . . . . 05 A7 E0 07 E6 F9 88 BF 93 FB 96 4D 76 D3 92 00 I've generated another [example 5.1]. If anybody manages to verify signature on it and/or on original [example 5.1], could you please notify me. Thank you. Alexey Shamov ------=_NextPart_000_008D_01BF1EF8.3CC10A70 Content-Type: application/octet-stream; name="modified5.1.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="modified5.1.bin" MIAGCSqGSIb3DQEHAqCAMIACAQExgDAHBgUrDgMCGgAAMIAGCSqGSIb3DQEHAaCAJIAEHFRoaXMg aXMgc29tZSBzYW1wbGUgY29udGVudC4AAAAAAACggDCCAt4wggKdoAMCAQICAgDIMAkGByqGSM44 BAMwEjEQMA4GA1UEAxMHQ2FybERTUzAeFw05OTA4MTcwMTEwNDlaFw0zOTEyMzEyMzU5NTlaMBMx ETAPBgNVBAMTCEFsaWNlRFNTMIIBtjCCASsGByqGSM44BAEwggEeAoGBAIGNze2D6gqeOT7CSCij 5EeT3Q7XqA7sU8WrhAhP/5Thc0h+DNbzREjR/p+vpKGJL+HZMMg23j+bv7dM3F9piuR10DcMkQiV m96nXvn89J8v3UOoi1TxP7AHCEdNXYjDw7Wz41UIddU5dhDEeL3/nbCElzfy5FEbteQJllzzflvb AhUA4kemGkVmuBPG2o+4NyErYov3k80CgYAmONAUiTKqOfs+bdlLWWpMdiM5BAI1XPLLGjDDHlBd 3ZtZ4s2qBT1YwHuiNrhuB699ikIlp/R1z0oIXks+kPht6pzJIYo7dhTpzi5dowfNI4W4LzABfG1J iRGJNkS9+MiVSlNWteL5c+waYTYfEX/Cve3RUP+YdMLRgUpgObo2OQOBhAACgYBc47ladRSWC6l6 3eM/qeysXty9txMRNKYWiSgRI9k0hmd1dRMSPUNbb+VRv/qJ8qIbPiR9PQeNW2PIu0WloErjhdbO BoA/6CN+GvIkq1MauCcNHu8Iv2YUgFxirGX6FYvxuzTU0pY39mFHssQyhPB+QUD9RqdjTjPypeL0 8oPluKOBgzCBgDAgBgNVHREEGTAXgRVhbGljZURzc0BleGFtcGxlcy5jb20wDAYDVR0TAQH/BAIw ADAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUcEQ+gi5vh95K03XjPSC8QyuT8R8wHQYDVR0O BBYEFL5sobPjwfftQ3CkzhMB4v3jl/7NMAkGByqGSM44BAMDMAAwLQIVAJiwxj/PcUdaNalKj8D4 JAXoRpSOAhRbn0jAjKHBApxE6umhh8GlfygtuwAAMYAwYgIBATAYMBIxEDAOBgNVBAMTB0NhcmxE U1MCAgDIMAcGBSsOAwIaMAkGByqGSM44BAMELzAtAhQ4uBm2c05JCJOnPeVM0bG4HOfVugIVAL/l FunUmAt6ERxGBD/559NchM8pAAAAAAAAAAA= ------=_NextPart_000_008D_01BF1EF8.3CC10A70-- From owner-ietf-smime-examples Mon Oct 25 13:49:16 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA15923 for ietf-smime-examples-bks; Mon, 25 Oct 1999 13:49:16 -0700 (PDT) Received: from gatekeeper.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA15919 for ; Mon, 25 Oct 1999 13:49:14 -0700 (PDT) Received: id QAA11358; Mon, 25 Oct 1999 16:48:07 -0400 Received: by gateway id <43HHPAWD>; Mon, 25 Oct 1999 16:50:49 -0400 Message-ID: From: Tom Kung To: ietf-smime-examples@imc.org, "'Alexey Shamov'" Subject: RE: Issues on -03 draft Date: Mon, 25 Oct 1999 16:50:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Goodays, I was also able to verify 5.2 to 5.5 inclusive as well as Alexey's modified 5.1. The 5.1 and 5.6 in the example was not able to be verified. Other examples have not been tried or because they are not supported by my tool. Example 5.4 states that there is a countersignature but my tool has been unable to find the countersignature. Also I found that AliceRSASignByCarl.cer is not the same as the certificate that is extracted from 5.2 and 5.5 - ie: they would produce different hash values, although the information contained in the certificates were able to verify the messages successfully. tom. > ---------- > From: Alexey Shamov[SMTP:al77@bigfoot.com] > Sent: Monday, October 25, 1999 8:50 AM > To: ietf-smime-examples@imc.org > Subject: Issues on -03 draft > > <> > Hi all, > > I've tried to verify digital signatures on examples 5.1-5.7. Verification > of > AliceDSS signature on message without signed attributes [example 5.1] > failed > with both MS DSS Base cryptoprovider and Crypto++ cryptolibrary. AliceDSS > signature on [example 5.4] with signed attributes was ok though. MS > Outlook > 2000 that is partially able to verify DSA signatures also failed to verify > 5.1's signature. All RSA's signatures were verified successfully. > > Another issue on [example 5.1] - there is one extra zero byte in the > encoded > signature (octet string should be 47, not 48 bytes long): > 881 04 48: . . . . . OCTET STRING > : . . . . . . 30 2D 02 14 08 D0 45 7D 63 E1 39 EC 62 B0 30 C2 > : . . . . . . 29 AD 42 EA 96 4F 91 86 02 15 00 A6 86 EE 8A 7A > : . . . . . . 05 A7 E0 07 E6 F9 88 BF 93 FB 96 4D 76 D3 92 00 > > I've generated another [example 5.1]. If anybody manages to verify > signature > on it and/or on original [example 5.1], could you please notify me. > > Thank you. > > Alexey Shamov > > > From owner-ietf-smime-examples Mon Oct 25 15:21:08 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA17663 for ietf-smime-examples-bks; Mon, 25 Oct 1999 15:21:08 -0700 (PDT) Received: from doggate.exchange.microsoft.com (doggate.exchange.microsoft.com [131.107.88.55]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA17659 for ; Mon, 25 Oct 1999 15:21:07 -0700 (PDT) Received: by doggate.exchange.microsoft.com with Internet Mail Service (5.5.2232.9) id <42Y7AGJ9>; Mon, 25 Oct 1999 15:23:41 -0700 Message-ID: From: "Jim Schaad (Exchange)" To: "'Alexey Shamov'" , ietf-smime-examples@imc.org Subject: RE: Issues on -03 draft Date: Mon, 25 Oct 1999 15:23:29 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2232.9) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have found a bug in my CSP for DSA which caused the 5.1 verify failure. I can confirm that the original version does fail (as should any DSA signature with no attributes). jim > -----Original Message----- > From: Alexey Shamov [mailto:al77@bigfoot.com] > Sent: Monday, October 25, 1999 5:50 AM > To: ietf-smime-examples@imc.org > Subject: Issues on -03 draft > > > Hi all, > > I've tried to verify digital signatures on examples 5.1-5.7. > Verification of > AliceDSS signature on message without signed attributes > [example 5.1] failed > with both MS DSS Base cryptoprovider and Crypto++ > cryptolibrary. AliceDSS > signature on [example 5.4] with signed attributes was ok > though. MS Outlook > 2000 that is partially able to verify DSA signatures also > failed to verify > 5.1's signature. All RSA's signatures were verified successfully. > > Another issue on [example 5.1] - there is one extra zero byte > in the encoded > signature (octet string should be 47, not 48 bytes long): > 881 04 48: . . . . . OCTET STRING > : . . . . . . 30 2D 02 14 08 D0 45 7D 63 E1 39 EC > 62 B0 30 C2 > : . . . . . . 29 AD 42 EA 96 4F 91 86 02 15 00 A6 > 86 EE 8A 7A > : . . . . . . 05 A7 E0 07 E6 F9 88 BF 93 FB 96 4D > 76 D3 92 00 > > I've generated another [example 5.1]. If anybody manages to > verify signature > on it and/or on original [example 5.1], could you please notify me. > > Thank you. > > Alexey Shamov > > > From owner-ietf-smime-examples Tue Nov 23 10:20:57 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA09876 for ietf-smime-examples-bks; Tue, 23 Nov 1999 10:20:57 -0800 (PST) Received: from balinese.baltimore.ie (firewall-user@pc215-8.indigo.ie [194.125.215.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA09871 for ; Tue, 23 Nov 1999 10:20:53 -0800 (PST) Received: by balinese.baltimore.ie; id SAA01418; Tue, 23 Nov 1999 18:22:42 GMT Received: from unknown(192.168.20.10) by balinese.baltimore.ie via smap (V4.2) id xma001372; Tue, 23 Nov 99 18:22:15 GMT Received: from ocelot.baltimore.ie (IDENT:root@ocelot.baltimore.ie [192.168.21.10]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id SAA30788 for ; Tue, 23 Nov 1999 18:22:15 GMT Received: from ocelot.baltimore.ie (afarrell@localhost [127.0.0.1]) by ocelot.baltimore.ie (8.8.7/8.8.7) with ESMTP id SAA21723 for ; Tue, 23 Nov 1999 18:22:14 GMT Message-Id: <199911231822.SAA21723@ocelot.baltimore.ie> To: ietf-smime-examples@imc.org Subject: results Date: Tue, 23 Nov 1999 18:22:14 +0000 From: Andrew Farrell Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All of these comments are on examples-03. If there's a more recent version, my apologies: I haven't seen it. (1) The dumpasn1 output and base64'd content for AliceRSASignByCarl don't match. similarly BobRSASignByCarl. (2) In the dumpasn1 for 5.6, the octet strings at 1328 and 1431 should be expanded, just so that the reader can run dumpasn1 on the decoded files and get the same results as in the document. (3) In 6.1, 6.4 and 6.4, the keyEncryptionAlgorithm should be id-alg-ESDH, not dh-public-number. (4) The MailListRc2.bin when base64 decoded is 17bytes long, and has 0d0a instead of 0a (5) The RC2 Key Wrapping examples are still those that I found fault with in Oslo, and Alexey Shamov similarly after that. My proposed replacement (from July): All the same up to "Pre Encrypt #1" (LCEKPADICV), then TEMP1 = 035e 972a b15c c4c9 c4a0 3dba a35a 2166 67e4 3ebc a267 46ae 8608 dbc8 9e64 ca29 TEMP3 = 29ca 649e c8db 0886 ae46 67a2 bc3e e467 6621 5aa3 ba3d a0c4 c9c4 5cb1 2a97 5e03 f797 9eb2 5900 d9c7 And the wrapped key is: f4d8 021c 1ea4 63d2 17a9 eb69 29ff a577 36d3 e203 86c9 0993 835b 4be4 ad8d 8a1b c63b 25de 2bf7 7993 The good news is, with a hack to fix (3) and a hack to fix a bug of ours, I can decrypt 6.1. Andrew. From owner-ietf-smime-examples Thu Dec 16 20:36:25 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA16016 for ietf-smime-examples-bks; Thu, 16 Dec 1999 20:36:25 -0800 (PST) Received: from mx.fujixerox.co.jp (firewall-user@mx.fujixerox.co.jp [202.32.191.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA16012 for ; Thu, 16 Dec 1999 20:36:23 -0800 (PST) Received: by mx.fujixerox.co.jp; id NAA11163; Fri, 17 Dec 1999 13:40:12 +0900 (JST) Received: from ns1.fujixerox.co.jp(129.249.118.101) by mx.fujixerox.co.jp via smap (3.2) id xma010916; Fri, 17 Dec 99 13:39:27 +0900 Received: from ms1.prime.fujixerox.co.jp (ms1.k.prime.fujixerox.co.jp [129.249.1.15]) by ns1.fujixerox.co.jp (8.9.3+3.2W/3.7W99111812) with ESMTP id NAA03837 for ; Fri, 17 Dec 1999 13:39:27 +0900 (JST) Received: from mds (mds.labo.atsugi.fujixerox.co.jp [129.249.198.134]) by ms1.prime.fujixerox.co.jp (8.9.3/3.7Wpl2-pbo) with SMTP id NAA17031; Fri, 17 Dec 1999 13:39:26 +0900 (JST) From: "Takanori Masui" To: Cc: Subject: Bob's RSA key pair on draft-ietf-smime-example-03 Date: Fri, 17 Dec 1999 13:33:18 +0900 Message-ID: <000001bf4847$d7c4a590$86c6f981@labo.atsugi.fujixerox.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by ns.secondary.com id UAA16013 Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello, Now I'm testing my program by data of draft-ietf-smime-example-03. I had a trouble because it seems to be that Bob's RSA key pair is wrong. I decrypted the encrypted data of original data using Alice's RSA keys, then I got original data. But when I use Bob's RSA keys, I could not get original data. Does anyone know on this information? It will be appreciated if you gave me any information on this. Thanks in advance, --------------------------------------------- Takanori Masui Fuji Xerox Co.,Ltd. E-mail: takanori.masui@fujixerox.co.jp --------------------------------------------- From owner-ietf-smime-examples Fri Dec 17 18:58:59 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA24009 for ietf-smime-examples-bks; Fri, 17 Dec 1999 18:58:59 -0800 (PST) Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA23998 for ; Fri, 17 Dec 1999 18:58:57 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 11zA8x-000KNW-0W for ietf-smime-examples@imc.org; Sat, 18 Dec 1999 03:02:51 +0000 Message-ID: <385AF93C.8575680@celocom.com> Date: Sat, 18 Dec 1999 03:02:20 +0000 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 To: ietf-smime-examples@imc.org Subject: Re: BobDHEncryptByCarl.cer References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I echo the first question. Has anyone validated the parameters: i.e. check the given seed+counter generates the parameters stated? IMHO this is an issue because an implementation may well verify the parameters and reject a DH certificate with invalid ones. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Sat Dec 18 17:45:33 1999 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA02927 for ietf-smime-examples-bks; Sat, 18 Dec 1999 17:45:33 -0800 (PST) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA02922 for ; Sat, 18 Dec 1999 17:45:21 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 11zVTK-000Ca2-0U for ietf-smime-examples@imc.org; Sun, 19 Dec 1999 01:49:19 +0000 Message-ID: <385C3A8E.82D6714D@celocom.com> Date: Sun, 19 Dec 1999 01:53:18 +0000 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 To: ietf-smime-examples@imc.org Subject: Re: BobDHEncryptByCarl.cer References: <385AF93C.8575680@celocom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've tried verifying the parameters in the DH certificates but without success. The code I'm using is very experimental (but it does manage to work with the X9.42 examples which have m=160 though and so don't use certain parts of the algorithm) so if someone else can confirm they are correct it would help. Thanks, Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Mon Dec 20 10:08:28 1999 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA24354 for ietf-smime-examples-bks; Mon, 20 Dec 1999 10:08:28 -0800 (PST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24350 for ; Mon, 20 Dec 1999 10:08:27 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 20 Dec 1999 10:12:00 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Dec 1999 10:11:59 -0800 Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC50106D453@dino.platinum.corp.microsoft.com> From: "Jim Schaad (Exchange)" To: "'Dr Stephen Henson'" , ietf-smime-examples@imc.org Subject: RE: BobDHEncryptByCarl.cer Date: Mon, 20 Dec 1999 10:11:21 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4B15.B3A9D934" Sender: owner-ietf-smime-examples@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_01BF4B15.B3A9D934 Content-Type: text/plain It is well known that the parameters don't validate according to the spec. I am in the process of trying to get valid parameters according to the DH spec. Notice that for the DH keys, the seed is not of sufficent length. If you allow for the seed length then they should validate. > -----Original Message----- > From: Dr Stephen Henson [mailto:drh@celocom.com] > Sent: Friday, December 17, 1999 7:02 PM > To: ietf-smime-examples@imc.org > Subject: Re: BobDHEncryptByCarl.cer > > > I echo the first question. Has anyone validated the parameters: i.e. > check the given seed+counter generates the parameters stated? > > IMHO this is an issue because an implementation may well verify the > parameters and reject a DH certificate with invalid ones. > > Steve. > -- > Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ > Personal Email: shenson@drh-consultancy.demon.co.uk > Senior crypto engineer, Celo Communications: http://www.celocom.com/ > Core developer of the OpenSSL project: http://www.openssl.org/ > Business Email: drh@celocom.com PGP key: via homepage. > ------_=_NextPart_001_01BF4B15.B3A9D934 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BobDHEncryptByCarl.cer

It is well known that the parameters don't validate = according to the spec.  I am in the process of trying to get valid = parameters according to the DH spec.  Notice that for the DH keys, = the seed is not of sufficent length.  If you allow for the seed = length then they should validate.

> -----Original Message-----
> From: Dr Stephen Henson [mailto:drh@celocom.com]
> Sent: Friday, December 17, 1999 7:02 PM
> To: ietf-smime-examples@imc.org
> Subject: Re: BobDHEncryptByCarl.cer
>
>
> I echo the first question. Has anyone validated = the parameters: i.e.
> check the given seed+counter generates the = parameters stated?
>
> IMHO this is an issue because an implementation = may well verify the
> parameters and reject a DH certificate with = invalid ones.
>
> Steve.
> --
> Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
> Personal Email: = shenson@drh-consultancy.demon.co.uk
> Senior crypto engineer, Celo Communications: http://www.celocom.com/
> Core developer of the   OpenSSL = project: http://www.openssl.org/
> Business Email: drh@celocom.com PGP key: via = homepage.
>

------_=_NextPart_001_01BF4B15.B3A9D934-- From owner-ietf-smime-examples Mon Jan 17 05:32:50 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06663 for ietf-smime-examples-bks; Mon, 17 Jan 2000 05:32:50 -0800 (PST) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06659 for ; Mon, 17 Jan 2000 05:32:49 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-31.mail.demon.net with esmtp (Exim 2.12 #1) id 12ACI0-000MbK-0V for ietf-smime-examples@imc.org; Mon, 17 Jan 2000 13:33:48 +0000 Message-ID: <38831AC5.71FF43E9@celocom.com> Date: Mon, 17 Jan 2000 13:36:05 +0000 From: Dr Stephen Henson Organization: Dr S N Henson X-Mailer: Mozilla 4.08 [en] (Win98; U) MIME-Version: 1.0 To: "ietf-smime-examples@imc.org" Subject: Re: BobDHEncryptByCarl.cer References: <9BE3A7FF0D67C341819FCA57736D5BC50106D453@dino.platinum.corp.microsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: > Jim Schaad (Exchange) wrote: > > It is well known that the parameters don't validate according to the > spec. I am in the process of trying to get valid parameters according > to the DH spec. Notice that for the DH keys, the seed is not of > sufficent length. If you allow for the seed length then they should > validate. > Well I did allow for the seed length in that I ignored the fact it wasn't long enough but I still can't get the values given. Has anyone independently checked these? I verified my code against the parameter test vectors in a draft X9.42 DH and they agreed, unfortunately all the examples had m=160 which meant certain parts of the algorithm weren't used. Does anyone knows of any other examples with m > 160? Thanks, Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Wed Mar 29 04:52:11 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA26970 for ietf-smime-examples-bks; Wed, 29 Mar 2000 04:52:11 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26965 for ; Wed, 29 Mar 2000 04:52:09 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Wed, 29 Mar 2000 07:54:08 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF31965C63@wfhqex01.wangfed.com> From: "Pawling, John" To: "'ietf-smime-examples@imc.org '" Subject: SFL Interop Test Results Date: Wed, 29 Mar 2000 07:54:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BF997D.DEB33934" Sender: owner-ietf-smime-examples@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_000_01BF997D.DEB33934 Content-Type: text/plain All, Attached are the results of the "Examples" document testing that we performed using the S/MIME Freeware Library. I will provide the actual test data to Paul Hoffman for posting on the IMC web site. Paul will notify this list when the test data is available. -John Pawling ------_=_NextPart_000_01BF997D.DEB33934 Content-Type: application/octet-stream; name="SFL Examples results.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="SFL Examples results.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAUAAAAAAAAAAA EAAAUgAAAAEAAAD+////AAAAAE8AAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEANyAJBAAA+BK/AAAAAAAAEAAAAAAABAAAiSUAAA4AYmpialUWVRYAAAAAAAAAAAAAAAAAAAAA AAAJBBYAHjYAADd8AAA3fAAAiSEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAGwAAAAAAEABAAAAAAAAQAEAAEAB AAAAAAAAQAEAAAAAAABAAQAAAAAAAEABAAAAAAAAQAEAABQAAAAAAAAAAAAAAKQBAAAAAAAAegkA AAAAAAB6CQAAAAAAAHoJAAAAAAAAegkAAAwAAACGCQAAJAAAAKQBAAAAAAAA8TAAAD4BAAC2CQAA FgAAAMwJAAAAAAAAzAkAAAAAAADMCQAAAAAAAMwJAAAAAAAAzAkAAD4AAAAKCgAAFAAAAB4KAAAM AAAAcDAAAAIAAAByMAAAAAAAAHIwAAAAAAAAcjAAAAAAAAByMAAAAAAAAHIwAAAAAAAAcjAAACQA AAAvMgAAIAIAAE80AACaAAAAljAAABUAAAAAAAAAAAAAAAAAAAAAAAAAQAEAAAAAAAAqCgAAAAAA AAAAAAAAAAAAAAAAAAAAAADMCQAAAAAAAMwJAAAAAAAAKgoAAAAAAAAqCgAAAAAAAJYwAAAAAAAA lAwAAAAAAABAAQAAAAAAAEABAAAAAAAAzAkAAAAAAAAAAAAAAAAAAMwJAAAAAAAAqzAAABYAAACU DAAAAAAAAJQMAAAAAAAAlAwAAAAAAAAqCgAA9gEAAEABAAAAAAAAzAkAAAAAAABAAQAAAAAAAMwJ AAAAAAAAcDAAAAAAAAAAAAAAAAAAAJQMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAKgoAAAAAAABwMAAAAAAAAJQMAABQBgAAlAwAAAAAAADkEgAA GgEAAEAvAADMAAAAQAEAAAAAAABAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAZDAAAAAAAADMCQAAAAAAAKoJAAAMAAAA4Bv+MgqZ vwGkAQAA1gcAAHoJAAAAAAAAIAwAAEYAAAAMMAAAGgAAAAAAAAAAAAAAZDAAAAwAAADBMAAAMAAA APEwAAAAAAAAJjAAAD4AAADpNAAAAAAAAGYMAAAuAAAA6TQAAAAAAABkMAAAAAAAAJQMAAAAAAAA VAEAAC4AAACCAQAAIgAAAEABAAAAAAAAQAEAAAAAAABAAQAAAAAAAEABAAAAAAAAAgDZAAAAMjkg TWFyY2ggMjAwMA0NIkV4YW1wbGVzIG9mIFMvTUlNRSBNZXNzYWdlcyIgU0ZMIFRlc3QgUmVzdWx0 cw0NUG9pbnQgb2YgY29udGFjdDogSm9obiBQYXdsaW5nLCBqb2huLnBhd2xpbmdAd2FuZy5jb20N DVRlc3QgU3VtbWFyeToNDVRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRG KSBTL01JTUUgd29ya2luZyBncm91cCBoYXMgcHVibGlzaGVkIHRoZSAiRXhhbXBsZXMgb2YgUy9N SU1FIE1lc3NhZ2VzIiBJbnRlcm5ldC1EcmFmdCB0aGF0IGRvY3VtZW50cyBhIHNldCBvZiBwcm9w ZXJseSBmb3JtYXR0ZWQgc2FtcGxlIFMvTUlNRSBtZXNzYWdlcyB3aGljaCBjYW4gYmUgdXNlZCB0 byB0ZXN0IFMvTUlNRSBpbXBsZW1lbnRhdGlvbnMgYW5kIHRvIHN1cHBvcnQgUy9NSU1FIGludGVy b3BlcmFiaWxpdHkgdGVzdGluZy4gIEouRy4gVmFuIER5a2UgYW5kIEFzc29jaWF0ZXOSIChWREEp IHVzZWQgdGhlIFMvTUlNRSBGcmVld2FyZSBMaWJyYXJ5IChTRkwpIHRvIHN1Y2Nlc3NmdWxseSBw cm9jZXNzIChpLmUuIGRlY29kZSwgdmVyaWZ5LCBkZWNyeXB0KSB0aGUgbWFqb3JpdHkgb2YgdGhl IHNhbXBsZXMgaW4gdGhlIJNFeGFtcGxlc5QgZG9jdW1lbnQuICBUaGUgU0ZMIGRvZXMgbm90IHN1 cHBvcnQgZXZlcnkgUy9NSU1FIHYzIG9wdGlvbmFsIGZlYXR1cmUgYW5kIGRvZXMgbm90IGJ1aWxk L3BhcnNlIE1JTUUgaGVhZGluZ3MsIHNvIHRoZSBTRkwgY291bGQgbm90IGJlIHVzZWQgdG8gdGVz dCBldmVyeSBzYW1wbGUgaW4gdGhlIJNFeGFtcGxlc5QgZG9jdW1lbnQuICBGb3IgZXhhbXBsZSwg dGhlIFNGTCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBDTVMgYXV0aGVudGljYXRlZERhdGEgYW5kIGRp Z2VzdGVkRGF0YSBjb250ZW50IHR5cGVzLiAgVkRBIGFsc28gdXNlZCB0aGUgU0ZMIHRvIGNvbnN0 cnVjdCBzYW1wbGUgZGF0YSAoc3VjaCBhcyBzaWduZWQgcmVjZWlwdHMgYW5kIGNvbnVudGVyc2ln bmF0dXJlcykgdG8gYmUgYWRkZWQgdG8gdGhlIJNFeGFtcGxlc5QgZG9jdW1lbnQuICANDVRoZSBT RkwgdGVzdGluZyBpcyBhdXRvbWF0ZWQgdGhyb3VnaCB0aGUgdXNlIG9mIHRlc3QgZHJpdmVycyBh bmQgY29uZmlndXJhdGlvbiBmaWxlcy4gIFRoaXMgYWxsb3dzIHRoZSB0ZXN0aW5nIHRvIGJlIGVh c2lseSByZXBlYXRlZCBhbmQgbW9kaWZpZWQgYnkgVkRBIG9yIGluZGVwZW5kZW50bHkgYnkgYSB0 aGlyZCBwYXJ0eS4gIEFsbCBTRkwgYW5kIHRlc3QgZHJpdmVyIHNvdXJjZSBjb2RlIGlzIGZyZWVs eSBhdmFpbGFibGUgdG8gYWxsIGZyb20gPBMgSFlQRVJMSU5LICJodHRwOi8vd3d3LmFybWFkaWxs by5odW50c3ZpbGxlLmFsLnVzL3NvZnR3YXJlL3NtaW1lIiABFGh0dHA6Ly93d3cuYXJtYWRpbGxv Lmh1bnRzdmlsbGUuYWwudXMvc29mdHdhcmUvc21pbWUVPi4gIEFzIHN0YXRlZCBpbiB0aGUgU0ZM IFB1YmxpYyBMaWNlbnNlLCB0aGUgU0ZMIChpbmNsdWRpbmcgU0ZMIHRlc3QgZHJpdmVyKSBzb3Vy Y2UgY29kZSBpcyBiZWluZyBwcm92aWRlZCBhdCBubyBjb3N0IGFuZCB3aXRoIG5vIGZpbmFuY2lh bCBsaW1pdGF0aW9ucyByZWdhcmRpbmcgaXRzIHVzZSBhbmQgZGlzdHJpYnV0aW9uLiBPcmdhbml6 YXRpb25zIGNhbiB1c2UgdGhlIFNGTCAoaW5jbHVkaW5nIFNGTCB0ZXN0IGRyaXZlcikgd2l0aG91 dCBwYXlpbmcgYW55IHJveWFsdGllcyBvciBsaWNlbnNpbmcgZmVlcy4gIFRoZXJlZm9yZSwgYSB0 aGlyZCBwYXJ0eSBjb3VsZCBpbmRlcGVuZGVudGx5IHZlcmlmeSB0aGUgU0ZMIHRlc3RpbmcgcGVy Zm9ybWVkIGJ5IFZEQS4gIEZ1cnRoZXJtb3JlLCBhIHRoaXJkIHBhcnR5IGNvdWxkIGVuaGFuY2Ug dGhlIFNGTCB0ZXN0IGRyaXZlciBvciBpbmNvcnBvcmF0ZSBpdCBpbiBhbiBhcHBsaWNhdGlvbiBz dWNoIGFzIGFuIFMvTUlNRSBpbnRlcm9wZXJhYmlsaXR5IHRlc3RpbmcgYXV0by1yZXNwb25kZXIg d2hpY2ggb3JnYW5pemF0aW9ucyBjb3VsZCB1c2UgdG8gdGVzdCB0aGVpciBTL01JTUUgaW1wbGVt ZW50YXRpb25zLiANDUluIEFwcmlsIDIwMDAsIFZEQSB3aWxsIHByb3ZpZGUgc2FtcGxlIGRhdGEg YW5kIHNwZWNpZmljIGNvbW1lbnRzIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBFeGFtcGxlcyBkb2N1 bWVudC4gIFZEQSB3aWxsIHByb3ZpZGUgdGVjaG5pY2FsIHN1cHBvcnQgd2hlbiB0aGVyZSBhcmUg cXVlc3Rpb25zIHJlZ2FyZGluZyB0aGUgdmFsaWRpdHkgb2YgdGhlIHNhbXBsZSBkYXRhLiAgQXMg cmVzb3VyY2VzIHBlcm1pdCwgVkRBIHdpbGwgYWxzbyBwYXJ0aWNpcGF0ZSBpbiBpbnRlcm9wZXJh YmlsaXR5IHRlc3Rpbmcgd2l0aCBvdGhlcnMuDQ0NVGVzdCBSZXN1bHRzOg0oTm90ZTogVGVzdCBu dW1iZXJzIGNvcnJlc3BvbmQgdG8gRXhhbXBsZXMtMDMgc2VjdGlvbiBudW1iZXJzLikNDQ00LiAg Q29udGVudEluZm8gVGVzdHMNDUNvbnRlbnRJbmZvIHdpdGggRGF0YSB0eXBlLCBCRVI6ICBTdWNj ZXNzZnVsbHkgQVNOLjEgZGVjb2RlZCB0aGUgQkVSLWVuY29kZWQgQ29udGVudEluZm8gc2FtcGxl IGluIEV4YW1wbGVzIGRvY3VtZW50LCBidXQgU0ZMIGNhbiBvbmx5IGNyZWF0ZSBERVItZW5jb2Rl ZCBDb250ZW50SW5mbyBvYmplY3RzIGJlY2F1c2UgdGhlIFZEQS1lbmhhbmNlZCBTTkFDQyBsaWJy YXJ5IGFsd2F5cyB1c2VzIERFUiB0byBBU04uMSBlbmNvZGUgb2JqZWN0cy4NDUNvbnRlbnRJbmZv IHdpdGggRGF0YSB0eXBlLCBERVI6ICBTdWNjZXNzZnVsbHkgZGVjb2RlZCBzYW1wbGUgaW4gRXhh bXBsZXMgZG9jdW1lbnQgYW5kIGdlbmVyYXRlZCBpZGVudGljYWwgc2FtcGxlIHVzaW5nIFNGTC4N DQ01LiAgU2lnbmVkRGF0YSBUZXN0cw0NQmFzaWMgc2lnbmVkIGNvbnRlbnQsIERTUzogIFN1Y2Nl c3NmdWxseSB2ZXJpZmllZCBzaWduYXR1cmUgb2Ygc2FtcGxlIGluIEV4YW1wbGVzIGRvY3VtZW50 IGFuZCBnZW5lcmF0ZWQgZXF1aXZhbGVudCBzYW1wbGUgdXNpbmcgU0ZMLg0NQmFzaWMgc2lnbmVk IGNvbnRlbnQsIFJTQTogIFN1Y2Nlc3NmdWxseSB2ZXJpZmllZCBzaWduYXR1cmUgb2Ygc2FtcGxl IGluIEV4YW1wbGVzIGRvY3VtZW50IGFuZCBnZW5lcmF0ZWQgZXF1aXZhbGVudCBzYW1wbGUgdXNp bmcgU0ZMLg0NQmFzaWMgc2lnbmVkIGNvbnRlbnQsIGRldGFjaGVkIGNvbnRlbnQ6IFN1Y2Nlc3Nm dWxseSB2ZXJpZmllZCBzaWduYXR1cmUgb2Ygc2FtcGxlIGluIEV4YW1wbGVzIGRvY3VtZW50IGFu ZCBnZW5lcmF0ZWQgZXF1aXZhbGVudCBzYW1wbGUgdXNpbmcgU0ZMLg0NU2lnbmVkIGNvbnRlbnQg d2l0aCBzaWduZWQvdW5zaWduZWQgYXR0cmlidXRlczogU3VjY2Vzc2Z1bGx5IHZlcmlmaWVkIHNp Z25hdHVyZSBvZiBzYW1wbGUgaW4gRXhhbXBsZXMgZG9jdW1lbnQgYW5kIGdlbmVyYXRlZCBlcXVp dmFsZW50IHNhbXBsZSB1c2luZyBTRkwuICBOb3RlczogRXhhbXBsZXMtMDMgc3RhdGVkIHRoYXQg dGhlcmUgd2FzIGEgY29udW50ZXJTaWduYXR1cmUgcHJlc2VudCBpbiB0aGUgc2FtcGxlIGRhdGEs IGJ1dCB0aGVyZSB3YXMgbm90IG9uZSBwcmVzZW50LiAgV2UgY3JlYXRlZCBhIHNpZ25lZERhdGEg aW5jbHVkaW5nIGEgY291bnRlcnNpZ25hdHVyZSBhdHRyaWJ1dGUuICBXZSB3ZXJlIHVuYWJsZSB0 byBnZW5lcmF0ZSB0aGUgQ291bnRlclNpZ25hdHVyZSB1c2luZyBEaWFuZZJzIHByaXZhdGUga2V5 IGJlY2F1c2UgaGVyIHByaXZhdGUga2V5IHdhcyBub3QgYXZhaWxhYmxlIGluIEV4YW1wbGVzLTAz IGRvY3VtZW50LiAgQ291bnRlclNpZ25hdHVyZSB3YXMgZ2VuZXJhdGVkIHVzaW5nIEFsaWNlUlNB IHByaXZhdGUga2V5LiAgTk9URSA6IFR3byBTRkwgLmNmZyBmaWxlcyBhcmUgbmVlZGVkIHRvIGdl bmVyYXRlIGEgY291bnRlclNpZ25hdHVyZSwgdGhlIGZpcnN0IG9uZSBjcmVhdGVzIHRoZSBvcmln aW5hbCBTaWduZWREYXRhIGFuZCB0aGUgc2Vjb25kIG9uZSBnZW5lcmF0ZXMgdGhlIGNvdW50ZXJT aWduYXR1cmUgb2YgdGhlIFNpZ25lZERhdGEuDQ1BbGwgUlNBIHNpZ25lZCBtZXNzYWdlOiAgU3Vj Y2Vzc2Z1bGx5IHZlcmlmaWVkIHNpZ25hdHVyZSBvZiBzYW1wbGUgaW4gRXhhbXBsZXMgZG9jdW1l bnQgYW5kIGdlbmVyYXRlZCBlcXVpdmFsZW50IHNhbXBsZSB1c2luZyBTRkwuDQ1NdWx0aXBsZSBE U1Mgc2lnbmF0dXJlczogU3VjY2Vzc2Z1bGx5IHZlcmlmaWVkIG9uZSBvZiB0aGUgc2lnbmF0dXJl cyBpbiB0aGUgc2FtcGxlIGluIHRoZSBFeGFtcGxlcyBkb2N1bWVudC4gIFVuYWJsZSB0byB2ZXJp Znkgc2Vjb25kIHNpZ25hdHVyZSBzaWduZWQgdXNpbmcgRGlhbmWScyBEU1MgcHJpdmF0ZSBrZXkg YmVjYXVzZSBoZXIgcHJpdmF0ZSBrZXkgd2FzIG5vdCBhdmFpbGFibGUgaW4gRXhhbXBsZXMtMDMg ZG9jdW1lbnQuICBXZSBnZW5lcmF0ZWQgYSBzaWduZWREYXRhIGluY2x1ZGluZyBhIHNpZ25lcklu Zm8gc2lnbmVkIHVzaW5nIEFsaWNlknMgRFNTIHByaXZhdGUga2V5IGFuZCBhbm90aGVyIHNpZ25l ckluZm8gc2lnbmVkIHVzaW5nIEFsaWNlknMgUlNBIHByaXZhdGUga2V5Lg0NU2lnbmluZyB1c2lu ZyBTS0k6ICBTdWNjZXNzZnVsbHkgdmVyaWZpZWQgc2lnbmF0dXJlIG9mIHNhbXBsZSBpbiBFeGFt cGxlcyBkb2N1bWVudCBhbmQgZ2VuZXJhdGVkIGVxdWl2YWxlbnQgc2FtcGxlIHVzaW5nIFNGTC4g DQ1TL01JTUUgbXVsdGlwYXJ0L3NpZ25lZCBtZXNzYWdlOiBTdWNjZXNzZnVsbHkgdmVyaWZpZWQg c2lnbmF0dXJlIG9mIHNhbXBsZSBpbiBFeGFtcGxlcyBkb2N1bWVudCBhbmQgZ2VuZXJhdGVkIGVx dWl2YWxlbnQgc2lnbmVkRGF0YSAobm90IGluY2x1ZGluZyBNSU1FIGhlYWRpbmcpIHVzaW5nIFNG TC4gDQ1TL01JTUUgYXBwbGljYXRpb24vcGtjczctbWltZSBzaWduZWQgbWVzc2FnZTogIFN1Y2Nl c3NmdWxseSB2ZXJpZmllZCBzaWduYXR1cmUgb2Ygc2FtcGxlIGluIEV4YW1wbGVzIGRvY3VtZW50 IGFuZCBnZW5lcmF0ZWQgZXF1aXZhbGVudCBzaWduZWREYXRhIChub3QgaW5jbHVkaW5nIE1JTUUg aGVhZGluZykgdXNpbmcgU0ZMLg0NDTYuICAgRW52ZWxvcGVkLWRhdGEgVGVzdHMNDUJhc2ljIGVu Y3J5cHRlZCBjb250ZW50LCBUcmlwbGVERVMgYW5kIERIOiAgU3VjY2Vzc2Z1bGx5IHVzZWQgU0ZM IHRvIGdlbmVyYXRlIGFuZCBwcm9jZXNzIGFuIGVxdWl2YWxlbnQgZW52ZWxvcGVkRGF0YSBzYW1w bGUuICBOb3RlczogIFdlIGNvdWxkIG5vdCB1c2UgQWxpY2WScyBrZXkgbWF0ZXJpYWwgaW5jbHVk ZWQgaW4gdGhlIEV4YW1wbGUtMDMgZG9jdW1lbnQgdG8gZ2VuZXJhdGUgRW52ZWxvcGVkRGF0YSwg c28gRXJpY2GScyBELUgga2V5IG1hdGVyaWFsIHdhcyB1c2VkIGluc3RlYWQuICBBbHNvLCBpbiBv cmRlciB0byBwcm92aWRlIHRoZSBPcmlnaW5hdG9yknMgUHVibGljIGtleSBpbiB0aGUgT3JpZ2lu YXRvcklkZW50aWZpZXJPcktleSwgRXBoZW1lcmFsLVN0YXRpYyAoRS1TKSBEaWZmaWUtSGVsbG1h biAoRC1IKSB3YXMgdXNlZCAoc2VlIG5vdGUgaW4gLmNmZyBmaWxlKS4gDQ1CYXNpYyBlbmNyeXB0 ZWQgY29udGVudCwgVHJpcGxlREVTIGFuZCBSU0E6ICBTdWNjZXNzZnVsbHkgZGVjcnlwdGVkIHNh bXBsZSBpbiBFeGFtcGxlcyBkb2N1bWVudCBhbmQgZ2VuZXJhdGVkIGVxdWl2YWxlbnQgZW52ZWxv cGVkRGF0YSB1c2luZyBTRkwuDQ1CYXNpYyBlbmNyeXB0ZWQgY29udGVudCwgUkMyLzQwIGFuZCBS U0E6ICBTdWNjZXNzZnVsbHkgZGVjcnlwdGVkIHNhbXBsZSBpbiBFeGFtcGxlcyBkb2N1bWVudCBh bmQgZ2VuZXJhdGVkIGVxdWl2YWxlbnQgZW52ZWxvcGVkRGF0YSB1c2luZyBTRkwuDQ1FbmNyeXB0 ZWQgY29udGVudCwgdHdvIHJlY2lwaWVudHMsIG5vIHNoYXJlZCBrZXlpbmcgbWF0ZXJpYWw6IFN1 Y2Nlc3NmdWxseSB1c2VkIFNGTCB0byBnZW5lcmF0ZSBhbmQgcHJvY2VzcyBhbiBlcXVpdmFsZW50 IGVudmVsb3BlZERhdGEgc2FtcGxlLiAgTm90ZXM6ICBXZSBjb3VsZCBub3QgdXNlIEFsaWNlknMg a2V5IG1hdGVyaWFsIGluY2x1ZGVkIGluIHRoZSBFeGFtcGxlLTAzIGRvY3VtZW50IHRvIGdlbmVy YXRlIEVudmVsb3BlZERhdGEsIHNvIEVyaWNhknMgRC1IIGtleSBtYXRlcmlhbCB3YXMgdXNlZCBp bnN0ZWFkLiAgQWxzbywgaW4gb3JkZXIgdG8gcHJvdmlkZSB0aGUgT3JpZ2luYXRvcpJzIFB1Ymxp YyBrZXkgaW4gdGhlIE9yaWdpbmF0b3JJZGVudGlmaWVyT3JLZXksIEUtUyBELUggd2FzIHVzZWQg KHNlZSBub3RlIGluIC5jZmcgZmlsZSkuIA0NRW5jcnlwdGVkIGNvbnRlbnQsIHR3byByZWNpcGll bnRzLCBzaGFyZWQga2V5aW5nIG1hdGVyaWFsOiAgVW5hYmxlIHRvIHBlcmZvcm0gdGVzdCBiZWNh dXNlIEJvYkRIU2hhcmVkRW5jcnlwdCBhbmQgRGlhbmVQdWJESFNoYXJlZEVuY3J5cHQga2V5cyBh cmUgbm90IGF2YWlsYWJsZSBpbiBFeGFtcGxlcy0wMyBkb2N1bWVudC4gIFNGTCBpcyBiZWluZyBl bmhhbmNlZCB0byBwcm9kdWNlIGVudmVsb3BlZERhdGEgb2JqZWN0cyB3aXRoIGFuIE9yaWdpbmF0 b3IgVXNlciBLZXlpbmcgTWF0ZXJpYWwuDQ1FbmNyeXB0ZWQgY29udGVudCwgVHJpcGxlREVTIGFu ZCBESCwgcHJldmlvdXNseS1kaXN0cmlidXRlZCBrZXlzOiBVc2VkIFNGTCB0byBzdWNjZXNzZnVs bHkgZ2VuZXJhdGUgYW5kIHByb2Nlc3MgYW4gZXF1aXZhbGVudCBlbnZlbG9wZWREYXRhIHNhbXBs ZS4gIE5vdGVzOiBVbmFibGUgdG8gdXNlIE1haWxMaXN0VHJpcGxlREVTIGtleSBwcm92aWRlZCBp biBFeGFtcGxlcy0wMyBzYW1wbGUsIHVzZWQgYXJiaXRyYXJ5IHN0cmluZyBpbnN0ZWFkLg0NRW5j cnlwdGVkIGNvbnRlbnQsIFJDMi80MCBhbmQgUlNBLCBwcmV2aW91c2x5LWRpc3RyaWJ1dGVkIGtl eXM6IFVzZWQgU0ZMIHRvIHN1Y2Nlc3NmdWxseSBnZW5lcmF0ZSBhbmQgcHJvY2VzcyBhbiBlcXVp dmFsZW50IGVudmVsb3BlZERhdGEgc2FtcGxlLiAgVW5hYmxlIHRvIHVzZSBNYWlsTGlzdFJDMiBr ZXkgcHJvdmlkZWQgaW4gRXhhbXBsZXMtMDMgc2FtcGxlLCB1c2VkIGFyYml0cmFyeSBzdHJpbmcg aW5zdGVhZC4NDVMvTUlNRSBhcHBsaWNhdGlvbi9wa2NzNy1taW1lIGVuY3J5cHRlZCBtZXNzYWdl OiAgU3VjY2Vzc2Z1bGx5IHVzZWQgU0ZMIHRvIGdlbmVyYXRlIGFuZCBwcm9jZXNzIGFuIGVxdWl2 YWxlbnQgZW52ZWxvcGVkRGF0YSBzYW1wbGUgKGV4Y2VwdCBmb3IgTUlNRSBoZWFkaW5nKS4gIE5v dGVzOiAgV2UgY291bGQgbm90IHVzZSBBbGljZZJzIGtleSBtYXRlcmlhbCBpbmNsdWRlZCBpbiB0 aGUgRXhhbXBsZS0wMyBkb2N1bWVudCB0byBnZW5lcmF0ZSBFbnZlbG9wZWREYXRhLCBzbyBFcmlj YZJzIEQtSCBrZXkgbWF0ZXJpYWwgd2FzIHVzZWQgaW5zdGVhZC4gIEFsc28sIGluIG9yZGVyIHRv IHByb3ZpZGUgdGhlIE9yaWdpbmF0b3KScyBQdWJsaWMga2V5IGluIHRoZSBPcmlnaW5hdG9ySWRl bnRpZmllck9yS2V5LCBFLVMgRC1IIHdhcyB1c2VkIChzZWUgbm90ZSBpbiAuY2ZnIGZpbGUpLg0N DTcuICBEaWdlc3RlZERhdGE6ICBTRkwgZG9lcyBub3Qgc3VwcG9ydC4NDQ04LiAgRW5jcnlwdGVk LURhdGE6ICBTRkwgc3VwcG9ydHMsIHN0aWxsIG5lZWQgdG8gdGVzdC4NDQ05LiAgQXV0aGVudGlj YXRlZC1EYXRhOiAgU0ZMIGRvZXMgbm90IHN1cHBvcnQuDQ0NMTAuIEtleSBXcmFwcGluZzogIFRl c3RzIGNvbmR1Y3RlZCBhcyBwYXJ0IG9mIEVudmVsb3BlZERhdGEgdGVzdGluZy4gDQ0NMTEuICBF U1MgRXhhbXBsZXMNDVJlY2VpcHRSZXF1ZXN0OiAgTm8gc2FtcGxlIHByb3ZpZGVkIGluIGRvY3Vt ZW50LiAgVXNlZCBTRkwgdG8gc3VjY2Vzc2Z1bGx5IGdlbmVyYXRlIGFuZCBwcm9jZXNzIGEgc2ln bmVkRGF0YSBpbmNsdWRpbmcgYSByZWNlaXB0UmVxdWVzdCBhdHRyaWJ1dGUuIA0NUmVjZWlwdDog IE5vIHNhbXBsZSBwcm92aWRlZCBpbiBkb2N1bWVudC4gIFVzZWQgU0ZMIHRvIHN1Y2Nlc3NmdWxs eSBnZW5lcmF0ZSBhbmQgcHJvY2VzcyBhIHNpZ25lZERhdGEgaW5jbHVkaW5nIGEgcmVjZWlwdCBj b250ZW50IHR5cGUuDQ1FU1NTZWN1cml0eUxhYmVsOiAgTm8gc2FtcGxlIHByb3ZpZGVkIGluIGRv Y3VtZW50LiAgVXNlZCBTRkwgdG8gc3VjY2Vzc2Z1bGx5IGdlbmVyYXRlIGFuZCBwcm9jZXNzIGEg c2lnbmVkRGF0YSBpbmNsdWRpbmcgYSBFU1NTZWN1cml0eUxhYmVsIHNpZ25lZCBhdHRyaWJ1dGUu DQ1FcXVpdmFsZW50TGFiZWxzOiAgTm8gc2FtcGxlIHByb3ZpZGVkIGluIGRvY3VtZW50LiAgVXNl ZCBTRkwgdG8gc3VjY2Vzc2Z1bGx5IGdlbmVyYXRlIGFuZCBwcm9jZXNzIGEgc2lnbmVkRGF0YSBp bmNsdWRpbmcgYW4gRXF1aXZhbGVudExhYmVscyBzaWduZWQgYXR0cmlidXRlLg0NbWxFeHBhbnNp b25IaXN0b3J5OiAgTm8gc2FtcGxlIHByb3ZpZGVkIGluIGRvY3VtZW50LiAgVXNlZCBTRkwgdG8g c3VjY2Vzc2Z1bGx5IGdlbmVyYXRlIGFuZCBwcm9jZXNzIGEgc2lnbmVkRGF0YSBpbmNsdWRpbmcg YW4gbWxFeHBhbnNpb25IaXN0b3J5IHNpZ25lZCBhdHRyaWJ1dGUuDQ1TaWduaW5nQ2VydGlmaWNh dGU6ICBObyBzYW1wbGUgcHJvdmlkZWQgaW4gZG9jdW1lbnQuICBVc2VkIFNGTCB0byBzdWNjZXNz ZnVsbHkgZ2VuZXJhdGUgYW5kIHByb2Nlc3MgYSBzaWduZWREYXRhIGluY2x1ZGluZyBhIFNpZ25p bmdDZXJ0aWZpY2F0ZSBzaWduZWQgYXR0cmlidXRlLg0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAADwQAAHQEAAB1BAAAhAQAABUF AAB7BQAAqQUAAMsFAADyBQAAAgkAAAMJAABFCQAARgkAAEcJAAB7CQAAfAkAAAgNAAAWDQAAbw0A AHANAACQDQAAkg0AAI8OAACRDgAAHg8AACAPAAClDwAApw8AABEQAAASEAAAORAAADoQAAB3FwAA kRcAAPUgAAAHIQAAISEAADQhAABaIQAAcSEAAIshAACcIQAAiSUAAPz2/PbzAPMA8wDuAObu4+4A 3gDcANUA1QDVANUA1QDVAPwA/AD8APwA/AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAMT0oEAFFKBABeSgQAAAM1CIEJNQiBPioBXAiBBDBKDwAADwIIgQNqAAAAAAYIAVUIAQkD agAAAABVCAEEUEoDAAAKNQiBUEoDAFwIgQAGNQiBXAiBKwAEAAAOBAAADwQAAD4EAAA/BAAAdQQA AHYEAACEBAAAhQQAAP8HAAAACAAA2gsAANsLAAAHDQAACA0AAAkNAAAXDQAAVw0AAFgNAABZDQAA bw0AAHANAABuDgAAbw4AAOwOAADtDgAA7g4AAAMPAAAEDwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA 9wAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAPcAAAAA AAAAAAAAAAD3AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPUA AAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADwAAAAAAAA AAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AAUAAAomAQtGBAAAAQEABgAANyQAOCQASCQAAAEAAAAcAAQAAIklAAD+AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIBAQEEDwAAig8AAIsPAAAREAAAEhAAAKQQAACl EAAAfBMAAH0TAAAAFAAAARQAAI0VAACOFQAADRYAAA4WAAC7FgAAvBYAAHYXAAB3FwAAeBcAAJIX AACTFwAAVRkAAFYZAADoGQAA6RkAAHgaAAB5GgAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+gAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAA AAD4AAAAAAAAAAAAAAAA+gAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD6AAAAAAAAAAAAAAAA+AAA AAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPIAAAAAAAAA AAAAAAD4AAAAAAAAAAAAAAAA6AAAAAAAAAAAAAAAAPIAAAAAAAAAAAAAAADoAAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAJAAAKJgELRgoANyQAOCQA SCQABgAANyQAOCQASCQAAAEAAAUAAAomAQtGAQAAG3kaAAApHAAAKhwAAEUdAABGHQAARR4AAEYe AAA2HwAANx8AAPQgAAD1IAAA9iAAAB8hAAAgIQAAISEAAFghAABZIQAAWiEAAIkhAACKIQAAiyEA ANEhAADSIQAA0yEAAOUhAADmIQAAeiIAAPUAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA9QAAAAAA AAAAAAAAAO8AAAAAAAAAAAAAAAD1AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPUAAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA9QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADtAAAAAAAAAAAAAAAA7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA 7QAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAADtAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAO0AAAAA AAAAAAAAAADhAAAAAAAAAAAAAAAAAAAAAAAJAAAKJgELRgkANyQAOCQASCQAAAEBAAABAAAGAAA3 JAA4JABIJAAACQAACiYBC0YKADckADgkAEgkAAAaeiIAAHsiAAADIwAABCMAAKIjAACjIwAAQiQA AEMkAADmJAAA5yQAAIklAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA7wAAAAAA AAAAAAAAAPkAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJAAAK JgELRgkANyQAOCQASCQABgAANyQAOCQASCQAAAocAB+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWw AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEkBAABEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANDJ6nn5us4RjIIAqgBLqQsC AAAAFwAAADUAAABoAHQAdABwADoALwAvAHcAdwB3AC4AYQByAG0AYQBkAGkAbABsAG8ALgBoAHUA bgB0AHMAdgBpAGwAbABlAC4AYQBsAC4AdQBzAC8AcwBvAGYAdAB3AGEAcgBlAC8AcwBtAGkAbQBl AAAA4Mnqefm6zhGMggCqAEupC2oAAABoAHQAdABwADoALwAvAHcAdwB3AC4AYQByAG0AYQBkAGkA bABsAG8ALgBoAHUAbgB0AHMAdgBpAGwAbABlAC4AYQBsAC4AdQBzAC8AcwBvAGYAdAB3AGEAcgBl AC8AcwBtAGkAbQBlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAUABEACgABAGkADwADAAAAAAAAAAAAMAAAQPH/AgAwAAwABgBO AG8AcgBtAGEAbAAAAAIAAAAQAF9IAQRtSAkEc0gJBHRICQQwAAFAAQACADAADAAJAEgAZQBhAGQA aQBuAGcAIAAxAAAACAABAAYkAUAmAAMANQiBAAAAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwADAAW AEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAA LgBVQKIA8QAuAAwACQBIAHkAcABlAHIAbABpAG4AawAAAAwAPioBQioCcGgAAP8APgBWQKIAAQE+ AAwAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAAZQByAGwAaQBuAGsAAAAMAD4qAUIqDHBogACAAAAA AACJIQAAFgAANgAAEQD/////AwAAAAQh//8BAKB6mQAAAAAAACH//wIAoHqZAAAAAAAEIP//AwCg epkAAAAAAAAAAAASDAAARRkAAIkhAAAAAJIAAAABAAEAAAACAAAAAAAAAAAADgAAAA8AAAA+AAAA PwAAAHUAAAB2AAAAhAAAAIUAAAD/AwAAAAQAANoHAADbBwAABwkAAAgJAAAJCQAAFwkAAFcJAABY CQAAWQkAAG8JAABwCQAAbgoAAG8KAADsCgAA7QoAAO4KAAADCwAABAsAAIoLAACLCwAAEQwAABIM AACkDAAApQwAAHwPAAB9DwAAABAAAAEQAACNEQAAjhEAAA0SAAAOEgAAuxIAALwSAAB2EwAAdxMA AHgTAACSEwAAkxMAAFUVAABWFQAA6BUAAOkVAAB4FgAAeRYAACkYAAAqGAAARRkAAEYZAABFGgAA RhoAADYbAAA3GwAA9BwAAPUcAAD2HAAAHx0AACAdAAAhHQAAWB0AAFkdAABaHQAAiR0AAIodAACL HQAA0R0AANIdAADTHQAA5R0AAOYdAAB6HgAAex4AAAMfAAAEHwAAoh8AAKMfAABCIAAAQyAAAOYg AADnIAAAiyEAAJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA AAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAA gJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgA AAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAA MAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAAAAAgJgAAAAAMAAA AAAAAACAAAAAgAgAAAABMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACAWQkAAJgBBCAAMAAAAAAA AACAWQkAAJgAAAAAMAAAAAAAAACAWQkAAJgBBCAAMAEAAAAAAACAWQkAAJgAAAAAMAAAAAAAAACA WQkAAJgAAAAAMAAAAAAAAACAWQkAAAgAAAABMAAAAAAAAACAAAAAgJgAAAAAMAAAAAAAAACA7goA AJgBASAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBASAAMAEAAAAAAACA7goAAJgA AAAAMAAAAAAAAACA7goAAJgBASAAMAIAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBASAA MAMAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBASAAMAQAAAAAAACA7goAAJgAAAAAMAAA AAAAAACA7goAAJgBASAAMAUAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBASAAMAYAAAAA AACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBASAAMAcAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA 7goAAJgBASAAMAgAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goA AJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBCiAAMAAAAAAAAACA7goAAJgA AAAAMAAAAAAAAACA7goAAJgBCiAAMAEAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBCiAA MAIAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBCiAAMAMAAAAAAACA7goAAJgAAAAAMAAA AAAAAACA7goAAJgBCiAAMAQAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBCiAAMAUAAAAA AACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgBCiAAMAYAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA 7goAAJgBCiAAMAcAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goA AJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgA AAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAA MAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAA AAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAJgAAAAAMAAAAAAAAACA7goAAAgAAAABMAAAAAAA AACAAAAAgJgAAAAAMAAAAAAAAACA0x0AAJgBCSAAMAAAAAAAAACA0x0AAJgAAAAAMAAAAAAAAACA 0x0AAJgBCSAAMAEAAAAAAACA0x0AAJgAAAAAMAAAAAAAAACA0x0AAJgBCSAAMAIAAAAAAACA0x0A AJgAAAAAMAAAAAAAAACA0x0AAJgBCSAAMAMAAAAAAACA0x0AAJgAAAAAMAAAAAAAAACA0x0AAJgB CSAAMAQAAAAAAACA0x0AAJgAAAAAMAAAAAAAAACA0x0AAJgBCSAAMAUAAAAAAACA0x0AAAAEAACJ JQAAFQAAAAAEAAAEDwAAeRoAAHoiAACJJQAAFgAAABgAAAAZAAAAGgAAAAAEAACJJQAAFwAAAAIF AABGBQAAewUAAIkhAAATWBQBFYT//wIAAAANAF8ASABsAHQANAA3ADgAOAA4ADkAOQAxADkADQBf AEgAbAB0ADQANwA4ADgAOAA5ADkAMgAwAGsFAABrBQAAiyEAAAAAAEABAABAbAUAAGwFAACLIQAA AAAAAEIDAABTAwAAWAMAAGQDAADBAwAA0wMAAF0JAABoCQAAcAkAAHsJAAC9CQAAyAkAAAoKAAAV CgAAbwoAAHoKAABrDQAAfA0AABkOAAApDgAAiA4AAJgOAACtDgAAtQ4AANQOAADXDgAA9w4AAAcP AABYDwAAaA8AACARAAAqEQAAXBEAAGYRAACsEwAAtRMAAOsUAAAEFQAAHRUAACsVAABJFQAATBUA AG8VAAB4FQAA4xcAAPwXAAAdGAAAIBgAAIUYAACXGAAAnBgAALMYAABZGQAAYhkAAPAZAAABGgAA rxwAAMgcAADpHAAA7BwAAPocAAAGHQAA5h0AAPQdAABfHgAAbR4AAAQfAAAUHwAAfx8AAI8fAACj HwAAsx8AAB8gAAAvIAAAQyAAAFUgAADBIAAA0yAAAOcgAAD5IAAAZCEAAHYhAACLIQAABwAcAAcA HAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAADEDgAAyg4A AGsZAACBGQAAaRoAAH8aAAB9HwAAfh8AAEMgAABVIAAAiyEAAAcAOgAHADoABwA6AAcAOgAHADoA BwAAAAAABwgAAB0IAAClDAAApgwAADYbAAA3GwAAiyEAAAMABAADAAQAAwAEAAMA//8UAAAAFQBW AGEAbAB1AGUAZAAgAEcAYQB0AGUAdwBhAHkAIABDAGwAaQBlAG4AdAAbAEEAOgBcAFMARgBMACAA RQB4AGEAbQBwAGwAZQBzACAAcgBlAHMAdQBsAHQAcwAuAGQAbwBjABUAVgBhAGwAdQBlAGQAIABH AGEAdABlAHcAYQB5ACAAQwBsAGkAZQBuAHQAWABDADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAA bABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABc AEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMARgBMACAARQB4AGEA bQBwAGwAZQBzACAAcgBlAHMAdQBsAHQAcwAuAGEAcwBkABUAVgBhAGwAdQBlAGQAIABHAGEAdABl AHcAYQB5ACAAQwBsAGkAZQBuAHQAGwBBADoAXABTAEYATAAgAEUAeABhAG0AcABsAGUAcwAgAHIA ZQBzAHUAbAB0AHMALgBkAG8AYwAVAFYAYQBsAHUAZQBkACAARwBhAHQAZQB3AGEAeQAgAEMAbABp AGUAbgB0ABsAQQA6AFwAUwBGAEwAIABFAHgAYQBtAHAAbABlAHMAIAByAGUAcwB1AGwAdABzAC4A ZABvAGMAFQBWAGEAbAB1AGUAZAAgAEcAYQB0AGUAdwBhAHkAIABDAGwAaQBlAG4AdABYAEMAOgBc AFcASQBOAEQATwBXAFMAXABBAHAAcABsAGkAYwBhAHQAaQBvAG4AIABEAGEAdABhAFwATQBpAGMA cgBvAHMAbwBmAHQAXABXAG8AcgBkAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBl ACAAbwBmACAAUwBGAEwAIABFAHgAYQBtAHAAbABlAHMAIAByAGUAcwB1AGwAdABzAC4AYQBzAGQA FQBWAGEAbAB1AGUAZAAgAEcAYQB0AGUAdwBhAHkAIABDAGwAaQBlAG4AdAAbAEEAOgBcAFMARgBM ACAARQB4AGEAbQBwAGwAZQBzACAAcgBlAHMAdQBsAHQAcwAuAGQAbwBjABUAVgBhAGwAdQBlAGQA IABHAGEAdABlAHcAYQB5ACAAQwBsAGkAZQBuAHQAWABDADoAXABXAEkATgBEAE8AVwBTAFwAQQBw AHAAbABpAGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIA ZABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMARgBMACAARQB4 AGEAbQBwAGwAZQBzACAAcgBlAHMAdQBsAHQAcwAuAGEAcwBkABUAVgBhAGwAdQBlAGQAIABHAGEA dABlAHcAYQB5ACAAQwBsAGkAZQBuAHQAWABDADoAXABXAEkATgBEAE8AVwBTAFwAQQBwAHAAbABp AGMAYQB0AGkAbwBuACAARABhAHQAYQBcAE0AaQBjAHIAbwBzAG8AZgB0AFwAVwBvAHIAZABcAEEA dQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAFMARgBMACAARQB4AGEAbQBw AGwAZQBzACAAcgBlAHMAdQBsAHQAcwAuAGEAcwBkABUAVgBhAGwAdQBlAGQAIABHAGEAdABlAHcA YQB5ACAAQwBsAGkAZQBuAHQAGwBBADoAXABTAEYATAAgAEUAeABhAG0AcABsAGUAcwAgAHIAZQBz AHUAbAB0AHMALgBkAG8AYwAVAFYAYQBsAHUAZQBkACAARwBhAHQAZQB3AGEAeQAgAEMAbABpAGUA bgB0AFgAQwA6AFwAVwBJAE4ARABPAFcAUwBcAEEAcABwAGwAaQBjAGEAdABpAG8AbgAgAEQAYQB0 AGEAXABNAGkAYwByAG8AcwBvAGYAdABcAFcAbwByAGQAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIA eQAgAHMAYQB2AGUAIABvAGYAIABTAEYATAAgAEUAeABhAG0AcABsAGUAcwAgAHIAZQBzAHUAbAB0 AHMALgBhAHMAZAAKAF0rxQ+MDSJ6/w//D/8P/w//D/8P/w//D/8PAABnH54YkA5onf8P/w//D/8P /w//D/8P/w//DxAAbS/eGBIR9FD/D/8P/w//D/8P/w//D/8P/w8AAO4RNSXWVwQa/w//D/8P/w// D/8P/w//D/8PAABKHcYnTHZmvf8P/w//D/8P/w//D/8P/w//DwAAAxqBN8jufhL/D/8P/w//D/8P /w//D/8P/w8AABVJhlFeH4zQ/w//D/8P/w//D/8P/w//D/8PAABSHhNUYF4Y7f8P/w//D/8P/w// D/8P/w//DwAAEmIQXhJoMjv/D/8P/w//D/8P/w//D/8P/w8AAO0o+3NwLFyB/w//D/8P/w//D/8P /w//D/8PAAAEAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJg hDD9bygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQ AmCEMP1vKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB 0AIGXoTQAmCEMP1vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4TQ AhGEMP0VxgUAAdACBl6E0AJghDD9bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAA AAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAJAAAALgABAC4AAgAuAAMALgAE AAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtvKAAL AAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4Q4BBGE yPsVxgUAATgEBl6EOARghMj7bygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAED BQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgABAC4A AgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhKAFEYRg +hXGBQABoAUGXoSgBWCEYPpvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAI AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEmP4VxgUAAdACBl6E0AJghJj+bygAAgAA AC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EoAURhJj+FcYFAAGgBQZehKAFYISY/gIA AQAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhHAIEYRM/xXGBQABcAgGXoRwCGCETP8C AAIALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4RACxGEmP4VxgUAAUALBl6EQAtghJj+ AgADAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EEA4RhJj+FcYFAAEQDgZehBAOYISY /gIABAAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhOAQEYRM/xXGBQAB4BAGXoTgEGCE TP8CAAUALgABAAAAAIABAAAAAAAAAAAAAAAAAAAAAAAAGAAAD4SwExGEmP4VxgUAAbATBl6EsBNg hJj+AgAGAC4AAQAAAASAAQAAAAAAAAAAAAAAAAAAAAAAABgAAA+EgBYRhJj+FcYFAAGAFgZehIAW YISY/gIABwAuAAEAAAACggEAAAAAAAAAAAAAAAAAAAAAAAAYAAAPhFAZEYRM/xXGBQABUBkGXoRQ GWCETP8CAAgALgAGAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4SVARGEa/4VxgUAAZUBBl6E lQFghGv+bygAAgAAAC4AAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxgAAA+ElQERhGv+FcYFAAGV AQZehJUBYIRr/m8oAAQAAAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGE MP0VxgUAAdACBl6E0AJghDD9bygABgAAAC4AAQAuAAIALgABAAAAAAABAwUHAAAAAAAAAAAAAAAA AAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygACAAAAC4AAQAuAAIALgADAC4AAQAAAAAA AQMFBwkAAAAAAAAAAAAAAAAAAxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+28oAAoAAAAuAAEA LgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgE Bl6EOARghMj7bygADAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAAAAABAwUHCQsNAAAAAAAA AAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygADgAAAC4AAQAuAAIALgADAC4ABAAu AAUALgAGAC4AAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxgAAA+EoAURhGD6FcYFAAGgBQZehKAF YIRg+m8oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEA AAAAAAAAAAADGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6bygAEgAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAC4ABwAuAAgALgALAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0V xgUAAdACBl6E0AJghDD9bygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw /RXGBQAB0AIGXoTQAmCEMP1vKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAP hNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAA AAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABwAAAC4AAQAuAAIALgADAAEAAAAA AAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAJAAAALgAB AC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhDgEEYTI+xXGBQABOAQG XoQ4BGCEyPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAA AAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUA LgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpv KAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAA AAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAu AAYALgAHAC4ACAAFAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E 0AJghDD9bygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIG XoTQAmCEMP1vKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXG BQAB0AIGXoTQAmCEMP1vKAAFAAAALgABAC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAA D4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAA AAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAJAAAALgABAC4AAgAuAAMA LgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMYAAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtv KAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4Q4 BBGEyPsVxgUAATgEBl6EOARghMj7bygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAA AAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgAB AC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhKAF EYRg+hXGBQABoAUGXoSgBWCEYPpvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4A CAALAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAPGAAAD4SyAhGETv0VxgUAAbICBl6EsgJghE79T0oA AFFKAABeSgAAbygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAA8YAAAPhLICEYRO/RXGBQAB sgIGXoSyAmCETv1PSgAAUUoAAF5KAABvKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAA AA8YAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1PSgAAUUoAAF5KAABvKAAFAAAALgABAC4AAgAB AAAAAAABAwUHAAAAAAAAAAAAAAAAAAAPGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9T0oAAFFK AABeSgAAbygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAA8YAAAPhNAC EYQw/RXGBQAB0AIGXoTQAmCEMP1PSgAAUUoAAF5KAABvKAAJAAAALgABAC4AAgAuAAMALgAEAAEA AAAAAAEDBQcJCwAAAAAAAAAAAAAAAA8YAAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtPSgAAUUoA AF5KAABvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAP GAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7T0oAAFFKAABeSgAAbygADQAAAC4AAQAuAAIALgAD AC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAA8YAAAPhKAFEYRg+hXGBQABoAUG XoSgBWCEYPpPSgAAUUoAAF5KAABvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEA AAAAAAEDBQcJCw0PEQAAAAAAAAAAAA8YAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpPSgAAUUoA AF5KAABvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAALAAAAAAABAAAAAAAA AAAAAAAAAAAAAAADGAAAD4RoARGEmP4VxgUAAWgBBl6EaAFghJj+bygAAQAAAAEAAAAAAAEDAAAA AAAAAAAAAAAAAAAAAAMYAAAPhGgBEYSY/hXGBQABaAEGXoRoAWCEmP5vKAADAAAALgABAAEAAAAA AAEDBQAAAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAFAAAALgAB AC4AAgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9 bygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXG BQAB0AIGXoTQAmCEMP1vKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAA AAAAAAMYAAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4A BQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygA DQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAP hKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAH AAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAAR AAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAGAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAPGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9T0oEAFFKBABeSgQAbygAAgAAAC4AAQAAAAAA AQMAAAAAAAAAAAAAAAAAAAAADxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/U9KBABRSgQAXkoE AG8oAAQAAAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAPGAAAD4TQAhGEMP0VxgUAAdAC Bl6E0AJghDD9T0oEAFFKBABeSgQAbygABgAAAC4AAQAuAAIALgABAAAAAAABAwUHAAAAAAAAAAAA AAAAAAAPGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9T0oEAFFKBABeSgQAbygACAAAAC4AAQAu AAIALgADAC4AAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAADxgAAA+EOAQRhMj7FcYFAAE4BAZehDgE YITI+09KBABRSgQAXkoEAG8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAA AAAAAAAAAAAPGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7T0oEAFFKBABeSgQAbygADAAAAC4A AQAuAAIALgADAC4ABAAuAAUALgABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAPGAAAD4Q4BBGEyPsV xgUAATgEBl6EOARghMj7T0oEAFFKBABeSgQAbygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG AC4AAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAADxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+k9K BABRSgQAXkoEAG8oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUH CQsNDxEAAAAAAAAAAAAPGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6T0oEAFFKBABeSgQAbygA EgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgAGAAAAAAABAAAAAAAAAAAAAAAA AAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygAAQAAAAEAAAAAAAEDAAAAAAAAAAAA AAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAADAAAALgABAAEAAAAAAAEDBQAA AAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIGXoTQAmCEMP1vKAAFAAAALgABAC4AAgAB AAAAAAABAwUHAAAAAAAAAAAAAAAAAAADGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9bygABwAA AC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMYAAAPhNACEYQw/RXGBQAB0AIG XoTQAmCEMP1vKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMY AAAPhDgEEYTI+xXGBQABOAQGXoQ4BGCEyPtvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAA AAABAwUHCQsNAAAAAAAAAAAAAAADGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7bygADQAAAC4A AQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMYAAAPhKAFEYRg +hXGBQABoAUGXoSgBWCEYPpvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAA AAEDBQcJCw0PEQAAAAAAAAAAAAMYAAAPhKAFEYRg+hXGBQABoAUGXoSgBWCEYPpvKAARAAAALgAB AC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAGAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAPGAAA D4TQAhGEMP0VxgUAAdACBl6E0AJghDD9T0oEAFFKBABeSgQAbygAAgAAAC4AAQAAAAAAAQMAAAAA AAAAAAAAAAAAAAAADxgAAA+E0AIRhDD9FcYFAAHQAgZehNACYIQw/U9KBABRSgQAXkoEAG8oAAQA AAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAPGAAAD4TQAhGEMP0VxgUAAdACBl6E0AJg hDD9T0oEAFFKBABeSgQAbygABgAAAC4AAQAuAAIALgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAAP GAAAD4TQAhGEMP0VxgUAAdACBl6E0AJghDD9T0oEAFFKBABeSgQAbygACAAAAC4AAQAuAAIALgAD AC4AAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAADxgAAA+EOAQRhMj7FcYFAAE4BAZehDgEYITI+09K BABRSgQAXkoEAG8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAA AAAPGAAAD4Q4BBGEyPsVxgUAATgEBl6EOARghMj7T0oEAFFKBABeSgQAbygADAAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAAPGAAAD4Q4BBGEyPsVxgUAATgE Bl6EOARghMj7T0oEAFFKBABeSgQAbygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAA AAAAAQMFBwkLDQ8AAAAAAAAAAAAADxgAAA+EoAURhGD6FcYFAAGgBQZehKAFYIRg+k9KBABRSgQA XkoEAG8oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEA AAAAAAAAAAAPGAAAD4SgBRGEYPoVxgUAAaAFBl6EoAVghGD6T0oEAFFKBABeSgQAbygAEgAAAC4A AQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgALgAKAAAASh3GJwAAAAAAAAAAAAAAABJiEF4A AAAAAAAAAAAAAADuETUlAAAAAAAAAAAAAAAAXSvFDwAAAAAAAAAAAAAAABVJhlEAAAAAAAAAAAAA AABSHhNUAAAAAAAAAAAAAAAA7Sj7cwAAAAAAAAAAAAAAAGcfnhgAAAAAAAAAAAAAAAADGoE3AAAA AAAAAAAAAAAAbS/eGAAAAAAAAAAAAAAAAP////////////////////////////////////////// /////////////woAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP//CgAAAAAAEgAPAAkEGQAJBBsACQQP AAkEGQAJBBsACQQPAAkEGQAJBBsACQQAAAAAAAAAAAAAAAAAAAAAAAAAAIshAAABAAAA/0ADgAEA QyEAAEMhAABcr2QAAQBFAEMhAAAAAAAAQyEAAAAAAAACEAAAAAAAAACJIQAAYAEACABAAAD//wEA AAAHAFUAbgBrAG4AbwB3AG4A//8BAAgAAAAAAAAAAAAAAP//AQAAAAAA//8AAAIA//8AAAAA//8A AAIA//8AAAAABQAAAEcWkAEAAAICBgMFBAUCAwSHOgAAAAAAAAAAAAAAAAAA/wAAAAAAAABUAGkA bQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAA AAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgSHOgAAAAAAAAAAAAAAAAAA /wAAAAAAAABBAHIAaQBhAGwAAABHEZABgAoAAAAAAAAAAAAAAQAAAAAABwgQAAAAAAAAAAAAAgAA AAAATQBTACAATQBpAG4AYwBoAG8AAAAt/zP/IAAOZh1nAAA/NZABAAACBwMJAgIFAgQEhzoAAAAA AAAAAAAAAAAAAP8AAAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAAIgAEAHAIiBgA8NAC5ARo AQAAAAAp5ENGhuRDRgAAAAAIAFYAAADWBAAAlBsAAAMADgAAAAQAAxA6AAAAAAAAAAAAAAADAAEA AAABAAAAAAAAALQEAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAA+MAAA EQAZAGQAAAAZAAAA3iEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIkhAAAAAAoAAAAAAAAAAAAAAAAAAAACAAAAXQIAAAAACDKDUQDwEADfAwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAPAEUAeABhAG0AcABsAGUAcwAgAHIAZQBzAHUAbAB0 AAAAAAAAABQATABvAHUAcgBkAGUAcwAgAFQALgAgAE0AYQBsAGQAbwBuAGEAZABvABUAVgBhAGwA dQBlAGQAIABHAGEAdABlAHcAYQB5ACAAQwBsAGkAZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoC AAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACQAQAAEQAAAAEAAACQAAAA AgAAAJgAAAADAAAAsAAAAAQAAAC8AAAABQAAANwAAAAGAAAA6AAAAAcAAAD0AAAACAAAAAQBAAAJ AAAAJAEAABIAAAAwAQAACgAAAEwBAAAMAAAAWAEAAA0AAABkAQAADgAAAHABAAAPAAAAeAEAABAA AACAAQAAEwAAAIgBAAACAAAA5AQAAB4AAAAQAAAARXhhbXBsZXMgcmVzdWx0AB4AAAABAAAAAHhh bR4AAAAVAAAATG91cmRlcyBULiBNYWxkb25hZG8AADkAHgAAAAEAAAAAb3VyHgAAAAEAAAAAb3Vy HgAAAAcAAABOb3JtYWwAIB4AAAAWAAAAVmFsdWVkIEdhdGV3YXkgQ2xpZW50ADkAHgAAAAIAAAA4 AGx1HgAAABMAAABNaWNyb3NvZnQgV29yZCA5LjAAbkAAAAAAhJkDDAAAAEAAAAAAPsBO/pi/AUAA AAAAfJYuCpm/AQMAAAADAAAAAwAAANYEAAADAAAAlBsAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAA AAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rlQBAAAQAQAA DAAAAAEAAABoAAAADwAAAHAAAAAFAAAAlAAAAAYAAACcAAAAEQAAAKQAAAAXAAAArAAAAAsAAAC0 AAAAEAAAALwAAAATAAAAxAAAABYAAADMAAAADQAAANQAAAAMAAAA8AAAAAIAAADkBAAAHgAAABoA AABKLkcuVmFuIER5a2UgJiBBc3NvY2lhdGVzAGwAAwAAADoAAAADAAAADgAAAAMAAADeIQAAAwAA AKAKCQALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAB4QAAABAAAAEAAAAEV4YW1wbGVz IHJlc3VsdAAMEAAAAgAAAB4AAAAGAAAAVGl0bGUAAwAAAAEAAAAAAOwAAAADAAAAAAAAACAAAAAB AAAAOAAAAAIAAABAAAAAAQAAAAIAAAAMAAAAX1BJRF9ITElOS1MAAgAAAOQEAABBAAAApAAAAAYA AAADAAAAFQBIAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAA1AAAAaAB0AHQAcAA6AC8ALwB3 AHcAdwAuAGEAcgBtAGEAZABpAGwAbABvAC4AaAB1AG4AdABzAHYAaQBsAGwAZQAuAGEAbAAuAHUA cwAvAHMAbwBmAHQAdwBhAHIAZQAvAHMAbQBpAG0AZQAAAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAA AAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAA FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAAP7///8dAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAj AAAA/v///yUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEA AAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA/v// /0AAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAAD+////SAAAAEkAAABKAAAASwAAAEwAAABNAAAA TgAAAP7////9////UQAAAP7////+/////v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAG CQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAAYM1NNAqZvwFTAAAAgAAAAAAAAABEAGEAdABhAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAC Af///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABwAAAAAEAAA AAAAADEAVABhAGIAbABlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAOAAIAAQAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAJAAAAOk0AAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHjYAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD8AAAAAEAAAAAAAAAUARABvAGMAdQBt AGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIB BAAAAP//////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARwAAAAAQAAAA AAAAAQBDAG8AbQBwAE8AYgBqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABIAAgECAAAABwAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAagAAAAAAAABPAGIAagBlAGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgABAP///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAYM1NNAqZvwFgzU00Cpm/AQAAAAAAAAAAAAAAAAEAAAD+//////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAA RhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3Vt ZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01BF997D.DEB33934-- From owner-ietf-smime-examples Wed Jul 19 17:55:41 2000 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA04510 for ietf-smime-examples-bks; Wed, 19 Jul 2000 17:55:41 -0700 (PDT) Received: from yahoo.com (216-164-132-57.s311.tnt2.lnhva.md.dialup.rcn.com [216.164.132.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04430; Wed, 19 Jul 2000 17:55:29 -0700 (PDT) From: Subject: Tuition-Free Computer and IT Training for Non-Profit Employees Date: Wed, 19 Jul 2000 21:01:39 Message-Id: <714.828941.257890@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Tuition-Free Computer and IT Training for Non-Profit Employees Dear Non-Profit Employee, Most non-profit employees want to improve their computer skills. However, high cost of training and a busy schedule have held them back. Now, the National Education Foundation (NEF) CyberLearning, a non-profit organization, dedicated to bridging the "Digital Divide," offers the Nation's non-profit employees a unique opportunity. With the support of Microsoft and others, NEF CyberLearning is now able to offer full tuition scholarships of $2,000 to the first 10,000 applicants, thus enabling them to take any or all of the 400+ Internet-based online personal computing and computer professional courses from anywhere at any time. The high-quality, user-friendly courses are either self-study or instructor-led. They cover all levels and almost all topics, including Computer Basics, Internet Basics, Web Design Basics, Networking Basics, Programming Basics, A+, Network+, MCSE, CNE, Microsoft Office, MOUS, WordPerfect, Lotus, Operating Systems, Windows, Windows 2000, Linux, Unix, Networking, WAN, LAN, Programming, Java, C++, Visual Basics, Internet, Web Design, Web Applications, Web Master, E-commerce, Databases, Oracle and Cisco. To sign up, just visit www.cyberlearning.org, click on "Free IT Training," complete the application and pay a nominal registration fee of $75 with an organization/personal credit card. This $75 is your only cost, since the tuition is free for you. Many non-profit organizations reimburse the $75. You can receive immediate access to all 400+ online courses, an online library of the latest 1,000+ computer/information technology books, instructor assistance, course-specific chat areas and round the clock technical support. Please feel free to forward this information to interested colleagues and others in non-profit organizations. If your department or division wants to sign up a group of employees, please indicate so in your reply and provide contact information. If you received this e-mail, it is because you are listed as a contact person or employee of a non-profit organization. If you do not wish to receive any further scholarship information from us, please reply with the message, "remove" in the Subject line. Thank you. The non-profit National Education Foundation (NEF) CyberLearning has provided tuition-free IT training to thousands of students, teachers, government and non-profit employees and disadvantaged individuals. It has earned many distinctions including "The Ivy League of IT Training," "1995 Fairfax Human Rights Award Winner," and " A Leader in Bridging the Digital Divide." "You are helping to empower America. I salute you for your ongoing commitment to creating a better America," --- President Clinton "This is an awesome opportunity." --- Washingtonjobs.com "Microsoft is pleased to play a part ... NEF can make a positive difference in the lives of a great number of individuals." --- Microsoft "I have found the CyberLearning online courses to be extremely easy and useful. I liked pre-course self-assessment and IT books online and available 24/7. The course screens were interactive and made me feel as if I was in the application itself. The site looks and feels very professional. The list of courses is huge. It includes something for almost everyone. I find this to be a very worthy cause." --- Ken Horowitz, IT Training Coordinator. From owner-ietf-smime-examples Tue Oct 24 17:03:21 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA18232 for ietf-smime-examples-bks; Tue, 24 Oct 2000 17:03:21 -0700 (PDT) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18163; Tue, 24 Oct 2000 17:00:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <200010241010.GAA02049@ietf.org> References: <200010241010.GAA02049@ietf.org> Date: Tue, 24 Oct 2000 17:06:36 -0700 To: ietf-smime@imc.org, ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: I-D ACTION:draft-ietf-smime-examples-04.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 6:10 AM -0400 10/24/00, 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 : Examples of S/MIME Messages > Author(s) : P. Hoffman > Filename : draft-ietf-smime-examples-04.txt > Pages : 8 > Date : 23-Oct-00 It's too bad that there is no emoticon for "really embarrassed". I put out this draft with essentially no changes from the -03 because the -03 expired a long time ago and I have completely ignored it. Well, I ignored in between feeling bad about it. But you get the picture. Because I had also lamely filed the comments people had sent me a year ago about -03 into different folders, I am not sure what need to be fixed. I know that much does need to be fixed, but I am not sure what. Please send (or, probably, re-send) all comments to me and the ietf-smime-examples@imc.org list. And I really, really promise to get -05 out before the cutoff for the San Diego IETF. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Tue Oct 24 17:46:49 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19000 for ietf-smime-examples-bks; Tue, 24 Oct 2000 17:46:49 -0700 (PDT) Received: from finch-post-10.mail.demon.net (finch-post-10.mail.demon.net [194.217.242.38]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA18994; Tue, 24 Oct 2000 17:46:46 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by finch-post-10.mail.demon.net with esmtp (Exim 2.12 #1) id 13oEnr-000PcX-0A; Wed, 25 Oct 2000 00:52:27 +0000 Message-ID: <39F62F21.C39633C5@celocom.com> Date: Wed, 25 Oct 2000 01:53:53 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime-examples@imc.org Subject: Re: I-D ACTION:draft-ietf-smime-examples-04.txt References: <200010241010.GAA02049@ietf.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman / IMC wrote: > > > Because I had also lamely filed the comments people had sent me a > year ago about -03 into different folders, I am not sure what need to > be fixed. I know that much does need to be fixed, but I am not sure > what. Please send (or, probably, re-send) all comments to me and the > ietf-smime-examples@imc.org list. And I really, really promise to get > -05 out before the cutoff for the San Diego IETF. > OK let me start with a comment I made ages ago about the DH parameters used in the certificates of the examples. I can't reproduce the DH parameters: that is using the algorithm of RFC2631 2.2.1 I cannot reproduce the parameters from the given seed and counter. It may be a problem with my implementation but I don't think so. To test my code I have asked everywhere I can think of for some independent test vectors that aren't equivalent to FIPS186 (DSS) parameter generation so far without success. My implementation works fine on FIPS186 compatible parameters. Various people have also stated that the parameter generation algorithm of RFC2631 is not exactly optimal and various other techniques are more efficient. I'm willing to do tests with anyone who has the relevant implementation or indeed give a step by step explanation as to why I think the parameters are incorrect. I consider this important because if we are including parameters in certificates with an invalid seed and counter then a compliant implementation would be perfectly justified in rejecting the certificates on those grounds. However if almost no one is implementing the RFC2631 parameter generation algorithm and confirmation cannot be obtained then IMHO it would be best if they were simply omitted from the certificates. A secondary issue is that if no one is implementing RFC2631 2.2.1 why are we saying that agents SHOULD use it? Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Sun Dec 3 15:40:16 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id PAA08772 for ietf-smime-examples-bks; Sun, 3 Dec 2000 15:40:16 -0800 (PST) Received: from powernet.com.eg (unassigned.future.com.eg [163.121.126.100] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08767 for ; Sun, 3 Dec 2000 15:40:13 -0800 (PST) From: bn1bn2@yahoo.com Received: from yNOh51hb0 [63.28.123.13] by powernet.com.eg (SMTPD32-5.00) id A86E4ED0120; Mon, 04 Dec 2000 01:34:06 +0200 DATE: 03 Dec 00 3:39:50 PM Message-ID: SUBJECT: Holiday Special: Don't miss the savings! Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hurry!!! Time is running out. Thinking of getting a laptop computer for the holidays, or any occasions... Brand new name brand notebooks at up to 35% savings, compare around than call us 1-800-644-9584. We have thousands Notebook PC, PDAs, Digital Cameras, Parts and Accessories in stock for the holiday, anything you need, we can get you the lower prices. C o m p a q ================================================== Compaq Armada M700 $2199 Intel PIII 650 MHz, 128MB, 12.0GB, 14.1in TFT, 24X CD-ROM, 56 Kbps, 10/100 Ethernet Card, Windows NT 4.0 Compaq Presario 1200-XL125 $1379 AMD K6-2 533 MHz, 64MB , 6.0GB, 13.3in TFT, 8X DVD-ROM, 56Kbps , WIN98se Compaq Presario 1200-XL300 $1095 Intel Celeron 600 MHz, 64MB, 6.0GB, 13in HPA, 24X CD-ROM, 56K , Windows ME Compaq Presario 1200-XL325 $1499 Intel PIII 650 MHz, 64MB, 6.0GB, 13.3in TFT, 8X DVD-ROM, 56K , Windows ME Compaq Presario 1700-XL360 $1799 Intel PIII 600 MHz, 64MB, 10.0GB, 14.1in TFT, 8X DVD-ROM, 56K , Windows ME H P ==================================================== HP Omni Book 6000 $3499 Intel PIII 850MHz , 128 MB , 20GB, 15.1in TFT, 8X DVD-ROM, 56Kbps, Windows 2000 HP Pavilion N5150 $1499 Intel PIII 600 MHz, 64MB, 10.0GB , 13.3in TFT, 8X DVD-ROM, 56Kbps, Windows Millennium Edition HP Pavilion N5170 $1599 Intel PIII 600 MHz , 64MB, 7.0GB , 14.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition HP Pavilion N5195 $2199 Intel PIII 700 MHz , 128MB , 20.0GB , 15.1in TFT, 8X DVD-ROM, 56Kbps, 10/100 Ethernet, Windows Millennium Edition S O N Y ==================================================== Sony VAIO PCG-F580 Notebook $2099 Intel PIII 650 MHz, 64MB, 12.0GB, 15.0in TFT, 8X DVD-ROM, 56K, Windows 98se Sony VAIO PCG-F650 Notebook $1889 Intel PIII 600 MHz, 64MB, 12.0GB, 14.1in TFT, 8X DVD-ROM, 56Kbps, Windows ME For more info or to place an order call: 1-800-644-9584 To Visit Our Site http://www.laptopland.com to find out more detail This message is being sent to you in compliance with the proposed Federal legislation for commercial e-mail (S.1618 - SECTION 301)."Pursuant to Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this e-mail may be stopped at no cost to you by submitting a request to be removed. INSTRUCTIONS- click here mailto:member9288@computerassociation.com?subject=removelist134 to be removed. From owner-ietf-smime-examples Wed Dec 6 20:58:10 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA23461 for ietf-smime-examples-bks; Wed, 6 Dec 2000 20:58:10 -0800 (PST) Received: from bsd.gymparnr.sk (bsd.gymparnr.sk [195.168.176.67]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA23449 for ; Wed, 6 Dec 2000 20:58:07 -0800 (PST) From: hjghjgjh@yahoo.com Received: (qmail 16795 invoked from network); 6 Dec 2000 00:18:29 -0000 Received: from 1cust62.tnt1.los-angeles.ca.da.uu.net (HELO 8hUwIj2m6?) (63.57.183.62) by bsd.gymparnr.sk with SMTP; 6 Dec 2000 00:18:29 -0000 DATE: 05 Dec 00 4:38:05 PM Message-ID: SUBJECT: 1+1=2 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Internet's Finest and Most Reliable Bulk Email Provider! Since 1996, Tech Data Technologies has provided bulk email service to thousands of well-satisfied customers. We offer the most competitive prices in the industry, made possible by our high percentage of repeat business. We have the most advanced, direct email technology, employed by only a knowledgeable few in the world. Our expert programmers have made it possible for us to penetrate any email blocking filter in use. We have over 120 million active email addresses, increasing our list at the rate of half a million to one million a month. We will put your product or service instantly and directly into the hands of millions of prospects! You will have instant, guaranteed results, something no other form of marketing can claim. Our turn around time is a remarkable 24 hours. Our email addresses are sorted by country, state and target. Your marketing campaign will speed with pinpoint accuracy to your desired audience! Your message can be presented in any language you wish, as plain text if you desire simplicity, or in html with color and graphics. Call us for a free consultation at (323)- 851- 8386 [U.S.A.]. We are open 24 hours a day, 7 days a week. No one understands the global market like we do. For a limited time, take advantage of our holiday special -- two million general U.S. emails for just $450 per million! We include, at no cost, a bullet proof email address for 30 days, a $400 value! BULK EMAIL PRICES 500,000........................$375 750,000........................$562 1,200,000........................$720 1,600,000.................. ...$960 3,000,000......................$1,500 3,000,000+ ...................PLEASE CALL FOR A QUOTE Resellers welcome. We accept Visa, MasterCard and check by FAX. DON'T WAIT! LET TECH DATA TECHNOLOGIES BE YOUR PARTNER!! Under Bill s.1618 TITLE III passed by the 105th U.S. Congress this letter is not considered "spam" as long as we include: 1) contact information and, 2) the way to be removed from future mailings (see below).To Remove Yourself From This List: reply to this email with the email address that you would like removed and the word REMOVE in the subject heading. From owner-ietf-smime-examples Mon Dec 25 09:57:14 2000 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10210 for ietf-smime-examples-bks; Mon, 25 Dec 2000 09:57:14 -0800 (PST) Received: from sem_mail.smkb.ac.il (skbb3.skb2.macam.ac.il [192.115.171.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09987; Mon, 25 Dec 2000 09:54:30 -0800 (PST) From: hj4hj6@yahoo.com Received: from U45m9Fab6 (1Cust34.tnt21.lax3.da.uu.net [63.28.123.34]) by sem_mail.smkb.ac.il with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id Y4M7R6CL; Thu, 21 Dec 2000 23:32:36 +0200 DATE: 21 Dec 00 1:39:38 PM Message-ID: SUBJECT: Improve your stepfamily life Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From owner-ietf-smime-examples Mon Jan 8 13:16:28 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA05774 for ietf-smime-examples-bks; Mon, 8 Jan 2001 13:16:28 -0800 (PST) Received: from mail.phaos.com ([206.30.74.234]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA05768; Mon, 8 Jan 2001 13:16:26 -0800 (PST) Received: from vamsi.phaos.com (pc228.starlan.com [206.30.74.228] (may be forged)) by mail.phaos.com (8.9.2/8.9.2) with ESMTP id UAA48493; Mon, 8 Jan 2001 20:23:48 -0500 (EST) (envelope-from vamsi@phaos.com) Message-Id: <4.3.2.7.2.20010108160040.00af7100@mail.phaos.com> X-Sender: vamsi@mail.phaos.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Jan 2001 16:14:04 -0500 To: ietf-smime-examples@imc.org From: Vamsi Motukuru Subject: message with a mlExpansionHistory attribute Cc: phoffman@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, In the ESS example 11.5 which is a message with the mlExpansionHistory attribute, the expansionTime field in the ASN1 type MLData contains a GeneralizedTime value which appears to be incorrect. Here is a portion of example 11.5. 749 30 234: SEQUENCE { 752 30 231: SEQUENCE { 755 04 7: OCTET STRING : 35 37 33 38 32 39 39 764 18 16: GeneralizedTime '199903111044330Z' 782 A1 201: [1] { 785 30 198: SEQUENCE { 788 A4 97: [4] { The GeneralizedTime value contains a "0" after the seconds value(33). I think this is not allowed in an ASN.1 GeneralizedTime but I could be wrong. Thanks, -- Vamsi From owner-ietf-smime-examples Tue Jan 9 10:54:04 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23866 for ietf-smime-examples-bks; Tue, 9 Jan 2001 10:54:04 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23859; Tue, 9 Jan 2001 10:54:02 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 9 Jan 2001 14:00:07 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BA8AE@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Vamsi Motukuru'" , ietf-smime-examples@imc.org Cc: phoffman@imc.org Subject: RE: message with a mlExpansionHistory attribute Date: Tue, 9 Jan 2001 14:00:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, Getronics Government Solutions generated the section 11.5 sample message included in the "Examples of S/MIME Messages" I-D. We agree that there should not be a trailing zero present in the GeneralizedTime value as per the X.690 DER rules. We will generate a new message with a corrected GeneralizedTime value for inclusion in the next version of the Examples I-D. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Vamsi Motukuru [mailto:vamsi@phaos.com] Sent: Monday, January 08, 2001 4:14 PM To: ietf-smime-examples@imc.org Cc: phoffman@imc.org Subject: message with a mlExpansionHistory attribute Hi, In the ESS example 11.5 which is a message with the mlExpansionHistory attribute, the expansionTime field in the ASN1 type MLData contains a GeneralizedTime value which appears to be incorrect. Here is a portion of example 11.5. 749 30 234: SEQUENCE { 752 30 231: SEQUENCE { 755 04 7: OCTET STRING : 35 37 33 38 32 39 39 764 18 16: GeneralizedTime '199903111044330Z' 782 A1 201: [1] { 785 30 198: SEQUENCE { 788 A4 97: [4] { The GeneralizedTime value contains a "0" after the seconds value(33). I think this is not allowed in an ASN.1 GeneralizedTime but I could be wrong. Thanks, -- Vamsi From owner-ietf-smime-examples Wed Jan 10 03:47:33 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id DAA22450 for ietf-smime-examples-bks; Wed, 10 Jan 2001 03:47:33 -0800 (PST) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA22445 for ; Wed, 10 Jan 2001 03:47:30 -0800 (PST) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id AAA10182 for ; Thu, 11 Jan 2001 00:52:29 +1300 (NZDT) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <97912754922830>; Thu, 11 Jan 2001 00:52:29 (NZDT) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime-examples@imc.org Subject: RE: message with a mlExpansionHistory attribute Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Thu, 11 Jan 2001 00:52:29 (NZDT) Message-ID: <97912754922830@kahu.cs.auckland.ac.nz> Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Pawling, John" writes: >Getronics Government Solutions generated the section 11.5 sample message >included in the "Examples of S/MIME Messages" I-D. We agree that there >should not be a trailing zero present in the GeneralizedTime value as per the >X.690 DER rules. We will generate a new message with a corrected >GeneralizedTime value for inclusion in the next version of the Examples I-D. [Snip] > 749 30 234: SEQUENCE { > 752 30 231: SEQUENCE { > 755 04 7: OCTET STRING > : 35 37 33 38 32 39 39 > 764 18 16: GeneralizedTime '199903111044330Z' > 782 A1 201: [1] { > 785 30 198: SEQUENCE { > 788 A4 97: [4] { Actually dumpasn1 should complain about that but from looking at the code I've only got it enabled for UTCTime, not GeneralizedTime. This will be fixed Real Soon Now (If I could get a copy of the original PDU I can use it to check that dumpasn1 will catch this). This also looks like output from a slightly older version, newer versions will identify the ASCII string hidden in the OCTET STRING and display it as text rather than hex. Peter. From owner-ietf-smime-examples Thu Jan 11 08:27:42 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04929 for ietf-smime-examples-bks; Thu, 11 Jan 2001 08:27:42 -0800 (PST) Received: from marcellus.entegrity.se (marcellus.entegrity.se [195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04853 for ; Thu, 11 Jan 2001 08:26:21 -0800 (PST) Received: from nelson ([10.0.0.38]) by marcellus.entegrity.se (8.9.3/8.9.3) with SMTP id RAA10029 for ; Thu, 11 Jan 2001 17:26:49 +0100 (MET) Reply-To: From: "Magnus Svensson" To: Subject: Issues with draft-ietf-smime-examples-05 Date: Thu, 11 Jan 2001 17:30:04 +0100 Message-ID: <000a01c07beb$c1546b00$2600000a@cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: When working with IETF's draft-ietf-smime-examples-05 I discovered some issues that I would like to present and probably needs to be fixed. If I am wrong I would appreciate if someone could explain it to me. - AliceRSASignByCarl.cer: The asn1dump of the certificate in the draft-text is not a correct representation of the binary certificate. The binary certificate has has a different OID for the signature algorithm identifier (sha-1WithRSAEncryption (1 3 14 3 2 29)) which also results in a different signature value. Alice's RSA certificate conveyed within the example messages (for example 5.2) has the OID that the draft-text specifies. If using the stand-alone binary certificate, this could lead to a conflict where you have two binary different certificates with the same issuer and serial number. I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs to be updated to be the same as the one present in the binary examples and the draft-text. - CRL's and nextUpdate field: None of the CRLs in the examples have the nextUpdate field present. I know that the field is optional in the ASN1 spec, but it is required to be present according to RFC 2459, sec 5.1.2.5. - example 6.2: The asn1dump of the example present in the draft-text is not a correct representation of the binary form of the 6.2 example. For example: before the asn1dump the draft-text declares that the example does not have an OriginatorInfo field, which is correct in the binary example but not according to the asn1dump that follows in the draft-text. There are also a lot of other differences but I will leave out those details. I suppose that the binary version of the example is the correct one and the asn1dump in the draft-text needs to be updated. If the binary version of the example is the correct one, there is an incorrect version number of the KeyTransRecipientInfo field. Since the RecipientIdentifier is of the IssuerAndSerialnumber choice the version number should be 0 and not 2 (RFC 2630, sec 6.2.1). Below is my asn1dump of the KeyTransRecipientInfo field of the binary version of the 6.2 example: 30 30 187: SEQUENCE { 33 02 1: INTEGER 2 36 30 38: SEQUENCE { 38 30 18: SEQUENCE { 40 31 16: SET { 42 30 14: SEQUENCE { 44 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 49 13 7: PrintableString 'CarlRSA' : } : } : } 58 02 16: INTEGER : 46 34 6B C7 80 00 56 BC 11 D3 6E 2E CD 5D 71 D0 : } 76 30 11: SEQUENCE { 78 06 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) : } 89 04 128: OCTET STRING : 45 1E C2 3C B5 4A DA DD CD F0 1F CF BE 2F 90 E4 : 54 DB 57 DC 87 40 E9 99 35 51 64 50 1B D0 5E 1C : 94 DC E9 9B 9F F8 B1 40 E4 F8 91 09 9D F8 F7 E5 : 19 DB 43 38 69 70 E7 67 36 E1 0E E6 4A 73 B0 DF : 19 AD 0E 47 4F 13 27 57 2C E9 81 F3 F1 A6 DF 1F : B6 B2 1D 32 D0 50 BE 0D 73 E1 D0 E3 27 FC 70 F4 : 05 8E DA D9 42 02 00 16 3F 64 26 45 9B F8 98 29 : 0C 68 09 94 E8 61 F9 09 4B 73 35 82 9A CE D0 8B : } Regards, Magnus Svensson From owner-ietf-smime-examples Thu Jan 11 10:23:52 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA15397 for ietf-smime-examples-bks; Thu, 11 Jan 2001 10:23:52 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA15392 for ; Thu, 11 Jan 2001 10:23:50 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 13:28:31 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BA8E6@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'magnus.svensson@entegrity.com'" , ietf-smime-examples@imc.org Subject: RE: Issues with draft-ietf-smime-examples-05 Date: Thu, 11 Jan 2001 13:30:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Magnus, Getronics Government Solutions generated the section 6.2 sample message included in the "Examples of S/MIME Messages" I-D (Examples-05). We agree that the section 6.2 sample message KeyTransRecipientInfo version number should be 0 (rather than 2) since the RecipientIdentifier is of the IssuerAndSerialnumber choice. We will generate a new message with a corrected version number for inclusion in the next version of the Examples I-D. The rest of your comments should be addressed by Paul Hoffman. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus@entegrity.se] Sent: Thursday, January 11, 2001 11:30 AM To: ietf-smime-examples@imc.org Subject: Issues with draft-ietf-smime-examples-05 When working with IETF's draft-ietf-smime-examples-05 I discovered some issues that I would like to present and probably needs to be fixed. If I am wrong I would appreciate if someone could explain it to me. - AliceRSASignByCarl.cer: The asn1dump of the certificate in the draft-text is not a correct representation of the binary certificate. The binary certificate has has a different OID for the signature algorithm identifier (sha-1WithRSAEncryption (1 3 14 3 2 29)) which also results in a different signature value. Alice's RSA certificate conveyed within the example messages (for example 5.2) has the OID that the draft-text specifies. If using the stand-alone binary certificate, this could lead to a conflict where you have two binary different certificates with the same issuer and serial number. I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs to be updated to be the same as the one present in the binary examples and the draft-text. - CRL's and nextUpdate field: None of the CRLs in the examples have the nextUpdate field present. I know that the field is optional in the ASN1 spec, but it is required to be present according to RFC 2459, sec 5.1.2.5. - example 6.2: The asn1dump of the example present in the draft-text is not a correct representation of the binary form of the 6.2 example. For example: before the asn1dump the draft-text declares that the example does not have an OriginatorInfo field, which is correct in the binary example but not according to the asn1dump that follows in the draft-text. There are also a lot of other differences but I will leave out those details. I suppose that the binary version of the example is the correct one and the asn1dump in the draft-text needs to be updated. If the binary version of the example is the correct one, there is an incorrect version number of the KeyTransRecipientInfo field. Since the RecipientIdentifier is of the IssuerAndSerialnumber choice the version number should be 0 and not 2 (RFC 2630, sec 6.2.1). Below is my asn1dump of the KeyTransRecipientInfo field of the binary version of the 6.2 example: 30 30 187: SEQUENCE { 33 02 1: INTEGER 2 36 30 38: SEQUENCE { 38 30 18: SEQUENCE { 40 31 16: SET { 42 30 14: SEQUENCE { 44 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 49 13 7: PrintableString 'CarlRSA' : } : } : } 58 02 16: INTEGER : 46 34 6B C7 80 00 56 BC 11 D3 6E 2E CD 5D 71 D0 : } 76 30 11: SEQUENCE { 78 06 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) : } 89 04 128: OCTET STRING : 45 1E C2 3C B5 4A DA DD CD F0 1F CF BE 2F 90 E4 : 54 DB 57 DC 87 40 E9 99 35 51 64 50 1B D0 5E 1C : 94 DC E9 9B 9F F8 B1 40 E4 F8 91 09 9D F8 F7 E5 : 19 DB 43 38 69 70 E7 67 36 E1 0E E6 4A 73 B0 DF : 19 AD 0E 47 4F 13 27 57 2C E9 81 F3 F1 A6 DF 1F : B6 B2 1D 32 D0 50 BE 0D 73 E1 D0 E3 27 FC 70 F4 : 05 8E DA D9 42 02 00 16 3F 64 26 45 9B F8 98 29 : 0C 68 09 94 E8 61 F9 09 4B 73 35 82 9A CE D0 8B : } Regards, Magnus Svensson From owner-ietf-smime-examples Sun Jan 14 11:22:42 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id LAA25055 for ietf-smime-examples-bks; Sun, 14 Jan 2001 11:22:42 -0800 (PST) Received: from [165.227.249.17] (ip17.proper.com [165.227.249.17]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA25050 for ; Sun, 14 Jan 2001 11:22:41 -0800 (PST) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: In-Reply-To: <000a01c07beb$c1546b00$2600000a@cost.se> References: <000a01c07beb$c1546b00$2600000a@cost.se> Date: Sun, 14 Jan 2001 11:26:44 -0800 To: ietf-smime-examples@imc.org From: Paul Hoffman / IMC Subject: Re: Issues with draft-ietf-smime-examples-05 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 5:30 PM +0100 1/11/01, Magnus Svensson wrote: >- AliceRSASignByCarl.cer: >The asn1dump of the certificate in the draft-text is not a correct >representation of the binary certificate. The binary certificate has has a >different OID for the signature algorithm identifier (sha-1WithRSAEncryption >(1 3 14 3 2 29)) which also results in a different signature value. >Alice's RSA certificate conveyed within the example messages (for example >5.2) has the OID that the draft-text specifies. If using the stand-alone >binary certificate, this could lead to a conflict where you have two binary >different certificates with the same issuer and serial number. >I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs >to be updated to be the same as the one present in the binary examples and >the draft-text. Sounds right to me. Jim Schaad: comments? >- CRL's and nextUpdate field: >None of the CRLs in the examples have the nextUpdate field present. I know >that the field is optional in the ASN1 spec, but it is required to be >present according to RFC 2459, sec 5.1.2.5. Major yuck. Jim, could you re-generate the CRLs so that conform to 2459? It's OK if the next update for the CRLs is 2010. :-) John Pawling has given me the updated examples for 6.2 and 11.5, so I'm just waiting for the above before putting out -06. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime-examples Mon Jan 15 05:35:31 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA24600 for ietf-smime-examples-bks; Mon, 15 Jan 2001 05:35:31 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id FAA24593 for ; Mon, 15 Jan 2001 05:35:29 -0800 (PST) Received: (qmail 9571 invoked by uid 0); 15 Jan 2001 13:40:21 -0000 Received: from dial-up-merc4.lviv.net (HELO alexey22) (194.44.63.100) by mail.gmx.net (mp010-rz3) with SMTP; 15 Jan 2001 13:40:21 -0000 From: "Alexei Shamov" To: Subject: More examples-05 issues Date: Mon, 15 Jan 2001 15:41:15 +0200 Message-ID: <000401c07ef8$d5a6c700$0200a8c0@alexey22> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi All, Testing examples-05 document, I have found some more issues as follows: 1. I was unable to decrypt some Diffie-Hellman enveloped messages (6.2, 6.9, 6.10) with User Keying Material specified in KeyAgreeRecipientInfo. Firstly, ukm is 1024 bits long (128 bytes) octet string. Should not it be 512 bits (64 bytes) as specified in RFC 2631 / 2.1.2? (Ahmed Bhamjee has already addressed this issue before). Secondly, in examples 6.2, 6.9 when RC2 CEK was wrapped with 3DES KEK, it seems that Triple-DES key wrap algorithm (RFC2630/12.6.2) was used (only 128-bit plain CEK appears after decryption, not LENGTH || CEK || PAD). Should not RC2 key wrap algorithm (RFC2630/12.6.4) be used? Example 6.10 failed at KeyCheck step of RC2 key unwrap. Perhaps this is a problem of my implementation (some debug information is attached to the end of this message). 2. MailingListRC2.bin file is 17 bytes long because of one extra '0d' byte. 3. BobPrivRSAEncrypt.pri is a copy of CarlPrivRSASign.pri. Correct version of the BobPrivRSAEncrypt.pri could be found in SFL examples at \smimeR1.8\test\CMS_MSExamples2.d\FirstSet.d\certs.d\private.d\BobPrivRSAEnc rypt.pri (635 bytes long). 4. In 6.2 and some other messages GeneralizedTime does not have century specified, as per RFC 2459/4.1.2.5.2. Is it acceptable? 01E1 A2 63: [2] { 01E3 02 1: INTEGER 4 01E6 30 22: SEQUENCE { 01E8 04 11: OCTET STRING 'MailListTripleDES' 01FB 18 D: GeneralizedTime '951230235959Z' : } Regards, Alexei P.S. Debug information for example 6.10 OtherInfo= 0000 30 A3: SEQUENCE { 0003 30 13: SEQUENCE { 0005 06 B: OBJECT IDENTIFIER : id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7) 0012 04 4: OCTET STRING : 00 00 00 01 : } 0018 A0 83: [0] { 001B 04 80: OCTET STRING : 17 2F 3B 6C DE 37 69 19 8A 7A 03 F2 DE A3 04 96 : 7E 0A 8E 30 3F 76 C8 58 3A 95 B0 46 98 23 50 82 : DC 46 52 6E 7C 5E 60 1B 3E B5 DC 2D 2D B7 1A EC : 13 70 8A 7B 83 73 4D 17 BE 93 4B 58 BC 66 D1 8B : 42 95 A7 E2 F1 9A 5B 08 61 16 88 E4 C2 AC DD 1A : 79 0D 37 FF A8 E6 7A AC 91 79 2F 2A 33 E1 E9 52 : 4F 18 AE 18 46 03 25 84 D1 13 E1 87 1B 48 80 74 : F3 33 23 68 1E CD 81 40 4A E9 83 02 2D 23 0B A2 : } 009E A2 6: [2] { 00A0 04 4: OCTET STRING : 00 00 00 80 : } : } ZZ = c2 5e 2c 49 65 6b 8e 28 36 45 9a 5c 54 f4 ce 64 0d 97 cc 0e ce 40 f3 4e ff 6c 9f 9a c8 76 c7 38 02 48 ec 39 c5 6b e1 6d 0a 73 ac cb cc 25 4b 6b b6 32 54 89 40 95 f7 64 06 99 d3 61 af 86 06 51 10 97 be 2a 2d 30 76 92 e6 26 8d 38 4b a6 7c cb 3c 68 4b f1 b4 44 6d 60 d3 b1 d7 13 4e 91 a1 96 48 c4 74 79 7e 1b 69 c5 43 52 11 cc b9 a0 93 4b e3 21 30 de 7a 98 85 c2 40 1c f4 b5 1f 4d 41 f2 KEK=95 cf 08 a6 f9 5c 97 a9 18 ae 3b ee 26 67 71 6a From owner-ietf-smime-examples Wed Jan 17 07:46:47 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA13589 for ietf-smime-examples-bks; Wed, 17 Jan 2001 07:46:47 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA13575 for ; Wed, 17 Jan 2001 07:46:44 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 10:51:54 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BA911@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Alexei Shamov'" , ietf-smime-examples@imc.org Cc: "Colestock, Robert" Subject: RE: More examples-05 issues Date: Wed, 17 Jan 2001 10:53:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0809D.9E7CE560" Sender: owner-ietf-smime-examples@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_000_01C0809D.9E7CE560 Content-Type: text/plain; charset="koi8-r" Alexei, Thank you very much for your feedback. Getronics Government Solutions generated the section 6.2, 6.9 and 6.10 sample messages included in the "Examples of S/MIME Messages" I-D (Examples-05). Please see my responses in-line. The rest of your comments should be addressed by Paul Hoffman. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Alexei Shamov [mailto:shamov@gmx.net] Sent: Monday, January 15, 2001 8:41 AM To: ietf-smime-examples@imc.org Subject: More examples-05 issues Hi All, Testing examples-05 document, I have found some more issues as follows: 1. I was unable to decrypt some Diffie-Hellman enveloped messages (6.2, 6.9, 6.10) with User Keying Material specified in KeyAgreeRecipientInfo. [JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for encrypting and RSA for key management, so I do not understand your above comment in relation to the section 6.2 sample. There was a bug reported in the section 6.2 SFL-generated sample message (incorrect KeyTransRecipientInfo version value). I have attached the message reporting the bug and the corrected section 6.2 sample message (6.2.bin).] Firstly, ukm is 1024 bits long (128 bytes) octet string. Should not it be 512 bits (64 bytes) as specified in RFC 2631 / 2.1.2? (Ahmed Bhamjee has already addressed this issue before). [JSP: In the sample messages for sections 6.9 and 6.10, you are correct that the size of partyAInfo contained in the OtherInfo sequence must be 512 bits in size. When Ahmed Bhamjee reported this error in the SFL (see attached message), we corrected the bug in the SFL, but we forgot to re-generate the sample messages for sections 6.9 and 6.10 including the incorrect partyAInfo values. We will generate corrected messages and provide them to the list as soon as possible.] Secondly, in examples 6.2, 6.9 when RC2 CEK was wrapped with 3DES KEK, it seems that Triple-DES key wrap algorithm (RFC2630/12.6.2) was used (only 128-bit plain CEK appears after decryption, not LENGTH || CEK || PAD). Should not RC2 key wrap algorithm (RFC2630/12.6.4) be used? [JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for encrypting and RSA for key management, so I do not understand your above comment in relation to the section 6.2 sample. In the section 6.9 sample message, a 3DES KEK is used, so the Triple-DES key wrap algorithm is used.] Example 6.10 failed at KeyCheck step of RC2 key unwrap. Perhaps this is a problem of my implementation (some debug information is attached to the end of this message). [JSP: We will reply to this comment in a later message.] 4. In 6.2 and some other messages GeneralizedTime does not have century specified, as per RFC 2459/4.1.2.5.2. Is it acceptable? [JSP: You are correct that GeneralizedTime must always specify the century. When we re-generate the sample message for section 6.9, we will ensure that the GeneralizedTime value is corrected. Also, we will re-generate the sample messages for section 6.11 to correct the GeneralizedTime value. We have already re-generated the sample message for section 11.5 to correct the GeneralizedTime value (attached). If you see any other incorrect GeneralizedTimes, please let us know. Please note that the X.509 certificates included in many of the sample messages (such as Section 6.2) include UTCTimes which (correctly) do not specify the century. ] 01E1 A2 63: [2] { 01E3 02 1: INTEGER 4 01E6 30 22: SEQUENCE { 01E8 04 11: OCTET STRING 'MailListTripleDES' 01FB 18 D: GeneralizedTime '951230235959Z' Regards, Alexei P.S. Debug information for example 6.10 OtherInfo= 0000 30 A3: SEQUENCE { 0003 30 13: SEQUENCE { 0005 06 B: OBJECT IDENTIFIER : id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7) 0012 04 4: OCTET STRING : 00 00 00 01 : } 0018 A0 83: [0] { 001B 04 80: OCTET STRING : 17 2F 3B 6C DE 37 69 19 8A 7A 03 F2 DE A3 04 96 : 7E 0A 8E 30 3F 76 C8 58 3A 95 B0 46 98 23 50 82 : DC 46 52 6E 7C 5E 60 1B 3E B5 DC 2D 2D B7 1A EC : 13 70 8A 7B 83 73 4D 17 BE 93 4B 58 BC 66 D1 8B : 42 95 A7 E2 F1 9A 5B 08 61 16 88 E4 C2 AC DD 1A : 79 0D 37 FF A8 E6 7A AC 91 79 2F 2A 33 E1 E9 52 : 4F 18 AE 18 46 03 25 84 D1 13 E1 87 1B 48 80 74 : F3 33 23 68 1E CD 81 40 4A E9 83 02 2D 23 0B A2 : } 009E A2 6: [2] { 00A0 04 4: OCTET STRING : 00 00 00 80 : } : } ZZ = c2 5e 2c 49 65 6b 8e 28 36 45 9a 5c 54 f4 ce 64 0d 97 cc 0e ce 40 f3 4e ff 6c 9f 9a c8 76 c7 38 02 48 ec 39 c5 6b e1 6d 0a 73 ac cb cc 25 4b 6b b6 32 54 89 40 95 f7 64 06 99 d3 61 af 86 06 51 10 97 be 2a 2d 30 76 92 e6 26 8d 38 4b a6 7c cb 3c 68 4b f1 b4 44 6d 60 d3 b1 d7 13 4e 91 a1 96 48 c4 74 79 7e 1b 69 c5 43 52 11 cc b9 a0 93 4b e3 21 30 de 7a 98 85 c2 40 1c f4 b5 1f 4d 41 f2 KEK=95 cf 08 a6 f9 5c 97 a9 18 ae 3b ee 26 67 71 6a ------_=_NextPart_000_01C0809D.9E7CE560 Content-Type: message/rfc822 Content-Description: More UKM size in the SMIME Freeware Library v1.8 Message-ID: <4B0D36365AD3D2118FF40060972A16C0019B1A57@wfhqex01.wangfed.com> From: "Pawling, John" To: "'imc-sfl@imc.org'" Subject: More UKM size in the SMIME Freeware Library v1.8 Date: Tue, 12 Dec 2000 13:55:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" All, Please note the additional change required to implement this fix. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Colestock, Robert To: 'Ahmed Bhamjee ' Cc: Pawling, John Sent: 12/12/2000 1:51 PM Subject: FW: UKM size in the SMIME Freeware Library v1.8 Ahmed: Since the 512 is a bit count, you must also modify the source in sm_free3.cpp to divide by 8 for the random number call. It ends up our old value used 1024 bits (the parameter to the SMTI_Random(...) routine takes a byte count). in ./alg_libs/sm_free3/sm_free3.cpp ... SME(SMTI_Random(NULL, pUKM, SM_FREE_RA_SIZE/8)); ... Bob Colestock VDA. -----Original Message----- From: Colestock, Robert Sent: Tuesday, December 12, 2000 12:41 PM To: 'imc-cml@imc.org'; 'Ahmed Bhamjee ' Subject: RE: UKM size in the SMIME Freeware Library v1.8 Ahmed: You are absolutely correct. I had to dig up the rfc2631 specification for DH to determine the actual UserKeyMaterial size. 128 byte length works fine, but is not correct to the specification. Thank you for pointing this out. If you wish to change your copy, simply update the variable "SM_FREE_RA_SIZE" in ./alg_libs/sm_free3/sm_free3.h from 128 to 512 and re-build. Our next release will have the updated size. This has been tested on ESDH operations and now produces the appropriate sized PartyAInfo structures (only used for the wrap hash). Thank you Bob Colestock VDA. -----Original Message----- From: Ahmed Bhamjee To: ietf-smime@imc.org Sent: 12/12/2000 6:18 AM Subject: UKM size in the SMIME Freeware Library v1.8 I have been testing our product with the latest SFL version. More specifically, I have performed tests using the Diffie-Hellman key agreement method. From the RFC (2631), the size of partyAInfo contained in the OtherInfo sequence must be 512 bits in size. However, the SFL produces keying material with partyAInfo set to 128 bytes. Should this not be 64 bytes? Perhaps I am missing something. Thanks Ahmed ------_=_NextPart_000_01C0809D.9E7CE560 Content-Type: message/rfc822 Content-Description: RE: Issues with draft-ietf-smime-examples-05 Message-ID: <0B95FB5619B3D411817E006008A592592BA8ED@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'magnus.svensson@entegrity.com'" , "'Paul Hoffman (E-mail)'" Subject: RE: Issues with draft-ietf-smime-examples-05 Date: Thu, 11 Jan 2001 15:03:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Magnus and Paul, Attached is the corrected section 6.2 sample message (includes KeyTransRecipientInfo version set to 0). We fixed the bug in the SFL that caused this problem. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Pawling, John [mailto:John.Pawling@GetronicsGov.com] Sent: Thursday, January 11, 2001 1:30 PM To: 'magnus.svensson@entegrity.com'; ietf-smime-examples@imc.org Subject: RE: Issues with draft-ietf-smime-examples-05 Magnus, Getronics Government Solutions generated the section 6.2 sample message included in the "Examples of S/MIME Messages" I-D (Examples-05). We agree that the section 6.2 sample message KeyTransRecipientInfo version number should be 0 (rather than 2) since the RecipientIdentifier is of the IssuerAndSerialnumber choice. We will generate a new message with a corrected version number for inclusion in the next version of the Examples I-D. The rest of your comments should be addressed by Paul Hoffman. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus@entegrity.se] Sent: Thursday, January 11, 2001 11:30 AM To: ietf-smime-examples@imc.org Subject: Issues with draft-ietf-smime-examples-05 When working with IETF's draft-ietf-smime-examples-05 I discovered some issues that I would like to present and probably needs to be fixed. If I am wrong I would appreciate if someone could explain it to me. - AliceRSASignByCarl.cer: The asn1dump of the certificate in the draft-text is not a correct representation of the binary certificate. The binary certificate has has a different OID for the signature algorithm identifier (sha-1WithRSAEncryption (1 3 14 3 2 29)) which also results in a different signature value. Alice's RSA certificate conveyed within the example messages (for example 5.2) has the OID that the draft-text specifies. If using the stand-alone binary certificate, this could lead to a conflict where you have two binary different certificates with the same issuer and serial number. I suppose that the stand-alone binary form ("AliceRSASignByCarl.cer") needs to be updated to be the same as the one present in the binary examples and the draft-text. - CRL's and nextUpdate field: None of the CRLs in the examples have the nextUpdate field present. I know that the field is optional in the ASN1 spec, but it is required to be present according to RFC 2459, sec 5.1.2.5. - example 6.2: The asn1dump of the example present in the draft-text is not a correct representation of the binary form of the 6.2 example. For example: before the asn1dump the draft-text declares that the example does not have an OriginatorInfo field, which is correct in the binary example but not according to the asn1dump that follows in the draft-text. There are also a lot of other differences but I will leave out those details. I suppose that the binary version of the example is the correct one and the asn1dump in the draft-text needs to be updated. If the binary version of the example is the correct one, there is an incorrect version number of the KeyTransRecipientInfo field. Since the RecipientIdentifier is of the IssuerAndSerialnumber choice the version number should be 0 and not 2 (RFC 2630, sec 6.2.1). Below is my asn1dump of the KeyTransRecipientInfo field of the binary version of the 6.2 example: 30 30 187: SEQUENCE { 33 02 1: INTEGER 2 36 30 38: SEQUENCE { 38 30 18: SEQUENCE { 40 31 16: SET { 42 30 14: SEQUENCE { 44 06 3: OBJECT IDENTIFIER commonName (2 5 4 3) 49 13 7: PrintableString 'CarlRSA' : } : } : } 58 02 16: INTEGER : 46 34 6B C7 80 00 56 BC 11 D3 6E 2E CD 5D 71 D0 : } 76 30 11: SEQUENCE { 78 06 9: OBJECT IDENTIFIER : rsaEncryption (1 2 840 113549 1 1 1) : } 89 04 128: OCTET STRING : 45 1E C2 3C B5 4A DA DD CD F0 1F CF BE 2F 90 E4 : 54 DB 57 DC 87 40 E9 99 35 51 64 50 1B D0 5E 1C : 94 DC E9 9B 9F F8 B1 40 E4 F8 91 09 9D F8 F7 E5 : 19 DB 43 38 69 70 E7 67 36 E1 0E E6 4A 73 B0 DF : 19 AD 0E 47 4F 13 27 57 2C E9 81 F3 F1 A6 DF 1F : B6 B2 1D 32 D0 50 BE 0D 73 E1 D0 E3 27 FC 70 F4 : 05 8E DA D9 42 02 00 16 3F 64 26 45 9B F8 98 29 : 0C 68 09 94 E8 61 F9 09 4B 73 35 82 9A CE D0 8B : } Regards, Magnus Svensson ------_=_NextPart_000_01C0809D.9E7CE560 Content-Type: application/octet-stream; name="6.2.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.2.bin" MIIHjgYJKoZIhvcNAQcDoIIHfzCCB3sCAQKgggX2oIIFgTCCApswggJaoAMCAQICAQEwCQYHKoZI zjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDTk5MDgxNjIyNTA1MFoXDTM5MTIzMTIzNTk1OVow EjEQMA4GA1UEAxMHQ2FybERTUzCCAbcwggErBgcqhkjOOAQBMIIBHgKBgQC2SRg+ikTBKXGUTAHE EsF6ectUTasegfvGTLMOlAkG6wHUschxS8dFwFAlXZz82uRt0+KGSISCfboVlUoW9kbt3faY0rt+ igqKuhZ7uVABSJOL6yUVUZdV3I9TDhCpUPxwt80wVP3a3qiqIrWhr4vMAojni3Bfua3hCNRtKS3W 6QIVAN3BL99Tzgs0YHc+AqS/il2YuRDVAoGADO5Xm0u92rYHanQ3T1V/ne28YQ3rRlk8VgsrWwyR zqViUmnK4W0+vb/+4be5K2E8rcuuReMGrIwinZxEhwvHzfAc2bVOXXPerw7JHVpR9U9EeTVac6p/ RlEfqUIWnEjrinlhtNUvUyJEYx+GuKNYBiX4KcDvuuB18ELEY2VSmwoDgYUAAoGBAJmHdCcDZqCx wK3cLHW74WxEnNohbU1HbbFiCenYrh7yOrSUsaOOeptxTgCUybQlTrlglhkkAfNiDP51wPvO2GgA 4/3VcE/fI5YZBpT0sWGPOlexCBGkCyYl8FJ2geoLYg2VKuaGunKyp1CDC6onzRupTYma140YOYQ/ i8VWTYB6o0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUcEQ+ gi5vh95K03XjPSC8QyuT8R8wCQYHKoZIzjgEAwMwADAtAhRrqfBOelp54/m+PSvJBjfpERehEwIV AI80aSqLsTwDeZQyTRIfzon7RrI7MIIC3jCCAp2gAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYD VQQDEwdDYXJsRFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMI QWxpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxT xauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/d Q6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4 E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjA e6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3qnMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVK U1a14vlz7BphNh8Rf8K97dFQ/5h0wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23 ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8iSr Uxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTyg+W4o4GDMIGA MCAGA1UdEQQZMBeBFWFsaWNlRHNzQGV4YW1wbGVzLmNvbTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB /wQEAwIGwDAfBgNVHSMEGDAWgBRwRD6CLm+H3krTdeM9ILxDK5PxHzAdBgNVHQ4EFgQUvmyhs+PB 9+1DcKTOEwHi/eOX/s0wCQYHKoZIzjgEAwMwADAtAhUAmLDGP89xR1o1qUqPwPgkBehGlI4CFFuf SMCMocECnETq6aGHwaV/KC27oW8wbTAuMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERTUxcN OTkwODIwMDcwMDAwWjAJBgcqhkjOOAQDAzAAMC0CFGI/NhcxWC5nUHn1CUuMrdRr9GSfAhUAtTtO oUx7/Q/DjZu2/sNdb95lKH0xgb4wgbsCAQAwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABW vBHTbi7NXXHQMAsGCSqGSIb3DQEBAQSBgDdEnKVIo5C7UX4co72ZYuUxPz7LAHNNU5e8PdRW4ObC ITN0TbV7aU99zxNymhZdfUZ0TdHoUuvp4A1GBpWrEzMsPqZlO5vdDFUAHG6pGUSDl098c67sh99G O+Igzoishaa6Dh7QAP/Q1iiY8qb8RDnHGGlC64SygILsl6o4gm4GMEMGCSqGSIb3DQEHATAUBggq hkiG9w0DBwQII9+urs/vIIyAIAhLH1OEQKCYohzXr7CadYPYHlwFCrH0MfFMIAp565x8oXYwOAYD KqszMTEEL1RoaXMgaXMgYSB0ZXN0IEdlbmVyYWwgQVNOIEF0dHJpYnV0ZSwgbnVtYmVyIDEuMDoG CyqGSIb3DQEJEAIEMSswKQwgQ29udGVudCBIaW50cyBEZXNjcmlwdGlvbiBCdWZmZXIGBSoDBgUE ------_=_NextPart_000_01C0809D.9E7CE560 Content-Type: application/octet-stream; name="11.5.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="11.5.bin" MIIFFgYJKoZIhvcNAQcCoIIFBzCCBQMCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQcVGhp cyBpcyBzb21lIHNhbXBsZSBjb250ZW50LjGCBMQwggTAAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT UwICAMgwBwYFKw4DAhqgggRbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkE MRYEFEBq7AhSebpuFgItngYpwCKWh91IMDgGAyqrMzExBC9UaGlzIGlzIGEgdGVzdCBHZW5lcmFs IEFTTiBBdHRyaWJ1dGUsIG51bWJlciAxLjA6BgsqhkiG9w0BCRACBDErMCkMIENvbnRlbnQgSGlu dHMgRGVzY3JpcHRpb24gQnVmZmVyBgUqAwYFBDBKBgkqhkiG9w0BCQ8xPTA7MAcGBSoDBAUGMDAG BioDBAUGTQQmU21pbWUgQ2FwYWJpbGl0aWVzIHBhcmFtZXRlcnMgYnVmZmVyIDIwbQYLKoZIhvcN AQkQAgIxXjFcAgEBBgcqAwQFBgcIMTEwL4AIKgMEBQYHhnihIxMhVEhJUyBJUyBBIFRFU1QgU0VD VVJJVFktQ0FURUdPUlkuExtUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QwbwYLKoZIhvcNAQkQ AgoxYDBeBgUqAwQFBgQrQ29udGVudCBSZWZlcmVuY2UgQ29udGVudCBJZGVudGlmaWVyIEJ1ZmZl cgQoQ29udGVudCBSZWZlcmVuY2UgU2lnbmF0dXJlIFZhbHVlIEJ1ZmZlcjBzBgsqhkiG9w0BCRAC CzFkoGIwWjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVVTIEdvdmVybm1lbnQxETAPBgNVBAsTCFZE QSBTaXRlMQwwCgYDVQQLEwNWREExEjAQBgNVBAMTCURhaXN5IFJTQQIEClVEMzCB/AYLKoZIhvcN AQkQAgMxgewwgekwgeYEBzU3MzgyOTkYDzE5OTkwMzExMTA0NDMzWqGByTCBxqRhMF8xCzAJBgNV BAYTAlVTMRYwFAYDVQQKEw1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UE CxMDVkRBMRcwFQYDVQQDEw5CdWdzIEJ1bm55IERTQaRhMF8xCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UECxMDVkRBMRcwFQYDVQQD Ew5FbG1lciBGdWRkIERTQTCCAQIGCyqGSIb3DQEJEAIJMYHyMIHvMXICAQEGByoDBAUGBwkxPDA6 gAgqAwQFBgeGeKEuEyxFUVVJVkFMRU5UIFRISVMgSVMgQSBURVNUIFNFQ1VSSVRZLUNBVEVHT1JZ LhMmRVFVSVZBTEVOVCBUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QxeQIBAQYHKgMEBQYHCjE8 MDqACCoDBAUGB4Z4oS4TLEVRVUlWQUxFTlQgVEhJUyBJUyBBIFRFU1QgU0VDVVJJVFktQ0FURUdP UlkuEy1FUVVJVkFMRU5UIFRISVMgSVMgQSBTRUNPTkQgUFJJVkFDWSBNQVJLIFRFU1QwCQYHKoZI zjgEAQQuMCwCFCUrMMtCrl1l/6lyZJfAVCEG4i4LAhQHYaEkvnOUX2P9kg0uwjV9m3sOJw== ------_=_NextPart_000_01C0809D.9E7CE560-- From owner-ietf-smime-examples Wed Jan 17 08:42:27 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16532 for ietf-smime-examples-bks; Wed, 17 Jan 2001 08:42:27 -0800 (PST) Received: from arcg01.arcasia.com ([202.42.197.44]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA16479; Wed, 17 Jan 2001 08:42:21 -0800 (PST) From: bk12bk27@yahoo.com Received: from 0JqeNwI9Y ([216.214.106.162]) by arcg01.arcasia.com (Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) with SMTP id 482569D7.000DBADA; Wed, 17 Jan 2001 10:30:29 +0800 DATE: 16 Jan 01 6:44:00 PM Message-ID: <9jO317Socq40fd> SUBJECT: RE; THANK YOU Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Friend and Partner, Think of all the things you could do if you had more free time and money wasn't an object What kind of car would you be driving? Where would you live? Where would you go on vacation? Now, for a limited time, 300+ money making and saving secrets can be yours for less than $10.00. Click here http://www.300moneysecrets.com/ and ORDER NOW!!!!!!!!!!!!!! Get information now, that could make you millions!!!! ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** To be removed from our mailing list, please email sandywho1212@yahoo.com All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received. From owner-ietf-smime-examples Wed Jan 17 09:00:30 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17396 for ietf-smime-examples-bks; Wed, 17 Jan 2001 09:00:30 -0800 (PST) Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA17391 for ; Wed, 17 Jan 2001 09:00:29 -0800 (PST) Received: (qmail 18675 invoked by uid 0); 17 Jan 2001 17:05:33 -0000 Received: from dial-up-merc0.lviv.net (HELO alexey22) (194.44.63.96) by mail.gmx.net (mp013-rz3) with SMTP; 17 Jan 2001 17:05:33 -0000 From: "Alexei Shamov" To: "'Pawling, John'" , Cc: "'Colestock, Robert'" Subject: RE: More examples-05 issues Date: Wed, 17 Jan 2001 19:06:34 +0200 Message-ID: <000001c080a7$d9885c20$0200a8c0@alexey22> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <0B95FB5619B3D411817E006008A592592BA911@wfhqex06.gfgsi.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi John, Thank you for the update. Please find my comments below. >[JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for >encrypting and RSA for key management, so I do not understand your above >comment in relation to the section 6.2 sample. There was a bug reported in >the section 6.2 SFL-generated sample message (incorrect >KeyTransRecipientInfo version value). I have attached the message reporting >the bug and the corrected section 6.2 sample message (6.2.bin).] I have problems with 6.2 because Base64 representation of 6.2 is the same as of 6.9 in examples-05. Updated version is fine. >[JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for >encrypting and RSA for key management, so I do not understand your above >comment in relation to the section 6.2 sample. In the section 6.9 sample >message, a 3DES KEK is used, so the Triple-DES key wrap algorithm is used.] RFC 2630 does not explicitly define which algorithm should be used in mixed cases, when RC2 CEK is wrapped with 3DES KEK. However, 3DES key wrap can not be used in 6.9 because of the following: 1. 3DES unwrap algorithm MUST fail at 12.6.3.1 simply because ciphertext is not 40 bytes long. 2. 3DES key parity adjustment/verification does not make sence for RC2 CEK. I think that wrap algorithm should be selected according to CEK algoritm, not KEK algorithm (ie RC2 key wrap (12.6.4) should be used with RC2 CEK, and 3DES key wrap (12.6.2) with 3DES CEK). Btw. in the KEKRecipientInfo of the same message rc2 key wrap was correcly selected: 01E1 A2 63: [2] { 01E3 02 1: INTEGER 4 01E6 30 22: SEQUENCE { 01E8 04 11: OCTET STRING 'MailListTripleDES' 01FB 18 D: GeneralizedTime '951230235959Z' : } 020A 30 10: SEQUENCE { 020C 06 B: OBJECT IDENTIFIER : id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7) 0219 02 1: INTEGER 58 : } Regards, Alexei From owner-ietf-smime-examples Wed Jan 17 09:48:46 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id JAA19996 for ietf-smime-examples-bks; Wed, 17 Jan 2001 09:48:46 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA19991 for ; Wed, 17 Jan 2001 09:48:44 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 17 Jan 2001 12:55:30 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BA91E@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Alexei Shamov'" , ietf-smime-examples@imc.org Cc: "Colestock, Robert" Subject: RE: More examples-05 issues Date: Wed, 17 Jan 2001 12:55:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Alexei, I am glad to here that the updated 6.2.bin file worked as expected. We agree that RFC 2630 does not explicitly define which key wrap algorithm should be used in mixed cases such as when an RC2 CEK is wrapped with 3DES KEK. We also agree that the key wrap algorithm must be selected based on the CEK algorithm (i.e. RC2 key wrap must be used with RC2 CEK and 3DES key wrap must be used with 3DES CEK). We will use the S/MIME Freeware Library (SFL) to generate a new section 6.9 sample message using the RC2 key wrap algorithm to wrap the RC2 CEK. The SFL allows the calling application to select the KEK algorithm and the key wrap algorithm separately from the content encryption algorithm. We will enhance the SFL to force compliance that the key wrap algorithm must be selected based on the CEK algorithm. Thank you again for your feedback!! =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Alexei Shamov [mailto:shamov@gmx.net] Sent: Wednesday, January 17, 2001 12:07 PM To: 'Pawling, John'; ietf-smime-examples@imc.org Cc: 'Colestock, Robert' Subject: RE: More examples-05 issues Hi John, Thank you for the update. Please find my comments below. >[JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for >encrypting and RSA for key management, so I do not understand your above >comment in relation to the section 6.2 sample. In the section 6.9 sample >message, a 3DES KEK is used, so the Triple-DES key wrap algorithm is used.] RFC 2630 does not explicitly define which algorithm should be used in mixed cases, when RC2 CEK is wrapped with 3DES KEK. However, 3DES key wrap can not be used in 6.9 because of the following: 1. 3DES unwrap algorithm MUST fail at 12.6.3.1 simply because ciphertext is not 40 bytes long. 2. 3DES key parity adjustment/verification does not make sence for RC2 CEK. I think that wrap algorithm should be selected according to CEK algoritm, not KEK algorithm (ie RC2 key wrap (12.6.4) should be used with RC2 CEK, and 3DES key wrap (12.6.2) with 3DES CEK). Btw. in the KEKRecipientInfo of the same message rc2 key wrap was correcly selected: 01E1 A2 63: [2] { 01E3 02 1: INTEGER 4 01E6 30 22: SEQUENCE { 01E8 04 11: OCTET STRING 'MailListTripleDES' 01FB 18 D: GeneralizedTime '951230235959Z' : } 020A 30 10: SEQUENCE { 020C 06 B: OBJECT IDENTIFIER : id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7) 0219 02 1: INTEGER 58 : } Regards, Alexei From owner-ietf-smime-examples Thu Jan 18 05:44:04 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id FAA07981 for ietf-smime-examples-bks; Thu, 18 Jan 2001 05:44:04 -0800 (PST) Received: from marcellus.entegrity.se (marcellus.entegrity.se [195.100.88.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA07967 for ; Thu, 18 Jan 2001 05:44:01 -0800 (PST) Received: from nelson ([10.0.0.38]) by marcellus.entegrity.se (8.9.3/8.9.3) with SMTP id OAA03628; Thu, 18 Jan 2001 14:44:56 +0100 (MET) Reply-To: From: "Magnus Svensson" To: "'Pawling, John'" , Subject: RE: More examples-05 issues Date: Thu, 18 Jan 2001 14:48:13 +0100 Message-ID: <002001c08155$4e31be60$2600000a@cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 In-Reply-To: <0B95FB5619B3D411817E006008A592592BA911@wfhqex06.gfgsi.com> Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, After investigating your new 6.2 example I found that it has an OriginatorInfo structure, and thus contradicting the draft description of the example. The draft description is included below for reference: ---- 6.2 Basic encrypted content, TripleDES and RSA Same as 6.1, except with RSA for key management. An EnvelopedData from Alice to Bob of ExContent using TripleDES for encrypting and RSA for key management. Does not have a OriginatorInfo, and has unprotected attributes." ---- Furthermore the OriginatorInfo contains DSS certificates & CRLs for Alice and Carl. This is obvously of not much use since the example uses RSA for key management. In my opinion the 6.1 and 6.2 examples should not contain any optional information fields since they are basic examples. They should just stick to the basic requirements. If the unprotected attributes are also removed from the example it would actually also be backwards compatible to the PKCS#7 spec. Do you agree with me John? This is just my personal opinion, but the inconsistency with the OriginatorInfo field needs to be solved anyway. Regards, Magnus -----Original Message----- From: owner-ietf-smime-examples@mail.imc.org [mailto:owner-ietf-smime-examples@mail.imc.org]On Behalf Of Pawling, John Sent: Wednesday, January 17, 2001 4:53 PM To: 'Alexei Shamov'; ietf-smime-examples@imc.org Cc: Colestock, Robert Subject: RE: More examples-05 issues Alexei, Thank you very much for your feedback. Getronics Government Solutions generated the section 6.2, 6.9 and 6.10 sample messages included in the "Examples of S/MIME Messages" I-D (Examples-05). Please see my responses in-line. The rest of your comments should be addressed by Paul Hoffman. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Alexei Shamov [mailto:shamov@gmx.net] Sent: Monday, January 15, 2001 8:41 AM To: ietf-smime-examples@imc.org Subject: More examples-05 issues Hi All, Testing examples-05 document, I have found some more issues as follows: 1. I was unable to decrypt some Diffie-Hellman enveloped messages (6.2, 6.9, 6.10) with User Keying Material specified in KeyAgreeRecipientInfo. [JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for encrypting and RSA for key management, so I do not understand your above comment in relation to the section 6.2 sample. There was a bug reported in the section 6.2 SFL-generated sample message (incorrect KeyTransRecipientInfo version value). I have attached the message reporting the bug and the corrected section 6.2 sample message (6.2.bin).] Firstly, ukm is 1024 bits long (128 bytes) octet string. Should not it be 512 bits (64 bytes) as specified in RFC 2631 / 2.1.2? (Ahmed Bhamjee has already addressed this issue before). [JSP: In the sample messages for sections 6.9 and 6.10, you are correct that the size of partyAInfo contained in the OtherInfo sequence must be 512 bits in size. When Ahmed Bhamjee reported this error in the SFL (see attached message), we corrected the bug in the SFL, but we forgot to re-generate the sample messages for sections 6.9 and 6.10 including the incorrect partyAInfo values. We will generate corrected messages and provide them to the list as soon as possible.] Secondly, in examples 6.2, 6.9 when RC2 CEK was wrapped with 3DES KEK, it seems that Triple-DES key wrap algorithm (RFC2630/12.6.2) was used (only 128-bit plain CEK appears after decryption, not LENGTH || CEK || PAD). Should not RC2 key wrap algorithm (RFC2630/12.6.4) be used? [JSP: Section 6.2 contains a sample EnvelopedData using TripleDES for encrypting and RSA for key management, so I do not understand your above comment in relation to the section 6.2 sample. In the section 6.9 sample message, a 3DES KEK is used, so the Triple-DES key wrap algorithm is used.] Example 6.10 failed at KeyCheck step of RC2 key unwrap. Perhaps this is a problem of my implementation (some debug information is attached to the end of this message). [JSP: We will reply to this comment in a later message.] 4. In 6.2 and some other messages GeneralizedTime does not have century specified, as per RFC 2459/4.1.2.5.2. Is it acceptable? [JSP: You are correct that GeneralizedTime must always specify the century. When we re-generate the sample message for section 6.9, we will ensure that the GeneralizedTime value is corrected. Also, we will re-generate the sample messages for section 6.11 to correct the GeneralizedTime value. We have already re-generated the sample message for section 11.5 to correct the GeneralizedTime value (attached). If you see any other incorrect GeneralizedTimes, please let us know. Please note that the X.509 certificates included in many of the sample messages (such as Section 6.2) include UTCTimes which (correctly) do not specify the century. ] 01E1 A2 63: [2] { 01E3 02 1: INTEGER 4 01E6 30 22: SEQUENCE { 01E8 04 11: OCTET STRING 'MailListTripleDES' 01FB 18 D: GeneralizedTime '951230235959Z' Regards, Alexei P.S. Debug information for example 6.10 OtherInfo= 0000 30 A3: SEQUENCE { 0003 30 13: SEQUENCE { 0005 06 B: OBJECT IDENTIFIER : id-alg-CMSRC2wrap (1 2 840 113549 1 9 16 3 7) 0012 04 4: OCTET STRING : 00 00 00 01 : } 0018 A0 83: [0] { 001B 04 80: OCTET STRING : 17 2F 3B 6C DE 37 69 19 8A 7A 03 F2 DE A3 04 96 : 7E 0A 8E 30 3F 76 C8 58 3A 95 B0 46 98 23 50 82 : DC 46 52 6E 7C 5E 60 1B 3E B5 DC 2D 2D B7 1A EC : 13 70 8A 7B 83 73 4D 17 BE 93 4B 58 BC 66 D1 8B : 42 95 A7 E2 F1 9A 5B 08 61 16 88 E4 C2 AC DD 1A : 79 0D 37 FF A8 E6 7A AC 91 79 2F 2A 33 E1 E9 52 : 4F 18 AE 18 46 03 25 84 D1 13 E1 87 1B 48 80 74 : F3 33 23 68 1E CD 81 40 4A E9 83 02 2D 23 0B A2 : } 009E A2 6: [2] { 00A0 04 4: OCTET STRING : 00 00 00 80 : } : } ZZ = c2 5e 2c 49 65 6b 8e 28 36 45 9a 5c 54 f4 ce 64 0d 97 cc 0e ce 40 f3 4e ff 6c 9f 9a c8 76 c7 38 02 48 ec 39 c5 6b e1 6d 0a 73 ac cb cc 25 4b 6b b6 32 54 89 40 95 f7 64 06 99 d3 61 af 86 06 51 10 97 be 2a 2d 30 76 92 e6 26 8d 38 4b a6 7c cb 3c 68 4b f1 b4 44 6d 60 d3 b1 d7 13 4e 91 a1 96 48 c4 74 79 7e 1b 69 c5 43 52 11 cc b9 a0 93 4b e3 21 30 de 7a 98 85 c2 40 1c f4 b5 1f 4d 41 f2 KEK=95 cf 08 a6 f9 5c 97 a9 18 ae 3b ee 26 67 71 6a From owner-ietf-smime-examples Thu Jan 18 10:37:18 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA28381 for ietf-smime-examples-bks; Thu, 18 Jan 2001 10:37:18 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA28376 for ; Thu, 18 Jan 2001 10:37:17 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 18 Jan 2001 13:44:07 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BA930@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'magnus.svensson@entegrity.com'" , ietf-smime-examples@imc.org Cc: "Colestock, Robert" Subject: RE: More examples-05 issues Date: Thu, 18 Jan 2001 13:44:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Magnus, Thank you for your feedback. I agree that the section 6.2 sample message should not include OriginatorInfo or unprotected attributes. I agree that it is useful to have a sample message using RSA for key management and TripleDES for content encryption that minimizes the inclusion of optional fields. We will re-generate the 6.2 sample message and provide to the list. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus@entegrity.se] Sent: Thursday, January 18, 2001 8:48 AM To: 'Pawling, John'; ietf-smime-examples@imc.org Subject: RE: More examples-05 issues John, After investigating your new 6.2 example I found that it has an OriginatorInfo structure, and thus contradicting the draft description of the example. The draft description is included below for reference: ---- 6.2 Basic encrypted content, TripleDES and RSA Same as 6.1, except with RSA for key management. An EnvelopedData from Alice to Bob of ExContent using TripleDES for encrypting and RSA for key management. Does not have a OriginatorInfo, and has unprotected attributes." ---- Furthermore the OriginatorInfo contains DSS certificates & CRLs for Alice and Carl. This is obvously of not much use since the example uses RSA for key management. In my opinion the 6.1 and 6.2 examples should not contain any optional information fields since they are basic examples. They should just stick to the basic requirements. If the unprotected attributes are also removed from the example it would actually also be backwards compatible to the PKCS#7 spec. Do you agree with me John? This is just my personal opinion, but the inconsistency with the OriginatorInfo field needs to be solved anyway. Regards, Magnus From owner-ietf-smime-examples Thu Feb 1 13:34:22 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA06490 for ietf-smime-examples-bks; Thu, 1 Feb 2001 13:34:22 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA06485 for ; Thu, 1 Feb 2001 13:34:21 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 1 Feb 2001 16:44:34 -0500 Message-ID: <0B95FB5619B3D411817E006008A592592BAA16@wfhqex06.gfgsi.com> From: "Pawling, John" To: "SMIME Examples List (E-mail)" Subject: New Samples for Examples-06 I-D Date: Thu, 1 Feb 2001 16:44:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C08C98.2987FEF0" Sender: owner-ietf-smime-examples@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_000_01C08C98.2987FEF0 Content-Type: text/plain; charset="iso-8859-1" All, In reply to several e-mail messages, Getronics Government Solutions has used the S/MIME Freeware Library (SFL) to generate new versions of the following sample messages (attached). We propose that these messages should be included in the next release of the "Examples of S/MIME Messages" Internet-Draft. Thanks to all who provided feedback regarding our sample messages!! We look forward to further feedback. 1) Section 6.2: Corrected KeyTransRecipientInfo version value (now set to 0); removed originatorInfo field; removed unprotectedAttributes. 2) Section 6.9: Corrected partyAInfo value (64 bytes); corrected GeneralizedTime value (included century value); used RC2 key wrap algorithm to wrap the RC2 CEK; added unprotectedAttributes. 3) Section 6.10: Corrected partyAInfo value (64 bytes). 4) Section 6.11: Corrected the GeneralizedTime value (included century value). 5) Section 11.5: Corrected the GeneralizedTime value (removed trailing 0). =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== <<6.2.bin>> <<6.9.bin>> <<6.10.bin>> <<6.11.bin>> <<11.5.bin>> ------_=_NextPart_000_01C08C98.2987FEF0 Content-Type: application/octet-stream; name="6.2.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.2.bin" MIIBHAYJKoZIhvcNAQcDoIIBDTCCAQkCAQAxgb4wgbsCAQAwJjASMRAwDgYDVQQDEwdDYXJsUlNB AhBGNGvHgABWvBHTbi7NXXHQMAsGCSqGSIb3DQEBAQSBgJDxHGl+wYw6gx8aJ3wvoHdpeRMNppt1 pSGl761IvnB7ZkPI8PKUCud1PhLIkNExhlwde3ZfU5l4jW4dmXI8+CZMQmB0oErZLs5GgKeIw/0z sPpQ9auflDTxW4MeJI7Wj82QbVpRBSh6CU2Le56TN6AX+UYvG5CrPiwkWNGn5n6HMEMGCSqGSIb3 DQEHATAUBggqhkiG9w0DBwQIxETKjVy7kFKAIKt67M90ynBBEYOroPxchEFmXRH5dJ4sR60HBN6Z L2Am ------_=_NextPart_000_01C08C98.2987FEF0 Content-Type: application/octet-stream; name="6.9.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.9.bin" MIICzAYJKoZIhvcNAQcDoIICvTCCArkCAQIxggHwMIG7AgEAMCYwEjEQMA4GA1UEAxMHQ2FybFJT QQIQRjRrx4AAVrwR024uzV1x0DALBgkqhkiG9w0BAQEEgYACxsSW5xJUMAicOkypx01YU1p05xtj ifcjxyk/2oNez29Lhic87GXPAKZW2dD8pILFkd2gVYZdMKg5QUVzQ1lhiW4Kxddv9H8J7H18hat0 756vxWnMfr1yDqEPvgsxH6sGXBE+gzh7v+EJVBPLhZGThUumCkqhQQpvu4r2d7ZEJ6GByAIBA6Aa MBgwEjEQMA4GA1UEAxMHQ2FybERTUwICANShQgRAAS3ZwmxvrIxXGJhOvhH2I40LurfMv1EQVaLa 9SvyJQzdAre+jVzN9bK1yB/EiDX4wIPg6ZZyhpFu/nz5l0wbyjAbBgcqhkjOPgIBMBAGCyqGSIb3 DQEJEAMHAgE6MEYwRDAYMBIxEDAOBgNVBAMTB0NhcmxEU1MCAgDJBCjnlslYA6an/SIN674iN1am RzciWkn+AZHlHkDhUSfemgmdyJ1DbO0KomUCAQQwJAQRTWFpbExpc3RUcmlwbGVERVMYDzE5OTUx MjMwMjM1OTU5WjAQBgsqhkiG9w0BCRADBwIBOgQoNFY/1pcAsyqHeECl75zmRzxRYx7Nw3zDusEi 6uLC5xQAsUO3+T1UajBIBgkqhkiG9w0BBwEwGQYIKoZIhvcNAwIwDQIBOgQIvZv1SpB4+zSAIDLF VHuPLsv7kzi54d1VQZ5aH+xA/RsQ2C7cdRStzvDLoXYwOAYDKqszMTEEL1RoaXMgaXMgYSB0ZXN0 IEdlbmVyYWwgQVNOIEF0dHJpYnV0ZSwgbnVtYmVyIDEuMDoGCyqGSIb3DQEJEAIEMSswKQwgQ29u dGVudCBIaW50cyBEZXNjcmlwdGlvbiBCdWZmZXIGBSoDBgUE ------_=_NextPart_000_01C08C98.2987FEF0 Content-Type: application/octet-stream; name="6.10.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.10.bin" MIICwwYJKoZIhvcNAQcDoIICtDCCArACAQIxggJfoYICWwIBA6CCAaehggGjMIIBFwYHKoZIzj4C ATCCAQoCgYEA7CzNpO+aJi9ip7sjTd8rJcFo0p6pRVs28ZSJGq99ESSdPbk8KejXI4Azpp5FAruq zJ4oBZWgsxd2wfclNWECQZInDF6uSOXzbjjvkdHPN/6aQJfILTWenZPG+BWvP9p0OrfEk7W5u3Zs H6h+vDqqQwqBZPxj8HtxmPrAOHkQGjMCgYEAugvXdD3nNOVME6eVlrvx5GE3CPsSx/uckXcGmTXw SCSWMxIBfo3sC/aywGOnFcVelYaic8VJRjd5YP13BQlIm3CNPAX2zkQsf30bKxXd8wUvvoUgj435 tKBFdCv0O51CYjQnJ4GObw9eYoWJzO0hw5FwBlTucKiSVVtuGSJNYqcEAAOBhQACgYEA2dsVn6HH 55XtS3OoelWZJw7XWTnqOMtSjX8DhH7ueYFv2Wtd4TxbzjsfKCbUhUdz6K6Esj7Txay1XocgXAjs jkRDPN71SfY+c3B4FGC2ypj1vRLXi5NxXTh4GMt9i8AA8jdNnN8x0V5Dx25NxFoEs+WgFkmcNWyd M+lSgwjgRDGhQgRAtyk/u8zzy7ce+bpL+QzBJHCXeY4BxfqULHnSZwhqDhd9dCnj94Cs4akO9f43 f+fElOtjCd2sCWHx3FtNfBZmczAfBgsqhkiG9w0BCRADBTAQBgsqhkiG9w0BCRADBwIBOjBGMEQw GDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyQQodmupYn7dSnMAjpxqmT1TqeQDl9RKS2/enK8Xu7wf 2ND/WBbaTEPruDBIBgkqhkiG9w0BBwEwGQYIKoZIhvcNAwIwDQIBOgQIsipMrm4q07eAIAcUq4i8 xiudrTKzmOjUsCGLj5wOzcx7M8JLVr0zzmhA ------_=_NextPart_000_01C08C98.2987FEF0 Content-Type: application/octet-stream; name="6.11.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.11.bin" MIHBBgkqhkiG9w0BBwOggbMwgbACAQIxZqJkAgEEMCQEEU1haWxMaXN0VHJpcGxlREVTGA8xOTk1 MTIzMDIzNTk1OVowDwYLKoZIhvcNAQkQAwYFAAQodDHARVFMPC0u2mNQi67UrGTMla6vzQ+Mtkgf C0USTfukq8eDMEtprTBDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECEEecOx9VoDZgCDATH5uMelg REm54z4kptRYTV5lB2mlaak4831QyQmzwA== ------_=_NextPart_000_01C08C98.2987FEF0 Content-Type: application/octet-stream; name="11.5.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="11.5.bin" MIIFFgYJKoZIhvcNAQcCoIIFBzCCBQMCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQcVGhp cyBpcyBzb21lIHNhbXBsZSBjb250ZW50LjGCBMQwggTAAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT UwICAMgwBwYFKw4DAhqgggRbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkE MRYEFEBq7AhSebpuFgItngYpwCKWh91IMDgGAyqrMzExBC9UaGlzIGlzIGEgdGVzdCBHZW5lcmFs IEFTTiBBdHRyaWJ1dGUsIG51bWJlciAxLjA6BgsqhkiG9w0BCRACBDErMCkMIENvbnRlbnQgSGlu dHMgRGVzY3JpcHRpb24gQnVmZmVyBgUqAwYFBDBKBgkqhkiG9w0BCQ8xPTA7MAcGBSoDBAUGMDAG BioDBAUGTQQmU21pbWUgQ2FwYWJpbGl0aWVzIHBhcmFtZXRlcnMgYnVmZmVyIDIwbQYLKoZIhvcN AQkQAgIxXjFcAgEBBgcqAwQFBgcIMTEwL4AIKgMEBQYHhnihIxMhVEhJUyBJUyBBIFRFU1QgU0VD VVJJVFktQ0FURUdPUlkuExtUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QwbwYLKoZIhvcNAQkQ AgoxYDBeBgUqAwQFBgQrQ29udGVudCBSZWZlcmVuY2UgQ29udGVudCBJZGVudGlmaWVyIEJ1ZmZl cgQoQ29udGVudCBSZWZlcmVuY2UgU2lnbmF0dXJlIFZhbHVlIEJ1ZmZlcjBzBgsqhkiG9w0BCRAC CzFkoGIwWjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVVTIEdvdmVybm1lbnQxETAPBgNVBAsTCFZE QSBTaXRlMQwwCgYDVQQLEwNWREExEjAQBgNVBAMTCURhaXN5IFJTQQIEClVEMzCB/AYLKoZIhvcN AQkQAgMxgewwgekwgeYEBzU3MzgyOTkYDzE5OTkwMzExMTA0NDMzWqGByTCBxqRhMF8xCzAJBgNV BAYTAlVTMRYwFAYDVQQKEw1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UE CxMDVkRBMRcwFQYDVQQDEw5CdWdzIEJ1bm55IERTQaRhMF8xCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UECxMDVkRBMRcwFQYDVQQD Ew5FbG1lciBGdWRkIERTQTCCAQIGCyqGSIb3DQEJEAIJMYHyMIHvMXICAQEGByoDBAUGBwkxPDA6 gAgqAwQFBgeGeKEuEyxFUVVJVkFMRU5UIFRISVMgSVMgQSBURVNUIFNFQ1VSSVRZLUNBVEVHT1JZ LhMmRVFVSVZBTEVOVCBUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QxeQIBAQYHKgMEBQYHCjE8 MDqACCoDBAUGB4Z4oS4TLEVRVUlWQUxFTlQgVEhJUyBJUyBBIFRFU1QgU0VDVVJJVFktQ0FURUdP UlkuEy1FUVVJVkFMRU5UIFRISVMgSVMgQSBTRUNPTkQgUFJJVkFDWSBNQVJLIFRFU1QwCQYHKoZI zjgEAQQuMCwCFCUrMMtCrl1l/6lyZJfAVCEG4i4LAhQHYaEkvnOUX2P9kg0uwjV9m3sOJw== ------_=_NextPart_000_01C08C98.2987FEF0-- From owner-ietf-smime-examples Sun Feb 4 08:18:04 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA21630 for ietf-smime-examples-bks; Sun, 4 Feb 2001 08:18:04 -0800 (PST) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA21625 for ; Sun, 4 Feb 2001 08:18:03 -0800 (PST) Received: from nelson (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id D40J5QY0; Sun, 4 Feb 2001 08:23:28 -0800 From: "Magnus Svensson" To: "'Pawling, John'" , Subject: Incorrect OID used in example 6.1 Date: Sun, 4 Feb 2001 17:23:28 +0100 Message-ID: <000601c08ec6$cf437fb0$2600000a@cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: John, I think I discovered another error in the 6.1 example. The keyEncryptionAlgorithm in the KeyAgreeRecipientInfo structure is encoded as follows in the 6.1 example: SEQUENCE { OBJECT IDENTIFIER dhPublicNumber (1 2 840 10046 2 1) SEQUENCE { OBJECT IDENTIFIER '1 2 840 113549 1 9 16 3 6' NULL } } Since the 6.1 example uses Ephemeral-Static DH the keyEncryptionAlgorithm-identifier should not be dhPublicNumber as displayed above. According to CMS (RFC2630) section 12.3.1.1 the keyEncryptionAlgorithm-identifier should be the id-alg-ESDH (1 2 840 113549 1 9 16 3 6) instead. Regards, Magnus From owner-ietf-smime-examples Mon Feb 5 07:59:11 2001 Received: by ns.secondary.com (8.9.3/8.9.3) id HAA14783 for ietf-smime-examples-bks; Mon, 5 Feb 2001 07:59:11 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA14777 for ; Mon, 5 Feb 2001 07:59:10 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Feb 2001 11:09:41 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EB8B@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Magnus Svensson'" , ietf-smime-examples@imc.org Subject: RE: Incorrect OID used in example 6.1 Date: Mon, 5 Feb 2001 11:09:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Magnus, Thank you very much for your feedback. Jim Schaad created the 6.1 example included in the Examples-05 document. I agree with your comment that when using E-S D-H, the KeyAgreeRecipientInfo keyEncryptionAlgorithm OID must be id-alg-ESDH defined in RFC 2630, Section 12.3.1.1 (1 2 840 113549 1 9 16 3 5). Recommend that Jim should re-generate the 6.1 example using the correct KeyAgreeRecipientInfo keyEncryptionAlgorithm OID (or we could do it, if required). The same problem exists in the 6.9 example that we created. We will re-create the 6.9 example with the E-S D-H KeyAgreeRecipientInfo keyEncryptionAlgorithm OID set to id-alg-ESDH. Please note that our new 6.10 example correctly includes the E-S D-H KeyAgreeRecipientInfo keyEncryptionAlgorithm OID set to id-alg-ESDH. Thanks again, =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus.svensson@entegrity.com] Sent: Sunday, February 04, 2001 11:23 AM To: 'Pawling, John'; ietf-smime-examples@imc.org Subject: Incorrect OID used in example 6.1 John, I think I discovered another error in the 6.1 example. The keyEncryptionAlgorithm in the KeyAgreeRecipientInfo structure is encoded as follows in the 6.1 example: SEQUENCE { OBJECT IDENTIFIER dhPublicNumber (1 2 840 10046 2 1) SEQUENCE { OBJECT IDENTIFIER '1 2 840 113549 1 9 16 3 6' NULL } } Since the 6.1 example uses Ephemeral-Static DH the keyEncryptionAlgorithm-identifier should not be dhPublicNumber as displayed above. According to CMS (RFC2630) section 12.3.1.1 the keyEncryptionAlgorithm-identifier should be the id-alg-ESDH (1 2 840 113549 1 9 16 3 6) instead. Regards, Magnus From owner-ietf-smime-examples Thu Feb 8 07:52:48 2001 Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA26275 for ietf-smime-examples-bks; Thu, 8 Feb 2001 07:52:48 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26271 for ; Thu, 8 Feb 2001 07:52:46 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 8 Feb 2001 11:03:23 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EBD2@wfhqex06.gfgsi.com> From: "Pawling, John" To: "SMIME Examples List (E-mail)" Subject: New Corrected Samples for Examples-06 I-D Date: Thu, 8 Feb 2001 11:03:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C091E8.A925F090" Sender: owner-ietf-smime-examples@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_000_01C091E8.A925F090 Content-Type: text/plain; charset="iso-8859-1" All, In reply to several e-mail messages, Getronics Government Solutions has used the S/MIME Freeware Library (SFL) to generate new corrected versions of the following sample messages (attached). We propose that these messages should be included in the next release of the "Examples of S/MIME Messages" Internet-Draft. Thanks to all who provided feedback regarding our sample messages!! We look forward to further feedback. 1) Section 6.1: KeyAgreeRecipientInfo keyEncryptionAlgorithm OID set to id-alg-ESDH (1 2 840 113549 1 9 16 3 5) as defined in RFC 2630, Section 12.3.1.1. 2) Section 6.2: Corrected KeyTransRecipientInfo version value (now set to 0); removed OriginatorInfo field; removed unprotectedAttributes; included NULL parameter in KeyTransRecipientInfo keyEncryptionAlgorithm parameters field in conjunction with the rsaEncryption OID (1 2 840 113549 1 1 1}. 3) Section 6.9: Corrected partyAInfo value (64 bytes); corrected GeneralizedTime value (included century value); used RC2 key wrap algorithm to wrap the RC2 CEK; added unprotectedAttributes; KeyAgreeRecipientInfo keyEncryptionAlgorithm OID set to id-alg-ESDH; E-S D-H KeyAgreeRecipientInfo originatorPublicKey AlgorithmIdentifier parameter field set to absent in conjunction with the dh-public-number OID (1 2 840 10046 2 1}; included NULL parameter in KeyTransRecipientInfo keyEncryptionAlgorithm parameters field in conjunction with the rsaEncryption OID. 4) Section 6.10: Corrected partyAInfo value (64 bytes); E-S D-H KeyAgreeRecipientInfo originatorPublicKey AlgorithmIdentifier parameter field set to absent in conjunction with the dh-public-number OID. 5) Section 6.11: Corrected the GeneralizedTime value to include century value. (No new changes since 2/1/01) 6) Section 11.5: Corrected the GeneralizedTime value by removing trailing 0. (No new changes since 1/10/01) Thank you again for the feedback!! =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== <<6.1.bin>> <<6.2.bin>> <<6.9.bin>> <<6.10.bin>> <<6.11.bin>> <<11.5.bin>> ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="6.1.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.1.bin" MIIBqgYJKoZIhvcNAQcDoIIBmzCCAZcCAQIxggFLoYIBRwIBA6CBlaGBkjAJBgcqhkjOPgIBA4GE AAKBgES5JjITd62IzfWfS02pbP84YOuEq0Xmo/TilCeX8I0ppesfIZFoWDnI8knYmdtIqJ5HpZ4G vrT0oIYBEMRQ+7H1MYgSexUYcPhyCGVPUaejlhjoebSmbPG3emEm9q9NNEIi3YDzx0LOahyMpiTp VGqgZ7GA3ruwxP68RUzS7DV0oUIEQKl0xOmqedPOXHSk7aXbZfXAN9aB8QqTXySh25eW7oeLedvp BxEjznAkhDByAoPVfWDT1PanTUzC4In6zVkgopMwHgYLKoZIhvcNAQkQAwUwDwYLKoZIhvcNAQkQ AwYFADBGMEQwGDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyQQol6Icmx1yA0z6H87aroVJ4Q0yBJeA Q8sASWA2p91LDuXWqHu6ZpSXpzBDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECDfnftcWF8isgCBq 8riaWGWyrfQ6oDGyvfdSeusr+wR3D+JZxjO7Bf0M6g== ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="6.2.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.2.bin" MIIBHgYJKoZIhvcNAQcDoIIBDzCCAQsCAQAxgcAwgb0CAQAwJjASMRAwDgYDVQQDEwdDYXJsUlNB AhBGNGvHgABWvBHTbi7NXXHQMA0GCSqGSIb3DQEBAQUABIGAWVbrrp0wNgdTKuDx8i4gk9yu7eQz hfIarAWGIKldyMvwrD/9ZnH3Qv8sMFK8bbLW6Uq00Y29l1N5DaN5X65relGRj9Q9rFJmfsmLUDA7 b7WrbR7EGerQdyX3igKs9LfAbXQbKI7yYGHiejvDpLxOyIibeC5mft9cgqbUSej0T0gwQwYJKoZI hvcNAQcBMBQGCCqGSIb3DQMHBAhqRXOe7X0RN4Ag/Hc8dnMk9WOHdd17XMQQncrbBEeTlCeitIzg 14OaHkg= ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="6.9.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.9.bin" MIIDTwYJKoZIhvcNAQcDoIIDQDCCAzwCAQIxggJzMIG9AgEAMCYwEjEQMA4GA1UEAxMHQ2FybFJT QQIQRjRrx4AAVrwR024uzV1x0DANBgkqhkiG9w0BAQEFAASBgHzkUauC4LKrHIYCQHCIYfcX5025 l7RJDbSbCQe4vxr6tqS7Wm1TodUdBe5pQfYOryEcD7OwTb7JA1bqoJOFsarjnz7khfeLmx8I4WlP JDoajpMSZGEzlFbwxLn8Ec4GJhBlvxPIYhfns0CbfsM6/LsMZMfzflzyTxEhiw/fjKEuoYIBSAIB A6CBlaGBkjAJBgcqhkjOPgIBA4GEAAKBgBhPuiZ0uqGbkbtvVzUs5yBm5HTWlD/+LshmTKbFSIu/ N86owVkaB8HBj0hsieZuHjSYqDmMtZGurxplw9XBDgbowQOVE9/zfmQFpCxs693uFB/Tw/FgtMQB Mij/zOUKFGU1BG8J6bOBvVBVEcxB9j0zvax3WUOJXx3fxy8zE/nfoUIEQMMUEvE468aEMLgXTYIq psX9Fkz53Sl+rvZCCGtUaM/cPg/CtzETNMw9RGD28/eBP4EYoMJwowFUN8SOmamT5m8wHwYLKoZI hvcNAQkQAwUwEAYLKoZIhvcNAQkQAwcCATowRjBEMBgwEjEQMA4GA1UEAxMHQ2FybERTUwICAMkE KCiNfo1x+qd86aiNzQ1zhU3vnKnChOBEAdaR7OKRB33qDENYQANM1A6iZQIBBDAkBBFNYWlsTGlz dFRyaXBsZURFUxgPMTk5NTEyMzAyMzU5NTlaMBAGCyqGSIb3DQEJEAMHAgE6BCheqAQudhNRAo6M u/b2ukF7NNRCDA0Tn7KlgpA7Fa9ZVpusw0Fd7NwIMEgGCSqGSIb3DQEHATAZBggqhkiG9w0DAjAN AgE6BAiRYdUC/BhJcIAgKqQa0f9Js5Od3uwstSM7KQPSdDMiw9xoeYPeK1wbL8GhdjA4BgMqqzMx MQQvVGhpcyBpcyBhIHRlc3QgR2VuZXJhbCBBU04gQXR0cmlidXRlLCBudW1iZXIgMS4wOgYLKoZI hvcNAQkQAgQxKzApDCBDb250ZW50IEhpbnRzIERlc2NyaXB0aW9uIEJ1ZmZlcgYFKgMGBQQ= ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="6.10.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.10.bin" MIIBsQYJKoZIhvcNAQcDoIIBojCCAZ4CAQIxggFNoYIBSQIBA6CBlqGBkzAJBgcqhkjOPgIBA4GF AAKBgQCEy3SL/SU2RmtslVcF10MSGTHrNUAyZepHaqzMtJ8SO0LropuN03VtSG3bvVoT6pUX7KDI kI33VdtWxyVgEsG9c2VCjBWtLeiqrpfN67WLjTkCpOgnvMxzWkdnRqajkCKhwauflz/7+iFmCMyN naMWJp/nr+j0IW9T/KVxt9lcdqFCBED/6C5jBB679IBeUAOuXR93R2oh1ZvDBHUhTkyGfg67p5nr UlDH0/AVWWDNeb3aYB5O6RlpQKKA5jka6h30HSuGMB8GCyqGSIb3DQEJEAMFMBAGCyqGSIb3DQEJ EAMHAgE6MEYwRDAYMBIxEDAOBgNVBAMTB0NhcmxEU1MCAgDJBCi7DKvfor6gWgPTKhDKBZBYCXv0 2Z0vTiIp3kv8EGxmsBVUHHrfFgTBMEgGCSqGSIb3DQEHATAZBggqhkiG9w0DAjANAgE6BAiJlkHm w+OLRoAg9AXWII8dbvCbLAzgqRC3Gm/GB1YumhXxoFZzBIGHaVQ= ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="6.11.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.11.bin" MIHBBgkqhkiG9w0BBwOggbMwgbACAQIxZqJkAgEEMCQEEU1haWxMaXN0VHJpcGxlREVTGA8xOTk1 MTIzMDIzNTk1OVowDwYLKoZIhvcNAQkQAwYFAAQodDHARVFMPC0u2mNQi67UrGTMla6vzQ+Mtkgf C0USTfukq8eDMEtprTBDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECEEecOx9VoDZgCDATH5uMelg REm54z4kptRYTV5lB2mlaak4831QyQmzwA== ------_=_NextPart_000_01C091E8.A925F090 Content-Type: application/octet-stream; name="11.5.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="11.5.bin" MIIFFgYJKoZIhvcNAQcCoIIFBzCCBQMCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQcVGhp cyBpcyBzb21lIHNhbXBsZSBjb250ZW50LjGCBMQwggTAAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERT UwICAMgwBwYFKw4DAhqgggRbMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJKoZIhvcNAQkE MRYEFEBq7AhSebpuFgItngYpwCKWh91IMDgGAyqrMzExBC9UaGlzIGlzIGEgdGVzdCBHZW5lcmFs IEFTTiBBdHRyaWJ1dGUsIG51bWJlciAxLjA6BgsqhkiG9w0BCRACBDErMCkMIENvbnRlbnQgSGlu dHMgRGVzY3JpcHRpb24gQnVmZmVyBgUqAwYFBDBKBgkqhkiG9w0BCQ8xPTA7MAcGBSoDBAUGMDAG BioDBAUGTQQmU21pbWUgQ2FwYWJpbGl0aWVzIHBhcmFtZXRlcnMgYnVmZmVyIDIwbQYLKoZIhvcN AQkQAgIxXjFcAgEBBgcqAwQFBgcIMTEwL4AIKgMEBQYHhnihIxMhVEhJUyBJUyBBIFRFU1QgU0VD VVJJVFktQ0FURUdPUlkuExtUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QwbwYLKoZIhvcNAQkQ AgoxYDBeBgUqAwQFBgQrQ29udGVudCBSZWZlcmVuY2UgQ29udGVudCBJZGVudGlmaWVyIEJ1ZmZl cgQoQ29udGVudCBSZWZlcmVuY2UgU2lnbmF0dXJlIFZhbHVlIEJ1ZmZlcjBzBgsqhkiG9w0BCRAC CzFkoGIwWjELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVVTIEdvdmVybm1lbnQxETAPBgNVBAsTCFZE QSBTaXRlMQwwCgYDVQQLEwNWREExEjAQBgNVBAMTCURhaXN5IFJTQQIEClVEMzCB/AYLKoZIhvcN AQkQAgMxgewwgekwgeYEBzU3MzgyOTkYDzE5OTkwMzExMTA0NDMzWqGByTCBxqRhMF8xCzAJBgNV BAYTAlVTMRYwFAYDVQQKEw1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UE CxMDVkRBMRcwFQYDVQQDEw5CdWdzIEJ1bm55IERTQaRhMF8xCzAJBgNVBAYTAlVTMRYwFAYDVQQK Ew1VUyBHb3Zlcm5tZW50MREwDwYDVQQLEwhWREEgU2l0ZTEMMAoGA1UECxMDVkRBMRcwFQYDVQQD Ew5FbG1lciBGdWRkIERTQTCCAQIGCyqGSIb3DQEJEAIJMYHyMIHvMXICAQEGByoDBAUGBwkxPDA6 gAgqAwQFBgeGeKEuEyxFUVVJVkFMRU5UIFRISVMgSVMgQSBURVNUIFNFQ1VSSVRZLUNBVEVHT1JZ LhMmRVFVSVZBTEVOVCBUSElTIElTIEEgUFJJVkFDWSBNQVJLIFRFU1QxeQIBAQYHKgMEBQYHCjE8 MDqACCoDBAUGB4Z4oS4TLEVRVUlWQUxFTlQgVEhJUyBJUyBBIFRFU1QgU0VDVVJJVFktQ0FURUdP UlkuEy1FUVVJVkFMRU5UIFRISVMgSVMgQSBTRUNPTkQgUFJJVkFDWSBNQVJLIFRFU1QwCQYHKoZI zjgEAQQuMCwCFCUrMMtCrl1l/6lyZJfAVCEG4i4LAhQHYaEkvnOUX2P9kg0uwjV9m3sOJw== ------_=_NextPart_000_01C091E8.A925F090-- From owner-ietf-smime-examples Mon Feb 19 09:27:57 2001 Received: by above.proper.com (8.9.3/8.9.3) id JAA12557 for ietf-smime-examples-bks; Mon, 19 Feb 2001 09:27:57 -0800 (PST) Received: from mail.imc.org ([211.219.97.33]) by above.proper.com (8.9.3/8.9.3) with SMTP id JAA12548 for ; Mon, 19 Feb 2001 09:27:55 -0800 (PST) Message-Id: <200102191727.JAA12548@above.proper.com> From: Asian.Postcard Date: Tue, 20 Feb 2001 02:27:37 X-Mailer: Prospect Mailer 2000 To: ietf-smime-examples@imc.org Subject: You can send actual postcard from asia MIME-Version: 1.0 Content-Type: text/plain;charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: If you received an actual postcard from abroad¡¦. How do you feel ? We send it from Seoul Korea to your client in worldwide with a Korea stamp and oriental postcard with your handwritten messages. Your customer will think you are sending it from Korea with traveling, even if you are not there. a) customer's interest - say hello from the mystery world. b) customer's inspiration - your special concerns from abroad. c) unique experience - receiving news from the opposite side of the earth. d) hand-written message - think of them as a valued customer For most companies it means the difference between a sizeable profit margin and just getting by. A successful business requires good communication between the company and the client and the company showing that it cares about its clients. With our personalized postcards you have the opportunity to show that you care about the people who make your business profitable. Many companies have greeting cards that can be received electronically. Our company is not one of those. Even though we realize that we are in the electronic age we relate to how important an 'actual' postcard received at their home or office can be. Our postcards served handwritten so that they can be personable. These messages will relate that you care about their business and think of them as a valued customer. So why wait any longer to let your customers know how you feel about them Visit our website today at http://www.asiancard.com to let them know how important they are to you. Sincerely Jaeson Joe Asian postcard service postman@asiancard.com From owner-ietf-smime-examples Mon Mar 5 06:20:12 2001 Received: by above.proper.com (8.9.3/8.9.3) id GAA26280 for ietf-smime-examples-bks; Mon, 5 Mar 2001 06:20:12 -0800 (PST) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA26271 for ; Mon, 5 Mar 2001 06:20:08 -0800 (PST) Received: from nelson (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFRD8GGW; Mon, 5 Mar 2001 06:19:23 -0800 From: "Magnus Svensson" To: Subject: Old issues remaining in draft-ietf-smime-examples-06.txt Date: Mon, 5 Mar 2001 15:18:33 +0100 Message-ID: <002401c0a57f$2b0129a0$2600000a@cost.se> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I checked the draft-ietf-smime-examples-06.txt to verify that the issues I reported earlier had been fixed. Unfortunately some of them remains and I therefore list them here again: 1. Bob's private RSA key is incorrect. It is actually identical to Carl's private RSA key. This error is present in both the draft text (the ASN.1 text) and the binary file. As Alexei Shamov pointed out for some time ago, the correct key can be retrieved by downloading SFL and using the path \smimeR1.8\test\CMS_MSExamples2.d\FirstSet.d\certs.d\private.d\ BobPrivRSAEncrypt.pri. This is surely not a preferred solution, so I suggest that this issue really is fixed for the next draft. Finding this error is most probably a frustrating and timeconsuming effort if you are not aware of it's presence. 2. nextUpdate field is missing in all CRLs. I mentioned this problem in a previous mail but the problem is still present. The nextUpdate field is required to be present, see RFC 2459 section 5.1.2.5. 3. In the description of example 6.2 the draft text states: "Does not have a OriginatorInfo, and has unprotected attributes.". Since the example does not have unprotected attributes the draft text should state "Does not have an OriginatorInfo or unprotected attributes.". 4. Example 6.1. Listed below the ASN.1 text are additional information regarding the keys used in the example. This listing contains two CEKs. The CEK with the hex-sequence beginning with "CD4F7C8373..." is the correct one. The other one needs to be removed. 5. Alice's and Bob's RSA certificates distributed separately are different from those present within the messages. The first has a signature algorithm OID of sha-1WithRSAEncryption (1 3 14 3 2 29) and the latter sha1withRSAEncryption (1 2 840 113549 1 1 5). The draft text incorrectly declares the algorithm OID for the separate certificates to be sha1withRSAEncryption (1 2 840 113549 1 1 5). I suppose only the PKCS#1 (and PKIX) variant should be used. The PKCS#1 OID is sha1withRSAEncryption (1 2 840 113549 1 1 5). Regards, Magnus From owner-ietf-smime-examples Mon Mar 5 07:26:52 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id HAA29869 for ietf-smime-examples-bks; Mon, 5 Mar 2001 07:26:52 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA29865 for ; Mon, 5 Mar 2001 07:26:50 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 5 Mar 2001 10:30:02 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945ED49@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Magnus Svensson'" , ietf-smime-examples@imc.org Subject: RE: Old issues remaining in draft-ietf-smime-examples-06.txt Date: Mon, 5 Mar 2001 10:29:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0A589.22741770" Sender: owner-ietf-smime-examples@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_000_01C0A589.22741770 Content-Type: text/plain; charset="iso-8859-1" All, I confirmed that Magnus' comments #2 and #3 are correct. His other comments are probably accurate also, but I did not confirm. Regarding comment #1, attached is the BobPrivRSAEncrypt.pri file that we used with the SFL to generate the samples submitted for inclusion in the Examples-06 document. Regarding comment #3, agree with Magnus that Section 6.2 should state "does not have unprotected attributes." We intentionally omitted unprotected attributes when we created the 6.2 sample using the SFL. This was requested on the smime-examples mail list so that the 6.2 sample would be backwards-compatible with S/MIME v2. Jim Schaad was kind enough to generate the certificates and CRLs included in the Examples-06 document. Recommend that Jim work with Paul Hoffman to address Magnus' comments regarding the certificates and CRLs included in the Examples-06 document. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Magnus Svensson [mailto:magnus.svensson@entegrity.com] Sent: Monday, March 05, 2001 9:19 AM To: ietf-smime-examples@imc.org Subject: Old issues remaining in draft-ietf-smime-examples-06.txt I checked the draft-ietf-smime-examples-06.txt to verify that the issues I reported earlier had been fixed. Unfortunately some of them remains and I therefore list them here again: 1. Bob's private RSA key is incorrect. It is actually identical to Carl's private RSA key. This error is present in both the draft text (the ASN.1 text) and the binary file. As Alexei Shamov pointed out for some time ago, the correct key can be retrieved by downloading SFL and using the path \smimeR1.8\test\CMS_MSExamples2.d\FirstSet.d\certs.d\private.d\ BobPrivRSAEncrypt.pri. This is surely not a preferred solution, so I suggest that this issue really is fixed for the next draft. Finding this error is most probably a frustrating and timeconsuming effort if you are not aware of it's presence. 2. nextUpdate field is missing in all CRLs. I mentioned this problem in a previous mail but the problem is still present. The nextUpdate field is required to be present, see RFC 2459 section 5.1.2.5. 3. In the description of example 6.2 the draft text states: "Does not have a OriginatorInfo, and has unprotected attributes.". Since the example does not have unprotected attributes the draft text should state "Does not have an OriginatorInfo or unprotected attributes.". 4. Example 6.1. Listed below the ASN.1 text are additional information regarding the keys used in the example. This listing contains two CEKs. The CEK with the hex-sequence beginning with "CD4F7C8373..." is the correct one. The other one needs to be removed. 5. Alice's and Bob's RSA certificates distributed separately are different from those present within the messages. The first has a signature algorithm OID of sha-1WithRSAEncryption (1 3 14 3 2 29) and the latter sha1withRSAEncryption (1 2 840 113549 1 1 5). The draft text incorrectly declares the algorithm OID for the separate certificates to be sha1withRSAEncryption (1 2 840 113549 1 1 5). I suppose only the PKCS#1 (and PKIX) variant should be used. The PKCS#1 OID is sha1withRSAEncryption (1 2 840 113549 1 1 5). Regards, Magnus ------_=_NextPart_000_01C0A589.22741770 Content-Type: application/octet-stream; name="BobPrivRSAEncrypt.pri" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BobPrivRSAEncrypt.pri" MIICdgIBADANBgkqhkiG9w0BAQEFAASCAmAwggJcAgEAAoGBAORL/xi4JFf0d/9uc3uTcVy8MxqS knIj2EFG0M0ROgSzjq+Cnb1RHhd68nYsK4Y5p73XjRpT7OQA1ejsojax7eJQ4jIJij+fmSWPuE6r uX3VlmXaFqDFvg6uRFvvXvSnKcuC3axE6aqTlCkO+BjWyFde8nbE8hFgOLkbPB2XyWrxAgMBAAEC gYEArnPkW19bZlrJ18bvOF9TISovYv7eKZp6hmc2531ieHU9c6C8KQ7zj73Dycm2+LrWE5vDl3rK avC4hWVOD72nqPdUBkG969wgd5DfYZuab3Te6jvUnIdg7XaE8WowN9XgkBb4gEfDGWvtdXe6Su05 tl0CRztfG8gcq8vo9SY/pIECQQD/3wmgVgtCUp7ETZOzsEm73ueBfSiZ0LFIugs54Rx7IhgztkD2 v9yuHdChrQRxWmEKbjvOMNo2n2UlKbunDn8LAkEA5GloGF/5V9B8ZokPumMdcssgpIF2ZInNfdHC J6kurHpWmoUH2TADowOrf4iSUCQBqhsHHyBMt8l7Vve2wn6rcwJAVzZsj4wEdmy21O4kRAD4gOKv QgGpDxSE+OcA4I+MJ6QtX6LlbbVjwK1E6XaRpxlJLkb4d4VLO4cE8K/S2FQmlQJAZKEPrFV0G70N YXsXA82w5qcZHYCv8UFI2Bq2iBSgLHrFdtQPDh96KrJuNwSrOUVzukaoD42CXyIUBc+io/N8gwJA Jh4dHKGYK+TbOOhXbmtzGYhhOvp0SjaLR2hdUOsm4+p9m05lqa97q0sudlE9qNARq6PWqMAnNh1U C6qn0W2N+g== ------_=_NextPart_000_01C0A589.22741770-- From owner-ietf-smime-examples Thu Mar 15 19:53:14 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA27702 for ietf-smime-examples-bks; Thu, 15 Mar 2001 19:53:14 -0800 (PST) Received: from gandalf.trustpoint.com (gandalf.trustpoint.com [157.22.240.75]) by above.proper.com (8.9.3/8.9.3) with ESMTP id TAA27696 for ; Thu, 15 Mar 2001 19:53:09 -0800 (PST) Received: from ronald.certicom.com (ronald [10.1.6.23]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id TAA09704 for ; Thu, 15 Mar 2001 19:53:08 -0800 Received: (from ronald@localhost) by ronald.certicom.com (8.8.7/8.8.7) id TAA13221 for ietf-smime-examples@imc.org; Thu, 15 Mar 2001 19:53:04 -0800 Date: Thu, 15 Mar 2001 19:53:04 -0800 From: "Life is hard, and then you die" To: ietf-smime-examples@imc.org Subject: comments and corrections for draft-ietf-smime-examples-06 Message-ID: <20010315195304.E13107@trustpoint.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="FL5UXtIhxfXey3p5" X-Mailer: Mutt 1.0.1i Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --FL5UXtIhxfXey3p5 Content-Type: text/plain; charset=us-ascii While decoding the examples, I found what I believe are a few bugs. Specifically: 1) Example 6.7: the KEKIdentifier contains a GeneralizedTime of '951230235959Z', which not a valid GeneralizedTime - the year must be 4 digits long, i.e. '19951230235959Z'. 2) Examples 6.4 and 6.5: the OId for the DH key-agreement algorithm in the KeyAgreeRecipientInfo.keyEncryptionAlgorithm field is given as 1.2.840.10046.2.1; however, rfc-2630, section 12.3.1.1 states that the OId must be 1.2.840.113549.1.9.16.3.5 . 3) Example 7.0, DigestedData: the content is not the ExContent.bin bytes - it's a truncated version thereof ("This some sampe content."). The digest however was calculated over ExContent.bin bytes, which means that the digest doesn't verify. I'm attaching a fixed DigestedData (7.0.bin). 4) Examples 5.1, 5.3, 5.6, 5.7, SignedData: I'm unable to verify the signatures on these. To double check, I've extracted the raw signature bytes and the public key and took the ExContent.bin, and they still won't verify, so I'm assuming the examples are at fault. Also, a hint that the examples might be screwed is that the signatures contain a spurious 0 byte at the end (in the case of 5.3 there are actually two of them): if you do the math on the last octet string in the SignerInfo, you'll see that while it always has length 48, the dsa signature within is actually only 47 bytes long (46 bytes in the case of 5.3). 5) Examples 5.4, 5.10, 11.1, 11.3, 11.4, and 11.5, SignedData: The OId in SignerInfo.signatureAlgorithm is given as 1.2.840.10040.4.1, but instead it should be 1.2.840.10040.4.3 (the former is the *key* algorithm OId for DSA, not signature algorithm OId). I'm attaching fixed 5.4.bin and 5.10.bin, which I'm able to verify the signature on - I haven't tested the 11.x series yet. 6) Examples 5.8 and 5.9, signed mails: These have both the above problems, i.e. wrong OId, spurious 0 byte at the end, and signature won't verify. Interestingly, I can't verify any DSA signatures created by Jim Schaad; those created by John Pawling I can (after fixing the OId). 7) Bob's RSA private key (BobPrivRSAEncrypt.pri) does not match the public key in his certificate (BobRSASignByCarl.cer) - compare the moduli and you'll see they differ. The examples 6.2 and 6.3 (haven't checked the others yet) seem to use a private key other than the one given (presumably the one matching the public key in the certificate?) as I'm unable to decrypt those. 8) 6.8.eml got a bit messed up: when you decode it with the provided perl script the LF's are missing (i.e. there are only CR's). No big deal, though. Lastly, would it be possible to add a couple examples of nested CMS messages? I.e. CMS messages where the ContentType is not "Data"? (for example EnvelopedData within SignedData and visa versa) I know these aren't used by S/MIME, but CMS does mention that they can be used, and unfortunately it does not say anything about what exactly goes into the EncapsulatedContentInfo.eContent and as input for the calculation of the EncryptedContentInfo.encryptedContent when the content type is anything other than "Data". (I presume it's just the BER-encoded object?) Cheers, Ronald --FL5UXtIhxfXey3p5 Content-Type: application/octet-stream Content-Disposition: attachment; filename="7.0.bin" Content-Transfer-Encoding: base64 MF4GCSqGSIb3DQEHBaBRME8CAQAwBwYFKw4DAhowKwYJKoZIhvcNAQcBoB4EHFRoaXMgaXMg c29tZSBzYW1wbGUgY29udGVudC4EFEBq7AhSebpuFgItngYpwCKWh91I --FL5UXtIhxfXey3p5 Content-Type: application/octet-stream Content-Disposition: attachment; filename="5.4.bin" Content-Transfer-Encoding: base64 MIIKpwYJKoZIhvcNAQcCoIIKmDCCCpQCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQc VGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCB4cwggICMIIBb6ADAgECAhBGNGvHgABW vBHTbi7EELOwMAkGBSsOAwIdBQAwEjEQMA4GA1UEAxMHQ2FybFJTQTAeFw05OTA5MTkwMTA4 NDdaFw0zOTEyMzEyMzU5NTlaMBMxETAPBgNVBAMTCEFsaWNlUlNBMIGfMA0GCSqGSIb3DQEB AQUAA4GNADCBiQKBgQDgiXM5jdj19eiHdjl/TrAFu1OD3g+3q9x9x3UpDQUubRLfpoYm1NJv qlgp/Jfs+oJRDzCAvrFQnkZE8Sy72DLPxmhvB9mwYKy+7jQJahP19wUFk99eujVW2WH/GX/J geb4bOqHQHDvrG0sdJ8t+lU6uZl3AqZIUoxO81c4V3RXXwIDAQABo2AwXjAMBgNVHRMBAf8E AjAAMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTp4JAnrHggeprTTPJCN04irp44uzAd BgNVHQ4EFgQUd9K00bdMioqjzkWdzuw8oDrj/1AwCQYFKw4DAh0FAAOBgQC/NDLm/GqIQX3w XJmhk7dJtwJSHsuErJPXWCsAoZzESEiZ3QLDxgX40iXxo5zJMwGKdg5vd0Ojv+Hms2oEeTnu 4enlnVAHiyLcElDj87Q9nuWTnrHNM/ngq5hxCfjrsPyc7PGI2K4D0f5g4WIUsaIj0siNGB9e 7ptyAifChT0ELjCCApswggJaoAMCAQICAQEwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJs RFNTMB4XDTk5MDgxNjIyNTA1MFoXDTM5MTIzMTIzNTk1OVowEjEQMA4GA1UEAxMHQ2FybERT UzCCAbcwggErBgcqhkjOOAQBMIIBHgKBgQC2SRg+ikTBKXGUTAHEEsF6ectUTasegfvGTLMO lAkG6wHUschxS8dFwFAlXZz82uRt0+KGSISCfboVlUoW9kbt3faY0rt+igqKuhZ7uVABSJOL 6yUVUZdV3I9TDhCpUPxwt80wVP3a3qiqIrWhr4vMAojni3Bfua3hCNRtKS3W6QIVAN3BL99T zgs0YHc+AqS/il2YuRDVAoGADO5Xm0u92rYHanQ3T1V/ne28YQ3rRlk8VgsrWwyRzqViUmnK 4W0+vb/+4be5K2E8rcuuReMGrIwinZxEhwvHzfAc2bVOXXPerw7JHVpR9U9EeTVac6p/RlEf qUIWnEjrinlhtNUvUyJEYx+GuKNYBiX4KcDvuuB18ELEY2VSmwoDgYUAAoGBAJmHdCcDZqCx wK3cLHW74WxEnNohbU1HbbFiCenYrh7yOrSUsaOOeptxTgCUybQlTrlglhkkAfNiDP51wPvO 2GgA4/3VcE/fI5YZBpT0sWGPOlexCBGkCyYl8FJ2geoLYg2VKuaGunKyp1CDC6onzRupTYma 140YOYQ/i8VWTYB6o0IwQDAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBhjAdBgNV HQ4EFgQUcEQ+gi5vh95K03XjPSC8QyuT8R8wCQYHKoZIzjgEAwMwADAtAhRrqfBOelp54/m+ PSvJBjfpERehEwIVAI80aSqLsTwDeZQyTRIfzon7RrI7MIIC3jCCAp2gAwIBAgICAMgwCQYH KoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDTk5MDgxNzAxMTA0OVoXDTM5MTIzMTIz NTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2MIIBKwYHKoZIzjgEATCCAR4CgYEAgY3N 7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv4dkwyDbeP5u/ t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2EMR4vf+d sISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5+z5t 2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3q nMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0 wtGBSmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9 Q1tv5VG/+onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKs ZfoVi/G7NNTSljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTyg+W4o4GDMIGAMCAGA1UdEQQZMBeB FWFsaWNlRHNzQGV4YW1wbGVzLmNvbTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIGwDAf BgNVHSMEGDAWgBRwRD6CLm+H3krTdeM9ILxDK5PxHzAdBgNVHQ4EFgQUvmyhs+PB9+1DcKTO EwHi/eOX/s0wCQYHKoZIzjgEAwMwADAtAhUAmLDGP89xR1o1qUqPwPgkBehGlI4CFFufSMCM ocECnETq6aGHwaV/KC27oYHbMIHYMIGZMAkGByqGSM44BAMwEjEQMA4GA1UEAxMHQ2FybERT UxcNOTkwODI3MDcwMDAwWjBpMBMCAgDIFw05OTA4MjIwNzAwMDBaMBMCAgDJFw05OTA4MjIw NzAwMDBaMBMCAgDTFw05OTA4MjIwNzAwMDBaMBMCAgDSFw05OTA4MjIwNzAwMDBaMBMCAgDU Fw05OTA4MjQwNzAwMDBaMAkGByqGSM44BAMDLwAwLAIUfmVSdjP+NHMX0feW+aDU2G1cfT0C FAJ6W7fVWxjBz4fvftok8yqDnDWhMYIB7DCCAegCAQEwGDASMRAwDgYDVQQDEwdDYXJsRFNT AgIAyDAHBgUrDgMCGqBfMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHgYJKoZIhvcNAQkF MREYDzIwMDAwNDI2MTkwMjAwWjAjBgkqhkiG9w0BCQQxFgQUQGrsCFJ5um4WAi2eBinAIpaH 3UgwCQYHKoZIzjgEAwQuMCwCFEgQuUNPhajwhZb7Qhy5Zc53RBHhAhRpI/JgWc4iFgU/JWRo Po2y/X3MKKGCASIwggEeBgkqhkiG9w0BCQYxggEPMIIBCwIBATAmMBIxEDAOBgNVBAMTB0Nh cmxSU0ECEEY0a8eAAFa8EdNuLsQQs7AwBwYFKw4DAhqgRTAeBgkqhkiG9w0BCQUxERgPMjAw MDA0MjYxOTAyMDBaMCMGCSqGSIb3DQEJBDEWBBTsD+8vKk/UePnGe53FLE0wyGD9hDALBgkq hkiG9w0BAQEEgYAwHAv0OVdDUgpMsGkKgMC0C5WbnCR7b2DPlkMoTUKs04zuwqv4lFnr+Jy2 BBU9tXkIl8DV+ARCUXN9KQPRzNy4vcRbkwtu3pzrhnC0OKS1RVD2MOtPlhcEL5dxWWSSomia iRvbmVmQEE+qYjE/0LR3HE4p5OPNPmrqA0d4SakuUw== --FL5UXtIhxfXey3p5 Content-Type: application/octet-stream Content-Disposition: attachment; filename="5.10.bin" Content-Transfer-Encoding: base64 MIIFFwYJKoZIhvcNAQcCoIIFCDCCBQQCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQc VGhpcyBpcyBzb21lIHNhbXBsZSBjb250ZW50LjGCBMUwggTBAgEBMBgwEjEQMA4GA1UEAxMH Q2FybERTUwICAMgwBwYFKw4DAhqgggRcMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwIwYJ KoZIhvcNAQkEMRYEFEBq7AhSebpuFgItngYpwCKWh91IMDgGAyqrMzExBC9UaGlzIGlzIGEg dGVzdCBHZW5lcmFsIEFTTiBBdHRyaWJ1dGUsIG51bWJlciAxLjA6BgsqhkiG9w0BCRACBDEr MCkMIENvbnRlbnQgSGludHMgRGVzY3JpcHRpb24gQnVmZmVyBgUqAwYFBDBKBgkqhkiG9w0B CQ8xPTA7MAcGBSoDBAUGMDAGBioDBAUGTQQmU21pbWUgQ2FwYWJpbGl0aWVzIHBhcmFtZXRl cnMgYnVmZmVyIDIwbQYLKoZIhvcNAQkQAgIxXjFcAgEBBgcqAwQFBgcIMTEwL4AIKgMEBQYH hnihIxMhVEhJUyBJUyBBIFRFU1QgU0VDVVJJVFktQ0FURUdPUlkuExtUSElTIElTIEEgUFJJ VkFDWSBNQVJLIFRFU1QwbwYLKoZIhvcNAQkQAgoxYDBeBgUqAwQFBgQrQ29udGVudCBSZWZl cmVuY2UgQ29udGVudCBJZGVudGlmaWVyIEJ1ZmZlcgQoQ29udGVudCBSZWZlcmVuY2UgU2ln bmF0dXJlIFZhbHVlIEJ1ZmZlcjBzBgsqhkiG9w0BCRACCzFkoGIwWjELMAkGA1UEBhMCVVMx FjAUBgNVBAoTDVVTIEdvdmVybm1lbnQxETAPBgNVBAsTCFZEQSBTaXRlMQwwCgYDVQQLEwNW REExEjAQBgNVBAMTCURhaXN5IFJTQQIEClVEMzCB/QYLKoZIhvcNAQkQAgMxge0wgeowgecE BzU3MzgyOTkYEDE5OTkwMzExMTA0NDMzMFqhgckwgcakYTBfMQswCQYDVQQGEwJVUzEWMBQG A1UEChMNVVMgR292ZXJubWVudDERMA8GA1UECxMIVkRBIFNpdGUxDDAKBgNVBAsTA1ZEQTEX MBUGA1UEAxMOQnVncyBCdW5ueSBEU0GkYTBfMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNVVMg R292ZXJubWVudDERMA8GA1UECxMIVkRBIFNpdGUxDDAKBgNVBAsTA1ZEQTEXMBUGA1UEAxMO RWxtZXIgRnVkZCBEU0EwggECBgsqhkiG9w0BCRACCTGB8jCB7zFyAgEBBgcqAwQFBgcJMTww OoAIKgMEBQYHhnihLhMsRVFVSVZBTEVOVCBUSElTIElTIEEgVEVTVCBTRUNVUklUWS1DQVRF R09SWS4TJkVRVUlWQUxFTlQgVEhJUyBJUyBBIFBSSVZBQ1kgTUFSSyBURVNUMXkCAQEGByoD BAUGBwoxPDA6gAgqAwQFBgeGeKEuEyxFUVVJVkFMRU5UIFRISVMgSVMgQSBURVNUIFNFQ1VS SVRZLUNBVEVHT1JZLhMtRVFVSVZBTEVOVCBUSElTIElTIEEgU0VDT05EIFBSSVZBQ1kgTUFS SyBURVNUMAkGByqGSM44BAMELjAsAhQE7dxQTjnC2qZ7Dh8qsoyFcmIPMwIUGHRabuAsU+tR DyfkhZ3ll8nyeJQ= --FL5UXtIhxfXey3p5-- From owner-ietf-smime-examples Thu Mar 15 20:17:12 2001 Received: by above.proper.com (8.9.3/8.9.3) id UAA28046 for ietf-smime-examples-bks; Thu, 15 Mar 2001 20:17:12 -0800 (PST) Received: from gandalf.trustpoint.com (gandalf.trustpoint.com [157.22.240.75]) by above.proper.com (8.9.3/8.9.3) with ESMTP id UAA28042 for ; Thu, 15 Mar 2001 20:17:10 -0800 (PST) Received: from ronald.certicom.com (ronald [10.1.6.23]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id UAA09726 for ; Thu, 15 Mar 2001 20:17:09 -0800 Received: (from ronald@localhost) by ronald.certicom.com (8.8.7/8.8.7) id UAA13235 for ietf-smime-examples@imc.org; Thu, 15 Mar 2001 20:17:09 -0800 Date: Thu, 15 Mar 2001 20:17:09 -0800 From: "Life is hard, and then you die" To: ietf-smime-examples@imc.org Subject: Re: comments and corrections for draft-ietf-smime-examples-06 Message-ID: <20010315201709.F13107@trustpoint.com> References: <20010315195304.E13107@trustpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20010315195304.E13107@trustpoint.com>; from ronald on Thu, Mar 15, 2001 at 07:53:04PM -0800 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Thu, Mar 15, 2001 at 07:53:04PM -0800, Life is hard, and then you die wrote: > 7) Bob's RSA private key (BobPrivRSAEncrypt.pri) does not match the > public key in his certificate (BobRSASignByCarl.cer) - compare the > moduli and you'll see they differ. The examples 6.2 and 6.3 (haven't > checked the others yet) seem to use a private key other than the one > given (presumably the one matching the public key in the > certificate?) as I'm unable to decrypt those. Oh, sorry, I meant to update this: the key sent by John Pawling on March 5th and which he claimed is BobPrivRSAEncrypt.pri is actually still the same as CarlPrivRSASign.pri, i.e. doesn't match Bob's certificate (unless the list archive is faulty: http://www.imc.org/ietf-smime-examples/mail-archive/bin00018.bin ). Cheers, Ronald From owner-ietf-smime-examples Mon Mar 19 19:42:57 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id TAA27150 for ietf-smime-examples-bks; Mon, 19 Mar 2001 19:42:57 -0800 (PST) Received: from galkam.com.au (galkam.lnk.telstra.net [139.130.61.32]) by above.proper.com (8.9.3/8.9.3) with SMTP id TAA27145 for ; Mon, 19 Mar 2001 19:42:54 -0800 (PST) Received: FROM galkam.com.au BY galkam.com.au ; Tue, 20 Mar 2001 14:46:55 +11:00 Message-ID: <014201c0b0f0$688ca020$328080c4@galkserv> From: "Glen Kleidon" To: Subject: I am clearly missing something. General Questions Date: Tue, 20 Mar 2001 14:46:55 +1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01C0B14C.9BE32780" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_013F_01C0B14C.9BE32780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am trying to come to grips with the SMIME. I am getting there I = think but I am just missing a couple of bits of info. Perhaps there is = a RFC I haven't read which answers all these questions. In the examples (draft-ietf-smime-examples-06.txt) I could not = understand how you get 9 bytes for the DES3/RSA oid but I have now been = told that you encode the first two digits as a+40 + b but is that 43 (2B) or $40 + $02 + $01 =3D = $43 and the large number > 7f in multiple bytes. Are these large = numbers encoded in Lowbyte/Highbyte format? eg the new id-RSAES-OAEP is iso(1) member-body(2) us(840) = rsadsi(113549) pkcs(1) pkcs-1(1) 7 again 10 bytes would that be =20 2B 03 48 01 BB 8D 01 01 07 or 43 03 48 01 BB 8D 01 01 07 or 2B 48 03 01 8D BB 01 01 07 or 43 48 03 01 8D BB 01 01 07 or or something else? =20 Also, are the lengths low/high byte too eg in example 6.1 should the sequence be for =20 0 30 286: SEQUENCE { =20 4 06 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) : (PKCS #7) 15 A0 271: [0] { --- I can't get this line either? 19 30 267: SEQUENCE { 23 02 1: INTEGER 0 =20 30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 02 01 00 ?? ?? ?? = ?? ?? ?? =20 And should the lengths for integer data have 4 bytes ? and what about = the octec strings?=20 Second, when I base64 decode your examples it is in what appears to be = UNICODE. It isn't though. I can't see how you go from the sequence = above to the data I get after base 64 decoding the example. If there is = a RFC or other document which explains these things could you tell me = what it is? ------=_NextPart_000_013F_01C0B14C.9BE32780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I  am trying to come to grips with = the=20 SMIME.   I am getting there I think but I am just missing a = couple of=20 bits of info.  Perhaps there is a RFC I haven't read which answers = all=20 these questions.
 
In the examples=20 (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 = bytes=20 for the DES3/RSA oid but I have now been told that you encode = the
first two digits as a+40 + b but is = that=20 43 (2B)  or $40 + $02 + $01 =3D $43 and the large number = > 7f in=20 multiple bytes.  Are these large numbers encoded in = Lowbyte/Highbyte=20 format?
 
eg the new = id-RSAES-OAEP   is iso(1)=20 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7  again 10 = bytes
  would that=20 be        
2B 03 48 01 BB 8D 01 01 07  =20 or
43 03 48 01 BB 8D 01 01 = 07  =20 or
2B 48 03 01 8D BB 01 01 07  =20 or
43 48 03 01 8D BB 01 01 = 07  =20 or
or something else?
 
Also, are the lengths low/high byte=20 too
eg in example 6.1 should the sequence = be =20 for
 
0=20 30  286: SEQUENCE=20 {          =20
4 06    = 9:  =20 OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7=20 3)
         = :    =20 (PKCS #7)
15 A0  271:   [0]=20 {            =  ---=20 I can't get this line either?
19 30  = 267:    =20 SEQUENCE {
23 02    = 1:      =20 INTEGER 0
 
30 1E 01 06 09 2B 03 48 = 01 BB 8D 01=20 07 03 0A 0F 01 00 30 0B 01 02 01 00
     ??  =20 ??         ??  &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         =20 ??         ??  = ?? =20
 
And should the lengths for = integer data=20 have 4 bytes ? and what about the octec strings?
 
Second, when I base64 decode your = examples it=20 is in what appears to be UNICODE.  It isn't though.  I can't = see how=20 you go from the sequence above to the data I get after base 64 = decoding the=20 example.  If there is a RFC or other document which explains = these=20 things could you tell me what it is?
 
------=_NextPart_000_013F_01C0B14C.9BE32780-- From owner-ietf-smime-examples Mon Mar 19 20:03:17 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id UAA27467 for ietf-smime-examples-bks; Mon, 19 Mar 2001 20:03:17 -0800 (PST) Received: from galkam.com.au (galkam.lnk.telstra.net [139.130.61.32]) by above.proper.com (8.9.3/8.9.3) with SMTP id UAA27463 for ; Mon, 19 Mar 2001 20:03:13 -0800 (PST) Received: FROM galkam.com.au BY galkam.com.au ; Tue, 20 Mar 2001 15:07:16 +11:00 Message-ID: <016701c0b0f3$3ff7a670$328080c4@galkserv> From: "Glen Kleidon" To: Subject: Just not getting it. General Questions from brand new Crytographer Date: Tue, 20 Mar 2001 15:07:16 +1100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0164_01C0B14F.73513B10" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0164_01C0B14F.73513B10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have been working on SMIME for about 4 days so please don't laugh at = any of my questions!! At Paul's suggestion, I post these basic questions here. I am trying to come to grips with the SMIME. I am getting there I = think but I am just missing a couple of bits of info. Perhaps there is = a RFC I haven't read which answers all these questions. In the examples (draft-ietf-smime-examples-06.txt) I could not = understand how you get 9 bytes for the DES3/RSA oid but I have now been = told that you encode the first two digits as a+40 + b but is that 43 (2B) or $40 + $02 + $01 =3D = $43 and the large number > 7f in multiple bytes. Are these large = numbers encoded in Lowbyte/Highbyte format? eg the new id-RSAES-OAEP is iso(1) member-body(2) us(840) = rsadsi(113549) pkcs(1) pkcs-1(1) 7 =20 would that be =20 2B 03 48 01 BB 8D 01 01 07 or 43 03 48 01 BB 8D 01 01 07 or 2B 48 03 01 8D BB 01 01 07 or 43 48 03 01 8D BB 01 01 07 or or something else? =20 Also, are the lengths low/high byte too eg in example 6.1 should the sequence be for =20 0 30 286: SEQUENCE { =20 4 06 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) : (PKCS #7) 15 A0 271: [0] { --- I can't get this line either? if = there are 4 bytes what is 18? 19 30 267: SEQUENCE { --- and here if there 4 bytes what is 22 = (are there 3 bytes per length?)=20 23 02 1: INTEGER 0 =20 30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 ?? 02 01 = 00 ?? ?? ?? = ?? ?? ?? =20 00 04 15 18 19 22 23 =20 And should the lengths for integer data have 4 bytes ? and what about = the octec strings?=20 Second, when I base64 decode your examples it is in what appears to be = UNICODE. It isn't though. I can't see how you go from the sequence = above to the data I get after base 64 decoding the example. If there is = a RFC or other document which explains these things could you tell me = what it is? ------=_NextPart_000_0164_01C0B14F.73513B10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have been working on SMIME for about = 4 days so=20 please don't laugh at any of my questions!!
 
At Paul's suggestion, I post these = basic questions=20 here.
 
I  am trying to come to grips with = the=20 SMIME.   I am getting there I think but I am just missing a = couple of=20 bits of info.  Perhaps there is a RFC I haven't read which answers = all=20 these questions.
 
In the examples=20 (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 = bytes=20 for the DES3/RSA oid but I have now been told that you encode = the
first two digits as a+40 + b but is = that=20 43 (2B)  or $40 + $02 + $01 =3D $43 and the large number = > 7f in=20 multiple bytes.  Are these large numbers encoded in = Lowbyte/Highbyte=20 format?
 
eg the new = id-RSAES-OAEP   is iso(1)=20 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 =20
  would that=20 be        
2B 03 48 01 BB 8D 01 01 07  =20 or
43 03 48 01 BB 8D 01 01 = 07  =20 or
2B 48 03 01 8D BB 01 01 07  =20 or
43 48 03 01 8D BB 01 01 = 07  =20 or
or something else?
 
Also, are the lengths low/high byte=20 too
eg in example 6.1 should the sequence = be =20 for
 
0=20 30  286: SEQUENCE=20 {          =20
4 06    = 9:  =20 OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7=20 3)
         = :    =20 (PKCS #7)
15 A0  271:   [0]=20 {            =  ---=20 I can't get this line either?  if there are 4 bytes what is = 18?
19=20 30  267:     SEQUENCE=20 {      --- and here if there 4 = bytes=20 what is 22 (are there 3 bytes per length?)
23 02   =20 1:       INTEGER 0
 
30 1E 01 06 09 2B 03 48 = 01 BB 8D 01=20 07 03 0A 0F 01 00 30 0B 01 ?? 02 01 00
     ??  =20 ??         ??  &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         =20 ??         ??  = ?? =20
00       04   &nbs= p;      =20             &= nbsp;       15    =    18=20 19       22 23
And should the lengths for = integer data=20 have 4 bytes ? and what about the octec strings?
 
Second, when I base64 decode your = examples it=20 is in what appears to be UNICODE.  It isn't though.  I can't = see how=20 you go from the sequence above to the data I get after base 64 = decoding the=20 example.  If there is a RFC or other document which explains = these=20 things could you tell me what it is?
 
 
------=_NextPart_000_0164_01C0B14F.73513B10-- From owner-ietf-smime-examples Tue Mar 20 00:29:02 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id AAA17758 for ietf-smime-examples-bks; Tue, 20 Mar 2001 00:29:02 -0800 (PST) Received: from exchsvr1.entegrity.com (exchsvr1.entegrity.com [207.215.19.3]) by above.proper.com (8.9.3/8.9.3) with ESMTP id AAA17750 for ; Tue, 20 Mar 2001 00:28:55 -0800 (PST) Received: from nelson (dave.entegrity.se [195.100.88.62]) by exchsvr1.entegrity.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id GFRD9QXJ; Tue, 20 Mar 2001 00:28:05 -0800 From: "Magnus Svensson" To: "'Glen Kleidon'" , Subject: RE: I am clearly missing something. General Questions Date: Tue, 20 Mar 2001 09:26:02 +0100 Message-ID: <001801c0b117$66fec270$2600000a@cost.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C0B11F.C8C32A70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.3018.1300 Importance: Normal In-Reply-To: <014201c0b0f0$688ca020$328080c4@galkserv> Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C0B11F.C8C32A70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Glenn, The Cryptographic Message Syntax (RFC 2630) is a must when working with S/MIME ASN.1 structures since most of them are described there. This RFC and related documents can be retrieved from http://www.ietf.org/html.charters/smime-charter.html. The id-RSAES-OAEP you describe should be encoded as: 2A 86 48 86 F7 0D 01 01 07 If you are unsure of how the ASN.1 coding works, check out "A Layman's Guide to a Subset of ASN.1, BER, and DER" at ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.asc. /Magnus -----Original Message----- From: owner-ietf-smime-examples@mail.imc.org [mailto:owner-ietf-smime-examples@mail.imc.org]On Behalf Of Glen Kleidon Sent: Tuesday, March 20, 2001 4:47 AM To: ietf-smime-examples@imc.org Subject: I am clearly missing something. General Questions I am trying to come to grips with the SMIME. I am getting there I think but I am just missing a couple of bits of info. Perhaps there is a RFC I haven't read which answers all these questions. In the examples (draft-ietf-smime-examples-06.txt) I could not understand how you get 9 bytes for the DES3/RSA oid but I have now been told that you encode the first two digits as a+40 + b but is that 43 (2B) or $40 + $02 + $01 = $43 and the large number > 7f in multiple bytes. Are these large numbers encoded in Lowbyte/Highbyte format? eg the new id-RSAES-OAEP is iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7 again 10 bytes would that be 2B 03 48 01 BB 8D 01 01 07 or 43 03 48 01 BB 8D 01 01 07 or 2B 48 03 01 8D BB 01 01 07 or 43 48 03 01 8D BB 01 01 07 or or something else? Also, are the lengths low/high byte too eg in example 6.1 should the sequence be for 0 30 286: SEQUENCE { 4 06 9: OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7 3) : (PKCS #7) 15 A0 271: [0] { --- I can't get this line either? 19 30 267: SEQUENCE { 23 02 1: INTEGER 0 30 1E 01 06 09 2B 03 48 01 BB 8D 01 07 03 0A 0F 01 00 30 0B 01 02 01 00 ?? ?? ?? ?? ?? ?? And should the lengths for integer data have 4 bytes ? and what about the octec strings? Second, when I base64 decode your examples it is in what appears to be UNICODE. It isn't though. I can't see how you go from the sequence above to the data I get after base 64 decoding the example. If there is a RFC or other document which explains these things could you tell me what it is? ------=_NextPart_000_0019_01C0B11F.C8C32A70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Glenn,
 
The=20 Cryptographic Message Syntax (RFC 2630) is a must when working with = S/MIME ASN.1=20 structures since most of them are described there. This RFC and related=20 documents can be retrieved from http://www.= ietf.org/html.charters/smime-charter.html.
 
If you=20 are unsure of how the ASN.1 coding works, check out "A=20 Layman's Guide to a Subset of ASN.1, BER, and DER" at = ftp://ftp.rs= asecurity.com/pub/pkcs/ascii/layman.asc.
 
The = example with=20 RS
-----Original Message-----
From:=20 owner-ietf-smime-examples@mail.imc.org=20 [mailto:owner-ietf-smime-examples@mail.imc.org]On Behalf Of Glen=20 Kleidon
Sent: Tuesday, March 20, 2001 4:47 AM
To:=20 ietf-smime-examples@imc.org
Subject: I am clearly missing = something.=20 General Questions

I  am trying to come to grips = with the=20 SMIME.   I am getting there I think but I am just missing a = couple=20 of bits of info.  Perhaps there is a RFC I haven't read which = answers all=20 these questions.
 
In the examples=20 (draft-ietf-smime-examples-06.txt) I could not understand how you get = 9 bytes=20 for the DES3/RSA oid but I have now been told that you encode = the
first two digits as a+40 + b but is = that=20 43 (2B)  or $40 + $02 + $01 =3D $43 and the large = number > 7f=20 in multiple bytes.  Are these large numbers encoded in = Lowbyte/Highbyte=20 format?
 
eg the new = id-RSAES-OAEP   is=20 iso(1)=20 member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 7  again = 10=20 bytes
  would=20 that be        
2B 03 48 01 BB 8D 01 01 07   = or
43 03 48 01 BB 8D 01 01 = 07  =20 or
2B 48 03 01 8D BB 01 01 07   = or
43 48 03 01 8D BB 01 01 = 07  =20 or
or something else?
 
Also, are the lengths low/high byte=20 too
eg in example 6.1 should the sequence = be =20 for

0=20 30  286: SEQUENCE=20 = {          =20
4 06    = 9:  =20 OBJECT IDENTIFIER envelopedData (1 2 840 113549 1 7=20 3)
        =20 :     (PKCS #7)
15 A0  271:   = [0]=20 = {            =  ---=20 I can't get this line either?
19 30  = 267:    =20 SEQUENCE {
23 02    = 1:      =20 INTEGER 0
 
30 1E 01 06 09 2B 03 48 = 01 BB 8D 01=20 07 03 0A 0F 01 00 30 0B 01 02 01 00
     ??  =20 = ??         ??  &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp;         =20 ??         ??  = ?? =20
 
And should the lengths for = integer data=20 have 4 bytes ? and what about the octec strings?
 
Second, when I base64 = decode your examples=20 it is in what appears to be UNICODE.  It isn't though.  I = can't see=20 how you go from the sequence above to the data I get after base = 64=20 decoding the example.  If there is a RFC or other document = which=20 explains these things could you tell me what it is?
 
------=_NextPart_000_0019_01C0B11F.C8C32A70-- From owner-ietf-smime-examples Thu Mar 22 07:29:07 2001 Received: by above.proper.com (8.9.3/8.9.3) id HAA26574 for ietf-smime-examples-bks; Thu, 22 Mar 2001 07:29:07 -0800 (PST) Received: from berit.xware.se (xware.se [195.43.225.34]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA26564 for ; Thu, 22 Mar 2001 07:29:05 -0800 (PST) Received: from matsburk.xware.se by berit.xware.se (8.8.0/8.8.0) with ESMTP id QAA20981; Thu, 22 Mar 2001 16:30:23 +0100 Message-Id: <4.3.2.7.2.20010322154315.00dc9c10@berit.xware.se> X-Sender: mats@berit.xware.se X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 22 Mar 2001 16:28:54 +0100 To: openssl-dev@openssl.org, ietf-smime-examples@imc.org From: Mats Nilsson Subject: OpenSSL S/MIME validation against draft-ietf-smime-examples? In-Reply-To: <3A60501D.F1D82CA5@celocom.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi [openssl-0.9.6, WinNT4sp6] I tried to verify OpenSSL's S/MIME implementation using the sample messages in http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-06.txt First I ran into problems with their base64 encoding, which was rejected by OpenSSL due to long lines. To make OpenSSL decode these files, I reformatted the contents to fit into the 80 character/line restriction. Then I tried the tests 5.1 and 5.9 (Basic DH-DSS signed contents, CMS and S/MIME formatted). No matter what I tried (different certificates, different options) I couldn't make OpenSSL verify the document signature. The certificate chain verification works, though. I tried something like the following (after having converted the supplied certificates to pem): $ openssl smime -verify -certfiles AliceDss.pem -CAfile CarlDssSelf.pem -in 5.9.eml This is some sample content.Verification Failure 386:error:0A071003::lib(10) :DSA_do_verify:BN lib:.\crypto\dsa\dsa_ossl.c:288: 386:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:.\cryp to\pkcs7\pk7_doit.c:815: 386:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:.\crypto\pkcs7\ pk7_smime.c:248: A side comment, I tried the first basic validation test of the NIST X.509 Path Validation suite (http://csrc.nist.gov/pki/testing/x509paths.html), which works. That one uses RSA. Has anyone successfully verified the OpenSSL S/MIME implementation with these samples? Are the samples incorrect? Am I using OpenSSL incorrectly? Regards, Mats Nilsson From owner-ietf-smime-examples Thu Mar 22 13:17:09 2001 Received: by above.proper.com (8.9.3/8.9.3) id NAA24913 for ietf-smime-examples-bks; Thu, 22 Mar 2001 13:17:09 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA24909 for ; Thu, 22 Mar 2001 13:17:08 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 22 Mar 2001 16:17:24 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EEB7@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Mats Nilsson'" , openssl-dev@openssl.org, ietf-smime-examples@imc.org Subject: RE: OpenSSL S/MIME validation against draft-ietf-smime-examples? Date: Thu, 22 Mar 2001 16:17:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Mats, We used the S/MIME Freeware Library to successfully verify the 5.1 and 5.9 samples. We have not tried to use OpenSSL's S/MIME implementation to verify any of the samples. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Mats Nilsson [mailto:mats.nilsson@xware.se] Sent: Thursday, March 22, 2001 10:29 AM To: openssl-dev@openssl.org; ietf-smime-examples@imc.org Subject: OpenSSL S/MIME validation against draft-ietf-smime-examples? Hi [openssl-0.9.6, WinNT4sp6] I tried to verify OpenSSL's S/MIME implementation using the sample messages in http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-06.txt First I ran into problems with their base64 encoding, which was rejected by OpenSSL due to long lines. To make OpenSSL decode these files, I reformatted the contents to fit into the 80 character/line restriction. Then I tried the tests 5.1 and 5.9 (Basic DH-DSS signed contents, CMS and S/MIME formatted). No matter what I tried (different certificates, different options) I couldn't make OpenSSL verify the document signature. The certificate chain verification works, though. I tried something like the following (after having converted the supplied certificates to pem): $ openssl smime -verify -certfiles AliceDss.pem -CAfile CarlDssSelf.pem -in 5.9.eml This is some sample content.Verification Failure 386:error:0A071003::lib(10) :DSA_do_verify:BN lib:.\crypto\dsa\dsa_ossl.c:288: 386:error:21071069:PKCS7 routines:PKCS7_signatureVerify:signature failure:.\cryp to\pkcs7\pk7_doit.c:815: 386:error:21075069:PKCS7 routines:PKCS7_verify:signature failure:.\crypto\pkcs7\ pk7_smime.c:248: A side comment, I tried the first basic validation test of the NIST X.509 Path Validation suite (http://csrc.nist.gov/pki/testing/x509paths.html), which works. That one uses RSA. Has anyone successfully verified the OpenSSL S/MIME implementation with these samples? Are the samples incorrect? Am I using OpenSSL incorrectly? Regards, Mats Nilsson From owner-ietf-smime-examples Fri Mar 23 05:57:06 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA10737 for ietf-smime-examples-bks; Fri, 23 Mar 2001 05:57:06 -0800 (PST) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA10731 for ; Fri, 23 Mar 2001 05:57:03 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 14gS3r-0009jm-0U; Fri, 23 Mar 2001 13:57:03 +0000 Message-ID: <3ABB564B.E8B7274F@celocom.com> Date: Fri, 23 Mar 2001 13:57:31 +0000 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "ietf-smime-examples@imc.org" CC: "Pawling, John" Subject: Problems with Example 5.1. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It has been reported to me that OpenSSL has problems verifying the signature on example 5.1. I have now analysed the example and found a few issues. Firstly the description: > A SignedData with no attribute certificates, signed by Alice using > DH-DSS, just her certificate (not Carl's root cert), no CRL. The > message is ExContent, and is included in the eContent. There are no > signed or unsigned attributes. > DH-DSS?? The final OCTET STRING which encapsulates the signature includes a trailing zero. Finally I cannot get OpenSSL to verify the signature on that example. OpenSSL does however verify the signature on the certificate. I didn't immediately report this because I could not be certain there wasn't a bug in OpenSSLs DSA implementation that this example triggered. I have since manually implemented the DSA verification algorithm for this example using the Unix 'dc' calculator and input the relevant values. The result from dc agrees with OpenSSL: that is the value for 'v' is identical (see FIPS186 section 6) not just the fact that it cannot verify the signature. While I cannot rule out the possibility that I've done something silly the evidence suggests there is a problem with that signature. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Fri Mar 23 06:52:43 2001 Received: by above.proper.com (8.9.3/8.9.3) id GAA15295 for ietf-smime-examples-bks; Fri, 23 Mar 2001 06:52:43 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id GAA15291 for ; Fri, 23 Mar 2001 06:52:41 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 09:52:57 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EECB@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Dr S N Henson'" , ietf-smime-examples@imc.org Subject: RE: Problems with Example 5.1. Date: Fri, 23 Mar 2001 09:52:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, I agree with your first comment that "DH-DSS" should be "DSA". This is true for all occurrences of "DH-DSS" in the document. We will use the S/MIME Freeware Library to re-test example 5.1 as extracted from the Examples-06 document. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Dr S N Henson [mailto:drh@celocom.com] Sent: Friday, March 23, 2001 8:58 AM To: ietf-smime-examples@imc.org Cc: Pawling, John Subject: Problems with Example 5.1. It has been reported to me that OpenSSL has problems verifying the signature on example 5.1. I have now analysed the example and found a few issues. Firstly the description: > A SignedData with no attribute certificates, signed by Alice using > DH-DSS, just her certificate (not Carl's root cert), no CRL. The > message is ExContent, and is included in the eContent. There are no > signed or unsigned attributes. > DH-DSS?? The final OCTET STRING which encapsulates the signature includes a trailing zero. Finally I cannot get OpenSSL to verify the signature on that example. OpenSSL does however verify the signature on the certificate. I didn't immediately report this because I could not be certain there wasn't a bug in OpenSSLs DSA implementation that this example triggered. I have since manually implemented the DSA verification algorithm for this example using the Unix 'dc' calculator and input the relevant values. The result from dc agrees with OpenSSL: that is the value for 'v' is identical (see FIPS186 section 6) not just the fact that it cannot verify the signature. While I cannot rule out the possibility that I've done something silly the evidence suggests there is a problem with that signature. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Fri Mar 23 11:56:20 2001 Received: by above.proper.com (8.9.3/8.9.3) id LAA04413 for ietf-smime-examples-bks; Fri, 23 Mar 2001 11:56:20 -0800 (PST) Received: from anchor-post-33.mail.demon.net (anchor-post-33.mail.demon.net [194.217.242.91]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA04401 for ; Fri, 23 Mar 2001 11:56:14 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-33.mail.demon.net with esmtp (Exim 2.12 #1) id 14gXfT-000HBV-0X for ietf-smime-examples@imc.org; Fri, 23 Mar 2001 19:56:16 +0000 Message-ID: <3ABBAB5D.8C9AF1B6@celocom.com> Date: Fri, 23 Mar 2001 20:00:29 +0000 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-smime-examples@imc.org Subject: Re: comments and corrections for draft-ietf-smime-examples-06 References: <20010315195304.E13107@trustpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hmmm... I hadn't noticed someone had already reported problems with example 5.1 when I posted the query... "Life is hard, and then you die" wrote: > > > 4) Examples 5.1, 5.3, 5.6, 5.7, SignedData: > I'm unable to verify the signatures on these. To double check, > I've extracted the raw signature bytes and the public key and > took the ExContent.bin, and they still won't verify, so I'm > assuming the examples are at fault. > > Also, a hint that the examples might be screwed is that the > signatures contain a spurious 0 byte at the end (in the case of > 5.3 there are actually two of them): if you do the math on the > last octet string in the SignerInfo, you'll see that while it > always has length 48, the dsa signature within is actually only > 47 bytes long (46 bytes in the case of 5.3). > ... > > 6) Examples 5.8 and 5.9, signed mails: > These have both the above problems, i.e. wrong OId, spurious > 0 byte at the end, and signature won't verify. > > Interestingly, I can't verify any DSA signatures created by Jim Schaad; > those created by John Pawling I can (after fixing the OId). > I've done some further tests using OpenSSL and I agree with this DSA signature problem: I can verify the [JP] DSA examples but not the [JS] ones. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Fri Mar 23 12:25:44 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA06783 for ietf-smime-examples-bks; Fri, 23 Mar 2001 12:25:44 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06774 for ; Fri, 23 Mar 2001 12:25:42 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 15:25:57 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EED4@wfhqex06.gfgsi.com> From: "Pawling, John" To: ietf-smime-examples@imc.org Subject: RE: comments and corrections for draft-ietf-smime-examples-06 Date: Fri, 23 Mar 2001 15:25:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, We will re-test all of these messages using the S/MIME Freeware Library. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Dr S N Henson [mailto:drh@celocom.com] Sent: Friday, March 23, 2001 3:00 PM To: ietf-smime-examples@imc.org Subject: Re: comments and corrections for draft-ietf-smime-examples-06 Hmmm... I hadn't noticed someone had already reported problems with example 5.1 when I posted the query... "Life is hard, and then you die" wrote: > > > 4) Examples 5.1, 5.3, 5.6, 5.7, SignedData: > I'm unable to verify the signatures on these. To double check, > I've extracted the raw signature bytes and the public key and > took the ExContent.bin, and they still won't verify, so I'm > assuming the examples are at fault. > > Also, a hint that the examples might be screwed is that the > signatures contain a spurious 0 byte at the end (in the case of > 5.3 there are actually two of them): if you do the math on the > last octet string in the SignerInfo, you'll see that while it > always has length 48, the dsa signature within is actually only > 47 bytes long (46 bytes in the case of 5.3). > ... > > 6) Examples 5.8 and 5.9, signed mails: > These have both the above problems, i.e. wrong OId, spurious > 0 byte at the end, and signature won't verify. > > Interestingly, I can't verify any DSA signatures created by Jim Schaad; > those created by John Pawling I can (after fixing the OId). > I've done some further tests using OpenSSL and I agree with this DSA signature problem: I can verify the [JP] DSA examples but not the [JS] ones. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Fri Mar 23 12:25:46 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA06794 for ietf-smime-examples-bks; Fri, 23 Mar 2001 12:25:46 -0800 (PST) Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA06788 for ; Fri, 23 Mar 2001 12:25:45 -0800 (PST) From: Victor_Baranov@3com.com Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f2NKNnd28790; Fri, 23 Mar 2001 12:23:49 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.ops.3com.com [139.87.48.104]) by opal.3com.com (Switch-2.1.0/Switch-2.1.0) with SMTP id f2NKPGE25868; Fri, 23 Mar 2001 12:25:16 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A18.00702C11 ; Fri, 23 Mar 2001 12:25:13 -0800 X-Lotus-FromDomain: 3COM To: Dr S N Henson cc: ietf-smime-examples@imc.org Message-ID: <88256A18.00702952.00@hqoutbound.ops.3com.com> Date: Fri, 23 Mar 2001 15:25:02 -0500 Subject: Re: comments and corrections for draft-ietf-smime-examples-06 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hello guys. I've unsubscribed some time ago, but recently started to get the e-mails again. Can someone please remind how to unsubscribe? Thanks. Dr S N Henson on 23.03.2001 15:00:29 Sent by: Dr S N Henson To: ietf-smime-examples@imc.org cc: (Victor Baranov/C/CA/3Com) Subject: Re: comments and corrections for draft-ietf-smime-examples-06 Hmmm... I hadn't noticed someone had already reported problems with example 5.1 when I posted the query... "Life is hard, and then you die" wrote: > > > 4) Examples 5.1, 5.3, 5.6, 5.7, SignedData: > I'm unable to verify the signatures on these. To double check, > I've extracted the raw signature bytes and the public key and > took the ExContent.bin, and they still won't verify, so I'm > assuming the examples are at fault. > > Also, a hint that the examples might be screwed is that the > signatures contain a spurious 0 byte at the end (in the case of > 5.3 there are actually two of them): if you do the math on the > last octet string in the SignerInfo, you'll see that while it > always has length 48, the dsa signature within is actually only > 47 bytes long (46 bytes in the case of 5.3). > ... > > 6) Examples 5.8 and 5.9, signed mails: > These have both the above problems, i.e. wrong OId, spurious > 0 byte at the end, and signature won't verify. > > Interestingly, I can't verify any DSA signatures created by Jim Schaad; > those created by John Pawling I can (after fixing the OId). > I've done some further tests using OpenSSL and I agree with this DSA signature problem: I can verify the [JP] DSA examples but not the [JS] ones. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Fri Mar 23 14:24:54 2001 Received: by above.proper.com (8.9.3/8.9.3) id OAA14757 for ietf-smime-examples-bks; Fri, 23 Mar 2001 14:24:54 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA14752 for ; Fri, 23 Mar 2001 14:24:53 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 23 Mar 2001 17:25:09 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EEDE@wfhqex06.gfgsi.com> From: "Pawling, John" To: ietf-smime-examples@imc.org Cc: "Colestock, Robert" Subject: RE: comments and corrections for draft-ietf-smime-examples-06 Date: Fri, 23 Mar 2001 17:25:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, We extracted the example data directly from the Examples-06 document. We performed the following tests using the S/MIME Freeware Library (SFL). Like Steve and others, we were unable to verify the signature of Examples 5.1, 5.3, 5.6 and 5.7 using the SFL. We successfully verified Examples 5.2, 5.4, 5.5, 5.11, 11.1, 11.2, 11.3, 11.4 and 11.6 using the SFL. We did not test Example 11.5 today. We successfully decrypted Examples 6.1, 6.2, 6.3, 6.4, 6.9, 6.10 and 6.11 using the SFL. We did no test all of the encrypted examples today. We plan to continue testing the Example-06 samples to determine if there are any other samples that we can't successfully decrypt or verify using the SFL. We will provide a complete report early next week. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== From owner-ietf-smime-examples Sat Mar 24 10:13:46 2001 Received: by above.proper.com (8.9.3/8.9.3) id KAA11221 for ietf-smime-examples-bks; Sat, 24 Mar 2001 10:13:46 -0800 (PST) Received: from nitgw.mains.nitech.ac.jp (nitgw.mains.nitech.ac.jp [133.68.21.192]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA11216 for ; Sat, 24 Mar 2001 10:13:43 -0800 (PST) Received: from galaxy.elcom.nitech.ac.jp (galaxy.elcom.nitech.ac.jp [133.68.163.180]) by nitgw.mains.nitech.ac.jp (01022815) with ESMTP id f2OIDd118650 for ; Sun, 25 Mar 2001 03:13:39 +0900 (JST) Received: from mars.elcom.nitech.ac.jp (mars.elcom.nitech.ac.jp [133.68.163.1]) by galaxy.elcom.nitech.ac.jp (00091320) with ESMTP id DAA14469 for ; Sun, 25 Mar 2001 03:11:04 +0900 (JST) Received: from popo (ppp06.elcom.nitech.ac.jp [133.68.161.106]) by mars.elcom.nitech.ac.jp (8.9.3/3.7W) with SMTP id DAA06517 for ; Sun, 25 Mar 2001 03:13:39 +0900 (JST) Message-ID: <005701c0b48e$4fa457a0$68a14485@elcom.nitech.ac.jp> From: "Takuto Okuno" To: Subject: draft-ietf-smime-examples-06.txt Date: Sun, 25 Mar 2001 03:14:46 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear smime-examples group: I sent a message to Paul Hoffman corresponding a bug of draft-ietf-smime-examples-06.txt. Then, he told me that I had better send my report to smime-examples mailing list. > Thank you for your message. Please send it to the > ietf-smime-examples@imc.org mailing list. I am just the editor of the > document, not the creator of the examples. This kind of message is > very helpful in us creating a good document. > > --Paul Hoffman, Director > --Internet Mail Consortium So, the following message is my bug report of this smime draft. This might be helpful to improve the draft document :-) > Okuno@A.I.LAB > > Hi, I tried to use this smime examples for my own S/MIME application > and found a mistake in the document. > > The mistake is pretty big one that I couldn't find Bob's RSA Private > Key and I couldn't finish some tests, such as 6.2 and 6.3 ! > > You can see that extracted files, CarlPrivRSASign.pri and > BobPrivRSAEncrypt.pri, have same content and Bob's Private Key > does not exist elsewhere. Also, it is same situation in the draft document. > > I hope you would put the Bob's Private Key in the document > and republish your ietf draft :-) > > Cheers, > Takuto Okuno. > From owner-ietf-smime-examples Mon Mar 26 08:17:23 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id IAA08951 for ietf-smime-examples-bks; Mon, 26 Mar 2001 08:17:23 -0800 (PST) Received: from wfhqex05.gfgsi.com (netva01.wangfed.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id IAA08946 for ; Mon, 26 Mar 2001 08:17:21 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 26 Mar 2001 11:17:36 -0500 Message-ID: <0B95FB5619B3D411817E006008A5925945EEE7@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Takuto Okuno'" , ietf-smime-examples@imc.org Subject: RE: draft-ietf-smime-examples-06.txt Date: Mon, 26 Mar 2001 11:17:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0B610.4423E930" Sender: owner-ietf-smime-examples@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_000_01C0B610.4423E930 Content-Type: text/plain; charset="iso-2022-jp" Takuto, Attached is the BobPrivRSAEncrypt.pri file that can be used to decrypt the section 6.2 message included in the Examples-06 document. I believe that Paul Hoffman plans to correct this problem in the next Examples draft. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Takuto Okuno [mailto:usapato@anet.ne.jp] Sent: Saturday, March 24, 2001 1:15 PM To: ietf-smime-examples@imc.org Subject: draft-ietf-smime-examples-06.txt Dear smime-examples group: I sent a message to Paul Hoffman corresponding a bug of draft-ietf-smime-examples-06.txt. Then, he told me that I had better send my report to smime-examples mailing list. > Thank you for your message. Please send it to the > ietf-smime-examples@imc.org mailing list. I am just the editor of the > document, not the creator of the examples. This kind of message is > very helpful in us creating a good document. > > --Paul Hoffman, Director > --Internet Mail Consortium So, the following message is my bug report of this smime draft. This might be helpful to improve the draft document :-) > Okuno@A.I.LAB > > Hi, I tried to use this smime examples for my own S/MIME application > and found a mistake in the document. > > The mistake is pretty big one that I couldn't find Bob's RSA Private > Key and I couldn't finish some tests, such as 6.2 and 6.3 ! > > You can see that extracted files, CarlPrivRSASign.pri and > BobPrivRSAEncrypt.pri, have same content and Bob's Private Key > does not exist elsewhere. Also, it is same situation in the draft document. > > I hope you would put the Bob's Private Key in the document > and republish your ietf draft :-) > > Cheers, > Takuto Okuno. > ------_=_NextPart_000_01C0B610.4423E930 Content-Type: application/octet-stream; name="BobPrivRSAEncrypt.pri" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BobPrivRSAEncrypt.pri" MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAMpc4S7sz8E7XRAb31Q1cZkKCdg9 5GG/oL4KvhGkPLU4QUFIBOFbsRccU7X0xRXT/gz7DKzqgBg2A35Bk1PXQHRJ29nGr/7Wyg3KAYSP oemjACEnUdVAGarjwDB4W6Cy5sEtJDbLrkQQgrDddNf261Ensqe2rXjKpxtZURjvKAxTAgMBAAEC gYA0koCl8jvfFY8N2k/gzqmeeq8oEJw+kMwv0xah+qsS4XSCgzVRXsLZIDDXOqnhC9wafzZBzgJN R+sMZ/jgdTF3DgacqExmcFzHTYrADDauU7rOnVacgXN0ImgG5fQoXBQXJbSCwBNpmA1d/h2WVAqP wBiMBEPbFGl6Dnr8/aCt8QJBAPWOJoKJzNRNz+10F9HYTyTh/S4Mdljx4CnvAGfR2wzxATD+9niY YrK7mvLXMV3tjEOIwHAcok4oJOqou0yDPdUCQQDS+GgiLrHNgsWwvLvQuMFWzAoriEhRdZfv2n2H i8CIVSYcgfxDedA7yEH6ri76aPpJ5EF6eKuKOvasaL35xC2HAkEAlc8ewX8unsvGMhkkuxqb1mWl X+WsgkE2wH6WocBPQsr6Lhku544YkPCR7NvKu4JEk6MnvH5LqyEkvKEqe9iJ7QJAFP0RnxT2K3Pv Jv4f0UwQMApsmJgeWbxROVOLWYjVxrpx6DQmXLApv0jVB5N8qPz4qZFD0mNe7YmgMNbaz5Zs0QJB AOkZX4OaDo50o2eiWUX85EoeMjCbSL2T3PZido/mCQPGmidY+RrUO1/N517JqUArAr2dr7dxFyKO M77vgWc9ua4= ------_=_NextPart_000_01C0B610.4423E930-- From owner-ietf-smime-examples Wed Mar 28 05:25:05 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA29977 for ietf-smime-examples-bks; Wed, 28 Mar 2001 05:25:05 -0800 (PST) Received: from nitgw.mains.nitech.ac.jp (nitgw.mains.nitech.ac.jp [133.68.21.192]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA29958 for ; Wed, 28 Mar 2001 05:24:54 -0800 (PST) Received: from galaxy.elcom.nitech.ac.jp (galaxy.elcom.nitech.ac.jp [133.68.163.180]) by nitgw.mains.nitech.ac.jp (01022815) with ESMTP id f2SDOB101999; Wed, 28 Mar 2001 22:24:11 +0900 (JST) Received: from mars.elcom.nitech.ac.jp (mars.elcom.nitech.ac.jp [133.68.163.1]) by galaxy.elcom.nitech.ac.jp (00091320) with ESMTP id WAA23524; Wed, 28 Mar 2001 22:21:31 +0900 (JST) Received: from popo (ppp25.elcom.nitech.ac.jp [133.68.161.125]) by mars.elcom.nitech.ac.jp (8.9.3/3.7W) with SMTP id WAA07591; Wed, 28 Mar 2001 22:24:08 +0900 (JST) Message-ID: <004a01c0b78a$8dad7960$7da14485@elcom.nitech.ac.jp> From: "Takuto Okuno" To: "Pawling, John" , References: <0B95FB5619B3D411817E006008A5925945EEE7@wfhqex06.gfgsi.com> Subject: Re: draft-ietf-smime-examples-06.txt Date: Wed, 28 Mar 2001 22:24:28 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, I could do a test with a attached PrivateKey. Thanks a lot for your help :-) > Takuto, > > Attached is the BobPrivRSAEncrypt.pri file that can be used to decrypt the > section 6.2 message included in the Examples-06 document. I believe that > Paul Hoffman plans to correct this problem in the next Examples draft. > > =========================================== > John Pawling, John.Pawling@GetronicsGov.com > Getronics Government Solutions, LLC > =========================================== -- Takuto Okuno. From owner-ietf-smime-examples Fri Apr 6 12:16:26 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA21258 for ietf-smime-examples-bks; Fri, 6 Apr 2001 12:16:26 -0700 (PDT) Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21253 for ; Fri, 6 Apr 2001 12:16:24 -0700 (PDT) Received: from vamsi.phaos.com (pc228.starlan.com [206.30.74.228] (may be forged)) by mail.phaos.com (8.9.3/8.9.3) with ESMTP id OAA08786 for ; Fri, 6 Apr 2001 14:08:29 -0400 Message-Id: <5.0.2.1.0.20010406150721.00a66330@206.30.74.234> X-Sender: vamsi@206.30.74.234 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 15:15:44 -0400 To: ietf-smime-examples@imc.org From: Vamsi Motukuru Subject: Signed Receipts using Outlook Express Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: While looking at the S/MIME ESS signed-receipt message generated using Outlook Express 5.0 on Windows 2000, I noticed that in the ' EncapsulatedContentInfo' field of the CMS 'Signed-Data' ASN.1 structure, the eContent [0] EXPLICIT OCTET STRING is instead encoded as a eContent [0] EXPLICIT SEQUENCE Is this a known issue or am I mistaken ? Thanks in advance, Vamsi Motukuru From owner-ietf-smime-examples Fri Apr 6 12:17:37 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id MAA21338 for ietf-smime-examples-bks; Fri, 6 Apr 2001 12:17:37 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA21333 for ; Fri, 6 Apr 2001 12:17:35 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 15:18:35 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692938@wfhqex06.gfgsi.com> From: "Pawling, John" To: "SMIME Examples List (E-mail)" Cc: "Colestock, Robert" Subject: Corrected Samples for Examples-07 I-D Date: Fri, 6 Apr 2001 15:18:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0BECE.5D71BF90" Sender: owner-ietf-smime-examples@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_000_01C0BECE.5D71BF90 Content-Type: text/plain; charset="iso-8859-1" All, In reply to several e-mail messages, Getronics Government Solutions has used the S/MIME Freeware Library (SFL) to generate new corrected versions (see below) of the following sample messages (attached). We propose that these messages should be included in the next release (-07) of the "Examples of S/MIME Messages" Internet-Draft. We still need to generate corrected samples for sections 5.8, 5.9 and 6.8. We need to enhance our MIME capabilities before generating those samples. Thanks to all who provided feedback!! We look forward to further feedback. 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures as specified in RFC 2630, Section 12.2.1. New samples including the corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, 11.1, 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all DSA-signed messages including those submitted by Jim Schaad, because we (and others) could not verify the signature of Jim's DSA-signed messages. 2) We corrected the SFL to properly implement the following requirement as specified in RFC 2630, Section 12.3.1: "For key agreement of RC2 key-encryption keys, 128 bits must be generated as input to the key expansion process used to compute the RC2 effective key [RC2]." New corrected samples are provided for sections 6.3, 6.7, 6.9, 6.10. The sample for section 6.7 also included the correct KEKRecipientInfo version value (4). 3) We were unable to use the BobPrivRSAEncrypt private key included in the Examples-06 document. We are providing a new BobPrivRSAEncrypt private key that can be used to decrypt the sample 6.2 message included in the Examples-06 document. We are also providing a new BobRSASignByCarl certificate. Paul: Recommend changing all occurrences of "DH-DSS" to "DSA" to be consistent with RFC 2630. Thank you again for the feedback!! =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== <> ------_=_NextPart_000_01C0BECE.5D71BF90 Content-Type: application/octet-stream; name="smime_examples.zip" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime_examples.zip" UEsDBBQAAAAIADV2eyq121qZ/AEAAAQCAAAUAAAAQm9iUlNBU2lnbkJ5Q2FybC5jZXIzaGJiMGhi zF3AzMTIxCTgZpJ9vIEhbI/g5Ty9s7GFFww42Vi1+ZiZZFkZDIQMBQz42JhDWZiF2Z0Ti3KCgh0N 5MR5LS0NLA0tDQwNLA2MosR5jS0NjYyByNTS1DLKQNCQ34AXoofNKT8JpKVxPlCEU6vNo+07LyMj IysDc2Mvg0FjJ1NjI8OpmId6b84ftI4VkL4fYlo4k4vzhu2TxP0L9nHtE1xis9XC0dGD5WH0RnGZ 4K1fjope/sfzm2fNqwYJM+Y6x8nB1x1KPG/fPLb+37VTvKcYW/oXvlzMoKgeeNVBctXjAwYV0Qs2 PTuoq2J2ep2LQNOGuyXXv70OVN+0fNvailPLpSMDJd5r8AQzMTMyMC5OMIgz4AE6WlaYkfE/C5MB A9jbsvwgHgszE6uCgTyIr8wiYSDWIPLywQT1NRUKVbMu+3xyMvdTWjfPYreBLEgBH4sYi8iLLzvS b2yetkTrs+AqzctTo9rEtqgghSoz0Nczfq2vVWRctbljz8f3QvG+EQY3+vz2PNTZVJcR3svjHHNd zvXi96nGjxaUnhI+EbzHWG325hMB98+2ZEm/8DjhdKExOcdYch9T5jcxw/orM+83VH22/iGtWasW aM6sZP9N1Nbgs1HXx3XT713/KrZy+drjouuD7VaoTtx0JN4vSzTcPWDPpl8AUEsDBBQAAAAIAPp1 hipEbhm86AMAAFMEAAAIAAAAMTEuMy5iaW4zaGLxZ+PUavNo+87LyM60oInFwaCJxYaJkdGQ04Cd jVWbj5lJykAboYRxgRyLTEhGZrECEBXn56YqFCfmFuSkKiTn55Wk5pXoLWhiemTQxHQPiOcuYGZi ZGJiYjhhwMnGDjThnAULs4GQoYABHxtzKAuzMLtzYlGOS3CwgZw4r6WlgYWhuYGhoYGJZZQ4r7Gl oZExEJlamlpGGQgbChrwQ/RwOOZkJqeCNDUxbgNibZjJjECOHFNjI0Nj79m3za+45lnaHfLQWPzE ffJdvusr+N4EH13dwuH/f8rDYo86nmufXTwu/pu/fsnCTv2HNw1OmN2zn71/u8+d+MyuJ6UXzHkm ckydfW953M8/X+br33Ve0R3y0X4DO4e7b2zH4cNbNz8O5Si9alkmcKRi7/+5G1qmm396Eii99Qnn tJjPddG3mUQZHrkvk3JN2yF87Fb/DnNF7aTu75PPMjU2qFlcEOk0WmX52y73pndklk+ZsiULk2nM p9NSBoflAmLvzo58dHYVq23EgepFZjvy2NfXdjmpLv9Set6LI87bbsKP3FdzTip2WZeJvDynF7uY /axy6w59A8aaXM9OwU4zl70/Tkz1Cg7b+uhn8RupRDN5wfpDe99eDPg/o+TQxUavBMtdZpbMjS0M QGfEPN4ZVSoyjXtl1d3H9ivfrIm7s3e7sKDJMrFODUHlmyZt6aWlwkK2ztH5TwP3/+r8tEjaTqXW lr03OvnEbtelC7wet147x9Zg/0K5TuqTyupgqR3qvHLvOfaniTTEJK1J/SXa/XG3yZVL08y/Jbpv OmLU8qHO0eGv2/JkP+NPSx99+dT8dMfixmaDxgYDBWCEygqySBqIN4omgiO1uNghtQKcnIr1kvNz DXhAKoQZGf+zMBkwgBONLD+Ix8LMxHbAQB7EV2aRMBBrEClwsWvSy2+/53W59LGtwh5n7ckf5Q1k QQr4WMRYRPblLNz8+OD3t84FS84JMz76+3j6v7NIaZIZaLouMNpmbDhmf77QPcp0pVf/gR8qrC/c pvQxiUTP9zjQs/Ag0xyXVy8Xth9cWq+hu9uwiVEcmN6EgRnFQAJbkganelgGWtC4zkACnoc4mQ25 kTKUgTJChsUQ6FiHrDccQZW78sSYdOexaR5QmtZ+18Mgl40bpkiAickwzjAGaDXQA8wsrGzsHMBc o9/AAeG0VSxUFlYM8fAMVgAiR4UQ1+AQhWBX59Agz5BIXWfHEFd3/6BIPWFphJKAIM8wR+dIBV/H IG+weqSwYdEHBo2IhmjN/qSNcpzT93g2Tjjf5VY35WssMMA62A753ff9m+B5UFGTh8WXY/vtqEkA UEsDBBQAAAAIAPp1hiol9EyTFwQAAEAFAAAIAAAAMTEuNC5iaW4zaGK1YePUavNo+87LyM60oIlV 16CJVZOJkdGQ04CdjVWbj5lJykAboYRxgRyLTEhGZrECEBXn56YqFCfmFuSkKiTn55Wk5pXoLWhi emTQxHQPiOcuYGZiZGJiYjhhwMnGDjThnAULs4GQoYABHxtzKAuzMLtzYlGOS3CwgZw4r6WlgYWh uYGhoYGJZZQ4r7GloZExEJlamlpGGQgbChrwQ/RwOOZkJqeCNDUxbgNibZjJjECOHFNjI0Nj79m3 za+45lnaHfLQWPzEffJdvusr+N4EH13dwuH/f8rDYo86nmufXTwu/pu/fsnCTv2HNw1OmN2zn71/ u8+d+MyuJ6UXzHkmckydfW953M8/X+br33Ve0R3y0X4DO4e7b2zH4cNbNz8O5Si9alkmcKRi7/+5 G1qmm396Eii99QnntJjPddG3mUQZHrkvk3JN2yF87Fb/DnNF7aTu75PPMjU2qFlcEOk0WmX52y73 pndklk+ZsiULk2nMp9NSBoflAmLvzo58dHYVq23EgepFZjvy2NfXdjmpLv9Set6LI87bbsKP3Fdz Tip2WZeJvDynF7uY/axy6w59A8aaXM9OwU4zl70/Tkz1Cg7b+uhn8RupRDN5wfpDe99eDPg/o+TQ xUavBMtdZpbMjS0MQGfEPN4ZVSoyjXtl1d3H9ivfrIm7s3e7sKDJMrFODUHlmyZt6aWlwkK2ztH5 TwP3/+r8tEjaTqXWlr03OvnEbtelC7wet147x9Zg/0K5TuqTyupgqR3qvHLvOfaniTTEJK1J/SXa /XG3yZVL08y/JbpvOmLU8qHO0eGv2/JkP+NPSx99+dT8dMfixmaDxgYDBWCEygqySBqIN4omgiO1 uNghtQKcnIr1kvNzDXhAKoQZGf+zMBkwgBONLD+Ix8LMxHbAQB7EV2aRMBBrEClwsWvSy2+/53W5 9LGtwh5n7ckf5Q1kQQr4WMRYRPblLNz8+OD3t84FS84JMz76+3j6v7NIaZIZaLouMNpmbDhmf77Q Pcp0pVf/gR8qrC/cpvQxiUTP9zjQs/Ag0xyXVy8Xth9cWq+hu9uwiYkFmMIZgBnFQAJbkganelgG WtDEONtAAp6JOJkNuZFylIEyQobFEOhah6w3HEGVu/LEmHTnsWkeUJrWftfDoJCNG6ZIgInJMMkw AWg30AfMLKxs7ByGpgbGDRwQTlvFQnVhVSd/J4UQD89gBSByVAhxDQ5RCHZ1Dg3yDInUdXYMcXX3 D4rUE5ZGKAkI8gxzdI5U8HUM8garN2h8hmwnp2HjNYPGy4Yp1LBXHlUZht2G2Ui2cJJrixqqMqAK fz8XLB5FpAQWPQMdJhGxnIhL5QGVBXODZh6yzJvj+VvvzBsmEadQR/+0D6J33drE7Bbv9q4JOVnN AABQSwMEFAAAAAgA+nWGKlW1IhNtAQAA/QEAAAgAAAAxMS41LmJpbjNoYvzJxqnV5tH2nZeRnWlB E+MrgybGZ0yMjIacBuxsrNp8zExSBtoIJYwL5FhkQjIyixWAqDg/N1WhODG3ICdVITk/ryQ1r0TP sIlxOdCIxUAjDCQMhAwFDPjYmENZmIXZnROLclyCg5mYGE7AjQZaaGcgATeek9mQG8kuA2WEDIuh GIuIQ9YbjqDKXXliTLrz2DQPKE1rv+th0PiHjRumSoCJ2bDxjUHjS4PGZyzspubGFkaWlhL8hpaW lgbGhoaGBiYmxsZRCxtPGjQeW5JoEG/IbcAJch6bMFNosKGYgQiIwyXMGxqs4J5fllqUlwv0k6Gg AT9InFuYI8zFUSE4syTVkMeACyLEDBQyFDcQhXiSz6k0vVjBqTQvr1LBJdiRJla45uSmFim4laak gKwAGs4O9P05CxZmFj0DHSYRiczfSaG/cgM2+ad8VC6qaBUpPrmdSaRa9JhR0vdJ5UulI/q3re7x vLEr8hYAUEsDBBQAAAAIAC18hiqxN37P7AMAAFoEAAAIAAAAMTEuNi5iaW4zaGIJY+PUavNo+87L yM60oInF3aCJxZmJkdGQ04CdjVWbj5lJykAboYRxgRyLTEhGZrECEBXn56YqFCfmFuSkKiTn55Wk 5pXoLWhiemTQxHQPiOcuYGZiZGJiYjhhwMnGDjThnAULs4GQoYABHxtzKAuzMLtzYlGOS3CwgZw4 r6WlgYWhuYGhoYGJZZQ4r7GloZExEJlamlpGGQgbChrwQ/RwOOZkJqeCNDUxbgNibZjJjECOHFNj I0Nj79m3za+45lnaHfLQWPzEffJdvusr+N4EH13dwuH/f8rDYo86nmufXTwu/pu/fsnCTv2HNw1O mN2zn71/u8+d+MyuJ6UXzHkmckydfW953M8/X+br33Ve0R3y0X4DO4e7b2zH4cNbNz8O5Si9alkm cKRi7/+5G1qmm396Eii99QnntJjPddG3mUQZHrkvk3JN2yF87Fb/DnNF7aTu75PPMjU2qFlcEOk0 WmX52y73pndklk+ZsiULk2nMp9NSBoflAmLvzo58dHYVq23EgepFZjvy2NfXdjmpLv9Set6LI87b bsKP3FdzTip2WZeJvDynF7uY/axy6w59A8aaXM9OwU4zl70/Tkz1Cg7b+uhn8RupRDN5wfpDe99e DPg/o+TQxUavBMtdZpbMjS0MQGfEPN4ZVSoyjXtl1d3H9ivfrIm7s3e7sKDJMrFODUHlmyZt6aWl wkK2ztH5TwP3/+r8tEjaTqXWlr03OvnEbtelC7wet147x9Zg/0K5TuqTyupgqR3qvHLvOfaniTTE JK1J/SXa/XG3yZVL08y/JbpvOmLU8qHO0eGv2/JkP+NPSx99+dT8dMfixmaDxgYDBWCEygqySBqI N4omgiO1uNghtQKcnIr1kvNzDXhAKoQZGf+zMBkwgBONLD+Ix8LMxHbAQB7EV2aRMBBrEClwsWvS y2+/53W59LGtwh5n7ckf5Q1kQQr4WMRYRPblLNz8+OD3t84FS84JMz76+3j6v7NIaZIZaLouMNpm bDhmf77QPcp0pVf/gR8qrC/cpvQxiUTP9zjQs/Ag0xyXVy8Xth9cWq+hu9sQmNaA6U0KmFEMJLAl aXCqh2WgBY3bDCTgeYiT2ZAbKUMZKCNkWAyBjnXIesMRVLkrT4xJdx6b5gGlae13PQxK2bhhigSY eAzTDFIMDAz0WHRCPDyDFYDIUSHY093P089dwdk1KMTTzdPZMcRVwTEkJMjTKRTICnENDgHpYGPT YmZhZWM3UDFQgrFZJBCmBIY6+gB1uwZBdCDCiEXPQIdJJJ/tcSPrXgMVfc4TrxPDb2lWclauZxLh rjpruCarvSzbVpwlWPfnqr5lc44AAFBLAwQUAAAACAAthIUqrZAxQWMDAACdAwAABwAAADUuMS5i aW4zaGKeycap1ebR9p2XkZ1pQRNzl0ETcxsTI6MhpwE7G6s2HzOTlIE2QgnjAjkWmZCMzGIFICrO z01VKE7MLchJVUjOzytJzSvRW9DE9MigiekeEM9dwMzEyMTExHDCgJONHWjCOQsWZgMhQwEDPjbm UBZmYXbnxKIcl+BgAzlxXktLAwtDcwNDQwMTyyhxXmNLQyNjIDK1NLWMMhA2FDTgh+jhcMzJTE4F aWpi3AbE2jCTGYEcOabGRobG3rNvm19xzbO0O+ShsfiJ++S7fNdX8L0JPrq6hcP//5SHxR51PNc+ u3hc/Dd//ZKFnfoPbxqcMLtnP3v/dp878ZldT0ovmPNM5Jg6+97yuJ9/vszXv+u8ojvko/0Gdg53 39iOw4e3bn4cylF61bJM4EjF3v9zN7RMN//0JFB66xPOaTGf66JvM4kyPHJfJuWatkP42K3+HeaK 2knd3yefZWpsULO4INJptMryt13uTe/ILJ8yZUsWJtOYT6elDA7LBcTenR356OwqVtuIA9WLzHbk sa+v7XJSXf6l9LwXR5y33YQfua/mnFTssi4TeXlOL3Yx+1nl1h36Bow1uZ6dgp1mLnt/nJjqFRy2 9dHP4jdSiWbygvWH9r69GPB/Rsmhi41eCZa7zCyZG1sYgM6IebwzqlRkGvfKqruP7Ve+WRN3Z+92 YUGTZWKdGoLKN03a0ktLhYVsnaPznwbu/9X5aZG0nUqtLXtvdPKJ3a5LF3g9br12jq3B/oVyndQn ldXBUjvUeeXec+xPE2mISVqT+ku0++NukyuXppl/S3TfdMSo5UOdo8Nft+XJfsaflj768qn56Y7F jc0GjQ0GCsAIlRVkkTQQbxRNBEdqcbFDagU4ORXrJefnGvCAVAgzMv5nYTJgACcaWX4Qj4WZie2A gTyIr8wiYSDWIFLgYtekl99+z+ty6WNbhT3O2pM/yhvIghTwsYixiOzLWbj58cHvb50LlpwTZnz0 9/H0f2eR0iQz0HRdYLTN2HDM/nyhe5TpSq/+Az9UWF+4TeljEome73GgZ+FBpjkur14ubD+4tF5D d7dhskEiMJMYSGBLzuAUD888CGtY9Ax0mETcJR/y7ZL0nslbcOBgU4yDlOPDW4eZREK2KIa+3ND3 ULGnITnxr/r9o8wOnwBQSwMEFAAAAAgALISFKq3fEvXiAgAAHAUAAAgAAAA1LjEwLmJpbrVSS2sT URg1MzeTTNKXTVuLL64Win2l320qNtWC0yQ2aW2rmaTQVlon7W07mkzCzETNzkSI+gdEN5KCO3+A oJuiUBXErbgQXAliUXDjRsSbpm0GWnChwmWY+83hnPOdOVCwtwpiZzFc/FFrc3Clgl2Egt3O2WxE BIdg76rjuYPQVYXYSkfR4diKamB2jHSKYkNJZZIUL6Q1k2qmlxTQOhTQc0YBrdBIGqBO4OOI9zgC ip4MyjLH7Xu1Q10qoFmoOhB54rZoQVv1CyItqOnslQ1nNPdUa+F6Hgoda8fv3f4QhgGB73zsIwT1 bvtSsEkNE49QjepKEkvyBJZMU1cTWZN2Yy2bSlAdEy8MCu5t+gYOkS7oqMGByh44rGqmgYPUWNDV jKmmNTycXVqiumDv5AU7gtGqtXoyBKfLK3XyyC4ACMLmyzhql1MqSyigZJSEmlRNlRo4o+hKippU N3BikxD3QcrqgyNz5BJLT3BssjichEDvTWflUryx2uY5FgtHZMyOhGMhOYblUCAejcSmewJSLDQy GZ32eg5VIReikSkpMI3HpejYJh7SVjkXuQxzW9ZR1/b2UcqcUW2B7uQRWWRPdUllhitBoBO7wbK6 rClmVqd4Sklm6RYSDKugmyyWEjBD3CCWiyF4uLhMWqCpfHF5auMyHklfo7qWYtRkP9SX526Pcyoo MXqTkhpwVUY8G5FGaKjUSwwqqpHDUVnikCse9EH+p1WVJ/kNyH+G/CfkOHnKN9Dn97fWE7/fD6w5 BPr7fb6Z1fxryK8/UmD+H5k7AM0Vc3XD2WWDpaFpORyUpf8iEUqm2L85l11cLEtAwcZZ9xdJ/jvk vxHd0iyRnIFBS7O8nu7QxThry/nQRAz/uWTte6J39Y3kLJquv9Ts2RPNgJMTwT2qLjLdYvjtAOIR gJdr3vfuS+vA2texntGh609+zd56v7zysZ+N7/DhN67My/m7Vx80jB55dl8RnC9+A1BLAwQUAAAA CAAthIUq3wSa7UYDAAB+AwAABwAAADUuMy5iaW4zaGKuYuPUavNo+87LyM60oIk526CJOZ2JkdGQ 04CdjVWbj5lJyoAboYRxQRPTI4MmpntAPHcBMxMjExMTwwkDTjZ2oIpzFizMBkKGAgZ8bMyhLMzC 7M6JRTkuwcEGcuK8lpYGFobmBoaGBiaWUeK8xpaGRsZAZGppahllIGwoaMAP0cPhmJOZnArS1MS4 DYi1YSYzAjlyTI2NDI29Z982v+KaZ2l3yENj8RP3yXf5rq/gexN8dHULh///KQ+LPep4rn128bj4 b/76JQs79R/eNDhhds9+9v7tPnfiM7uelF4w55nIMXX2veVxP/98ma9/13lFd8hH+w3sHO6+sR2H D2/d/DiUo/SqZZnAkYq9/+duaJlu/ulJoPTWJ5zTYj7XRd9mEmV45L5MyjVth/CxW/07zBW1k7q/ Tz7L1NigZnFBpNNoleVvu9yb3pFZPmXKlixMpjGfTksZHJYLiL07O/LR2VWsthEHqheZ7chjX1/b 5aS6/EvpeS+OOG+7CT9yX805qdhlXSby8pxe7GL2s8qtO/QNGGtyPTsFO81c9v44MdUrOGzro5/F b6QSzeQF6w/tfXsx4P+MkkMXG70SLHeZWTI3tjAAnRHzeGdUqcg07pVVdx/br3yzJu7O3u3CgibL xDo1BJVvmrSll5YKC9k6R+c/Ddz/q/PTImk7lVpb9t7o5BO7XZcu8Hrceu0cW4P9C+U6qU8qq4Ol dqjzyr3n2J8m0hCTtCb1l2j3x90mVy5NM/+W6L7piFHLhzpHh79uy5P9jD8tffTlU/PTHYsbmw0a GwwUgBEqK8giaSDeKJoIjtTiYofUisTcgpzUYr3k/FwDHpAKYUbG/yxMBgzgRCPLD+KxMDOxHTCQ B/GVWSQMxBpEClzsmvTy2+95XS59bKuwx1l78kd5A1mQAj4WMRaRfTkLNz8++P2tc8GSc8KMj/4+ nv7vLFKaZAaarguMthkbjtmfL3SPMl3p1X/ghwrrC7cpfUwi0fM9DvQsPMg0x+XVy4XtB5fWa+ju NkwxSAJmAgMJbMkZnOLhmQNhDYs+0BYRpZ6fxxtyLLoeH11iJBrM5MAmZ2QItLuhO6otist78rWt d1QYnutq3lm+5xYAUEsDBBQAAAAIAJpzhioR9tntcAgAAK0KAAAHAAAANS40LmJpbpVWCThUax+f c2ax70vSDZFKincYyyhL2SZb1hZbhkfFNSFL0WeZIUKu2yWRwUgbSSZky65wy3RthVCMuhFlqyjx nUmL78nz3O+e532f87y/c973/H/v7/d/zx/QePNwPFtjSDEfBCAumEHjvQhovKkwBOF5ABcOqyyI hqWB8o9XIIYM5hf7o14BckgL8KV4ygWQKX4+nnIevscCPY8FqjBoXLGABsOABvky0DAEw8ImhF+b I1H77op0HlNpEi4uAjzLC6/HooAoXhgI4tAOGLQYlyH5uI+t3S4gs0aASAREPBHggTZBy3GNgDoR r6aONA2iBtERiOFFgNDyHO5dPl4enpxJ1Gwg8D1MCMKi0NREFKDGwVQq6nlcADGx5927V7HBxAir ImyVXdSgUNmN/rDmICUBrApF9NnVmE1dHb75B5QWLox/pNkIgcgapnWWidHUtqoetUf3j/py9Ra5 FdS8IfB4i737gMUmP3Ot1NjXS15aG9FKfTnnMxZr4Pe2gLItMHv7RwedivQT8FWS7Vmrmf3a+wP3 H4LREArKdQOugB8Je70YBC1hYID6Qny9EGeEQcO4OiDLGStgpIBkpPjo8983F5yUC73YaTG9W8tK vjBLuwqs57wgiJHEiJ/oKGkvs4iPz2UZZ7LGdzJ02EvWK/YVjbCuJai9XPA+syts0jk9J7lsTxls K/MguiD5yQFlVA69iURKH4Ab72PnOhSncumt6lB8sKDvCcPc2qGXxd6YEOKbodEXmdZcCfL9otbs mRLdrBfJWcw29fnnN9L8eeZeFy3Qx6fO9BSi2xfdhtzFmZcUOloSpWRd32Qchzc3nNbFqCAuyEC6 47ILIAgJjwvRh6WNQf8ku5Gd3VfZtfGaamoaQAP8JPtqc2hQGdKVvy0MIQMZjuJ39kjpxRvVK/mn WEBNovWhIQ/sLW/IUD/dtygWTOHBvYa6mC3+5s3GddaKLvSFvhFK53AMKZoWVilx3kzyvcnEwPu0 jqrweN74SslTFdYQKTnhtaKEzQWH/iQ7QeE86wW/sjZg/7lv8Hq+fGnOrYSH8Jm/E/wOVdwc4u6i KG1/PApLoAbqVZ/ZsfgIbif04Mu18S5pFcLdMDWS/83+DPPqvjtc3oFaex0iMifukgVemxzcuY9P 2Yn/HOuKu63Xn0MUveraxaGyCmXyzpsPCo3ZuIKz8pl0o1i+5rbJX3pLrVwCBm8Jtq53tHm31yhE wzEgP8LERjZvtySd9Do+hFzSrWonb+QhG1OeewCnOKdU97byedDk7iYkUTJ40dTTKM4OpccGbkYf ZjDrbvZvC6oa8jGi922gWJpSmO48oz2FMtM6JSnM3N9CM/ytUCmtJYpWFW6pazdCM+78i0F1n1g9 R1Hsz91+e58ppK7FpcwyyUk6+5ncIpf5NilO2gZTx/jcBc5vfRlTefz2NesovvzNbevyLOMuPkmU IkbrJ9zbZxkZmrsbGHzJ4uV0wAI0cvvfjIBiVhjez0iPpuIbO2jWGcTWlbtrqJw8JbvCUWgknbbD 4r/mTVqFOoaw52t0lVtxWqMia3LEEC2SCF5bE5g70SEpapaisqy4Tya3dyDWHER65rI9YVTL/+tP LYDHAwLxn4+lZYPeWdWg1MS2iagx3iyiXgNpS+6IafKA4JPrguN2925Ec+9dShkKIIXzP54xIrUv Zt+6nBOnOtQLWjQH9TNqyyz6D3nFjwT9pcV/jvt8xuA11/mF2WzVAcPrCfZT+kVc3KaWLmcaG0uL 2Q7cQd3EYOGmk9VLmUXRF7SmR2zWlY7wpDrPhDs9RTZl2PSqtPHhcrH7fUnlWhuU3RM+JLchBt2k /Zd4nFo+8ZMepdf8oLdFsAIRA2s4Tz+QBo0y1i4DGQeH2/KxugfqTl3SLD/GdSssfrfitdmgR2bc ruZ6v89RxuitG+J3BIuPslRccrnaFE6XqwLoP5Q9cSJxmkbVcy3nzez2lQ7PB4xLkzVlRSIaqifa rZfSAhvaqWZuxEpNIpoajRg00pld4RgknsqXFzrA1s8bL3Dtry4TEyFclYzbIqLQS4g5EhQkJqpr 6OT7wqb2Y9z0pXV6G8N0uRKdPFqqjK8wzNinH7NwkfqvFMKlpzfesJMu3ywg85a79rB4pLN7gedH iYSpKkJXR6rWe7Lp7Sa16MnwXQafTa55WKlPXxmenY56UZ5LjQLUSCDHMaAIZi1YQ5UgfxE1IMDA 8+SXf16Aiocv5V8c6ata+IfDa3xyitn1HyYM/S6zxKDhz+wLi20/OVwClVZ0X/+Rv6mjRp5ZUt3c Ruwrk5TfYHGnbFLd2Zx6mG40NpoTW38lYsv2qhzqU0DtAdT0f3D2sq/VtIAWQC5H4AXEOPnwFVb7 BnPA1tXAztXAjtXArq8g4Ru4gp4qCmyDxcM9bYPVFwkBa9o/pM4zunoozmG6sDgc6lTW7SRV/yj2 bXjfxpmtUXSNHDwNeoNk0xjnzyK1Gq0vOf2thmEcAlLfywMeNJ5vRUkDZH48weJFpITUAFJ5EIAm nohEikSp8OM5Bo8oZeA9zm0bUnlMEt6ehVOqk0+NHSCtoIIBQAURKlu23sBamaVTbVj7NCHsFq3k veyfCJxeA9Wd35mY1EyDn7IE81T1UXEfc2iQPOdk+PEdHEJPCIH4OPQ2rVYmrVJXfSdr/K8phTHt NXMFYx4mMZyajpD9CxprI5wB34qCCkON7Jx/+IeNrl6Nn89D+YXrTM3j9L9n99rx/DF1aseze8Ul Mm8Xmo+EX5eTUH64ZzbwDGqOWChim/a53rwNej6xoZSe0M3rwLS6E6Had4+hwxixbzrnfreYnPSp oendwZLFUmFpl8Kt58gN5sUe2cm4mzsaDwzSzK+hNC219UZewrdxfRL/BVBLAwQUAAAACAAshIUq WUl655YEAADABQAABwAAADUuNi5iaW4zaGLdw8ap1ebR9p2XkZ1pQRPrWoMm1pVMjIyGnAbsbKza fMxMUgbaCCWMC+RYZEIyMosVgKg4PzdVoTgxtyAnVSE5P68kNa9Eb0ETywKDJsZdQFy5gJmJkYmJ ieGSAScbO9CEcxYszAZChgIGfGzMoSzMwuzOiUU5LsHBBnLivJaWBhaG5gZGQNIgSpzX2NLQyBiI TC1NLaMMhA0FDfghejhcMhPzUkGaGicjjGVkbmxlYGpsZFjAIF6h866uMVhPL5GDf+HswCCpW5Er ivWFVLdxnD71XsulrCuI89VeVqWr/N/+ul1fP9OCk0/4tL/OXRmT7zL7Vf8rX7aOfN403XyfocoN iROfPS2jtz96ql73p8e1KLrOrj/D965bldK+vv9nbllqLrZ8Ot/5ZejJ69HLGtPPHFh1Vu+o8uLG ZoPGBgMFoGNlBVkkDcQbRVPADi4udkitAAdVsV5yfq4BD0iFMCPjfxYmAwZwgMjyg3gszExsBwzk QXxlFgkDsQaRAhe7Jr389ntel0sf2yrscdae/FHeQBakgI9FjEUkxWBmbcwdV+6ZVkH6YvsjAu6e 05ZACm9moOm6TCJ1PDyN4ltmhWw6bPC664jNoSCzeVOZRBmOzRc/VOi9Rs+y11ZAftZm320/BRcb NDHdA+K5sNg7QXzsGRoamFjijT3HnMxkcOw1MW4DYm14BAI5cqAIbOw9+7b5Fdc8S7tDHhqLn7hP vst3fQXfm+Cjq1s4/P9PeVjsUcdz7bOLx8V/89cvWdip//CmwQmze/az92/3uROf2fWk9II5z0SO qbPvLY/7+efLfP27ziu6Qz7ab2DncPeN7Th8eOvmx6EcpVctywSOVOz9P3dDy3TzT08Cpbc+4ZwW 87ku+jYwUB65L5NyTdshfOxW/w5zRe2k7u+TzzI1NqhZXBDpNFpl+dsu96Z3ZJZPmbIlC5NpzKfT UgaH5QJi786OfHR2FattxIHqRWY78tjX13Y5qS7/UnreiyPO227Cj9xXc04qdlmXibw8pxe7mP2s cusOfQPGmlzPTsFOM5e9P05M9QoO2/roZ/EbqUQzecH6Q3vfXgz4P6Pk0MVGrwTLXWaWzI0twCTe EPN4Z1SpyDTulVV3H9uvfLMm7s7e7cKCJsvEOjUElW+atKWXlgoL2TpH5z8N3P+r89MiaTuVWlv2 3ujkE7tdly7wetx67Rxbg/0L5TqpTyqrg6V2qPPKvefYnybSEJO0JvWXaPfH3SZXLk0z/5bovumI UcuHOkeHv27Lk/2MPy199OVT89MdWFJ4IjhSaZbC9+Us3Pz44Pe3zgVLzgkzPvr7ePq/sxgpXJRh xoZj9ucL3aNMV3r1H/ihwvrCbUofk0j0fI8DPQsPMs1xefVyYfvBpfUaursNG48bJALLOAMJbOkZ nOThZR/CHhY9Ax0mkerXsU284h+vhV/juzyRT3WltVolM5OI0aTVX0UW9acnFp5REq+/N2VSxY1z Bkn4rLiE1Qp9UF61cEzrqneN15N68+NoO9tHUfalZmxA/7XNfae/mbnQbpH3jz9ay7ZObZwgOh8A UEsDBBQAAAAIAC2EhSpVo4OBYAMAAJkDAAAHAAAANS43LmJpbjNoYp7KxqnV5tH2nZeRnWlBE3Ob QRNzExMjsyGnATsbqzYfM5OUgTZCCeMCORaZkIzMYgUgKs7PTVUoTswtyElVSM7PK0nNK9Fb0MT0 yKCJ6R4Qz13AzMTIxMTEcMKAk40daMI5CxZmAyFDAQM+NuZQFmZhdufEohyX4GADOXFeS0sDC0Nz A0NDAxPLKHFeY0tDI2MgMrU0tYwyEDYUNOCH6OFwzMlMTgVpamLcBsTaMJMZgRw5psZGhsbes2+b X3HNs7Q75KGx+In75Lt811fwvQk+urqFw///lIfFHnU81z67eFz8N3/9koWd+g9vGpwwu2c/e/92 nzvxmV1PSi+Y80zkmDr73vK4n3++zNe/67yiO+Sj/QZ2Dnff2I7Dh7dufhzKUXrVskzgSMXe/3M3 tEw3//QkUHrrE85pMZ/rom8ziTI8cl8m5Zq2Q/jYrf4d5oraSd3fJ59lamxQs7gg0mm0yvK3Xe5N 78gsnzJlSxYm05hPp6UMDssFxN6dHfno7CpW24gD1YvMduSxr6/tclJd/qX0vBdHnLfdhB+5r+ac VOyyLhN5eU4vdjH7WeXWHfoGjDW5np2CnWYue3+cmOoVHLb10c/iN1KJZvKC9Yf2vr0Y8H9GyaGL jV4JlrvMLJkbWxiAzoh5vDOqVGQa98qqu4/tV75ZE3dn73ZhQZNlYp0agso3TdrSS0uFhWydo/Of Bu7/1flpkbSdSq0te2908ondrksXeD1uvXaOrcH+hXKd1CeV1cFSO9R55d5z7E8TaYhJWpP6S7T7 426TK5emmX9LdN90xKjlQ52jw1+35cl+xp+WPvryqfnpjsWNzQaNDQYKwAiVFWSRNBBvFE0ER2px sUNqBTg5Fesl5+ca8IBUCDMy/mdhMmAAJxpZfhCPhZmJ7YCBPIivzCJhINYgUuBi16SX337P63Lp Y1uFPc7akz/KG8iCFPCxiLGI7MtZuPnxwe9vnQuWnBNmfPT38fR/Z5HSJDPQdF1gtM3YcMz+fKF7 lOlKr/4DP1RYX7hN6WMSiZ7vcaBn4UGmOS6vXi5sP7i0XkN3t2G8QSwwkzRgNxmecRBWsOgZ6DCJ sNpF3vv76XvTr/2laVoPp715vnZhBZOI95ekae+yG9e7mRx9oq6gmOLhUqgCAFBLAwQUAAAACAAs hIUqEr6ix6cBAACyAQAACAAAADYuMTAuYmluM2hiXMfGqdXm0fadl5GdeUET43yDJsbZTIxMhk2M XgubGN2YGJkXNE5e2DjBgJONHajwnB1QpLGJgame6cLHfdNDcuosUvwDO9nzW9J4192fcnyflpF/ f//1cxJFLllRE1bcWZyzuLgwYn41m9jXdtWV5hk3i+seHvQwlF09pdVprkXRntN1AosVV65YfP/4 1VNNB4UTr646pvhU5PwTv1P/Qxayb7itc+uPrcRz4dOv9i428+/a/9izfN2uSFNpx+qFTiwOgh9v yW658X5OsNvfIJ5JFvbvXyz++EAt12V69d/Sj6kOXUoneSftXaGU/13muKzo1Zr/rp1mfxZnbPNy VJ4u2/RPpt1Ano0b6nlOAWZWAwFkLjsTo5WBm4GLgYSBkKGAAR8bcygLszC7c2JRjktwMBMTw0kW DfPJ92ZGz1NhPS3B+mDa63ruHK6NW1+8LH3kKnkt8e38o+eK7RaunXOudo+BByKUGQ0k2TggHGYm A16gLSwcB6pWti8IyRZuUDCZLPqCWa7Ls0GgQ+3xzez29N3iBp9juFcUrwyavG21UTEAUEsDBBQA AAAIAIGNhSpUrxuFHwEAACcBAAAHAAAANi4zLmJpbjNoYlRm49Rq82j7zsvIzrygiVHEoIlRgImR wbDxgEHjXiDDQM1AyFDAgI+NOZSFWZjdObEoJyjYkUnAzST7eAND2B7By3l6Z2MLLxjwwg1iZGRl YGlsyIpWOGzc577k759XnGyqzrtO68n7Kit+UMyL3KNaeIFLZhNb+a3CWefNiq8u/d30avmza9uc IxbHmMyI+LXwJz/H+6PteV+/L6ncfLh/00rf+xcTPj/MzXW4+Xqzr2JT3er2zW0lfy/subQru8Rs 8XfWapYn3xj5mq4abC15anRtctnT57JL3Qw8EF5jNJBk44BwmJkMeJkYrVg4mM4p1Vit/8/YoDAl cvfP3rjCvzxVHJfW53AfPxvyRob9HneJoJvZ3qQj7R4AUEsDBBQAAAAIACyEhSr7AULbvgAAAMoA AAAHAAAANi43LmJpbjNoPM7GqdXm0fadl5GdeUHjToPGbUyMTIbpi1KZGFkMVFgEfRMzc3wyi0tC ijILclJdXIMl+A0tLU0NjYwNjIxNLU0towwE2LihRnAKMLMzMVqxaCyYd29nlORfs9wOxt/XsqT/ m+6dv+/nWmlV19WTMn9UTXa/+jR8hv3ON5EGHgjrGQ0k2TggHGYmA16QORx/PhX3P1T2mdGg8DfO 91VJYbl6awfz17b20glGfFqNij87vY9NESzXm6jMAQBQSwMEFAAAAAgALISFKvqKnToiAwAAVAMA AAcAAAA2LjkuYmluM2hiDmDj1GrzaPvOy8jOvKCJ2dGgidmWiZHJsImpxKBxLxMjg4GagZChgAEf G3MoC7Mwu3NiUU5QsCOTgJtJ9vEGhrA9gpfz9M7GFl4w4IWbxMjIysDS2KCydlXHzkd1Lz9JXzZR 2XjT22xa9J/MA2+Wyp37Jc/kuarCqjPq9b0DtXUTjrv9SxYNLNrj21quECFrXHv1ntjy1bsiZp+K Y67adMIqWfvxa8+5PPMf2FvbFm3XvzWT98jx+mM7dR479jzJPLL65kHhL6f1klhdXs1SZ7C+fG8t u23xwQfzSrUWNjF6MjEyL2ictrBxsgEnGzvQeefsgCKNrQxMjY0M86Lt+ldLJ89at9B1/Xvb8nVB DXbaB+P1F64stto0YXv+P319xlVthxttmIJqm5xWbvu4Ki//y3PNxley/7XdTwrP3RbM2rVg1aLk yWoRtzPT7hiFbwuYOfX/3KUMpzeV7lDsWxpbe1HQZufhrteHGPTMp7e9SQvmyHn1tGLluhUyfv73 2h+FLHRicYh0azpZ4SLEem3h38PPzTqt2dKnGl7I7phjzPZp06wTzy8UGB6WbTX6Emm1tVzqum1E PrtLR/jRGYcdfs+c3cP70ETCQJ6NGxrqnALMrAYCyFx2JkYrAzcDFwMJjCh0CQ5mYmI4yaJRGfb9 h+pUyd6oa7UbdVc/YX9332/f3w1LCtwknzz77Coj6dzJWRShzvh4USoTI4uBCougb2Jmjk9mcUlI UWZBTqqLa7AEv6GlpamhkbGBkbGppallFKYjWDSsrm9ONcw6Pzvc8do/T88ozmOZIYe0pdnVXjkL B/oEpjMdfbM/b1nN9NkGHoj0yGggycYB4TAzGfCCzOE4ohk+JdmYo7pBgefrNJtopuN3nlo6+ZTN Lv/RyxK+yFBTWvuera8q/46nMQvLDCzYmLVWGxsasuiHZGQWKwBRokJJanGJgntqXmpRYo6CY7Cf gmNJSVFmUmlJqo5CXmluUmqRgqGegRWSD5hYDLUNNHkUnPPzSlLzShQ8MvNKihVcUouTgSFQkpmf p+BUmpaWWsTGqsXMxsoCAFBLAwQKAAAAAABcdnsqE7eO4HoCAAB6AgAAFQAAAEJvYlByaXZSU0FF bmNyeXB0LnByaTCCAnYCAQAwDQYJKoZIhvcNAQEBBQAEggJgMIICXAIBAAKBgQDkS/8YuCRX9Hf/ bnN7k3FcvDMakpJyI9hBRtDNEToEs46vgp29UR4XevJ2LCuGOae9140aU+zkANXo7KI2se3iUOIy CYo/n5klj7hOq7l91ZZl2hagxb4OrkRb7170pynLgt2sROmqk5QpDvgY1shXXvJ2xPIRYDi5Gzwd l8lq8QIDAQABAoGBAK5z5FtfW2ZaydfG7zhfUyEqL2L+3imaeoZnNud9Ynh1PXOgvCkO84+9w8nJ tvi61hObw5d6ymrwuIVlTg+9p6j3VAZBvevcIHeQ32Gbmm903uo71JyHYO12hPFqMDfV4JAW+IBH wxlr7XV3ukrtObZdAkc7XxvIHKvL6PUmP6SBAkEA/98JoFYLQlKexE2Ts7BJu97ngX0omdCxSLoL OeEceyIYM7ZA9r/crh3Qoa0EcVphCm47zjDaNp9lJSm7pw5/CwJBAORpaBhf+VfQfGaJD7pjHXLL IKSBdmSJzX3RwiepLqx6VpqFB9kwA6MDq3+IklAkAaobBx8gTLfJe1b3tsJ+q3MCQFc2bI+MBHZs ttTuJEQA+IDir0IBqQ8UhPjnAOCPjCekLV+i5W21Y8CtROl2kacZSS5G+HeFSzuHBPCv0thUJpUC QGShD6xVdBu9DWF7FwPNsOanGR2Ar/FBSNgatogUoCx6xXbUDw4feiqybjcEqzlFc7pGqA+Ngl8i FAXPoqPzfIMCQCYeHRyhmCvk2zjoV25rcxmIYTr6dEo2i0doXVDrJuPqfZtOZamve6tLLnZRPajQ Eauj1qjAJzYdVAuqp9FtjfpQSwMEFAAAAAgA+nWGKrqWOAH/AwAAYgQAAAgAAAAxMS4xLmJpbjNo Yolj49Rq82j7zsvIzrSgicXfoInFm4mR0ZDTgJ2NVZuPmUnKQBuhhHGBHItMSEZmsQIQFefnpioU J+YW5KQqJOfnlaTmlegtaGJ6ZNDEdA+I5y5gZmJkYmJiOGHAycYONOGcBQuzgZChgAEfG3MoC7Mw u3NiUY5LcLCBnDivpaWBhaG5gaGhgYlllDivsaWhkTEQmVqaWkYZCBsKGvBD9HA45mQmp4I0NTFu A2JtmMmMQI4cU2MjQ2Pv2bfNr7jmWdod8tBY/MR98l2+6yv43gQfXd3C4f9/ysNijzqea59dPC7+ m79+ycJO/Yc3DU6Y3bOfvX+7z534zK4npRfMeSZyTJ19b3nczz9f5uvfdV7RHfLRfgM7h7tvbMfh w1s3Pw7lKL1qWSZwpGLv/7kbWqabf3oSKL31Cee0mM910beZRBkeuS+Tck3bIXzsVv8Oc0XtpO7v k88yNTaoWVwQ6TRaZfnbLvemd2SWT5myJQuTacyn01IGh+UCYu/Ojnx0dhWrbcSB6kVmO/LY19d2 Oaku/1J63osjzttuwo/cV3NOKnZZl4m8PKcXu5j9rHLrDn0Dxppcz07BTjOXvT9OTPUKDtv66Gfx G6lEM3nB+kN7314M+D+j5NDFRq8Ey11mlsyNLQxAZ8Q83hlVKjKNe2XV3cf2K9+sibuzd7uwoMky sU4NQeWbJm3ppaXCQrbO0flPA/f/6vy0SNpOpdaWvTc6+cRu16ULvB63XjvH1mD/QrlO6pPK6mCp Heq8cu859qeJNMQkrUn9Jdr9cbfJlUvTzL8lum86YtTyoc7R4a/b8mQ/409LH3351Px0x+LGZoPG BgMFYITKCrJIGog3iiaCI7W42CG1ApycivWS83MNeEAqhBkZ/7MwGTCAE40sP4jHwszEdsBAHsRX ZpEwEGsQKXCxa9LLb7/ndbn0sa3CHmftyR/lDWRBCvhYxFhE9uUs3Pz44Pe3zgVLzgkzPvr7ePq/ s0hpkhloui4w2mZsOGZ/vtA9ynSlV/+BHyqsL9ym9DGJRM/3ONCz8CDTHJdXLxe2H1xar6G727CJ UQ2Y3pSAGcVAAluSBqd6WAZa0LjPQAKehziZDbmRMpSBMkKGxRDoWIesNxxBlbvyxJh057FpHlCa 1n7Xw6CWjRumSICJ0TDPIIfFyBUSVgqGhnqGChrgfKGQWJxdrJCWX6SQqFCUmpyaWVCikFaUn6vg kpmYl6q5UNxAdImwgaAhvwEvxL1sTvlJQcGOBrIG0o2SRflJqUUlwKAHRkBJfnK2Q3liXjo4JhBh xaJnoMMkUuNb819h85LO++HxsT7P7H68cz76jkkkZVWWRjzP7967JolC4ivr6+5ISQgBAFBLAQIU ABQAAAAIADV2eyq121qZ/AEAAAQCAAAUAAAAAAAAAAAAIAC2gQAAAABCb2JSU0FTaWduQnlDYXJs LmNlclBLAQIUABQAAAAIAPp1hipEbhm86AMAAFMEAAAIAAAAAAAAAAAAIAC2gS4CAAAxMS4zLmJp blBLAQIUABQAAAAIAPp1hiol9EyTFwQAAEAFAAAIAAAAAAAAAAAAIAC2gTwGAAAxMS40LmJpblBL AQIUABQAAAAIAPp1hipVtSITbQEAAP0BAAAIAAAAAAAAAAAAIAC2gXkKAAAxMS41LmJpblBLAQIU ABQAAAAIAC18hiqxN37P7AMAAFoEAAAIAAAAAAAAAAAAIAC2gQwMAAAxMS42LmJpblBLAQIUABQA AAAIAC2EhSqtkDFBYwMAAJ0DAAAHAAAAAAAAAAAAIAC2gR4QAAA1LjEuYmluUEsBAhQAFAAAAAgA LISFKq3fEvXiAgAAHAUAAAgAAAAAAAAAAAAgALaBphMAADUuMTAuYmluUEsBAhQAFAAAAAgALYSF Kt8Emu1GAwAAfgMAAAcAAAAAAAAAAAAgALaBrhYAADUuMy5iaW5QSwECFAAUAAAACACac4YqEfbZ 7XAIAACtCgAABwAAAAAAAAAAACAAtoEZGgAANS40LmJpblBLAQIUABQAAAAIACyEhSpZSXrnlgQA AMAFAAAHAAAAAAAAAAAAIAC2ga4iAAA1LjYuYmluUEsBAhQAFAAAAAgALYSFKlWjg4FgAwAAmQMA AAcAAAAAAAAAAAAgALaBaScAADUuNy5iaW5QSwECFAAUAAAACAAshIUqEr6ix6cBAACyAQAACAAA AAAAAAAAACAAtoHuKgAANi4xMC5iaW5QSwECFAAUAAAACACBjYUqVK8bhR8BAAAnAQAABwAAAAAA AAAAACAAtoG7LAAANi4zLmJpblBLAQIUABQAAAAIACyEhSr7AULbvgAAAMoAAAAHAAAAAAAAAAAA IAC2gf8tAAA2LjcuYmluUEsBAhQAFAAAAAgALISFKvqKnToiAwAAVAMAAAcAAAAAAAAAAAAgALaB 4i4AADYuOS5iaW5QSwECFAAKAAAAAABcdnsqE7eO4HoCAAB6AgAAFQAAAAAAAAAAACAAtoEpMgAA Qm9iUHJpdlJTQUVuY3J5cHQucHJpUEsBAhQAFAAAAAgA+nWGKrqWOAH/AwAAYgQAAAgAAAAAAAAA AAAgALaB1jQAADExLjEuYmluUEsFBgAAAAARABEApwMAAPs4AAAAAA== ------_=_NextPart_000_01C0BECE.5D71BF90-- From owner-ietf-smime-examples Fri Apr 6 12:37:21 2001 Received: by above.proper.com (8.9.3/8.9.3) id MAA22332 for ietf-smime-examples-bks; Fri, 6 Apr 2001 12:37:21 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id MAA22328 for ; Fri, 6 Apr 2001 12:37:20 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Fri, 6 Apr 2001 15:38:21 -0400 Message-ID: <0B95FB5619B3D411817E006008A5925969293A@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Vamsi Motukuru'" , ietf-smime-examples@imc.org Subject: RE: Signed Receipts using Outlook Express Date: Fri, 6 Apr 2001 15:38:16 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Vamsi, The sample signed receipt in the Examples-06 document is correctly ASN.1 encoded as specified in RFC 2634 (ESS). RFC 2630 (CMS) defines EncapsulatedContentInfo as follows: EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded Receipt content MUST be directly encoded within the signedData encapContentInfo eContent OCTET STRING defined in [CMS]." In March 2000, we performed signed receipt interop testing with Microsoft. We discovered that they were incorrectly ASN.1 encoding signed receipts. Their original signed receipt was composed of a signedData encapsulating a Receipt content, but the eContent OCTET STRING tag and length fields were missing. After they fixed their code to correctly ASN.1 encode the receipt structure inside of the signedData encapContentInfo eContent OCTET STRING, then we were able to successfully use the S/MIME Freeware Library to ASN.1 decode and verify their signed receipts. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Vamsi Motukuru [mailto:vamsi@phaos.com] Sent: Friday, April 06, 2001 3:16 PM To: ietf-smime-examples@imc.org Subject: Signed Receipts using Outlook Express While looking at the S/MIME ESS signed-receipt message generated using Outlook Express 5.0 on Windows 2000, I noticed that in the ' EncapsulatedContentInfo' field of the CMS 'Signed-Data' ASN.1 structure, the eContent [0] EXPLICIT OCTET STRING is instead encoded as a eContent [0] EXPLICIT SEQUENCE Is this a known issue or am I mistaken ? Thanks in advance, Vamsi Motukuru From owner-ietf-smime-examples Fri Apr 6 13:31:00 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id NAA26594 for ietf-smime-examples-bks; Fri, 6 Apr 2001 13:31:00 -0700 (PDT) Received: from mail.phaos.com ([206.30.74.234]) by above.proper.com (8.9.3/8.9.3) with ESMTP id NAA26588 for ; Fri, 6 Apr 2001 13:30:59 -0700 (PDT) Received: from vamsi.phaos.com (pc228.starlan.com [206.30.74.228] (may be forged)) by mail.phaos.com (8.9.3/8.9.3) with ESMTP id PAA09025; Fri, 6 Apr 2001 15:22:58 -0400 Message-Id: <5.0.2.1.0.20010406162152.00a60a20@206.30.74.234> X-Sender: vamsi@206.30.74.234 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Fri, 06 Apr 2001 16:30:12 -0400 To: "Pawling, John" , ietf-smime-examples@imc.org From: Vamsi Motukuru Subject: RE: Signed Receipts using Outlook Express In-Reply-To: <0B95FB5619B3D411817E006008A5925969293A@wfhqex06.gfgsi.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_368866922==_" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --=====================_368866922==_ Content-Type: text/plain; charset="us-ascii"; format=flowed John, The signed-receipt in examples-06 in correctly encoded. The signed-receipt that I am talking about was generated using Outlook Express 5.0/Win2000 Professional and the encoding is incorrect. Please see the attached file. Could you tell me which Microsoft product that was used for inter-op testing. Thanks, Vamsi At 03:38 PM 4/6/01 -0400, Pawling, John wrote: >Vamsi, > >The sample signed receipt in the Examples-06 document is correctly ASN.1 >encoded as specified in RFC 2634 (ESS). > >RFC 2630 (CMS) defines EncapsulatedContentInfo as follows: > EncapsulatedContentInfo ::= SEQUENCE { > eContentType ContentType, > eContent [0] EXPLICIT OCTET STRING OPTIONAL } > >RFC 2634 (ESS), Section 2.4, bullet 9 states: "The ASN.1 DER encoded Receipt >content MUST be directly encoded within the signedData encapContentInfo >eContent OCTET STRING defined in [CMS]." > >In March 2000, we performed signed receipt interop testing with Microsoft. >We discovered that they were incorrectly ASN.1 encoding signed receipts. >Their original signed receipt was composed of a signedData encapsulating a >Receipt content, but the eContent OCTET STRING tag and length fields were >missing. After they fixed their code to correctly ASN.1 encode the receipt >structure inside of the signedData encapContentInfo eContent OCTET STRING, >then we were able to successfully use the S/MIME Freeware Library to ASN.1 >decode and verify their signed receipts. > >=========================================== >John Pawling, John.Pawling@GetronicsGov.com >Getronics Government Solutions, LLC >=========================================== > > >-----Original Message----- >From: Vamsi Motukuru [mailto:vamsi@phaos.com] >Sent: Friday, April 06, 2001 3:16 PM >To: ietf-smime-examples@imc.org >Subject: Signed Receipts using Outlook Express > > > > >While looking at the S/MIME ESS signed-receipt message generated using >Outlook Express 5.0 on Windows 2000, I noticed that in the >' EncapsulatedContentInfo' field of the CMS 'Signed-Data' ASN.1 structure, >the > eContent [0] EXPLICIT OCTET STRING >is instead encoded as a > eContent [0] EXPLICIT SEQUENCE > >Is this a known issue or am I mistaken ? > >Thanks in advance, > >Vamsi Motukuru _______________________________________ --=====================_368866922==_ Content-Type: application/pkcs7-mime; name="rcpt.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="rcpt.p7m" MIIOIgYJKoZIhvcNAQcCoIIOEzCCDg8CAQExCzAJBgUrDgMCGgUAMIGzBgsqhkiG9w0BCRABAaCB ozCBoAIBAQYJKoZIhvcNAQcBBA1ib2JAcGhhb3MuY29tBIGAaCCThnghibDB20ltkAcoPNWyfWcT fn+TuwPyknF6Ukwc6DsXNpS91WAX4btccdxKvLx/uPnfbZfgbFTNlUG6CSLUwMpRdfyi2cp2fHnv EX0AWBaTLSI8M06+ir6l4z0InuEgFSrCJQrjE1FkmrjFYSpjhUU79SjBYLPT0e4hgrCgggr1MIID 2DCCAsACEQDQHkCLAAACfAAAAAIAAAABMA0GCSqGSIb3DQEBBQUAMIGpMQswCQYDVQQGEwJ1czEN MAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwg U2lnbmF0dXJlIFRydXN0IENvLjERMA8GA1UECxMIRFNUQ0EgWDExFjAUBgNVBAMTDURTVCBSb290 Q0EgWDExITAfBgkqhkiG9w0BCQEWEmNhQGRpZ3NpZ3RydXN0LmNvbTAeFw05ODEyMDExODE4NTVa Fw0wODExMjgxODE4NTVaMIGpMQswCQYDVQQGEwJ1czENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMO U2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLjERMA8G A1UECxMIRFNUQ0EgWDExFjAUBgNVBAMTDURTVCBSb290Q0EgWDExITAfBgkqhkiG9w0BCQEWEmNh QGRpZ3NpZ3RydXN0LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANLGJrbnpT3B xGjVUG9TxW9JEwm4ryxIjRRqoxdfWvnTLnUv2Chi0ZMv/E3Uq4flCMeZ55I/db3rJbQVwZsZPdJE jdd0IG03Ao9pk1uKxBmd9LIO/BZsubEFkoPRhSxglD5FVaDZqwgh5mDoO3TymVBRaNADLbGAvqPY UrBEzUNKcI5YhZXhTizWLUFv1oTnyJhEykfbLCSlaSbPa7gnYsP0yXqSI+0TZ4KuRS5F5X5yP4Wd lGIQ5jyRoa13AOAV7POEgHJ6jm5gl8ckWRA0g1vhpaRptlc1HHhZxtMvOnNn7pTKBBMFYgZwI7P0 fO5F2WQLW0mqpEPOJsREEmy43XkCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEAojeyP2n714Z5VEkx lTMr89EJFEliYIalsBHiUMIdBlc+LegzZL6bqq1fG03UmZWii5rJYnK1aerZWKs17RWiQ9a2vAd5 ZWRzfdd5ynvVWlHG4VMElo04z6MXrDlxawHDi1M8Y+nuecDkvpIyZHqzH5eUYr3qsiAVlfuX8ngv YzZAOONGDx3drJXK50uQe7FLqdTF65raqtWjlBRGjS0f8zrWkzr2Pnn86Oawde3uPclwx12qgUtG JRzHbBXjlU4PqjI3lAoXJJIThFjSY28r9+ZbYgsTF7ANUkz+/m9c4pFuHf2kYtdo+o56T9II2pPc 8JIRetDccpMMc5NihWjQ9DCCBxUwggX9oAMCAQICEQDQHkcyAAACfAAAACcAACqWMA0GCSqGSIb3 DQEBBQUAMIGpMQswCQYDVQQGEwJ1czENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMOU2FsdCBMYWtl IENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLjERMA8GA1UECxMIRFNU Q0EgWDExFjAUBgNVBAMTDURTVCBSb290Q0EgWDExITAfBgkqhkiG9w0BCQEWEmNhQGRpZ3NpZ3Ry dXN0LmNvbTAeFw0wMTAzMjIwODAxMThaFw0wMjAzMjIwODAxMThaMIHyMQswCQYDVQQGEwJVUzER MA8GA1UECBMITmV3IFlvcmsxETAPBgNVBAcTCE5ldyBZb3JrMR0wGwYDVQQKExREU1QgRGVtbyBD ZXJ0aWZpY2F0ZTFGMEQGA1UECxM9V2FybmluZzogVGVzdCB1c2Ugb25seSBSZWxpYW5jZSBMaW1p dCAwIERvbGxhciBWYWx1ZSBOZXcgWW9yazEQMA4GA1UEAxMHQWxpY2UgUzEeMBwGCSqGSIb3DQEJ ARYPYWxpY2VAcGhhb3MuY29tMSQwIgYKCZImiZPyLGQBARMURDAxRTQ3MzIuMjdDLjI3LjJBOTQw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAL/63pXsVv6BowLa0GSjn7xE9WYcxJDwleSbRTVT wuAALiQTHybFMpoJFDHnd5OrFWDqS/km+Nh8Hq+/B/87twcAwqptYKITyLxTTRIq+v5rMCocT3vE EnyoXmHTCeh0dMWbf5qOCENbUJGFi0RQFtmU6jmGvnJ0nDTzjHa/bxGrAgMBAAGjggNvMIIDazCC AaIGA1UdIASCAZkwggGVMIIBkQYJYIZIAYb5LwAAMIIBgjBSBggrBgEFBQcCARZGaHR0cHM6Ly9z ZWN1cmUuZGlnc2lndHJ1c3QuY29tL2RvY3MvcG9saWNpZXMvdHMvZHN0LWNwcy12MTk5OTA4MjQu aHRtbDCCASoGCCsGAQUFBwICMIIBHBqCARhUaGUgdmFsdWUgb2YgdGhpcyBUcnVzdCBJRCBDZXJ0 aWZpY2F0ZSwgaXRzIHJlbGlhbmNlIGxpbWl0LCBhbmQgdGhlIGxpYWJpbGl0eSBvZiB0aGUgaXNz dWVyIGFyZSBlc3RhYmxpc2hlZCBieSBjb250cmFjdCBhbmQgbGltaXRlZCBieSBVdGFoIGxhdy4g IFRvIHJlYXNvbmFibHkgcmVseSBvbiB0aGlzIGNlcnRpZmljYXRlLCB5b3UgbXVzdCBiZSBhbiBh dXRob3JpemVkIHJlbHlpbmcgcGFydHkgYW5kIHZhbGlkYXRlIGl0IGF0OiAgaHR0cHM6Ly9zZWN1 cmUuZGlnc2lndHJ1c3QuY29tL3RzMHwGA1UdHwR1MHMwcaBvoG2Ga2xkYXA6Ly9sZGFwLmRpZ3Np Z3RydXN0LmNvbS9vdT1EU1RDQSBYMSxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLixjPVVT P2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MIIBKwYJYIZIAYb4QgENBIIBHBaCARhU aGUgdmFsdWUgb2YgdGhpcyBUcnVzdCBJRCBDZXJ0aWZpY2F0ZSwgaXRzIHJlbGlhbmNlIGxpbWl0 LCBhbmQgdGhlIGxpYWJpbGl0eSBvZiB0aGUgaXNzdWVyIGFyZSBlc3RhYmxpc2hlZCBieSBjb250 cmFjdCBhbmQgbGltaXRlZCBieSBVdGFoIGxhdy4gIFRvIHJlYXNvbmFibHkgcmVseSBvbiB0aGlz IGNlcnRpZmljYXRlLCB5b3UgbXVzdCBiZSBhbiBhdXRob3JpemVkIHJlbHlpbmcgcGFydHkgYW5k IHZhbGlkYXRlIGl0IGF0OiAgaHR0cHM6Ly9zZWN1cmUuZGlnc2lndHJ1c3QuY29tL3RzMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgP4MA0GCSqGSIb3DQEBBQUAA4IBAQACwO8mzOfDR/jZVQ8BPRkNBBuG kBJe73Ze1wuauEbHN2RNLHWmlOa/xnzg6uKoZ5a0kvZWjrYP2fvg4+5a/WH8p09c/M8E+4pjy7LI HkMysUGNDh16+KLSaWmd0trHijr27heEpQp7hiS5Z9B4jLfzRbda5YAz0PkS2JAReSyIIvrNT2ws qjGaCb91wqYGzunedN86krfRbnrnqvKqroz6rg1soEAx4CLjcwUeF/S8W39IJ6JrBk/YVbPZolCI qNgkYwY8r4XKYI9riwqQeyuGEG4erbzCuu4WnF7D8f5vaII9Pqfc337lPZrFn1E3u8TV2X7cQyP7 1EStZ5xuXOnSMYICTDCCAkgCAQEwgb8wgakxCzAJBgNVBAYTAnVzMQ0wCwYDVQQIEwRVdGFoMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3Qg Q28uMREwDwYDVQQLEwhEU1RDQSBYMTEWMBQGA1UEAxMNRFNUIFJvb3RDQSBYMTEhMB8GCSqGSIb3 DQEJARYSY2FAZGlnc2lndHJ1c3QuY29tAhEA0B5HMgAAAnwAAAAnAAAqljAJBgUrDgMCGgUAoIHj MBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABATAcBgkqhkiG9w0BCQUxDxcNMDEwNDA2MTgyMjAw WjAjBgkqhkiG9w0BCQQxFgQUYDvDuqNu/EFqY1jVJ6mWrO8c1NAwJQYLKoZIhvcNAQkQAgUxFgQU 92MkYzLdcqpC9g3oWFmHUfkJmQQwWwYJKoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG 9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0w DQYJKoZIhvcNAQEBBQAEgYBREx7YQPXdxaHkHn5ivix2b1dgGsvxhql7OW43GF/T8Vfj4hzuu4ck H3LdVFFiHVJfbISx5GLyQlmhI4BmDKYJaEtlJV8t2O2P2+peoIrjsG720UOI+lLmO24K57U35SM5 /16DCe/GWDNlBsEKdzbQ4/NJ8M4rZnrHpQDbzo6eMg== --=====================_368866922==_-- From owner-ietf-smime-examples Sat Apr 21 16:18:35 2001 Received: by above.proper.com (8.9.3/8.9.3) id QAA24919 for ietf-smime-examples-bks; Sat, 21 Apr 2001 16:18:35 -0700 (PDT) Received: from gandalf.trustpoint.com (gandalf.trustpoint.com [157.22.240.75]) by above.proper.com (8.9.3/8.9.3) with ESMTP id QAA24914 for ; Sat, 21 Apr 2001 16:18:33 -0700 (PDT) Received: from ronald.certicom.com (ronald [10.1.6.23]) by gandalf.trustpoint.com (8.8.7/8.8.7) with ESMTP id QAA06631; Sat, 21 Apr 2001 16:18:29 -0700 Received: (from ronald@localhost) by ronald.certicom.com (8.8.7/8.8.7) id QAA26127; Sat, 21 Apr 2001 16:18:32 -0700 Date: Sat, 21 Apr 2001 16:18:32 -0700 From: "Life is hard, and then you die" To: "Pawling, John" Cc: "SMIME Examples List (E-mail)" , "Colestock, Robert" Subject: Re: Corrected Samples for Examples-07 I-D Message-ID: <20010421161832.C25798@trustpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Fri, 6 Apr 2001 at 15:18:30 -0400, John Pawling wrote: > 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures > as specified in RFC 2630, Section 12.2.1. New samples including the > corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, 11.1, > 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all DSA-signed > messages including those submitted by Jim Schaad, because we (and others) > could not verify the signature of Jim's DSA-signed messages. I can successfully verify the signatures on all these now (except for Diane's sig on 5.6, as we don't support parameter inheritance). > 2) We corrected the SFL to properly implement the following requirement as > specified in RFC 2630, Section 12.3.1: "For key agreement of RC2 > key-encryption keys, 128 bits must be generated as input to the key > expansion process used to compute the RC2 effective key [RC2]." New > corrected samples are provided for sections 6.3, 6.7, 6.9, 6.10. The sample > for section 6.7 also included the correct KEKRecipientInfo version value > (4). Ok, I can successfully decrypt all these now, except for 6.7 which I haven't tested yet. Note that 6.4, 6.5, and 6.8 all still have the wrong OId in the KeyEncryptionAlgorithmIdentifier. > 3) We were unable to use the BobPrivRSAEncrypt private key included in the > Examples-06 document. We are providing a new BobPrivRSAEncrypt private key > that can be used to decrypt the sample 6.2 message included in the > Examples-06 document. We are also providing a new BobRSASignByCarl > certificate. Umm, this is getting confusing. For one, the key and certificate you just provided are identical to those in the examples-06 document. The correct key however can be found in http://www.imc.org/ietf-smime-examples/mail-archive/bin00002.bin . Using this I can decrypt 6.2, 6.3, and 6.9. OTOH, I can't verify Bob's signature 11.2 - was that perchance generated using the key from examples-06? Cheers, Ronald From owner-ietf-smime-examples Sun Apr 22 05:31:14 2001 Received: by above.proper.com (8.9.3/8.9.3) id FAA27098 for ietf-smime-examples-bks; Sun, 22 Apr 2001 05:31:14 -0700 (PDT) Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88]) by above.proper.com (8.9.3/8.9.3) with ESMTP id FAA27087 for ; Sun, 22 Apr 2001 05:31:11 -0700 (PDT) Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=celocom.com) by anchor-post-30.mail.demon.net with esmtp (Exim 2.12 #1) id 14rJ1A-000NqM-0U for ietf-smime-examples@imc.org; Sun, 22 Apr 2001 13:31:10 +0100 Message-ID: <3AE2CF72.1E409008@celocom.com> Date: Sun, 22 Apr 2001 13:32:50 +0100 From: Dr S N Henson Organization: S N Henson X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "SMIME Examples List (E-mail)" Subject: Re: Corrected Samples for Examples-07 I-D References: <20010421161832.C25798@trustpoint.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: "Life is hard, and then you die" wrote: > > On Fri, 6 Apr 2001 at 15:18:30 -0400, John Pawling wrote: > > 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures > > as specified in RFC 2630, Section 12.2.1. New samples including the > > corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, 11.1, > > 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all DSA-signed > > messages including those submitted by Jim Schaad, because we (and others) > > could not verify the signature of Jim's DSA-signed messages. > > I can successfully verify the signatures on all these now (except for > Diane's sig on 5.6, as we don't support parameter inheritance). > My code does support parameter inheritance and I can now verify the signature on 5.6. One additional minor point. Example 8.2 seems to contain a extra 0x0d character at the end. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Mon Apr 23 10:14:22 2001 Received: by above.proper.com (8.9.3/8.9.3) id KAA07827 for ietf-smime-examples-bks; Mon, 23 Apr 2001 10:14:22 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA07823 for ; Mon, 23 Apr 2001 10:14:21 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Apr 2001 13:15:19 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692A4C@wfhqex06.gfgsi.com> From: "Pawling, John" To: "SMIME Examples List (E-mail)" Subject: RE: Corrected Samples for Examples-07 I-D Date: Mon, 23 Apr 2001 13:15:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Steve, Thanks for your feedback. We generated the Example 8.2 included in the Examples-06 document. We will investigate: "Example 8.2 seems to contain a extra 0x0d character at the end." =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Dr S N Henson [mailto:drh@celocom.com] Sent: Sunday, April 22, 2001 8:33 AM To: SMIME Examples List (E-mail) Subject: Re: Corrected Samples for Examples-07 I-D "Life is hard, and then you die" wrote: > > On Fri, 6 Apr 2001 at 15:18:30 -0400, John Pawling wrote: > > 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures > > as specified in RFC 2630, Section 12.2.1. New samples including the > > corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, 11.1, > > 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all DSA-signed > > messages including those submitted by Jim Schaad, because we (and others) > > could not verify the signature of Jim's DSA-signed messages. > > I can successfully verify the signatures on all these now (except for > Diane's sig on 5.6, as we don't support parameter inheritance). > My code does support parameter inheritance and I can now verify the signature on 5.6. One additional minor point. Example 8.2 seems to contain a extra 0x0d character at the end. Steve. -- Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/ Personal Email: shenson@drh-consultancy.demon.co.uk Senior crypto engineer, Celo Communications: http://www.celocom.com/ Core developer of the OpenSSL project: http://www.openssl.org/ Business Email: drh@celocom.com PGP key: via homepage. From owner-ietf-smime-examples Mon Apr 23 11:00:15 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id LAA12586 for ietf-smime-examples-bks; Mon, 23 Apr 2001 11:00:15 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id LAA12581 for ; Mon, 23 Apr 2001 11:00:14 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Apr 2001 14:01:12 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692A52@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Life is hard, and then you die'" Cc: "SMIME Examples List (E-mail)" , "Colestock, Robert" Subject: RE: Corrected Samples for Examples-07 I-D Date: Mon, 23 Apr 2001 14:01:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Ronald, Thank you for your feedback. I have some initial responses to your comments in-line. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Life is hard, and then you die [mailto:ronald@trustpoint.com] Sent: Saturday, April 21, 2001 7:19 PM To: Pawling, John Cc: SMIME Examples List (E-mail); Colestock, Robert Subject: Re: Corrected Samples for Examples-07 I-D On Fri, 6 Apr 2001 at 15:18:30 -0400, John Pawling wrote: > 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures > as specified in RFC 2630, Section 12.2.1. New samples including the > corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, 11.1, > 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all DSA-signed > messages including those submitted by Jim Schaad, because we (and others) > could not verify the signature of Jim's DSA-signed messages. I can successfully verify the signatures on all these now (except for Diane's sig on 5.6, as we don't support parameter inheritance). [JSP: In a separate message, Stephen Henson stated that he was able to verify Diane's signature on sample 5.6.] > 2) We corrected the SFL to properly implement the following requirement as > specified in RFC 2630, Section 12.3.1: "For key agreement of RC2 > key-encryption keys, 128 bits must be generated as input to the key > expansion process used to compute the RC2 effective key [RC2]." New > corrected samples are provided for sections 6.3, 6.7, 6.9, 6.10. The sample > for section 6.7 also included the correct KEKRecipientInfo version value > (4). Ok, I can successfully decrypt all these now, except for 6.7 which I haven't tested yet. Note that 6.4, 6.5, and 6.8 all still have the wrong OId in the KeyEncryptionAlgorithmIdentifier. [JSP: The 6.4 and 6.5 samples were provided by Jim Schaad. We can generate replacement samples using the SFL, if that is OK with Jim. We still need to generate corrected samples for sections 5.8, 5.9 and 6.8. We need to enhance our MIME capabilities before generating those samples.] > 3) We were unable to use the BobPrivRSAEncrypt private key included in the > Examples-06 document. We are providing a new BobPrivRSAEncrypt private key > that can be used to decrypt the sample 6.2 message included in the > Examples-06 document. We are also providing a new BobRSASignByCarl > certificate. Umm, this is getting confusing. For one, the key and certificate you just provided are identical to those in the examples-06 document. The correct key however can be found in http://www.imc.org/ietf-smime-examples/mail-archive/bin00002.bin . Using this I can decrypt 6.2, 6.3, and 6.9. [JSP: We will investigate this.] OTOH, I can't verify Bob's signature 11.2 - was that perchance generated using the key from examples-06? [JSP: We will double check example 11.2. I am sure that you realize that example 11.2 is a signed receipt.] Cheers, Ronald From owner-ietf-smime-examples Wed May 2 10:54:31 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id KAA14832 for ietf-smime-examples-bks; Wed, 2 May 2001 10:54:31 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id KAA14826 for ; Wed, 2 May 2001 10:54:30 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 2 May 2001 13:55:27 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692B0E@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'SMIME Examples List (E-mail)'" Cc: "Colestock, Robert" Subject: More Corrected Samples for Examples-07 I-D Date: Wed, 2 May 2001 13:55:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D331.0F674BE0" Sender: owner-ietf-smime-examples@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_000_01C0D331.0F674BE0 Content-Type: text/plain; charset="iso-8859-1" All, In reply to several e-mail messages, Getronics Government Solutions has used the S/MIME Freeware Library (SFL) to generate additional sample messages (attached) for inclusion in the next release (-07) of the "Examples of S/MIME Messages" Internet-Draft. These messages are in addition to the samples provided in the 6 April 2001 message, subject "Corrected Samples for Examples-07 I-D". The only data provided on 6 April that is being replaced is the BobPrivRSAEncrypt private key. 1) We were unable to use the BobPrivRSAEncrypt private key included in the Examples-06 document. On 6 April we provided an incorrect BobPrivRSAEncrypt private key. The attached BobPrivRSAEncrypt(.prvORIG) private key can be used to decrypt the sample 6.2 message included in the Examples-06 document. We recommend that the attached BobPrivRSAEncrypt(.prvORIG) private key replace the one included in the Examples-06 document. 2) We generated new samples for sections 6.4 and 6.5 that include the correct OID for Ephemeral-Static Diffie-Hellman in the KeyEncryptionAlgorithmIdentifier field. 3) Attached is the Example 8.2 binary file without an extra 0x0d character at the end. We still need to generate corrected samples for sections 5.8, 5.9 and 6.8. We also plan to generate a sample multipart/signed message that can be added to the Examples document We need to enhance our MIME capabilities before generating those samples. Thanks to all who provided feedback!! We look forward to further feedback. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== <<6.4.bin>> <<6.5.bin>> <<8.2.bin>> <> ------_=_NextPart_000_01C0D331.0F674BE0 Content-Type: application/octet-stream; name="6.4.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.4.bin" MIIC9wYJKoZIhvcNAQcDoIIC6DCCAuQCAQIxggKYoYIBSAIBA6CBlqGBkzAJBgcqhkjOPgIBA4GF AAKBgQCdbqpNVTUFZmX3oGR1mWf7Tk9TVTR6hSGVK35iPN4KySAcTIBHPqZf9UsHEiZ0vti4Lizq RSEFyH36aG4jRocP0tCoiw7eTX0s81F2n1j38nsjMNchU5ApmlteZBwN/37rnTXftdOj/zAiuK8x CcKOv8i9UfInpc00EbVMK79oGKFCBECDFBrYRijveD/IHik7FPj+FjYubzXIKWCKxmq/SOZ222p8 GDYTRyDiXzkIwgSX8/zmw291Tskwl7FBa6HoUNbHMB4GCyqGSIb3DQEJEAMFMA8GCyqGSIb3DQEJ EAMGBQAwRjBEMBgwEjEQMA4GA1UEAxMHQ2FybERTUwICANMEKDhzky1Gg8F+6mBrQc9ybzUNWbHj xQlZlOKC7Rj+Jhu8RoEbhZpWPzyhggFIAgEDoIGWoYGTMAkGByqGSM4+AgEDgYUAAoGBALpYk4u8 MVn5z/cjOnd1y/SbfF5T63OUT+V1VUhNUMSvcWmHyry1W2M7mg6l0POX2xhRwMs1pQcgIXkCB67K Ju5Erpw3N4vIRbNiT6SHDhF+SJa2o3Tg9J9dJsHofry/s0zrSlpYyxLoPkI8mdyz03pP0wiDdmtz 5rAI63YOuEBMoUIEQP/eiHo/qkTYEBSmKXLQCEyarH00tWhNCO3LSCpw1nrFQZuuxgMj8Ic/wVVN b+D/52sc71TtxFLdkAQlXvJDwRkwHgYLKoZIhvcNAQkQAwUwDwYLKoZIhvcNAQkQAwYFADBGMEQw GDASMRAwDgYDVQQDEwdDYXJsRFNTAgIAyQQoIZ9l8JcEwId+2Wki46GAsolO1n2zVd4jqlusDhcr RROpJLwJNQDmkjBDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECLia7T9eZxGKgCDqqtjEcWPkMZYR EuSOhGDwoBQC+SN54j3z/OOmdP0lOA== ------_=_NextPart_000_01C0D331.0F674BE0 Content-Type: application/octet-stream; name="6.5.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="6.5.bin" MIIBrQYJKoZIhvcNAQcDoIIBnjCCAZoCAQIxggFOoYIBSgIBA6CBlaGBkjAJBgcqhkjOPgIBA4GE AAKBgCHKVaMQM9OFoaZK2BiFExXXRaUXlN1nW+1DA+E24y7d+Tw4Zbk0ZokpDX5vhXL53eRifsOe 88Q4OWrqTgeDuEQjf779Ao9IlUjQLL8C7s2pruMg/SArer2sWYhi9UiFJqAgK/WWAkoa/KEPj5AD 7pFBRt6n5XkwN4rLQT9m8/cHMB4GCyqGSIb3DQEJEAMFMA8GCyqGSIb3DQEJEAMGBQAwgYwwRDAY MBIxEDAOBgNVBAMTB0NhcmxEU1MCAgDJBChzJjprl/lQOrhqjedHWLpMC03HJKITIm86k3DsLBfR a4AaueN5uKZ7MEQwGDASMRAwDgYDVQQDEwdDYXJsRFNTAgIA1AQorIS/KLUZVhm38r0yWVqexn71 ldzxIIAVwryVRz6S7s+2QY9Fg8nIXzBDBgkqhkiG9w0BBwEwFAYIKoZIhvcNAwcECMrUyMIptPqs gCACGOJ8GSE0zEOIiEX2fq2rlypDEeZFARE6wtgpbU1seA== ------_=_NextPart_000_01C0D331.0F674BE0 Content-Type: application/octet-stream; name="8.2.bin" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="8.2.bin" 0=81=D1=06 *=86H=86=F7=0D=01=07=06=A0=81=C30=81=C0=02=01=020C=06 = *=86H=86=F7=0D=01=07=060=14=06=08*=86H=86=F7=0D=03=07=04=08 = =96=C3=7F'=BF=A2*=80 = =B7H=E1F=D5*=88=F6=AC=9A?=9A=8F=B1W=E6=D2=FC=95a=EA=D9=8AxW=B4=C6=F1)=9D= =DA=1C=A1v08=06=03*=AB311=04/This is a test General ASN Attribute, = number 1.0:=06=0B*=86H=86=F7=0D=01 =10=02=041+0)=0C Content Hints = Description Buffer=06=05*=03=06=05=04 ------_=_NextPart_000_01C0D331.0F674BE0 Content-Type: application/octet-stream; name="BobPrivRSAEncrypt.prvORIG" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="BobPrivRSAEncrypt.prvORIG" MIICdwIBADANBgkqhkiG9w0BAQEFAASCAmEwggJdAgEAAoGBAMpc4S7sz8E7XRAb31Q1cZkKCdg9 5GG/oL4KvhGkPLU4QUFIBOFbsRccU7X0xRXT/gz7DKzqgBg2A35Bk1PXQHRJ29nGr/7Wyg3KAYSP oemjACEnUdVAGarjwDB4W6Cy5sEtJDbLrkQQgrDddNf261Ensqe2rXjKpxtZURjvKAxTAgMBAAEC gYA0koCl8jvfFY8N2k/gzqmeeq8oEJw+kMwv0xah+qsS4XSCgzVRXsLZIDDXOqnhC9wafzZBzgJN R+sMZ/jgdTF3DgacqExmcFzHTYrADDauU7rOnVacgXN0ImgG5fQoXBQXJbSCwBNpmA1d/h2WVAqP wBiMBEPbFGl6Dnr8/aCt8QJBAPWOJoKJzNRNz+10F9HYTyTh/S4Mdljx4CnvAGfR2wzxATD+9niY YrK7mvLXMV3tjEOIwHAcok4oJOqou0yDPdUCQQDS+GgiLrHNgsWwvLvQuMFWzAoriEhRdZfv2n2H i8CIVSYcgfxDedA7yEH6ri76aPpJ5EF6eKuKOvasaL35xC2HAkEAlc8ewX8unsvGMhkkuxqb1mWl X+WsgkE2wH6WocBPQsr6Lhku544YkPCR7NvKu4JEk6MnvH5LqyEkvKEqe9iJ7QJAFP0RnxT2K3Pv Jv4f0UwQMApsmJgeWbxROVOLWYjVxrpx6DQmXLApv0jVB5N8qPz4qZFD0mNe7YmgMNbaz5Zs0QJB AOkZX4OaDo50o2eiWUX85EoeMjCbSL2T3PZido/mCQPGmidY+RrUO1/N517JqUArAr2dr7dxFyKO M77vgWc9ua4= ------_=_NextPart_000_01C0D331.0F674BE0-- From owner-ietf-smime-examples Wed May 9 14:57:53 2001 Received: (from majordomo@localhost) by above.proper.com (8.9.3/8.9.3) id OAA21924 for ietf-smime-examples-bks; Wed, 9 May 2001 14:57:53 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.9.3/8.9.3) with ESMTP id OAA21917 for ; Wed, 9 May 2001 14:57:52 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 9 May 2001 17:58:49 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692B83@wfhqex06.gfgsi.com> From: "Pawling, John" To: "SMIME Examples List (E-mail)" Cc: "Colestock, Robert" Subject: Corrected Signed Receipt Sample for Examples-07 I-D Date: Wed, 9 May 2001 17:58:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0D8D3.39D14910" Sender: owner-ietf-smime-examples@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_000_01C0D8D3.39D14910 Content-Type: text/plain; charset="iso-8859-1" All, On 6 April 2001, we provided a new 11.1 sample message requesting a signed receipt, but we neglected to provide the corresponding 11.2 sample signed receipt. A new 11.2 sample signed receipt is attached that we generated based on the 6 April 11.1 sample message. Thanks to Ronald 'Life is hard, and then you die' for catching our omission. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== <<11.2.signedReceipt.bin>> > -----Original Message----- > From: Pawling, John > Sent: Friday, April 06, 2001 3:19 PM > To: SMIME Examples List (E-mail) > Cc: Colestock, Robert > Subject: Corrected Samples for Examples-07 I-D > > All, > > In reply to several e-mail messages, Getronics Government Solutions has > used the S/MIME Freeware Library (SFL) to generate new corrected versions > (see below) of the following sample messages (attached). We propose that > these messages should be included in the next release (-07) of the > "Examples of S/MIME Messages" Internet-Draft. We still need to generate > corrected samples for sections 5.8, 5.9 and 6.8. We need to enhance our > MIME capabilities before generating those samples. Thanks to all who > provided feedback!! We look forward to further feedback. > > 1) We corrected the SFL to use the id-dsa-with-sha1 OID for DSA signatures > as specified in RFC 2630, Section 12.2.1. New samples including the > corrected OID are provided for sections 5.1, 5.3, 5.4, 5.6, 5.7, 5.10, > 11.1, 11.3, 11.4, 11.5, 11.6. Note: We generated new samples for all > DSA-signed messages including those submitted by Jim Schaad, because we > (and others) could not verify the signature of Jim's DSA-signed messages. > > 2) We corrected the SFL to properly implement the following requirement as > specified in RFC 2630, Section 12.3.1: "For key agreement of RC2 > key-encryption keys, 128 bits must be generated as input to the key > expansion process used to compute the RC2 effective key [RC2]." New > corrected samples are provided for sections 6.3, 6.7, 6.9, 6.10. The > sample for section 6.7 also included the correct KEKRecipientInfo version > value (4). > > 3) We were unable to use the BobPrivRSAEncrypt private key included in the > Examples-06 document. We are providing a new BobPrivRSAEncrypt private > key that can be used to decrypt the sample 6.2 message included in the > Examples-06 document. We are also providing a new BobRSASignByCarl > certificate. > > Paul: Recommend changing all occurrences of "DH-DSS" to "DSA" to be > consistent with RFC 2630. > > Thank you again for the feedback!! > > =========================================== > John Pawling, John.Pawling@GetronicsGov.com > Getronics Government Solutions, LLC > =========================================== > > ------_=_NextPart_000_01C0D8D3.39D14910 Content-Type: application/octet-stream; name="11.2.signedReceipt.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="11.2.signedReceipt.bin" MIIECAYJKoZIhvcNAQcCoIID+TCCA/UCAQMxCTAHBgUrDgMCGjCBhQYLKoZIhvcNAQkQAQGgdgR0 MHICAQEGCSqGSIb3DQEHAQQyRXhhbXBsZSAxMS4xIChBbGljZSBhc2tzIGZvciBhIHJlY2VpcHQg ZnJvbSBEaWFuZSkELjAsAhR8TXz/ILOkid9XX11M5j747kPF7gIUZKpqKF8M+43dNGESF6l/ftwa GBKgggIEMIICADCCAW2gAwIBAgIQRjRrx4AAVrwR024uzV1x0DAJBgUrDgMCHQUAMBIxEDAOBgNV BAMTB0NhcmxSU0EwHhcNOTkwOTE5MDEwOTAyWhcNMzkxMjMxMjM1OTU5WjARMQ8wDQYDVQQDEwZC b2JSU0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMpc4S7sz8E7XRAb31Q1cZkKCdg95GG/ oL4KvhGkPLU4QUFIBOFbsRccU7X0xRXT/gz7DKzqgBg2A35Bk1PXQHRJ29nGr/7Wyg3KAYSPoemj ACEnUdVAGarjwDB4W6Cy5sEtJDbLrkQQgrDddNf261Ensqe2rXjKpxtZURjvKAxTAgMBAAGjYDBe MAwGA1UdEwEB/wQCMAAwDgYDVR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFOngkCeseCB6mtNM8kI3 TiKunji7MB0GA1UdDgQWBBTo9Lhn2LOWpCrzEaop05Vahha0JDAJBgUrDgMCHQUAA4GBAJj6r30h AaqziLzx7xJfTVgw2I5OvOEssn5oV40MQ1zXHkXR95Uz4qB1yhPIU7wzJpuzyFDfzYRqG+hIyELQ gWNsMxm+Amn2FjF/1JnfgHrzO/gbKX0mUTcDIj/2FT0w8zKK8a6X3tf1FqmnrccVr1M+qCWRssRf TmoVV0dQvLL6MYIBUzCCAU8CAQEwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7N XXHQMAcGBSsOAwIaoIGIMBoGCSqGSIb3DQEJAzENBgsqhkiG9w0BCRABATAeBgkqhkiG9w0BCQUx ERgPMjAwMTA0MDYxOTMzMDBaMCMGCSqGSIb3DQEJBDEWBBQsuaHZdX8AIPk1t5XXg0cWTApaTDAl BgsqhkiG9w0BCRACBTEWBBS2w+V2jkNorSb+RYOQ0QBcsGkdFDALBgkqhkiG9w0BAQEEgYAf3eO5 cqgiJhVOjYIABzmw1hFygRB6iWbz55HsZ5uzy4ZZ2poDBPdiiBzcvBvdTT5VxHWFDJrzRRmuc9hY aDQ/MXKkNzbrQ0k/6D22oHz1KSm2WP3wX09SgMMwylLr4GqypnrmE0bSoF6DxV+duF+BVYTcAWZI 61R/WVBmaSFjig== ------_=_NextPart_000_01C0D8D3.39D14910-- From owner-ietf-smime-examples Fri May 11 07:10:55 2001 Received: by above.proper.com (8.9.3/8.9.3) id HAA20759 for ietf-smime-examples-bks; Fri, 11 May 2001 07:10:55 -0700 (PDT) Received: from jena01.net.j.intershop.de (jena01.intershop.de [62.132.99.224]) by above.proper.com (8.9.3/8.9.3) with ESMTP id HAA20746 for ; Fri, 11 May 2001 07:10:50 -0700 (PDT) Received: by jena01.intershop.de with Internet Mail Service (5.5.2650.21) id ; Fri, 11 May 2001 16:10:20 +0200 Message-ID: <0925BB6F1711D411AFCC0060B0689A80A10510@jena02.intershop.de> From: Bernd Kunze To: "'SMIME Examples List (E-mail)'" Subject: digest-data Date: Fri, 11 May 2001 16:10:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi, The digest-data sample (7.) has a incorrect contentInfo->content part. There are missing four letters. So the length values are also wrong. The digestAlgorithmIdentifier is in RfC 2315 a OBJECT IDENTIFIER, but in the sample its a list of OIDs. What is the correct thing? Bernd -- Bernd Kunze, Security Management, Research and Development INTERSHOP Communications, 15th Floor, INTERSHOP Tower, D-07740 Jena Phone: +49-3641-50-3207, Fax: +49-3641-50-1012 Intershop(R) Sell Anywhere(tm), http://www.intershop.de From owner-ietf-smime-examples Tue Jun 19 10:54:12 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5JHsCj21339 for ietf-smime-examples-bks; Tue, 19 Jun 2001 10:54:12 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JHsBJ21335 for ; Tue, 19 Jun 2001 10:54:12 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 13:54:29 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692D8B@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'SMIME Examples List (E-mail)'" Cc: "Colestock, Robert" Subject: Corrected MIME Samples for Examples-07 I-D Date: Tue, 19 Jun 2001 13:54:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C0F8E8.DD5992B0" Sender: owner-ietf-smime-examples@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_000_01C0F8E8.DD5992B0 Content-Type: text/plain; charset="iso-8859-1" > All, > > In reply to several e-mail messages, Getronics Government Solutions has > used the S/MIME Freeware Library (SFL) to generate additional sample > messages (attached) for inclusion in the next release (-07) of the > "Examples of S/MIME Messages" Internet-Draft. We generated corrected > samples for sections 5.8, 5.9 and 6.8. Example 5.8 is an S/MIME > multipart/signed message. Example 5.9 is an S/MIME application/pkcs7-mime > signed message. Example 6.8 is an S/MIME application/pkcs7-mime encrypted > message. Please see the Examples-06 text for more info regarding these > samples. Thanks to all who provided feedback!! We look forward to > further feedback. > > =========================================== > John Pawling, John.Pawling@GetronicsGov.com > Getronics Government Solutions, LLC > =========================================== > > <<6.8.eml>> <<5.8.eml>> <<5.9.eml>> ------_=_NextPart_000_01C0F8E8.DD5992B0 Content-Type: application/octet-stream; name="6.8.eml" Content-Disposition: attachment; filename="6.8.eml" To: User2 From: User1, Subject: Example 6.8 Date: Tue, 19 Jun 2001 18:12:56 -0360 (Central Standard Time) Content-Type: Application/pkcs7-mime;name="smime.p7m";filename="smime.p7m" Content-Transfer-Encoding: base64 Content-Disposition: attachment;filename="smime.p7m" MIIBqwYJKoZIhvcNAQcDoIIBnDCCAZgCAQIxggFMoYIBSAIBA6CBlqGBkzAJBgcqhkjOPgIBA4GF AAKBgQDmJyhk4AWZ8CUECk03/cOmkEc/jeYF2ziID1hF7OLdS6ACqj2G89Fv3PsI2ryCcmW1Z6kE B4yL5xgu2inFqYTw4GsiHeFBMZIhB1lnSsBy5hgXWdeZoGMPk4UnFD7te36dGGVpsw0xAnsOTye3 N/A+xsBesttIU8pHCeDiLbm1CqFCBEBTodYFW2PPqeMUIsKkP4lE7Rb5tJDbnCUcpavNGhBRrAhI h1WHR5nxXSmQE8llSiF4j2NVrTXhspwQ5W7TRa9QMB4GCyqGSIb3DQEJEAMFMA8GCyqGSIb3DQEJ EAMGBQAwRjBEMBgwEjEQMA4GA1UEAxMHQ2FybERTUwICAMkEKPHqBuTzBDGEW5aE9huIj6Sn6OV6 v2bhhDvDDggZswdmZrAnQzuo+XQwQwYJKoZIhvcNAQcBMBQGCCqGSIb3DQMHBAhFMLeXwtc9S4Ag B4I9x5He+fE/WGA3mmvTnOFwYB8cKVpwt0EHi5zf5l8= ------_=_NextPart_000_01C0F8E8.DD5992B0 Content-Type: application/octet-stream; name="5.8.eml" Content-Disposition: attachment; filename="5.8.eml" To: User2 From: User1 Subject: Example 5.8 Date: Tue, 19 Jun 2001 18:12:55 -0360 (Central Standard Time) Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextBoundry____Tue,_19_Jun_2001_18:12:55"; protocol="application/pkcs7-signature" This is a multi-part message in MIME format. ------=_NextBoundry____Tue,_19_Jun_2001_18:12:55 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit This is some sample content. ------=_NextBoundry____Tue,_19_Jun_2001_18:12:55 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIIDegYJKoZIhvcNAQcCoIIDazCCA2cCAQExCTAHBgUrDgMCGjALBgkqhkiG9w0BBwGgggLiMIIC 3jCCAp2gAwIBAgICAMgwCQYHKoZIzjgEAzASMRAwDgYDVQQDEwdDYXJsRFNTMB4XDTk5MDgxNzAx MTA0OVoXDTM5MTIzMTIzNTk1OVowEzERMA8GA1UEAxMIQWxpY2VEU1MwggG2MIIBKwYHKoZIzjgE ATCCAR4CgYEAgY3N7YPqCp45PsJIKKPkR5PdDteoDuxTxauECE//lOFzSH4M1vNESNH+n6+koYkv 4dkwyDbeP5u/t0zcX2mK5HXQNwyRCJWb3qde+fz0ny/dQ6iLVPE/sAcIR01diMPDtbPjVQh11Tl2 EMR4vf+dsISXN/LkURu15AmWXPN+W9sCFQDiR6YaRWa4E8baj7g3IStii/eTzQKBgCY40BSJMqo5 +z5t2UtZakx2IzkEAjVc8ssaMMMeUF3dm1nizaoFPVjAe6I2uG4Hr32KQiWn9HXPSgheSz6Q+G3q nMkhijt2FOnOLl2jB80jhbgvMAF8bUmJEYk2RL34yJVKU1a14vlz7BphNh8Rf8K97dFQ/5h0wtGB SmA5ujY5A4GEAAKBgFzjuVp1FJYLqXrd4z+p7Kxe3L23ExE0phaJKBEj2TSGZ3V1ExI9Q1tv5VG/ +onyohs+JH09B41bY8i7RaWgSuOF1s4GgD/oI34a8iSrUxq4Jw0e7wi/ZhSAXGKsZfoVi/G7NNTS ljf2YUeyxDKE8H5BQP1Gp2NOM/Kl4vTyg+W4o4GDMIGAMCAGA1UdEQQZMBeBFWFsaWNlRHNzQGV4 YW1wbGVzLmNvbTAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBRwRD6C Lm+H3krTdeM9ILxDK5PxHzAdBgNVHQ4EFgQUvmyhs+PB9+1DcKTOEwHi/eOX/s0wCQYHKoZIzjgE AwMwADAtAhUAmLDGP89xR1o1qUqPwPgkBehGlI4CFFufSMCMocECnETq6aGHwaV/KC27MWQwYgIB ATAYMBIxEDAOBgNVBAMTB0NhcmxEU1MCAgDIMAcGBSsOAwIaMAkGByqGSM44BAMELzAtAhQJtxXY an7lX7WFz02W6pvGZJoXrQIVAKwURHiowoOBxnCas92QUlxxso+C ------=_NextBoundry____Tue,_19_Jun_2001_18:12:55-- ------_=_NextPart_000_01C0F8E8.DD5992B0 Content-Type: application/octet-stream; name="5.9.eml" Content-Disposition: attachment; filename="5.9.eml" To: User2 From: User1 Subject: Example 5.9 Date: Tue, 19 Jun 2001 18:12:55 -0360 (Central Standard Time) Content-Type: Application/pkcs7-mime;name=smime.p7m;filename=smime.p7m; micalg=SHA-1; protocol=application/pkcs7-signature Content-Transfer-Encoding: base64 MIIDmQYJKoZIhvcNAQcCoIIDijCCA4YCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHgQcVGhp cyBpcyBzb21lIHNhbXBsZSBjb250ZW50LqCCAuIwggLeMIICnaADAgECAgIAyDAJBgcqhkjOOAQD MBIxEDAOBgNVBAMTB0NhcmxEU1MwHhcNOTkwODE3MDExMDQ5WhcNMzkxMjMxMjM1OTU5WjATMREw DwYDVQQDEwhBbGljZURTUzCCAbYwggErBgcqhkjOOAQBMIIBHgKBgQCBjc3tg+oKnjk+wkgoo+RH k90O16gO7FPFq4QIT/+U4XNIfgzW80RI0f6fr6ShiS/h2TDINt4/m7+3TNxfaYrkddA3DJEIlZve p175/PSfL91DqItU8T+wBwhHTV2Iw8O1s+NVCHXVOXYQxHi9/52whJc38uRRG7XkCZZc835b2wIV AOJHphpFZrgTxtqPuDchK2KL95PNAoGAJjjQFIkyqjn7Pm3ZS1lqTHYjOQQCNVzyyxowwx5QXd2b WeLNqgU9WMB7oja4bgevfYpCJaf0dc9KCF5LPpD4beqcySGKO3YU6c4uXaMHzSOFuC8wAXxtSYkR iTZEvfjIlUpTVrXi+XPsGmE2HxF/wr3t0VD/mHTC0YFKYDm6NjkDgYQAAoGAXOO5WnUUlgupet3j P6nsrF7cvbcTETSmFokoESPZNIZndXUTEj1DW2/lUb/6ifKiGz4kfT0HjVtjyLtFpaBK44XWzgaA P+gjfhryJKtTGrgnDR7vCL9mFIBcYqxl+hWL8bs01NKWN/ZhR7LEMoTwfkFA/UanY04z8qXi9PKD 5bijgYMwgYAwIAYDVR0RBBkwF4EVYWxpY2VEc3NAZXhhbXBsZXMuY29tMAwGA1UdEwEB/wQCMAAw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFHBEPoIub4feStN14z0gvEMrk/EfMB0GA1UdDgQW BBS+bKGz48H37UNwpM4TAeL945f+zTAJBgcqhkjOOAQDAzAAMC0CFQCYsMY/z3FHWjWpSo/A+CQF 6EaUjgIUW59IwIyhwQKcROrpoYfBpX8oLbsxYzBhAgEBMBgwEjEQMA4GA1UEAxMHQ2FybERTUwIC AMgwBwYFKw4DAhowCQYHKoZIzjgEAwQuMCwCFDJO8Gq5wqYGtniAeddqK99H6zE9AhRk/03gvDcf u/gT5pjOss8w64EkIw== ------_=_NextPart_000_01C0F8E8.DD5992B0-- From owner-ietf-smime-examples Tue Jun 19 12:55:54 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.3/8.11.3) id f5JJtsb24600 for ietf-smime-examples-bks; Tue, 19 Jun 2001 12:55:54 -0700 (PDT) Received: from eweb01.e-certify.com (eweb01.e-certify.com [209.226.16.5] (may be forged)) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JJtqJ24596 for ; Tue, 19 Jun 2001 12:55:53 -0700 (PDT) Received: by eweb01.e-certify.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Jun 2001 15:58:33 -0400 Message-ID: <6B70FE9DEC8BD211BF7D00805F9F414BD3BE60@eweb01.e-certify.com> From: Vadim Blajkun To: "'ietf-smime-examples@imc.org'" Subject: Unknown OID Date: Tue, 19 Jun 2001 15:58:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=SHA1; boundary="----=_NextPart_000_004B_01C0F8D8.1DC55570"; protocol="application/x-pkcs7-signature" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_004B_01C0F8D8.1DC55570 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01C0F8D8.1DC0C190" ------=_NextPart_000_0047_01C0F8D8.1DC0C190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Does anyone know what object is identified by 1.2.840.113549.1.9.16.2.11 ? It is used in some of the examples in "draft-ietf-smime-examples-06.txt" document. Thanks, Vadim Blajkun E-Certify (Canada) 905.615-7187 ------=_NextPart_000_0047_01C0F8D8.1DC0C190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Does anyone know what object is = identified by 1.2.840.113549.1.9.16.2.11 ?
It is used in some of the = examples in "draft-ietf-smime-examples-06.txt" = document.

Thanks,

Vadim Blajkun
E-Certify (Canada)
905.615-7187

------=_NextPart_000_0047_01C0F8D8.1DC0C190-- ------=_NextPart_000_004B_01C0F8D8.1DC55570 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKCzCCAzkw ggIhoAMCAQICBAFP6xAwDQYJKoZIhvcNAQEFBQAwTDELMAkGA1UEBhMCY2ExEjAQBgNVBAoTCUUt Q2VydGlmeTESMBAGA1UECxMJSUQgQ2VudGVyMRUwEwYDVQQDEwxFLUNlcnRpZnkgQ0EwHhcNOTkw OTMwMTY1ODU3WhcNMDQwOTI3MTY1ODU3WjBMMQswCQYDVQQGEwJjYTESMBAGA1UEChMJRS1DZXJ0 aWZ5MRIwEAYDVQQLEwlJRCBDZW50ZXIxFTATBgNVBAMTDEUtQ2VydGlmeSBSQTCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBANywtyX77gy62KNyRA8qo+NIBNH0MHQGCA5fN8c2t4KaJUus a0mZABsX8vDfFxfp7SBqFGv9ycwP5gxrhuX1pPrbBSoAyA3qqmVANsrz5XU5jtxm20QcnsOLQzjL vPCaydnKNxPKUsEt6Ucg5cwkeODmG0y40lSCbQ65IWDvfLQA+1LELwr3BE6EL98YrGMGIN3asYHB 4a1/GIh38+v4rc96EFBWeZ5Uz94cm9dClOHP1Wz1Xj3N5WcTO5rNOmKE+WEebdVYjtn5rSo+lvHt qn8Q7vYAhTyxBQs00Vxi4I0Srr1MVMDivGRxYGWGxtmEq1hgajFufU+xiKL+FEw6jPsCAwEAAaMj MCEwDAYDVR0TBAUwAwEB/zARBglghkgBhvhCAQEEBAMCAAcwDQYJKoZIhvcNAQEFBQADggEBAK0Y gM8wvDvo8gIVVz3oTGPm7jKjf+UB8Ce5KtnBqJ4jHkeZ1y5ESxTL0L0mZAPyBo+f10iocWsWNMU+ tXmYs+bg0DgRmaQRe+M5pQ0/ndXSxXov6kQUzRBOoDSza4lf8K6fzVPVfnpQJQAhpG3pyHEA+600 F0gi7qcobIZy2/mbhkR4XgXpaDQwoRVlwananl2eI0ZOKuZOs0yfzEYImBw8Q5+0zqBg7yTOTh/o wqlyuy/aQgYh8JrleEcsCHRQaGD9hcL7r0qS8YSdAGrIViGOb8Exy1HsdnV63wEOcmih8iaO2bjG o2RS+m37Sj1aXbhUlO1VaGWdP1JMRpIWC74wggNjMIICS6ADAgECAgQDu48qMA0GCSqGSIb3DQEB BQUAMEwxCzAJBgNVBAYTAmNhMRIwEAYDVQQKEwlFLUNlcnRpZnkxEjAQBgNVBAsTCUlEIENlbnRl cjEVMBMGA1UEAxMMRS1DZXJ0aWZ5IFJBMB4XDTAxMDExMjE3MTIxMVoXDTAyMDExMjE3MTIxMVow gYIxCzAJBgNVBAYTAkNBMRIwEAYDVQQKEwlFLUNlcnRpZnkxGzAZBgNVBAsTEkUtQ2VydGlmeSBF bXBsb3llZTEWMBQGA1UEAxMNVmFkaW0gQmxhamt1bjEqMCgGCSqGSIb3DQEJARYbdmFkaW0uYmxh amt1bkBlLWNlcnRpZnkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDLA3b1Xia+WsUL oYZ6Hu71mlZ6A4JIacGnjRS2wjh2Qc+TsQQy4VsnczHM7bI4YUqMBcK4MyKjoFmk/fcM9hkKD8gu WcifezFo8BN80Fhlfr43dRBEYw07asOn8VUThT85KsF8mHCkSoMhHjqTOlucrF9dZKQ+a4n/YUJM tLM6YwIDAQABo4GZMIGWMCYGA1UdEQQfMB2BG3ZhZGltLmJsYWprdW5AZS1jZXJ0aWZ5LmNvbTAR BglghkgBhvhCAQEEBAMCAIAwCQYDVR0TBAIwADAMBgNVHQ8EBQMDAMAAMEAGA1UdHwQ5MDcwNaAz oDGGL2h0dHA6Ly93d3cuZS1jZXJ0aWZ5LmNvbS9pZGNlbnRlci9DUkwvcmFhbGwuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBgxitCBkyOxzVHp7PQJ4Ej4OOI9XDxb3MTRQaSl9NPfhHM96IETsYK8pUs 5iFwY0+DHCSPY63ELFsBhrW7sJrDi66CEiOqqQwGYlc/n+kJ2UXMNA8rll+vPKUtRy468S3qp4jD 6T0cLikqYY440x+V4GgTbd02TJQOl0cS/Whp/FC4YnWwbmQxvhheEkE7RTfetd0HbvSlU7X+M3TQ Yu2RZGgeESErNRcy7FKD6aemjfwAGnw/52XEX/ZZfjzaw9WVQeomfQYIOCqyqleSCxhg65j2cNbc jJhF06KlZoggIfQnmJWhpoynQJi/A2CDJsE6cZrRNmlgL8+Fy95CVq4XMIIDYzCCAkugAwIBAgIE A7uSgTANBgkqhkiG9w0BAQUFADBMMQswCQYDVQQGEwJjYTESMBAGA1UEChMJRS1DZXJ0aWZ5MRIw EAYDVQQLEwlJRCBDZW50ZXIxFTATBgNVBAMTDEUtQ2VydGlmeSBSQTAeFw0wMTAxMTIxNzI2MjZa Fw0wMjAxMTIxNzI2MjZaMIGCMQswCQYDVQQGEwJDQTESMBAGA1UEChMJRS1DZXJ0aWZ5MRswGQYD VQQLExJFLUNlcnRpZnkgRW1wbG95ZWUxFjAUBgNVBAMTDVZhZGltIEJsYWprdW4xKjAoBgkqhkiG 9w0BCQEWG3ZhZGltLmJsYWprdW5AZS1jZXJ0aWZ5LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEArGtcxje4+iCDNsAv0L2QgCoGvgQ7UxykHJx/iqxd6PGgzoN2329ZVrsUegUPA60uB495 oXb2sfVrzGglImVpNbiMVwrPwffQZbrtA70GHAYfmYWjA+rR610aY76W2fQKDgjAT4VL0aA/2+O5 JQTE1uZpDzaMHARcvmRZYPuoe5kCAwEAAaOBmTCBljAmBgNVHREEHzAdgRt2YWRpbS5ibGFqa3Vu QGUtY2VydGlmeS5jb20wEQYJYIZIAYb4QgEBBAQDAgCAMAkGA1UdEwQCMAAwDAYDVR0PBAUDAwAw ADBABgNVHR8EOTA3MDWgM6Axhi9odHRwOi8vd3d3LmUtY2VydGlmeS5jb20vaWRjZW50ZXIvQ1JM L3JhYWxsLmNybDANBgkqhkiG9w0BAQUFAAOCAQEA0U8HzgVJm2jMS5yhOpfgwriPGJaSW4Ae7Z0M YQjrjVkmdmAFCV+ELv54G6CgIJnfbyJjGYQetdVBtRkC+txCEXoD7DaA5f+u29dUeP8tEBsOQLSH mcBEu+TMtdx4sX/pZMz4wHdeABcvPkKMzGmtudRCUFJsKV6d/9QLeOaAqU1/45MD2LTqbebQu5V8 twi63ptUPX0b9CXeAiNMlACFCKlBxUbCMbceFSWseNP/EPYzp+GRcH6sCC1B+FutfK8mNVffw7yO AQHXCa4xsofLkmxBgqFKMzHqAER3WahzH6sRhuKAMJyv2+6HX3ITydu/lQ/ZRgUvIP9Pi6OWdYa6 MTGCAgswggIHAgEBMFQwTDELMAkGA1UEBhMCY2ExEjAQBgNVBAoTCUUtQ2VydGlmeTESMBAGA1UE CxMJSUQgQ2VudGVyMRUwEwYDVQQDEwxFLUNlcnRpZnkgUkECBAO7jyowCQYFKw4DAhoFAKCCAQ0w GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDEwNjE5MTk1NDI2WjAj BgkqhkiG9w0BCQQxFgQUUMxZZ+QkUzvat+Po6OohcNp6M8IwSQYJKoZIhvcNAQkPMTwwOjAKBggq hkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwBwYFKw4DAhowCgYIKoZIhvcNAgUwYwYJ KwYBBAGCNxAEMVYwVDBMMQswCQYDVQQGEwJjYTESMBAGA1UEChMJRS1DZXJ0aWZ5MRIwEAYDVQQL EwlJRCBDZW50ZXIxFTATBgNVBAMTDEUtQ2VydGlmeSBSQQIEA7uSgTANBgkqhkiG9w0BAQEFAASB gHi76Z8Qr1mNVef9UFOVnrLo+YybuPH3giGopLqJ/h9J3nrxb//4r+8CG6bTFXYAiEDkzzjzF+pl FtDTjSQIREatETpYFtauVpFgwKKJB2AmEpM8KfWBc9AR9ggZmvTvCfhijWH47aW+isz4lPvuKD1u GUleAsPmIZ2yu0uXnPvPAAAAAAAA ------=_NextPart_000_004B_01C0F8D8.1DC55570-- From owner-ietf-smime-examples Tue Jun 19 13:07:54 2001 Received: by above.proper.com (8.11.3/8.11.3) id f5JK7s924976 for ietf-smime-examples-bks; Tue, 19 Jun 2001 13:07:54 -0700 (PDT) Received: from wfhqex05.gfgsi.com (netva01.getronicsgov.com [206.137.100.2]) by above.proper.com (8.11.3/8.11.3) with ESMTP id f5JK7sJ24972 for ; Tue, 19 Jun 2001 13:07:54 -0700 (PDT) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Tue, 19 Jun 2001 16:08:11 -0400 Message-ID: <0B95FB5619B3D411817E006008A59259692D92@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'Vadim Blajkun'" , "'ietf-smime-examples@imc.org'" Subject: RE: Unknown OID Date: Tue, 19 Jun 2001 16:08:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0F8FB.8C17BEA0" Sender: owner-ietf-smime-examples@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_01C0F8FB.8C17BEA0 Content-Type: text/plain; charset="iso-8859-1" Vadim, RFC2633 defines 1.2.840.113549.1.9.16.2.11 to identify the SMIMEEncryptionKeyPreference signed attribute. id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11} =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Vadim Blajkun [mailto:vadim.blajkun@e-certify.com] Sent: Tuesday, June 19, 2001 3:59 PM To: 'ietf-smime-examples@imc.org' Subject: Unknown OID Does anyone know what object is identified by 1.2.840.113549.1.9.16.2.11 ? It is used in some of the examples in "draft-ietf-smime-examples-06.txt" document. Thanks, Vadim Blajkun E-Certify (Canada) 905.615-7187 ------_=_NextPart_001_01C0F8FB.8C17BEA0 Content-Type: text/html; charset="iso-8859-1"

Vadim,

RFC2633 defines 1.2.840.113549.1.9.16.2.11 to identify the SMIMEEncryptionKeyPreference signed attribute.

id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}

===========================================
John Pawling, John.Pawling@GetronicsGov.com
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Vadim Blajkun [mailto:vadim.blajkun@e-certify.com]
Sent: Tuesday, June 19, 2001 3:59 PM
To: 'ietf-smime-examples@imc.org'
Subject: Unknown OID



Does anyone know what object is identified by 1.2.840.113549.1.9.16.2.11 ?
It is used in some of the examples in "draft-ietf-smime-examples-06.txt" document.

Thanks,

Vadim Blajkun
E-Certify (Canada)
905.615-7187

------_=_NextPart_001_01C0F8FB.8C17BEA0-- From owner-ietf-smime-examples Tue Nov 27 23:29:21 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAS7TLO04290 for ietf-smime-examples-bks; Tue, 27 Nov 2001 23:29:21 -0800 (PST) Received: from mx1.fujixerox.co.jp (mx1.fujixerox.co.jp [202.32.191.28]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS7TJ804281 for ; Tue, 27 Nov 2001 23:29:19 -0800 (PST) Received: by mx1.fujixerox.co.jp; id QAA17439; Wed, 28 Nov 2001 16:29:13 +0900 (JST) Received: from unknown(129.249.118.131) by mx1.fujixerox.co.jp via smap (3.2) id xma016158; Wed, 28 Nov 01 16:26:52 +0900 Received: from ns1.fujixerox.co.jp (localhost [127.0.0.1]) by isvw1.fujixerox.co.jp (8.11.1/3.7W) with ESMTP id fAS7RDs11028 for ; Wed, 28 Nov 2001 16:27:13 +0900 (JST) Received: from ms1.prime.fujixerox.co.jp (ms1.k.prime.fujixerox.co.jp [129.249.1.15]) by ns1.fujixerox.co.jp (8.9.3+3.2W/3.7W99122215) with ESMTP id QAA08563 for ; Wed, 28 Nov 2001 16:27:10 +0900 (JST) Received: from fujixerox.co.jp (spider.labo.atsugi.fujixerox.co.jp [129.249.198.172]) by ms1.prime.fujixerox.co.jp (8.9.3/3.7Wpl2-pbo) with ESMTP id QAA07228 for ; Wed, 28 Nov 2001 16:26:57 +0900 (JST) Message-ID: <3C0491B6.73229C71@fujixerox.co.jp> Date: Wed, 28 Nov 2001 16:26:46 +0900 From: "Masui, Takanori" X-Mailer: Mozilla 4.51 [ja] (WinNT; I) X-Accept-Language: ja MIME-Version: 1.0 To: ietf-smime-examples@imc.org Subject: DSA signed message of smime-example-07 document Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have a following question on this document. 5.1(Basic signed content,DSS) and 5.3(Basic signed content,detached content) are signed message which are signed by Alice's DSA private key. 5.1 has internal content included in eConente, which is "This is some sample content." and 5.3 has external content, which is "This is some sample content." So the same content was signed by Alice in 5.1 and 5.2. However,the signature value is different. These example has no signed attribute, then I expect they have same signature. 5.1 signature 881 04 48: OCTET STRING, encapsulates { 883 30 45: SEQUENCE { 885 02 20: INTEGER : 08 D0 45 7D 63 E1 39 EC 62 B0 30 C2 29 AD 42 EA : 96 4F 91 86 907 02 21: INTEGER : 00 A6 86 EE 8A 7A 05 A7 E0 07 E6 F9 88 BF 93 FB : 96 4D 76 D3 92 } } 5.3 signature 849 04 48: OCTET STRING, encapsulates { 851 30 44: SEQUENCE { 853 02 20: INTEGER : 15 D0 DC EE FF D4 36 5B 93 0D CF 69 3D 37 45 A0 : 34 9A 63 35 875 02 20: INTEGER : 49 75 76 4C 33 00 0A AB 90 FD EF 9C 47 80 21 F1 : 49 EA 02 15 } } I wonder if I am misunderstanding. Signature calculating process which I'm understading is following "This is some sample content." ->digest(SHA1)->406a ec08 5279 ba6e 1602 2d9e 0629 c022 9687 dd48 ->DSASign(AlicePrivKey) Please clarify my understading. Thank you in advance, //Takanori Masui From owner-ietf-smime-examples Wed Nov 28 01:10:11 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAS9ABD18055 for ietf-smime-examples-bks; Wed, 28 Nov 2001 01:10:11 -0800 (PST) Received: from femail42.sdc1.sfba.home.com (femail42.sdc1.sfba.home.com [24.254.60.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAS9AA818051 for ; Wed, 28 Nov 2001 01:10:10 -0800 (PST) Received: from revelation ([65.4.166.11]) by femail42.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011128091010.ZDL28301.femail42.sdc1.sfba.home.com@revelation>; Wed, 28 Nov 2001 01:10:10 -0800 Reply-To: From: "Jim Schaad" To: "'Masui, Takanori'" , Subject: RE: DSA signed message of smime-example-07 document Date: Wed, 28 Nov 2001 01:11:33 -0800 Message-ID: <000001c177ec$acfc07f0$0c00a8c0@soaringhawk.net> 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 In-Reply-To: <3C0491B6.73229C71@fujixerox.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: These are going to be different values for DSA. If you look at the specifications of DSA you will notice that there is a random value (k) which is used in the computation. jim > -----Original Message----- > From: owner-ietf-smime-examples@mail.imc.org > [mailto:owner-ietf-smime-examples@mail.imc.org] On Behalf Of > Masui, Takanori > Sent: Tuesday, November 27, 2001 11:27 PM > To: ietf-smime-examples@imc.org > Subject: DSA signed message of smime-example-07 document > > > > > I have a following question on this document. > > > 5.1(Basic signed content,DSS) and 5.3(Basic signed content,detached > content) > are signed message which are signed by Alice's DSA private key. > > 5.1 has internal content included in eConente, > which is "This is some sample content." > > and > > 5.3 has external content, > which is "This is some sample content." > > So the same content was signed by Alice in 5.1 and 5.2. > > However,the signature value is different. > These example has no signed attribute, > then I expect they have same signature. > > 5.1 signature > > 881 04 48: OCTET STRING, encapsulates { > 883 30 45: SEQUENCE { > 885 02 20: INTEGER > : 08 D0 45 7D 63 E1 39 EC 62 > B0 30 C2 29 > AD 42 EA > : 96 4F 91 86 > 907 02 21: INTEGER > : 00 A6 86 EE 8A 7A 05 A7 E0 > 07 E6 F9 88 > BF 93 FB > : 96 4D 76 D3 92 > } > } > 5.3 signature > > 849 04 48: OCTET STRING, encapsulates { > 851 30 44: SEQUENCE { > 853 02 20: INTEGER > : 15 D0 DC EE FF D4 36 5B 93 > 0D CF 69 3D > 37 45 A0 > : 34 9A 63 35 > 875 02 20: INTEGER > : 49 75 76 4C 33 00 0A AB 90 > FD EF 9C 47 > 80 21 F1 > : 49 EA 02 15 > } > } > > I wonder if I am misunderstanding. > > Signature calculating process which I'm understading is following > > "This is some sample content." ->digest(SHA1)->406a ec08 5279 > ba6e 1602 > 2d9e 0629 c022 9687 dd48 > ->DSASign(AlicePrivKey) > > Please clarify my understading. > > Thank you in advance, > > //Takanori Masui > From owner-ietf-smime-examples Thu Nov 29 22:55:38 2001 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAU6tc007953 for ietf-smime-examples-bks; Thu, 29 Nov 2001 22:55:38 -0800 (PST) Received: from femail35.sdc1.sfba.home.com (femail35.sdc1.sfba.home.com [24.254.60.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAU6tb807948 for ; Thu, 29 Nov 2001 22:55:37 -0800 (PST) Received: from revelation ([65.4.166.11]) by femail35.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20011130065541.DUNO15766.femail35.sdc1.sfba.home.com@revelation>; Thu, 29 Nov 2001 22:55:41 -0800 Reply-To: From: "Jim Schaad" To: Cc: "Russ Housley" , Subject: SignedData Example Date: Thu, 29 Nov 2001 22:56:59 -0800 Message-ID: <000001c1796c$3585e200$0d00a8c0@soaringhawk.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_01C17929.276428A0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C17929.276428A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I have a new SignedData example that I would like to get some opinions of. I have tried it againist the Microsoft CAPI 2.0 system and it failed to verify, but I know how that code is implemented and it would fail this case. I encoded the sequence of authenticated attributes using the DER rules and hashed it. Then I encoded the entire message, including the autenticated attributes, using BER encoding rules - that is the SET OF is not sorted. I believe that this constitutes a legal SignedData message but would like some verification. Jim ------=_NextPart_000_0001_01C17929.276428A0 Content-Type: application/octet-stream; name="s1.bin" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="s1.bin" MIIBXQYJKoZIhvcNAQcCoIIBTjCCAUoCAQExCTAHBgUrDgMCGjAPBgkqhkiG9w0BBwGgAgQAMYIB JzCCASMCAQEwJjASMRAwDgYDVQQDEwdDYXJsUlNBAhBGNGvHgABWvBHTbi7EELOwMAcGBSsOAwIa oF0wHAYJKoZIhvcNAQkFMQ8XDTAxMTEzMDA2NTMwNVowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAjBgkqhkiG9w0BCQQxFgQU2jmj7l5rSw0yVb/vlWAYkK/YBwkwCwYJKoZIhvcNAQEBBIGAoCN+ 9nLwUfXsv+zCfyNFgBQsSC5fhtBbSe7RazOkTocs0qqJrawVqHRsGVtaFASYyeJid/Vrv6djODog YPmjuVMiuEQQphR6INI4ue4qrjTQGkvb8zK+NLHOwAOBxqGs6X6dfg8MLOu//+YSoN2sovC558rI 4A8+jUtZyxhTC84= ------=_NextPart_000_0001_01C17929.276428A0-- From owner-ietf-smime-examples Fri Nov 30 08:19:17 2001 Received: by above.proper.com (8.11.6/8.11.3) id fAUGJHW06973 for ietf-smime-examples-bks; Fri, 30 Nov 2001 08:19:17 -0800 (PST) Received: from wfhqex05.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUGJG806967 for ; Fri, 30 Nov 2001 08:19:17 -0800 (PST) Received: by wfhqex05.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 11:20:05 -0500 Message-ID: <0B95FB5619B3D411817E006008A59259B52073@wfhqex06.gfgsi.com> From: "Pawling, John" To: "'jimsch@exmsft.com'" , ietf-smime-examples@imc.org Cc: Russ Housley , trevorf@windows.microsoft.com Subject: RE: SignedData Example Date: Fri, 30 Nov 2001 11:20:33 -0500 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-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jim, Your SignedData sample message does not include the signer's cert. It is possible to obtain the signer's cert by other means, but it would simplify the testing if you could re-generate the sample to include the signer's cert. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== -----Original Message----- From: Jim Schaad [mailto:jimsch@nwlink.com] Sent: Friday, November 30, 2001 1:57 AM To: ietf-smime-examples@imc.org Cc: Russ Housley; trevorf@windows.microsoft.com Subject: SignedData Example I have a new SignedData example that I would like to get some opinions of. I have tried it againist the Microsoft CAPI 2.0 system and it failed to verify, but I know how that code is implemented and it would fail this case. I encoded the sequence of authenticated attributes using the DER rules and hashed it. Then I encoded the entire message, including the autenticated attributes, using BER encoding rules - that is the SET OF is not sorted. I believe that this constitutes a legal SignedData message but would like some verification. Jim From owner-ietf-smime-examples Fri Dec 28 19:00:33 2001 Received: by above.proper.com (8.11.6/8.11.3) id fBT30XX22061 for ietf-smime-examples-bks; Fri, 28 Dec 2001 19:00:33 -0800 (PST) Received: from example.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 fBT30W222057 for ; Fri, 28 Dec 2001 19:00:32 -0800 (PST) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Fri, 28 Dec 2001 19:06:16 -0800 Message-ID: <00f601c19014$ce315610$0600a8c0@brutesquadlabs.com> From: "Blake Ramsdell" To: "IETF-SMIME-Examples" Subject: Extracting examples Date: Fri, 28 Dec 2001 18:59:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I ran into one problem extracting examples -- the following section seems to give the extraction code some indigestion: |* Example from section 11.4 |* Creator: [JP] |>11.4.bin |* Creator: [JP] |>11.4.bin |MIIFPAYJKoZIhvcNAQcCoIIFLTCCBSkCAQExCTAHBgUrDgMCGjArBgkqhkiG9w0BBwGgHg The doubling of >11.4.bin seems to be the culprit, and when it is removed, it works fine, and all examples extract using the provided code under Cygwin. Blake -- Blake Ramsdell Brute Squad Labs From owner-ietf-smime-examples Mon Dec 31 21:01:46 2001 Received: by above.proper.com (8.11.6/8.11.3) id g0151k513935 for ietf-smime-examples-bks; Mon, 31 Dec 2001 21:01:46 -0800 (PST) Received: from example.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 g0151d313931 for ; Mon, 31 Dec 2001 21:01:43 -0800 (PST) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Mon, 31 Dec 2001 21:07:32 -0800 Message-ID: <012701c19281$ee452570$0600a8c0@brutesquadlabs.com> From: "Blake Ramsdell" To: "IETF-SMIME-Examples" Subject: More draft comments -- primarily section 5 Date: Mon, 31 Dec 2001 21:05:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Some more comments about the current draft, focusing on section 5. Most (all?) references to "DH-DSS" should be "DSS". This may have been brought up before. When referring to certificates and CRLs, we should use consistent terminology (the exact name used for the files, minus the file extensions), as opposed to narrative. I think that in general, we should adopt a convention for describing what's to be expected in the examples. For instance, for section 5, document the exact order of the certificates and CRLs. Section 5.2 Alice's certificate from the message does not match AliceRSASignByCarl.cer Section 5.4 Certificates contain AliceRSASignByCarl, CarlDSSSelf and AliceDSSSignByCarlNoInherit (doesn't match narrative or the dump). SigningTime attribute is incorrectly encoded with GeneralizedTime instead of UTCTime. Section 5.5 Alice's certificate from the message does not match any certificate (including AliceRSASignByCarl). Section 5.6 "Two SignedDatas" should be "Two SignerInfos" Section 5.7 the printed form of the dump shows AliceRSASignByCarl is included, but 5.7.bin only has AliceDSSSignByCarlNoInherit included. Section 5.8 the file 5.8.eml appears to only use CR for the EOL character. This should probably be CRLF. The text in the draft does not match the contents of the message. The .eml file does not appear to have a MIME-Version header. Section 5.9 same comments for 5.8. Additionally, the content is not legal S/MIME -- it needs a leading CRLF in order to satisfy the requirements of having a MIME entity (the CRLF will make the content implicit text/plain). Section 5.11 is not specific about which certificates are found in the message. I think to be consistent, it should document which certificates are contained (Alice and Carl's) CarlDSSCRLEmpty.crl gives the Java 2 SDK fits when parsing. This could very well be a Java 2 issue, and I'll investigate further. Blake -- Blake Ramsdell Brute Squad Labs From owner-ietf-smime-examples Sun Jan 6 04:51:43 2002 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g06Cphr25667 for ietf-smime-examples-bks; Sun, 6 Jan 2002 04:51:43 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g06Cpg325663 for ; Sun, 6 Jan 2002 04:51:42 -0800 (PST) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Sun, 6 Jan 2002 04:57:37 -0800 Message-ID: <01fe01c196b0$c212ff80$0600a8c0@brutesquadlabs.com> From: "Blake Ramsdell" To: "IETF-SMIME-Examples" Subject: Some more comments -- sections 6 and 7 Date: Sun, 6 Jan 2002 04:50:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: BobPrivRSAEncrypt.pri and CarlPrivRSASign.pri appear to be the same RSA private keys. I presume that they are both CarlPrivRSASign.pri, since BobPrivRSAEncrypt.pri does not successfully unwrap the key provided in the RecipientInfo in example 6.2. I have not done any testing with the Diffie-Hellman examples. The content included in encapContentInfo.eContent is not ExContent.bin. Further, it appears that the included digest is the digest of the correct ExContent.bin, so it does not match. The content found in the message is included below: 0000 54 68 69 73 20 73 6F 6D 65 20 73 61 6D 70 65 20 This some sampe 0010 63 6F 6E 74 65 6E 74 2E content. I believe that the content should be "This is some sample content." (ExContent.bin). Blake -- Blake Ramsdell Brute Squad Labs From owner-ietf-smime-examples Sun Jan 6 14:11:20 2002 Received: by above.proper.com (8.11.6/8.11.3) id g06MBKJ03886 for ietf-smime-examples-bks; Sun, 6 Jan 2002 14:11:20 -0800 (PST) Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g06MBH303879 for ; Sun, 6 Jan 2002 14:11:17 -0800 (PST) Received: from DEXTER ([192.168.0.6]) by brutesquadlabs.com with SMTP ; Sun, 6 Jan 2002 14:17:14 -0800 Message-ID: <021a01c196fe$face05b0$0600a8c0@brutesquadlabs.com> From: "Blake Ramsdell" To: "IETF-SMIME-Examples" References: <01fe01c196b0$c212ff80$0600a8c0@brutesquadlabs.com> Subject: Re: Some more comments -- sections 6 and 7 Date: Sun, 6 Jan 2002 14:10:41 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-smime-examples@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: ----- Original Message ----- From: "Blake Ramsdell" To: "IETF-SMIME-Examples" Sent: Sunday, January 06, 2002 4:50 AM Subject: Some more comments -- sections 6 and 7 > The content included in encapContentInfo.eContent is not ExContent.bin. > Further, it appears that the included digest is the digest of the correct > ExContent.bin, so it does not match. The con