From owner-ietf-smime@mail.imc.org Mon Nov 3 22:33:51 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12058 for ; Mon, 3 Nov 2003 22:33:51 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433jkT063143 for ; Mon, 3 Nov 2003 19:03:45 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA433jJb063142 for ietf-smime-bks; Mon, 3 Nov 2003 19:03:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433ikT063135 for ; Mon, 3 Nov 2003 19:03:44 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 3 Nov 2003 19:03:41 -0800 From: "Blake Ramsdell" To: , Cc: "'Sean P. Turner'" , "'Russ Housley'" Subject: S/MIME Working Group Agenda for the 58th IETF Date: Mon, 3 Nov 2003 19:03:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here is the agenda for the S/MIME working group meeting at IETF 58. Introductions (Blake Ramsdell) Working group status (Blake Ramsdell) CMS and ESS examples update (Paul Hoffman) MSGbis and CERTbis update (Blake Ramsdell) KEM status (Blake Ramsdell) GOST status (Blake Ramsdell) SEED overview (Jongwook Park) Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com From owner-ietf-smime@mail.imc.org Tue Nov 4 00:13:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15224 for ; Tue, 4 Nov 2003 00:13:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qmkT067053 for ; Mon, 3 Nov 2003 20:52:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA44qmdF067052 for ietf-smime-bks; Mon, 3 Nov 2003 20:52:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qlkT067044 for ; Mon, 3 Nov 2003 20:52:47 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id D62886DD55; Mon, 3 Nov 2003 20:52:41 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 Date: Mon, 3 Nov 2003 20:55:14 -0800 Message-ID: <00db01c3a28f$d5f5baa0$737eadcf@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Blake, I have now finished (almost) this year's work in the winery. Items of agreement are gone. jim > > > > Comments are on the -05 version of the document. > > > > > 11. Section 2.5.2 - where do we document SMimeCapabilities > for RC2? > > Should be a 40-bit vs 128-bit difference between these > which needs an > > ASN.1 structure and encoding. Based on reading of this document I > > could not correctly encode these values. > > I believe that this definition should be in the CMSALG > document (but it's not). Should we bite the bullet and just > stick it in this one? I agree that it needs to be specified > somewhere, but I feel a bit icky about sticking it in here. [JLS] - I agree that the best place is to put it into the CMSALG draft. This falls into the - Yes, but we can't do it. Since SMimeCapabilities is not defined in the CMS document, CMSALG can't reference it. CMSALG must not reference the S/MIME documents. Unless you want Russ to add SMIMECapabilities to CMS and this to CMSALG then it must go into this document however icky. > > > 15. Section 2.7.1.3: Need to be updated to comment on AES. > > I see your point. The intent is to fall back to something > useful for any version of S/MIME, and the older evil US-only > RC2/40 clients. It's not clear what discussion you'd have > about AES here. > > It may be the case that this rule should be removed > completely. Comments? > > Not changed, but needs discussion. [JLS] I think the best thing to do with be an information reference to "For what we use to do look at .... We no longer provide guidence on this because things have changed so much. > > > 20. Section 3.2.2: I would like to get some rewrites on > this section > > as to the purpose of S/MIME type. I think it is JUST to provide > > information about the information (misspelt in the > document) about the > > contained content. It just happens that for display via UAs, the > > distinction between signed and enveloped was consisted to be an > > important part of the content. Additionally, I think this is the > > correct direction for us to tell people about how to define new > > smime-types in the future. > > > > The next question is weither a compressed only message would > > show up in > > my mailbox. I think that the correct smime-type for a > compressed and > > signed message is actually signed-data not compressed data. > > So I think your position is that the smime-type should have > the "most relevant interpretation of the protected data", > instead of the "actual type that is being protected". I > think the best example is an IMAP client getting the headers > and changing the icon next to the message to indicate what > kind of message you've got. > > We can ask the audience, but I think that the conventional > wisdom is that the smime-type represents the type of the > outermost layer, and that's it -- just a further > clarification of the overloaded application/pkcs7-mime. > > Fixed speling of information, but I want to hear more about > how else we should change this to clarify the semantic (and > what the semantic is). [JLS] I have definitely moved to the position that this information is to tell what is inside the message rather than what security has been added to the message.. This is also the position that is held in several different documents (include ESS with receipts). > > > 23. Section 3.4.3.3: Just for giggles, I think that > adding a section > > with the hex encoding of the acutal bytes hashed for this > sample would > > be a good idea. This is one of the things people always > have problems > > with when doing multipart signed data. Also it might be > interesting > > to make the body a multipart/alternative. On the other hand this > > would probably be better in an appendix. > > I think that getting too far with the examples should be left > to the Examples draft and any successors. I do agree that > adding the hex dump would be a good idea. > > My attempt at the hex dump is this, but I need at least one > other person to double check it. > > Updated: > > The content that is digested (the first part of the > multipart/signed) are the bytes: > > 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 > 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c > 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a > [JLS] I will look at doing this before next week. > > 26. Appendix B: Refernces need to be divided. > > I'm not sure what you mean by "divided"... Normative vs Informational as you have noted elsewhere. > > Blake > From owner-ietf-smime@mail.imc.org Tue Nov 4 05:36:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07763 for ; Tue, 4 Nov 2003 05:36:02 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8KkT045901 for ; Tue, 4 Nov 2003 02:08:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4A8KKx045900 for ietf-smime-bks; Tue, 4 Nov 2003 02:08:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8GkT045889; Tue, 4 Nov 2003 02:08:17 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA4A8Go9028250; Tue, 4 Nov 2003 23:08:16 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA4ABfi05617; Tue, 4 Nov 2003 23:11:41 +1300 Date: Tue, 4 Nov 2003 23:11:41 +1300 Message-Id: <200311041011.hA4ABfi05617@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >Mozilla (and no doubt some others that didn't get any publicity) did the same >thing, and I'm sure they didn't get asked to do that by customers. Actually that's not right, I thought Mozilla (or at least some apps that used the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror was vulnerable, but it turns out that this was Konqueror with khtml rather than with kmozilla, with OpenSSL supplying the crypto. Apologies for the mixup. Before this gets read as "OpenSSL is vulnerable", that isn't the case either. OpenSSL provides application-defined callbacks that can be used to override some checks (used to handle, as one source aptly described it, "the mass of broken certs out there"). Some apps provide callbacks that ignore all errors, which apparently is what happened here. Standard OpenSSL doesn't have this problem. Peter. From rqsvccwbta@msn.com Mon Nov 10 16:21:59 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14173 for ; Mon, 10 Nov 2003 16:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJJUA-0004uA-00 for smime-archive@ietf.org; Mon, 10 Nov 2003 16:22:10 -0500 Received: from dsl-200-95-112-232.prodigy.net.mx ([200.95.112.232]) by ietf-mx with smtp (Exim 4.12) id 1AJJU7-0004u7-00 for smime-archive@ietf.org; Mon, 10 Nov 2003 16:22:08 -0500 Message-ID: From: "German Brewster" Reply-To: "German Brewster" To: smime-archive@ietf.org Subject: Re:Forever Young is Really Possible Date: Tue, 11 Nov 2003 14:11:42 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="BC04_AA2D3EE_BE3C" --BC04_AA2D3EE_BE3C Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Untitled Document

Want to look younger, have m= ore energy + lose weight in three weeks?

This proven discovery has be= en reported on by the New England Journal of Medicine. Forget aging and dietin= g forever. And it's Guaranteed.
WOULD YOU LIKE TO LOSE WEIGHT WHILE YOU SLE= EP?
No dieting.
No hunger pains.
No Cravings.
No strenuous exercise.
Change your life forever.

Go Here to Receive a Full Month's Supply Absolutely F@REE<= /b>

 
You are receiving this message as a member of the Opt-In
America List. To be taken out of the data base please
go here. We honor all remove requests. eierqwriqkhcw sxntxy tsi --BC04_AA2D3EE_BE3C-- From owner-ietf-smime@mail.imc.org Mon Nov 10 23:13:59 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04307 for ; Mon, 10 Nov 2003 23:13:58 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gKkT009163 for ; Mon, 10 Nov 2003 19:42:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB3gKnC009162 for ietf-smime-bks; Mon, 10 Nov 2003 19:42:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gIkT009150; Mon, 10 Nov 2003 19:42:19 -0800 (PST) (envelope-from pmhesse@geminisecurity.com) Received: from WJJCUSCLANGSTO1 ([68.101.35.22]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031111034205.OWO2297.lakemtao02.cox.net@WJJCUSCLANGSTO1>; Mon, 10 Nov 2003 22:42:05 -0500 Message-ID: <001101c3a805$c5b5ba70$4d2412ac@jjcus.na.jnj.com> From: "Peter Hesse" To: , Subject: request for change in son-of-rfc2633 Date: Mon, 10 Nov 2003 22:41:52 -0500 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C3A7DB.D5E6B950" 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@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C3A7DB.D5E6B950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I have recently run into a problem with signed emails not being able to be verified, because of the presence of the word "From" in the first columns of a line of the email message. This email will serve as an example of this potential problem. If your email client sees this message as signed but the signature is invalid, the next paragraph should start with the word "From"--see if it has been modified. From appearing as the first characters after a blank line will result in some email delivery agents (such as sendmail or exim) escaping the word--"From" is replaced with ">From". The reason for this behavior has to do with the UNIX mbox mail storage file format. The mbox format stores multiple messages in one file, and the messages are separated by the word "From" as the first characters following a blank line. Some mail delivery agents do not have this problem (i.e. Exchange), because they do not store messages in the mbox format. Many do, however, resulting in a modification of the message and the signature being invalidated. I would like to request that this issue be more directly dealt with in son-of-RFC2633. (Currently, it is mentioned in the example MIME-encoded message, but nowhere in the text.) One recommendation might be to borrow from RFC2015 (MIME Security with PGP), which states: Though not required, it is generally a good idea to use Quoted- Printable encoding in the first step (writing out the data to be signed in MIME canonical format) if any of the lines in the data begin with "From ", and encode the "F". This will avoid an MTA inserting a ">" in front of the line, thus invalidating the signature! Perhaps this might even be a SHOULD, although I will ask the group to weigh in on that. Thanks, --Peter ------=_NextPart_000_000D_01C3A7DB.D5E6B950 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr 3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2 Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP 8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1 cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX 5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs j1OYuQnyz6cxggHDMIIBvwIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 AgELMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMxMTExMDM0MTUyWjAjBgkqhkiG9w0BCQQxFgQUiwZyw+XEkLYZTGXX7PJ5QjnYr/0wWwYJ KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAEgYCfsEWDj+Vi HEn1kAAVx6yfGTkolRIR7uuC0KS1d4zrT1omaUnVTTKET9QBY7QUqdfb2gcvw9pZuRb4bBtYir0W Rfnmfuob1NwKXaPPSv6inoySZ2/j/LR3nHsMd2GWYQFI5Q9LGyhqahQcyEWV/vSe9YSd0yUl9hSS cL3sbEfE6AAAAAAAAA== ------=_NextPart_000_000D_01C3A7DB.D5E6B950-- From owner-ietf-smime@mail.imc.org Wed Nov 12 12:02:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27445 for ; Wed, 12 Nov 2003 12:02:39 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTpkT032479 for ; Wed, 12 Nov 2003 08:29:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACGTpOW032478 for ietf-smime-bks; Wed, 12 Nov 2003 08:29:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTlkT032454; Wed, 12 Nov 2003 08:29:48 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp1.pacifier.net (Postfix) with ESMTP id 339B570049; Wed, 12 Nov 2003 08:29:47 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt Date: Wed, 12 Nov 2003 10:32:18 -0600 Message-ID: <004a01c3a93a$8ad46b00$fd468182@augustcellars.local> 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: <200310201946.PAA22554@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul, There are three problems I have encountered during extracting the document. 1. Example 3.1.bin has a name mismatch 2. Example 3.2.bin has a name mismatch 3. Example 4.5.bin appears to be missing Jim From owner-ietf-smime@mail.imc.org Wed Nov 12 15:52:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08913 for ; Wed, 12 Nov 2003 15:52:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGDkT041134 for ; Wed, 12 Nov 2003 12:16:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACKGDL5041133 for ietf-smime-bks; Wed, 12 Nov 2003 12:16:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGBkT041126; Wed, 12 Nov 2003 12:16:12 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp2.pacifier.net (Postfix) with ESMTP id 354796ADC1; Wed, 12 Nov 2003 12:16:11 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt Date: Wed, 12 Nov 2003 14:18:41 -0600 Message-ID: <004b01c3a95a$2c52f1d0$fd468182@augustcellars.local> 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: <200310201946.PAA22554@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul, I have the following comments on the draft: 1. Section 3 examples passed. 2. Section 4 - Passing - 4.1, 4.2, 4.5, 4.7, 4.11 Untested - 4.3, 4.6, 4.8 Comments - 4.4 - Passes but also includes Alice RSA certificate. 4.9 - Body is not from 4.1, body is modified MIME body 4.10 - Actual list is [unknown OID, contentHints, smimeCapablilties, securityLabel, ContentReference, smimeEncryptKeyPreference, mlExpansionHistory, EquivalentLabel] 3. Section 5 - Passing - 5.1, Untested - 5.3, Comments - 5.2 the encoded and decode examples are not the same item 4. 6.0, 7.1, 7.2 passed 5. I would like to keep section 10 from the old document. I found that there were two example 4.4 in the old message thus the difference between my last message where I said that 4.5 did not exist in the binaries and the fact that I tested it in this message. I will get to the rest of the testing later this week. Jim From owner-ietf-smime@mail.imc.org Thu Nov 13 07:51:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22630 for ; Thu, 13 Nov 2003 07:51:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLTkT053489 for ; Thu, 13 Nov 2003 04:21:29 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADCLTej053488 for ietf-smime-bks; Thu, 13 Nov 2003 04:21:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLSkT053483 for ; Thu, 13 Nov 2003 04:21:28 -0800 (PST) (envelope-from lloyd@randombit.net) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id A8A563EB45; Thu, 13 Nov 2003 07:21:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id A78A346842 for ; Thu, 13 Nov 2003 07:21:27 -0500 (EST) Date: Thu, 13 Nov 2003 07:21:27 -0500 (EST) From: Jack Lloyd X-X-Sender: lloyd@centaur.acm.jhu.edu To: ietf-smime@imc.org Subject: CMS Implementation Questions Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been looking over the various CMS RFCs, and have a few questions, most of which probably have obvious and simple answers, but I could use some help. 1) I'm pretty sure I understand how to nest CMS structures correctly, but the existing S/MIME examples draft doesn't have any examples of, say, compress then encrypt then sign. Are there any examples floating around, or, are there any free implementations of CMS that do this, which I could use to generate a few tests? (Preferably PEM or raw binary, rather than MIME, but I'll take what I can get). 2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption key that was previously distributed to the sender and one or more recipients." Is there some typical mechanism for choosing this value? Obviously, as far as the RFC is concerned, one can do pretty much anything they please, but if there is a simple and commonly used method, I figure I might as well go with the crowd. 3) It is legal to include SignedAttributes and sign everything that way even when signing plain data content, correct? 4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? This is not particularly clear to me from the texts of RFCs 2630 and 3369. 5) Is the RC2 key wrap example in RFC 3217 right? For the KEK/IV/LCEKPADICV given there, I get: 03 5E 97 2A B1 5C C4 C9 C4 A0 3D BA A3 5A 21 66 67 E4 3E BC A2 67 46 AE 86 08 DB C8 9E 64 CA 29 for TEMP1. I found a mention of at least one other person who had the same problem, and am wondering if the RFC is incorrect, or if my RC2 code manages to pass ~30 test vectors while still being wrong. Either way, something needs fixing. Any help would be much appreciated. Jack From owner-ietf-smime@mail.imc.org Thu Nov 13 08:34:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25521 for ; Thu, 13 Nov 2003 08:34:21 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDEWkT055748 for ; Thu, 13 Nov 2003 05:14:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADDEWXH055747 for ietf-smime-bks; Thu, 13 Nov 2003 05:14:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDETkT055738 for ; Thu, 13 Nov 2003 05:14:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id D7EB163C15; Fri, 14 Nov 2003 02:14:27 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hADDEVT10649; Fri, 14 Nov 2003 02:14:31 +1300 Date: Fri, 14 Nov 2003 02:14:31 +1300 Message-Id: <200311131314.hADDEVT10649@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, lloyd@randombit.net Subject: Re: CMS Implementation Questions Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jack Lloyd writes: >1) I'm pretty sure I understand how to nest CMS structures correctly, but the > existing S/MIME examples draft doesn't have any examples of, say, compress > then encrypt then sign. Are there any examples floating around, or, are > there any free implementations of CMS that do this, which I could use to > generate a few tests? (Preferably PEM or raw binary, rather than MIME, but > I'll take what I can get). You can do it with cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, just run the self-tests and it'll dump one of every kind of CMS message you can think of into /tmp (you need to create this directory first if you're running under Windows). If I hadn't deleted them all in a cleanup about 15 minutes ago I'd send you pre-built examples. >2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption > key that was previously distributed to the sender and one or more > recipients." Is there some typical mechanism for choosing this value? > Obviously, as far as the RFC is concerned, one can do pretty much anything > they please, but if there is a simple and commonly used method, I figure I > might as well go with the crowd. Uhh, go to the PKIX archives and read the recent thread. Basically, this doesn't work properly if used with certain PKIX interpretations of keyIdentifiers. Peter. From owner-ietf-smime@mail.imc.org Fri Nov 14 14:39:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25827 for ; Fri, 14 Nov 2003 14:39:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAjkT028396 for ; Fri, 14 Nov 2003 11:10:45 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEJAig7028395 for ietf-smime-bks; Fri, 14 Nov 2003 11:10:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from vahqex2.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAdkT028369; Fri, 14 Nov 2003 11:10:39 -0800 (PST) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from digitalnet.com ([158.189.2.70]) by vahqex2.gfgsi.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 14:10:40 -0500 Message-ID: <3FB528AF.2020206@digitalnet.com> Date: Fri, 14 Nov 2003 14:10:39 -0500 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-sfl , ietf-smime@imc.org Subject: v2.3 S/MIME Freeware Library (SFL) Now Available Content-Type: multipart/alternative; boundary="------------040801000409060109070908" X-OriginalArrivalTime: 14 Nov 2003 19:10:40.0860 (UTC) FILETIME=[FEAD31C0:01C3AAE2] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------040801000409060109070908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at . The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.3 SFL uses the v2.3 Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.3 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.3 SFL is described in the v2.3 SFL Application Programming Interface (API) and v2.3 SFL Software Design Description documents. The use of the v2.3 CTIL API is described in the v2.3 CTIL API document. v2.3 SFL includes the following enhancements (compared to v2.2 SFL and CTIL releases): 1) The SFL library now provides Compressed Data Content Type for CMS. This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS. Compressed data can be performed on the SignedData and EnvelopedData items without application interaction, by providing the appropriate compressDataFlag flag during the session. 2) There is a major change in how the content is stored in the CSM_CommonData object. With the addition of Compressed Data Content Type for CMS, it was necessary to distinguish between clear content and unclear content. CSM_CommonData now stores both clear and unclear content making the application determine which content to use according to desired processing. See the CSM_CommonData section for the changes. 3) The SFL library now provides Password-Based Encryption for CMS. This provides a method of encrypting data using user-supplied passwords. It is implemented as a RecipientInfo type and is an extension to the RecipientInfo Types currently defined in CMS. 4) The thread support logic was updated in the SFL and libCtilMgr. Specifically, the CSM_CSInst::AccessCertificates() method has been removed to eliminate thread access problems. This does not affect the CSM_CtilInst class, used by the CML. The "AccessCertificcates()" and "AccessCRLs()" methods have been removed due to thread issues. They are described more fully in the CSM_CSInst class description. v2.3 CTILs include the following enhancements (compared to v2.2 release): 1) Elliptic Curve functionality has been added to the sm_free3 CTIL crypto library. This includes ECDSA and ECDH processing. v2.3 Certificate Builder include the following enhancements since v2.2: 1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation. 2) Certificate Builder has been enhanced with PKCS#12 generation logic. 3) Certificate Builder has been enhanced to generate UTF-8 strings. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: . The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at . DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see ). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. -- Matthew J. Bertapelle DigitalNet Government Solution, LLC www.DigitalNet.com --------------040801000409060109070908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code.  The SFL source code files and documents are freely available at 
<http://www.digitalnet.com/knowledge/sfl_home.htm>.  

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.  It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications.  When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method 
specification.  It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems.  Further enhancements, ports and testing of the SFL are still in process.  Further releases of the SFL will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.3 SFL uses the v2.3 
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.3 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; 
PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers;
and test data.  All CTILs were tested as Dynamically Linked Libraries
(DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were tested with the respective security libraries as shared objects
using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
products.  Signed messages have been exchanged with the RSA S/MAIL and 
WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability 
testing with Microsoft that exercised the majority of the features 
specified by RFCs 3369, 3370, 2631 and 2634.  This testing included the
RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL 
to successfully process the SFL-supported sample data included in the
S/MIME WG "Examples of S/MIME Messages" document.  We also used the
SFL to generate S/MIME v3 sample messages that were included in the 
"Examples" document.

The use of the v2.3 SFL is described in the v2.3 SFL Application 
Programming Interface (API) and v2.3 SFL Software Design Description
documents.  The use of the v2.3 CTIL API is described in the v2.3
CTIL API document. 


v2.3 SFL includes the following enhancements (compared to v2.2
SFL and CTIL releases):

1) The SFL library now provides Compressed Data Content Type for CMS.  This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS.  Compressed data can be performed on the SignedData and EnvelopedData items without application interaction, by providing the appropriate compressDataFlag flag during the session.

2) There is a major change in how the content is stored in the CSM_CommonData object.   With the addition of Compressed Data Content Type for CMS, it was necessary to distinguish between clear content and unclear content.  CSM_CommonData now stores both clear and unclear content making the application determine which content to use according to desired processing.  See the CSM_CommonData section for the changes.
 
3) The SFL library now provides Password-Based Encryption for CMS.  This provides a method of encrypting data using user-supplied passwords. It is implemented as a RecipientInfo type and is an extension to the RecipientInfo Types currently defined in CMS.

4) The thread support logic was updated in the SFL and libCtilMgr.  Specifically, the CSM_CSInst::AccessCertificates() method has been removed to eliminate thread access problems. This does not affect the CSM_CtilInst class, used by the CML.  The "AccessCertificcates()" and "AccessCRLs()" methods have been removed due to thread issues.  They are described more fully in the CSM_CSInst class description. 

v2.3 CTILs include the following enhancements (compared to
v2.2 release):

1) Elliptic Curve functionality has been added to the
sm_free3 CTIL crypto library.  This includes ECDSA and ECDH processing.
v2.3 Certificate Builder include the following enhancements since v2.2:

1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation.

2) Certificate Builder has been enhanced with PKCS#12 generation logic.

3) Certificate Builder has been enhanced to generate UTF-8 strings.


The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  DigitalNet is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL source code. 
The application developer must independently obtain these libraries and
then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.DigitalNet.com/knowledge/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by DigitalNet) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
DigitalNet used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.
-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com
--------------040801000409060109070908-- From owner-ietf-smime@mail.imc.org Mon Nov 17 10:54:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16959 for ; Mon, 17 Nov 2003 10:54:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHFLHkT032672 for ; Mon, 17 Nov 2003 07:21:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHFLHYE032671 for ietf-smime-bks; Mon, 17 Nov 2003 07:21:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHFLGkT032665 for ; Mon, 17 Nov 2003 07:21:16 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 15:21:17 -0000 From: "Bonatti, Chris" To: Subject: Draft S/MIME WG Notes Date: Mon, 17 Nov 2003 10:21:10 -0500 Organization: IECA, Inc. Message-ID: <003601c3ad1e$723cd7c0$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01C3ACF4.8966CFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C3ACF4.8966CFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Draft notes from last week's WG meeting are attached. Comments or corrections are welcome, of course. Regards, Chris ------=_NextPart_000_0037_01C3ACF4.8966CFC0 Content-Type: text/plain; name="IETF#58-SMIME-Notes.txt" Content-Disposition: attachment; filename="IETF#58-SMIME-Notes.txt" Content-Transfer-Encoding: quoted-printable IETF 58th Meeting Hilton Hotel - Minneapolis, Minnesota SMIME WG 11 November 2003, 1700-1800 INTRODUCTION The meeting was chaired by Blake Ramsdell of Brute Squad Labs. The other co-chair, Sean Turner of IECA, was unable to attend. Approximately 40 participants were in attendance. The Chairman introduced the agenda. There were no comments on the agenda from the WG. He acknowledged that Chris Bonatti agreed to serve as note-taker. He asked for an official XMPP scribe, but there were no volunteers. So the Chairman suggested that anybody using XMPP act on their own recognizance to highlight important statements over that service. WG STATUS The Chairman gave an update of the status of WG activities. He reported the following: There are two newly completed RFCs: - RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS), Russ Housley, July 2003. - RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), Jim Schaad, July 2003. Reported that four I-Ds were approved and were now in the RFC Editor's Queue: - draft-ietf-smime-camellia-05 - draft-ietf-smime-symkeydist-09 - draft-ietf-smime-x400wrap-09 - draft-ietf-smime-x400transport-09 WG Last Call coming up again on: - draft-ietf-smime-rfc2632bis-04 (Son-of-CERT) - draft-ietf-smime-rfc2633bis-06 (Son-of-MSG) - draft-ietf-smime-examples-12 Up and coming drafts include: - draft-ietf-smime-cms-rsa-kem-01 - draft-ietf-smime-gost-00 New draft coming in soon: - draft-park-cms-seed-00 Completed milestones - Submittted x400wrap and x400transport drafts Open Milestones - Complete rfc2632bis and rfc2633bis=20 - Complete examples draft - Develop draft on RSA PSS algorithm Longer Term - WG Last Call on RSA KEM - Submit RSA KEM - Final S/MIME version 3.1 interoperability matrix New Milestones - SEED - GOST EXAMPLES Paul Hoffman reported on the update to the CMS and ESS Examples draft. He noted that major revision was performed since Vienna. Essentially we admitted that we were in denial about a lot of the examples, and so rethought the scope so that it took at least two working implementations to include the case. Thus many examples were deleted. There are still some outstanding comments from Jim Schaad noting some bugs in the code. These should be resolved shortly. He noted that comments are still welcome. At least one comment outstanding. MSGbis and CERTbis Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts. He noted numerous changes from Jim Schaad (mostly editorial) had been integrated into the document. He noted that he still needs to clear up the "I-D Nits" issues (i.e., splitting references, etc.). He also noted that he is waiting for a secondary validation of hex dump. Jim Schaad is looking at this, but additional comments from others would be helpful. He noted that there was a new issue on definition of smimeCapabilities attribute values for the RC2 algorithm. It is not clear that these are defined anywhere. Ideally, we would like to have this elsewhere, but since it's kind of an afterthought we're going to have to squeeze it into MSG. Another new issue that has been discussed on the list is the guidance text on selection encryption algorithm. There was some obsolete language that dealt with weaker algorithms. Ramsdell indicated that he was revising text to update the decision tree to lead you instead to 3DES.=20 Another new issue was clarification of the semantics of the smime-type subtype. The smime-type is indicated an attribute on the Content-Type MIME header. Current values defined in MSG include signed-data, enveloped-data, compressed-data, and certs- only. The question is, what is the right way to use this. - As a hint for IMAP? - As a content hint for processing? Ramsdell stated that he believed this should really reflect the outermost wrapper that must first be processed. Chris Bonatti stated that he didn't have an answer to this question, but pointed out that the x400wrap and x400transport drafts added some new values of smime-type for signed-x400 and encrypted-x400. While these clearly address more than just the outer wrapper, they distinguish a different service and message spec than S/MIME per se so there is some value. Indicating that he was an e-mail implementer, DABOO stated that he does not want to have to decode the entire content to know what kind of visual indicator to present, but he does not think that these two things are separate. Jim Schaad indicated that what brought this issue up is the ambiguity of signed receipts. In the instance of a signed- receipt that is also encrypted, which smime-type value should be used: the signed-receipt (defined in RFC 2634) or encrypted-data (as per the MSG spec)? Somebody (Blake?) noted that they have the same issue with the SIP WG, in that they want to easily identify data that contains SIP so that they can further process them. The chairman noted that he was not sure whether the Application Area should be consulted before deciding this matter. The WG tentatively agreed that the strawman solution is that smime-type is more a display hint than a processing hint, and that we will clarify this in the document. More discussion on the list is possible. Ramsdell noted that there is a PKIX issue that may require clarifications to the language regarding the subjectKeyIdentifier (SKI), and that he is not clear what the outcome should be. The problem is that use of the SKI to identify certificates is not sufficiently unique by itself. The reason for this seems to be that some implementations may issue crappy SKIs that are short, locally incremented identifiers. We need to add language to clarify that certificate processing when identified with SKI should: - Be prepared for matching multiple certificates; - Be prepared for some of those candidate certificates to fail. This would help implementations to bullet-proof against failing in what is a predictable scenario. Russ Housley, the Security Area Director, stated that he agreed with most of this, but indicated that we should preface this new text with the statement that if the recommendations of RFC 3280 are followed (i.e., SKI is the hash of the public key) then the overlap of these identifiers is possible but unlikely. This text is required mainly because that recommendation is a SHOULD instead of a MUST. Ramsdell also indicated that he had made several minor updates to the CERTbis document. He reported that he has added differences since 3.0 certificate profile to the document. He has also added credits and minor editorial fixes. PSS STATUS Jim Schaad reported that he has finished the edits of the PKIX version of PSS. This S/MIME PSS draft should be completed shortly. He also indicated that the Interoperability Matrix entries for CMS and CMSALG are finished. He still needs to do some editorial work to clean up the document. The ESSbis issue is still alive, but there has been no recent movement. KEM STATUS The Chairman reported speaking to Burt Kaliski of RSA, and noted that the KEM draft is temporarily stalled. The KEM draft is based on ANSI X9.44, which has not yet stabilized its ASN.1 syntax. The KEM draft cannot progress to RFC status until relevant X9.44 areas are stabilized. GOST STATUS The Chairman reported that the GOST draft is being updated and will be posted after the meeting. The new draft will add normative references to CMS and Russian law. He noted there are still some additional comments that need to be taken care of. Normative reference to CPALGS is a problem. The GOST algorithm needs to be described in an international standard, national standard, or RFC. An informational RFC would be easiest. Russ Housley stated that he thinks they are aiming to provide such an informative RFC for the Seoul meeting. Paul Hoffman pointed out that making it an RFC makes things a lot easier than the alternatives. Ramsdell and Housley agreed. Another issue is ASN.1 modules. The -00 draft uses the X.680 version of ASN.1, and needs to switch to X.208-88 to align with the rest of S/MIME. There are also too many modules in the draft. There were six modules in the -00 version, and will be 5 in -01, but they can still be further merged. SEED STATUS Jongwook Park from KISA gave a presentation introducing the SEED algorithm. He noted that SEED is based on a Feistel structure with 16 rounds. It has a 128-bit blocksize, and employs a 128-bit key. He proposed publishing the SEED algorithm description as an informational RFC prior to the Seoul meeting. All the documentation is available now from http://www.kisa.or.kr/seed/index.html. He invited comments from the WG. Park also noted that we should watch for feedback from ISO/IEC JTC1 SC27. The Chairman asked whether SEED was currently being considered by ISO. Park indicated that it was. He noted that he does not attend the ISO meetings, but some of his colleagues do. Ramsdell asked whether ISO has assigned OIDs for the algorithm. Park indicated that they have not. He stated that they were examining the strength of the algorithm, but there had been no results yet. Russ Housley asked whether SEED was the Korean national algorithm. Park responded that SEED was mandatory in Korea. ------=_NextPart_000_0037_01C3ACF4.8966CFC0-- From owner-ietf-smime@mail.imc.org Mon Nov 17 11:50:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20367 for ; Mon, 17 Nov 2003 11:50:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHGOxkT036710 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHGOxfl036709 for ietf-smime-bks; Mon, 17 Nov 2003 08:24:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHGOxkT036704 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 16:24:50 -0000 From: "Bonatti, Chris" To: "'Jack Lloyd'" Cc: Subject: RE: CMS Implementation Questions Date: Mon, 17 Nov 2003 11:24:49 -0500 Organization: IECA, Inc. Message-ID: <005e01c3ad27$5310b700$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAHGOxkT036705 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit To take on a couple of the questions that Peter didn't address... Jack Lloyd writes: > 3) It is legal to include SignedAttributes and sign everything > that way even when signing plain data content, correct? Yes, this is basically what SignedData is for. %-} Maybe I'm not grokking the question. > 4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and > RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? > This is not particularly clear to me from the texts of RFCs 2630 > and 3369. IMPLICIT. The module in clause 12.1 of RFC 3369 defaults to IMPLICIT tagging, and nothing in the definitions of SignerIdentifier or RecipientIdentifier override this default. In both instances, this means that the context-specific tag [0] replaces the OCTET STRING tag. Maybe somebody with RC2 code in front of them can address question 5. Chris From owner-ietf-smime@mail.imc.org Mon Nov 17 13:37:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27337 for ; Mon, 17 Nov 2003 13:37:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9nkT041064 for ; Mon, 17 Nov 2003 10:09:49 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHI9nnq041063 for ietf-smime-bks; Mon, 17 Nov 2003 10:09:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9mkT041049 for ; Mon, 17 Nov 2003 10:09:48 -0800 (PST) (envelope-from lloyd@randombit.net) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id ABC8C3EB56; Mon, 17 Nov 2003 13:09:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id AAABB46840; Mon, 17 Nov 2003 13:09:48 -0500 (EST) Date: Mon, 17 Nov 2003 13:09:48 -0500 (EST) From: Jack Lloyd X-X-Sender: lloyd@centaur.acm.jhu.edu To: "Bonatti, Chris" Cc: ietf-smime@imc.org Subject: RE: CMS Implementation Questions In-Reply-To: <005e01c3ad27$5310b700$0300a8c0@ieca.com> Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 17 Nov 2003, Bonatti, Chris wrote: > To take on a couple of the questions that Peter didn't address... > > Jack Lloyd writes: > > > 3) It is legal to include SignedAttributes and sign everything > > that way even when signing plain data content, correct? > > Yes, this is basically what SignedData is for. %-} > Maybe I'm not grokking the question. > When signing something other than plain data content, using the attributes is required (section 5.3 of 3369). Otherwise, they are described as "optional"; I'm presuming this means an implementation MAY use signed attributes when signing plain data content as well? It is all-in-all fairly clear, but I would prefer being 100% certain I know what it's trying to say. When an RFC isn't completely and totally clear, I don't like to just assume I'm guessing the correct interpretation. > IMPLICIT. > > The module in clause 12.1 of RFC 3369 defaults to IMPLICIT > tagging, and nothing in the definitions of SignerIdentifier or > RecipientIdentifier override this default. In both instances, > this means that the context-specific tag [0] replaces the OCTET > STRING tag. I saw the default tagging, but given the ease of mixups, I wanted to be sure. There is lots of stuff in the module with explicit IMPLICIT tags, which shouldn't really have to be there given that is the default encoding. Sometimes IMPLICT tags are there, sometimes they are not. See last sentence of my previous paragraph. Thanks, Jack From owner-ietf-smime@mail.imc.org Tue Nov 18 11:01:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27261 for ; Tue, 18 Nov 2003 11:01:22 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFUAkT069780 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIFUAKh069779 for ietf-smime-bks; Tue, 18 Nov 2003 07:30:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAIFUAkT069773 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 18 Nov 2003 15:30:11 -0000 From: "Bonatti, Chris" To: "'Jack Lloyd'" Cc: Subject: RE: CMS Implementation Questions Date: Tue, 18 Nov 2003 10:30:10 -0500 Organization: IECA, Inc. Message-ID: <000101c3ade8$dae62680$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAIFUAkT069774 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit Jack Lloyd writes: > > On Mon, 17 Nov 2003, Bonatti, Chris wrote: > > > To take on a couple of the questions that Peter didn't address... > > > > Jack Lloyd writes: > > > > > 3) It is legal to include SignedAttributes and sign everything > > > that way even when signing plain data content, correct? > > > > Yes, this is basically what SignedData is for. %-} > > Maybe I'm not grokking the question. > > > > When signing something other than plain data content, using > the attributes is required (section 5.3 of 3369). Otherwise, > they are described as "optional"; I'm presuming this means an > implementation MAY use signed attributes when signing plain > data content as well? It is all-in-all fairly clear, but I > would prefer being 100% certain I know what it's trying to > say. When an RFC isn't completely and totally clear, I don't > like to just assume I'm guessing the correct interpretation. > The 'signedAttrs' field is an old function that goes back to PKCS-7 (i.e., the 'authenticatedAttributes' field). It has always been an option to include signed attributes in the signature regardless of the type. I think the reason for the requirement to include these for content types other than id-data stems from the desire to have the PKCS-9 'ContentType' attribute included to bind the type to the data. There has always been a perception that MIME content was the "default" for PKCS-7. This is supported by the fact that a MIME object is easily recognized, and self-identifies what type(s) it carries. This is not true for many other possible object types. I think that the requirement to include the 'ContentType' attribute originally comes from PKCS-9, though, not PKCS-7. There is no converse requirement to omit signed attributes when signing MIME data. I hope this helps. Chris From 15jvmi@aol.com Sat Nov 22 14:34:10 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19200 for ; Sat, 22 Nov 2003 14:34:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANdWO-0001Md-00 for smime-archive@ietf.org; Sat, 22 Nov 2003 14:34:20 -0500 Received: from [63.228.67.77] (helo=africaserver.africatvl.com) by ietf-mx with esmtp (Exim 4.12) id 1ANdWO-0001MM-00 for smime-archive@ietf.org; Sat, 22 Nov 2003 14:34:20 -0500 Received: from pcp594155pcs.dksnco01.tn.comcast.net ([68.53.155.43]) by africaserver.africatvl.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id XHCDHNTM; Fri, 21 Nov 2003 23:16:54 -0700 Received: from (HELO 7kbdk3r) [193.72.212.151] by pcp594155pcs.dksnco01.tn.comcast.net; Sat, 22 Nov 2003 12:12:36 -0700 Message-ID: <5$4-$6g-1k-6v9m5$4h-80$$q@0h3.7jjm> From: "Calvin Ramos" <15jvmi@aol.com> Reply-To: "Calvin Ramos" <15jvmi@aol.com> To: smimama@aol.com Subject: Rates are at historic lows, do not miss this Date: Sat, 22 Nov 2003 12:12:36 -0700 X-Mailer: eGroups Message Poster MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="8.3_B5.E043E" X-Priority: 3 --8.3_B5.E043E Content-Type: text/html; Content-Transfer-Encoding: base64 PHA+PGEgaHJlZj0iaHR0cDovL3d3dy5lbG9hbnF1b3RlLm5ldC9mcmVlcXVvdGUuYXNweD9z aXRlaWQ9bmV0bWFya2V0aW5nLTEwMiI+RnJlZSBRdW90ZXMgQXZhaWxhYmxlIGZyb20gMyBs ZW5kZXJzPGJyPg0KPGEgaHJlZj0iaHR0cDovL3d3dy5lbG9hbnF1b3RlLm5ldC9mcmVlcXVv dGUuYXNweD9zaXRlaWQ9bmV0bWFya2V0aW5nLTEwMiI+PGltZyBzcmM9Imh0dHA6Ly93d3cu ZWxvYW5xdW90ZS5uZXQvKHlqb3podjU1dmJraHExMjNnenJ1cnI0NSkvX2ltYWdlcy9oZWFk ZXIuanBnIiBib3JkZXI9IjAiPjwvYT4= --8.3_B5.E043E-- From halgbmnn@aol.com Thu Nov 27 02:42:02 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28778; Thu, 27 Nov 2003 02:42:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APGmy-0004T2-00; Thu, 27 Nov 2003 02:42:12 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1APGmy-0004Sv-00; Thu, 27 Nov 2003 02:42:12 -0500 Received: from midsouth-24-151-197-132.westtn.chartertn.net ([24.151.197.132]) by manatick with smtp (Exim 4.24) id 1APGmx-0007EB-5V; Thu, 27 Nov 2003 02:42:13 -0500 Received: from [130.25.76.53] by midsouth-24-151-197-132.westtn.chartertn.net with ESMTP id <766110-13858> for ; Thu, 27 Nov 2003 19:43:10 -0700 Message-ID: From: "Irma Stout" Reply-To: "Irma Stout" To: , , , , , , Date: Thu, 27 Nov 03 19:43:10 GMT X-Mailer: AOL 7.0 for Windows US sub 118 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="FE2D.F35D82A9.EDD.C9.." X-Priority: 3 X-MSMail-Priority: Normal --FE2D.F35D82A9.EDD.C9.. Content-Type: text/html; Content-Transfer-Encoding: quoted-printable

Graphic= s Loading... Please wait.



DO YOU WANT A MAGE FRONLY 1.= 5% ?

If you are in the market for a mort= gage, look for further than us for the lowest rates available!

Our risk-free, no obligation ratefi= nder softwa= re can help you find the lowest mortgage regardless of your financial situation!

Click here for yoREE ri= sk-free, no= obligation quote!

 

&nb= sp;

You are recieving this email because you= are a member at freeraffle.us.
We have your signup and confir= mation ip on file! Click here to remllow upto 3 days to be remove= d!

=

paz xveezmr pbffxjxnq jepzzrvuwi rmhfefpymxo qvguu --FE2D.F35D82A9.EDD.C9..-- From pope_fh@experimentarium.dk Sat Nov 29 10:54:43 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19381 for ; Sat, 29 Nov 2003 10:54:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ7Qu-0006l8-00 for smime-archive@ietf.org; Sat, 29 Nov 2003 10:54:56 -0500 Received: from [210.116.6.193] (helo=uni-mannheim.de) by ietf-mx with smtp (Exim 4.12) id 1AQ7Qf-0006hj-00; Sat, 29 Nov 2003 10:54:41 -0500 Message-ID: <2d8301c3b755$cbea848f$255d3517@aotdwze> From: "Terrell Pope" To: smime-archive@ietf.org, 2002-12-18131941.i-d@ietf.org Subject: STOP SUFFERING IN SILENCE , gcmyxudyn Date: Sun, 30 Nov 2003 15:18:00 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/html Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit

Traditional, liberal or newschool? Depends on how you were raised. Are we getting political here? Hell, no! This is just to describe your sex life. If you're traditional, delete this mail now. Please. If you're liberal, you get yourself some pills after you've realized that hanging a two-pounds stone from your cock doesn't make it longer. If you're newschool, you happily dabble with things others don't even know about. Traditionals have already deleted this mail. Ahem. Liberals - click here for the VP-RX, the best penis enlargement ever invented. If you're liberal heart rebels, no worry, it's money back guarantee. Check out what VP-RX can do to you remember, if the name sounds like a robot, it surely does a lot of things to you!


Newschoolers - use the most advanced scientific solution to enlarge your treasured organ - with a Magna-RX patch! Tht's right, no pills, creams, pumps, exercises - but the fuller, thicker feeling and the visible results can surely give you that tingling boost of self- confidence.. and the aching of that cock after four hours of a steamy threesome!

Click here to know more about this brand-new patch!







Remove me From freeman_walleryg@minedu.fi Sun Nov 30 12:35:51 2003 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05898; Sun, 30 Nov 2003 12:35:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQVUK-0000tM-00; Sun, 30 Nov 2003 12:36:04 -0500 Received: from d151-12-144-50.dnv.wideopenwest.com ([12.151.50.144] helo=home.pf.jcu.cz) by ietf-mx with smtp (Exim 4.12) id 1AQVU5-0000r5-00; Sun, 30 Nov 2003 12:35:50 -0500 Message-ID: <052a01c3b82c$6e3086e1$cd51b784@vaxkcqc> From: "Freeman Waller" To: sip-request@ietf.org, sipping@ietf.org, sipping-admin@ietf.org, sipping-request@ietf.org, smime-archive@ietf.org Subject: WA:NT" A. BIG C'O.C"K _' wqqophaevt Date: Mon, 01 Dec 2003 16:59:33 +0000 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Type: text/html Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit

Traditional, liberal or newschool? Depends on how you were raised. Are we getting political here? Hell, no! This is just to describe your sex life. If you're traditional, delete this mail now. Please. If you're liberal, you get yourself some pills after you've realized that hanging a two-pounds stone from your cock doesn't make it longer. If you're newschool, you happily dabble with things others don't even know about. Traditionals have already deleted this mail. Ahem. Liberals - click here for the VP-RX, the best penis enlargement ever invented. If you're liberal heart rebels, no worry, it's money back guarantee. Check out what VP-RX can do to you remember, if the name sounds like a robot, it surely does a lot of things to you!


Newschoolers - use the most advanced scientific solution to enlarge your treasured organ - with a Magna-RX patch! Tht's right, no pills, creams, pumps, exercises - but the fuller, thicker feeling and the visible results can surely give you that tingling boost of self- confidence.. and the aching of that cock after four hours of a steamy threesome!

Click here to know more about this brand-new patch!







Remove me Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAIFUAkT069780 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAIFUAKh069779 for ietf-smime-bks; Tue, 18 Nov 2003 07:30:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp006.bizmail.sc5.yahoo.com (smtp006.bizmail.sc5.yahoo.com [66.163.175.83]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAIFUAkT069773 for ; Tue, 18 Nov 2003 07:30:10 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 18 Nov 2003 15:30:11 -0000 From: "Bonatti, Chris" To: "'Jack Lloyd'" Cc: Subject: RE: CMS Implementation Questions Date: Tue, 18 Nov 2003 10:30:10 -0500 Organization: IECA, Inc. Message-ID: <000101c3ade8$dae62680$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAIFUAkT069774 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jack Lloyd writes: > > On Mon, 17 Nov 2003, Bonatti, Chris wrote: > > > To take on a couple of the questions that Peter didn't address... > > > > Jack Lloyd writes: > > > > > 3) It is legal to include SignedAttributes and sign everything > > > that way even when signing plain data content, correct? > > > > Yes, this is basically what SignedData is for. %-} > > Maybe I'm not grokking the question. > > > > When signing something other than plain data content, using > the attributes is required (section 5.3 of 3369). Otherwise, > they are described as "optional"; I'm presuming this means an > implementation MAY use signed attributes when signing plain > data content as well? It is all-in-all fairly clear, but I > would prefer being 100% certain I know what it's trying to > say. When an RFC isn't completely and totally clear, I don't > like to just assume I'm guessing the correct interpretation. > The 'signedAttrs' field is an old function that goes back to PKCS-7 (i.e., the 'authenticatedAttributes' field). It has always been an option to include signed attributes in the signature regardless of the type. I think the reason for the requirement to include these for content types other than id-data stems from the desire to have the PKCS-9 'ContentType' attribute included to bind the type to the data. There has always been a perception that MIME content was the "default" for PKCS-7. This is supported by the fact that a MIME object is easily recognized, and self-identifies what type(s) it carries. This is not true for many other possible object types. I think that the requirement to include the 'ContentType' attribute originally comes from PKCS-9, though, not PKCS-7. There is no converse requirement to omit signed attributes when signing MIME data. I hope this helps. Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9nkT041064 for ; Mon, 17 Nov 2003 10:09:49 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHI9nnq041063 for ietf-smime-bks; Mon, 17 Nov 2003 10:09:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHI9mkT041049 for ; Mon, 17 Nov 2003 10:09:48 -0800 (PST) (envelope-from lloyd@randombit.net) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id ABC8C3EB56; Mon, 17 Nov 2003 13:09:48 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id AAABB46840; Mon, 17 Nov 2003 13:09:48 -0500 (EST) Date: Mon, 17 Nov 2003 13:09:48 -0500 (EST) From: Jack Lloyd X-X-Sender: lloyd@centaur.acm.jhu.edu To: "Bonatti, Chris" Cc: ietf-smime@imc.org Subject: RE: CMS Implementation Questions In-Reply-To: <005e01c3ad27$5310b700$0300a8c0@ieca.com> Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: On Mon, 17 Nov 2003, Bonatti, Chris wrote: > To take on a couple of the questions that Peter didn't address... > > Jack Lloyd writes: > > > 3) It is legal to include SignedAttributes and sign everything > > that way even when signing plain data content, correct? > > Yes, this is basically what SignedData is for. %-} > Maybe I'm not grokking the question. > When signing something other than plain data content, using the attributes is required (section 5.3 of 3369). Otherwise, they are described as "optional"; I'm presuming this means an implementation MAY use signed attributes when signing plain data content as well? It is all-in-all fairly clear, but I would prefer being 100% certain I know what it's trying to say. When an RFC isn't completely and totally clear, I don't like to just assume I'm guessing the correct interpretation. > IMPLICIT. > > The module in clause 12.1 of RFC 3369 defaults to IMPLICIT > tagging, and nothing in the definitions of SignerIdentifier or > RecipientIdentifier override this default. In both instances, > this means that the context-specific tag [0] replaces the OCTET > STRING tag. I saw the default tagging, but given the ease of mixups, I wanted to be sure. There is lots of stuff in the module with explicit IMPLICIT tags, which shouldn't really have to be there given that is the default encoding. Sometimes IMPLICT tags are there, sometimes they are not. See last sentence of my previous paragraph. Thanks, Jack Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHGOxkT036710 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHGOxfl036709 for ietf-smime-bks; Mon, 17 Nov 2003 08:24:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp004.bizmail.sc5.yahoo.com (smtp004.bizmail.sc5.yahoo.com [66.163.175.81]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHGOxkT036704 for ; Mon, 17 Nov 2003 08:24:59 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 16:24:50 -0000 From: "Bonatti, Chris" To: "'Jack Lloyd'" Cc: Subject: RE: CMS Implementation Questions Date: Mon, 17 Nov 2003 11:24:49 -0500 Organization: IECA, Inc. Message-ID: <005e01c3ad27$5310b700$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id hAHGOxkT036705 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: To take on a couple of the questions that Peter didn't address... Jack Lloyd writes: > 3) It is legal to include SignedAttributes and sign everything > that way even when signing plain data content, correct? Yes, this is basically what SignedData is for. %-} Maybe I'm not grokking the question. > 4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and > RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? > This is not particularly clear to me from the texts of RFCs 2630 > and 3369. IMPLICIT. The module in clause 12.1 of RFC 3369 defaults to IMPLICIT tagging, and nothing in the definitions of SignerIdentifier or RecipientIdentifier override this default. In both instances, this means that the context-specific tag [0] replaces the OCTET STRING tag. Maybe somebody with RC2 code in front of them can address question 5. Chris Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAHFLHkT032672 for ; Mon, 17 Nov 2003 07:21:17 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAHFLHYE032671 for ietf-smime-bks; Mon, 17 Nov 2003 07:21:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp001.bizmail.yahoo.com (smtp001.bizmail.yahoo.com [216.136.172.125]) by above.proper.com (8.12.10/8.12.8) with SMTP id hAHFLGkT032665 for ; Mon, 17 Nov 2003 07:21:16 -0800 (PST) (envelope-from BonattiC@ieca.com) Received: from pcp04425525pcs.nrockv01.md.comcast.net (HELO Obsidian) (BonattiC@ieca.com@69.140.137.37 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 17 Nov 2003 15:21:17 -0000 From: "Bonatti, Chris" To: Subject: Draft S/MIME WG Notes Date: Mon, 17 Nov 2003 10:21:10 -0500 Organization: IECA, Inc. Message-ID: <003601c3ad1e$723cd7c0$0300a8c0@ieca.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0037_01C3ACF4.8966CFC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C3ACF4.8966CFC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Draft notes from last week's WG meeting are attached. Comments or corrections are welcome, of course. Regards, Chris ------=_NextPart_000_0037_01C3ACF4.8966CFC0 Content-Type: text/plain; name="IETF#58-SMIME-Notes.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="IETF#58-SMIME-Notes.txt" IETF 58th Meeting Hilton Hotel - Minneapolis, Minnesota SMIME WG 11 November 2003, 1700-1800 INTRODUCTION The meeting was chaired by Blake Ramsdell of Brute Squad Labs. The other co-chair, Sean Turner of IECA, was unable to attend. Approximately 40 participants were in attendance. The Chairman introduced the agenda. There were no comments on the agenda from the WG. He acknowledged that Chris Bonatti agreed to serve as note-taker. He asked for an official XMPP scribe, but there were no volunteers. So the Chairman suggested that anybody using XMPP act on their own recognizance to highlight important statements over that service. WG STATUS The Chairman gave an update of the status of WG activities. He reported the following: There are two newly completed RFCs: - RFC 3560: Use of the RSAES-OAEP Key Transport Algorithm in the Cryptographic Message Syntax (CMS), Russ Housley, July 2003. - RFC 3565: Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS), Jim Schaad, July 2003. Reported that four I-Ds were approved and were now in the RFC Editor's Queue: - draft-ietf-smime-camellia-05 - draft-ietf-smime-symkeydist-09 - draft-ietf-smime-x400wrap-09 - draft-ietf-smime-x400transport-09 WG Last Call coming up again on: - draft-ietf-smime-rfc2632bis-04 (Son-of-CERT) - draft-ietf-smime-rfc2633bis-06 (Son-of-MSG) - draft-ietf-smime-examples-12 Up and coming drafts include: - draft-ietf-smime-cms-rsa-kem-01 - draft-ietf-smime-gost-00 New draft coming in soon: - draft-park-cms-seed-00 Completed milestones - Submittted x400wrap and x400transport drafts Open Milestones - Complete rfc2632bis and rfc2633bis=20 - Complete examples draft - Develop draft on RSA PSS algorithm Longer Term - WG Last Call on RSA KEM - Submit RSA KEM - Final S/MIME version 3.1 interoperability matrix New Milestones - SEED - GOST EXAMPLES Paul Hoffman reported on the update to the CMS and ESS Examples draft. He noted that major revision was performed since Vienna. Essentially we admitted that we were in denial about a lot of the examples, and so rethought the scope so that it took at least two working implementations to include the case. Thus many examples were deleted. There are still some outstanding comments from Jim Schaad noting some bugs in the code. These should be resolved shortly. He noted that comments are still welcome. At least one comment outstanding. MSGbis and CERTbis Blake Ramsdell reported as the editor of MSGbis and CERTbis drafts. He noted numerous changes from Jim Schaad (mostly editorial) had been integrated into the document. He noted that he still needs to clear up the "I-D Nits" issues (i.e., splitting references, etc.). He also noted that he is waiting for a secondary validation of hex dump. Jim Schaad is looking at this, but additional comments from others would be helpful. He noted that there was a new issue on definition of smimeCapabilities attribute values for the RC2 algorithm. It is not clear that these are defined anywhere. Ideally, we would like to have this elsewhere, but since it's kind of an afterthought we're going to have to squeeze it into MSG. Another new issue that has been discussed on the list is the guidance text on selection encryption algorithm. There was some obsolete language that dealt with weaker algorithms. Ramsdell indicated that he was revising text to update the decision tree to lead you instead to 3DES.=20 Another new issue was clarification of the semantics of the smime-type subtype. The smime-type is indicated an attribute on the Content-Type MIME header. Current values defined in MSG include signed-data, enveloped-data, compressed-data, and certs- only. The question is, what is the right way to use this. - As a hint for IMAP? - As a content hint for processing? Ramsdell stated that he believed this should really reflect the outermost wrapper that must first be processed. Chris Bonatti stated that he didn't have an answer to this question, but pointed out that the x400wrap and x400transport drafts added some new values of smime-type for signed-x400 and encrypted-x400. While these clearly address more than just the outer wrapper, they distinguish a different service and message spec than S/MIME per se so there is some value. Indicating that he was an e-mail implementer, DABOO stated that he does not want to have to decode the entire content to know what kind of visual indicator to present, but he does not think that these two things are separate. Jim Schaad indicated that what brought this issue up is the ambiguity of signed receipts. In the instance of a signed- receipt that is also encrypted, which smime-type value should be used: the signed-receipt (defined in RFC 2634) or encrypted-data (as per the MSG spec)? Somebody (Blake?) noted that they have the same issue with the SIP WG, in that they want to easily identify data that contains SIP so that they can further process them. The chairman noted that he was not sure whether the Application Area should be consulted before deciding this matter. The WG tentatively agreed that the strawman solution is that smime-type is more a display hint than a processing hint, and that we will clarify this in the document. More discussion on the list is possible. Ramsdell noted that there is a PKIX issue that may require clarifications to the language regarding the subjectKeyIdentifier (SKI), and that he is not clear what the outcome should be. The problem is that use of the SKI to identify certificates is not sufficiently unique by itself. The reason for this seems to be that some implementations may issue crappy SKIs that are short, locally incremented identifiers. We need to add language to clarify that certificate processing when identified with SKI should: - Be prepared for matching multiple certificates; - Be prepared for some of those candidate certificates to fail. This would help implementations to bullet-proof against failing in what is a predictable scenario. Russ Housley, the Security Area Director, stated that he agreed with most of this, but indicated that we should preface this new text with the statement that if the recommendations of RFC 3280 are followed (i.e., SKI is the hash of the public key) then the overlap of these identifiers is possible but unlikely. This text is required mainly because that recommendation is a SHOULD instead of a MUST. Ramsdell also indicated that he had made several minor updates to the CERTbis document. He reported that he has added differences since 3.0 certificate profile to the document. He has also added credits and minor editorial fixes. PSS STATUS Jim Schaad reported that he has finished the edits of the PKIX version of PSS. This S/MIME PSS draft should be completed shortly. He also indicated that the Interoperability Matrix entries for CMS and CMSALG are finished. He still needs to do some editorial work to clean up the document. The ESSbis issue is still alive, but there has been no recent movement. KEM STATUS The Chairman reported speaking to Burt Kaliski of RSA, and noted that the KEM draft is temporarily stalled. The KEM draft is based on ANSI X9.44, which has not yet stabilized its ASN.1 syntax. The KEM draft cannot progress to RFC status until relevant X9.44 areas are stabilized. GOST STATUS The Chairman reported that the GOST draft is being updated and will be posted after the meeting. The new draft will add normative references to CMS and Russian law. He noted there are still some additional comments that need to be taken care of. Normative reference to CPALGS is a problem. The GOST algorithm needs to be described in an international standard, national standard, or RFC. An informational RFC would be easiest. Russ Housley stated that he thinks they are aiming to provide such an informative RFC for the Seoul meeting. Paul Hoffman pointed out that making it an RFC makes things a lot easier than the alternatives. Ramsdell and Housley agreed. Another issue is ASN.1 modules. The -00 draft uses the X.680 version of ASN.1, and needs to switch to X.208-88 to align with the rest of S/MIME. There are also too many modules in the draft. There were six modules in the -00 version, and will be 5 in -01, but they can still be further merged. SEED STATUS Jongwook Park from KISA gave a presentation introducing the SEED algorithm. He noted that SEED is based on a Feistel structure with 16 rounds. It has a 128-bit blocksize, and employs a 128-bit key. He proposed publishing the SEED algorithm description as an informational RFC prior to the Seoul meeting. All the documentation is available now from http://www.kisa.or.kr/seed/index.html. He invited comments from the WG. Park also noted that we should watch for feedback from ISO/IEC JTC1 SC27. The Chairman asked whether SEED was currently being considered by ISO. Park indicated that it was. He noted that he does not attend the ISO meetings, but some of his colleagues do. Ramsdell asked whether ISO has assigned OIDs for the algorithm. Park indicated that they have not. He stated that they were examining the strength of the algorithm, but there had been no results yet. Russ Housley asked whether SEED was the Korean national algorithm. Park responded that SEED was mandatory in Korea. ------=_NextPart_000_0037_01C3ACF4.8966CFC0-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAjkT028396 for ; Fri, 14 Nov 2003 11:10:45 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAEJAig7028395 for ietf-smime-bks; Fri, 14 Nov 2003 11:10:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from vahqex2.gfgsi.com (netva01.getronicsgov.com [67.105.229.98]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAEJAdkT028369; Fri, 14 Nov 2003 11:10:39 -0800 (PST) (envelope-from Matt.Bertapelle@DigitalNet.com) Received: from digitalnet.com ([158.189.2.70]) by vahqex2.gfgsi.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 14 Nov 2003 14:10:40 -0500 Message-ID: <3FB528AF.2020206@digitalnet.com> Date: Fri, 14 Nov 2003 14:10:39 -0500 From: Matt Bertapelle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: imc-sfl , ietf-smime@imc.org Subject: v2.3 S/MIME Freeware Library (SFL) Now Available Content-Type: multipart/alternative; boundary="------------040801000409060109070908" X-OriginalArrivalTime: 14 Nov 2003 19:10:40.0860 (UTC) FILETIME=[FEAD31C0:01C3AAE2] Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. --------------040801000409060109070908 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code. The SFL source code files and documents are freely available at . The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications. It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications. When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method specification. It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems. Further enhancements, ports and testing of the SFL are still in process. Further releases of the SFL will be provided as significant capabilities are added. The SFL has been successfully used to sign, verify, encrypt and decrypt CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0 Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.3 SFL uses the v2.3 Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) ASN.1 C++ Library to encode/decode objects. The v2.3 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers; and test data. All CTILs were tested as Dynamically Linked Libraries (DLL) using MS Windows. The Fortezza, BSAFE and Crypto++ CTILs were tested with the respective security libraries as shared objects using Linux and Solaris 2.8. The SFL has been successfully used to exchange signedData and envelopedData messages with the MS Internet Explorer Outlook Express v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME products. Signed messages have been exchanged with the RSA S/MAIL and WorldTalk S/MIME v2 products. The SFL has also been used to perform S/MIME v3 interoperability testing with Microsoft that exercised the majority of the features specified by RFCs 3369, 3370, 2631 and 2634. This testing included the RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms. We used the SFL to successfully process the SFL-supported sample data included in the S/MIME WG "Examples of S/MIME Messages" document. We also used the SFL to generate S/MIME v3 sample messages that were included in the "Examples" document. The use of the v2.3 SFL is described in the v2.3 SFL Application Programming Interface (API) and v2.3 SFL Software Design Description documents. The use of the v2.3 CTIL API is described in the v2.3 CTIL API document. v2.3 SFL includes the following enhancements (compared to v2.2 SFL and CTIL releases): 1) The SFL library now provides Compressed Data Content Type for CMS. This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS. Compressed data can be performed on the SignedData and EnvelopedData items without application interaction, by providing the appropriate compressDataFlag flag during the session. 2) There is a major change in how the content is stored in the CSM_CommonData object. With the addition of Compressed Data Content Type for CMS, it was necessary to distinguish between clear content and unclear content. CSM_CommonData now stores both clear and unclear content making the application determine which content to use according to desired processing. See the CSM_CommonData section for the changes. 3) The SFL library now provides Password-Based Encryption for CMS. This provides a method of encrypting data using user-supplied passwords. It is implemented as a RecipientInfo type and is an extension to the RecipientInfo Types currently defined in CMS. 4) The thread support logic was updated in the SFL and libCtilMgr. Specifically, the CSM_CSInst::AccessCertificates() method has been removed to eliminate thread access problems. This does not affect the CSM_CtilInst class, used by the CML. The "AccessCertificcates()" and "AccessCRLs()" methods have been removed due to thread issues. They are described more fully in the CSM_CSInst class description. v2.3 CTILs include the following enhancements (compared to v2.2 release): 1) Elliptic Curve functionality has been added to the sm_free3 CTIL crypto library. This includes ECDSA and ECDH processing. v2.3 Certificate Builder include the following enhancements since v2.2: 1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation. 2) Certificate Builder has been enhanced with PKCS#12 generation logic. 3) Certificate Builder has been enhanced to generate UTF-8 strings. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.8, we may port the SFL to other operating systems. All source code for the SFL is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the SFL without paying any royalties or licensing fees. DigitalNet is developing the SFL under contract to the U.S. Government. The U.S. Government is furnishing the SFL source code at no cost to the vendor subject to the conditions of the "SFL Public License". On 14 January 2000, the U.S. Department of Commerce, Bureau of Export Administration published a new regulation implementing an update to the U.S. Government's encryption export policy . In accordance with the revisions to the Export Administration Regulations (EAR) of 14 Jan 2000, the downloading of the SFL source code is not password controlled. The SFL is composed of a high-level library that performs generic CMS and ESS processing independent of the crypto algorithms used to protect a specific object. The SFL high-level library makes calls to an algorithm-independent CTIL API. The underlying, external crypto token libraries are not distributed as part of the SFL source code. The application developer must independently obtain these libraries and then link them with the SFL. The SFL uses the CML and eSNACC ASN.1 Library to encode/decode certificates, ACs, CRLs and components thereof. The CML is freely available at: . The SFL has been successfully tested in conjunction with the Access Control Library (ACL) that is freely available to everyone from: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by DigitalNet) at . DigitalNet used the SFL to successfully process the NIST test data. NIST is using the SFL and CML as part of the NIST S/MIME Test Facility (NSMTF) that they are planning to host (see ). Vendors will be able to use the NSMTF to help determine if their products comply with the IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. The SFL has been integrated into many applications to provide CMS/ESS security services. For example, the SFL was integrated into a security plug-in for a commercial e-mail application that enabled the application to meet the Bridge Certification Authority Demonstration Phase II requirements including implementing ESS features such as security labels. The Internet Mail Consortium (IMC) has established an SFL web page . The IMC has also established an SFL mail list which is used to: distribute information regarding SFL releases; discuss SFL-related issues; and provide a means for SFL users to provide feedback, comments, bug reports, etc. Subscription information for the imc-sfl mailing list is at the IMC web site listed above. All comments regarding the SFL source code and documents are welcome. This SFL release announcement was sent to several mail lists, but please send all messages regarding the SFL to the imc-sfl mail list ONLY. Please do not send messages regarding the SFL to any of the IETF mail lists. We will respond to all messages sent to the imc-sfl mail list. -- Matthew J. Bertapelle DigitalNet Government Solution, LLC www.DigitalNet.com --------------040801000409060109070908 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 
All,

DigitalNet Government Solutions has delivered the Version 2.3 S/MIME Freeware Library (SFL) source code.  The SFL source code files and documents are freely available at 
<http://www.digitalnet.com/knowledge/sfl_home.htm>.  

The SFL implements the IETF S/MIME v3 RFC 3369 Cryptographic Message Syntax (CMS) and RFC 2634 Enhanced Security Services (ESS) specifications.  It implements portions of the RFC 2633 Message Specification, RFC 2632 Certificate Handling, and RFC 3370 CMS Algorithms specifications.  When used in conjunction with the Crypto++ freeware library, the SFL implements the RFC 2631 Diffie-Hellman (D-H) Key Agreement Method 
specification.  It has been successfully tested using the Microsoft (MS) Windows 2000/XP, Linux and Sun Solaris 2.8 operating systems.  Further enhancements, ports and testing of the SFL are still in process.  Further releases of the SFL will be provided as significant capabilities are added. 

The SFL has been successfully used to sign, verify, encrypt and decrypt 
CMS/ESS objects using: DSA, E-S D-H, 3DES algorithms provided by the 
Crypto++ library; RSA suite of algorithms provided by the RSA BSAFE 6.0
Crypto-C and Crypto++ libraries; and Fortezza suite of algorithms 
provided by the Fortezza Crypto Card.  The v2.3 SFL uses the v2.3 
Certificate Management Library (CML) and v1.6 Enhanced SNACC (eSNACC) 
ASN.1 C++ Library to encode/decode objects.  The v2.3 SFL release 
includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token
Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ CTIL; 
PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; test utilities; test drivers;
and test data.  All CTILs were tested as Dynamically Linked Libraries
(DLL) using MS Windows.  The Fortezza, BSAFE and Crypto++ CTILs
were tested with the respective security libraries as shared objects
using Linux and Solaris 2.8.  

The SFL has been successfully used to exchange signedData and 
envelopedData messages with the MS Internet Explorer Outlook Express 
v4.01, Netscape Communicator 4.X, Entrust and Baltimore S/MIME 
products.  Signed messages have been exchanged with the RSA S/MAIL and 
WorldTalk S/MIME v2 products. 

The SFL has also been used to perform S/MIME v3 interoperability 
testing with Microsoft that exercised the majority of the features 
specified by RFCs 3369, 3370, 2631 and 2634.  This testing included the
RSA, DSA, E-S D-H, 3DES, SHA and Fortezza algorithms.  We used the SFL 
to successfully process the SFL-supported sample data included in the
S/MIME WG "Examples of S/MIME Messages" document.  We also used the
SFL to generate S/MIME v3 sample messages that were included in the 
"Examples" document.

The use of the v2.3 SFL is described in the v2.3 SFL Application 
Programming Interface (API) and v2.3 SFL Software Design Description
documents.  The use of the v2.3 CTIL API is described in the v2.3
CTIL API document. 


v2.3 SFL includes the following enhancements (compared to v2.2
SFL and CTIL releases):

1) The SFL library now provides Compressed Data Content Type for CMS.  This is implemented as a new ContentInfo type and is an extension to the types currently defined in CMS.  Compressed data can be performed on the SignedData and EnvelopedData items without application interaction, by providing the appropriate compressDataFlag flag during the session.

2) There is a major change in how the content is stored in the CSM_CommonData object.   With the addition of Compressed Data Content Type for CMS, it was necessary to distinguish between clear content and unclear content.  CSM_CommonData now stores both clear and unclear content making the application determine which content to use according to desired processing.  See the CSM_CommonData section for the changes.
 
3) The SFL library now provides Password-Based Encryption for CMS.  This provides a method of encrypting data using user-supplied passwords. It is implemented as a RecipientInfo type and is an extension to the RecipientInfo Types currently defined in CMS.

4) The thread support logic was updated in the SFL and libCtilMgr.  Specifically, the CSM_CSInst::AccessCertificates() method has been removed to eliminate thread access problems. This does not affect the CSM_CtilInst class, used by the CML.  The "AccessCertificcates()" and "AccessCRLs()" methods have been removed due to thread issues.  They are described more fully in the CSM_CSInst class description. 

v2.3 CTILs include the following enhancements (compared to
v2.2 release):

1) Elliptic Curve functionality has been added to the
sm_free3 CTIL crypto library.  This includes ECDSA and ECDH processing.
v2.3 Certificate Builder include the following enhancements since v2.2:

1) Certificate Builder has been enhanced with ECDSA certificate public/private key generation.

2) Certificate Builder has been enhanced with PKCS#12 generation logic.

3) Certificate Builder has been enhanced to generate UTF-8 strings.


The SFL is developed to maximize portability to 32-bit operating 
systems.  In addition to testing on MS Windows, Linux and Solaris 2.8, 
we may port the SFL to other operating systems.

All source code for the SFL is being provided at no cost and with no 
financial limitations regarding its use and distribution. 
Organizations can use the SFL without paying any royalties or 
licensing fees.  DigitalNet is developing the SFL under contract to 
the U.S. Government.  The U.S. Government is furnishing the SFL
source code at no cost to the vendor subject to the conditions of 
the "SFL Public License".

On 14 January 2000, the U.S. Department of Commerce, Bureau of 
Export Administration published a new regulation implementing an update 
to the U.S. Government's encryption export policy 
<http://www.bxa.doc.gov/Encryption/Default.htm>.  In accordance with 
the revisions to the Export Administration Regulations (EAR) of 14 Jan 
2000, the downloading of the SFL source code is not password controlled.

The SFL is composed of a high-level library that performs generic CMS 
and ESS processing independent of the crypto algorithms used to 
protect a specific object.  The SFL high-level library makes calls to 
an algorithm-independent CTIL API.  The underlying, external crypto
token libraries are not distributed as part of the SFL source code. 
The application developer must independently obtain these libraries and
then link them with the SFL.  
 
The SFL uses the CML and eSNACC ASN.1 Library to encode/decode
certificates, ACs, CRLs and components thereof.  The CML is freely
available at: <http://www.DigitalNet.com/knowledge/cml_home.htm>.

The SFL has been successfully tested in conjunction with the Access
Control Library (ACL) that is freely available to everyone from: 
<http://www.DigitalNet.com/knowledge/acl_home.htm>.

The National Institute of Standards and Technology (NIST) is providing 
test S/MIME messages (created by DigitalNet) at 
<http://csrc.nist.gov/pki/testing/x509paths.html>.  
DigitalNet used the SFL to successfully process the NIST test data.

NIST is using the SFL and CML as part of the NIST S/MIME Test 
Facility (NSMTF) that they are planning to host (see 
<http://csrc.ncsl.nist.gov/pki/smime/>).  Vendors will be able to use
the NSMTF to help determine if their products comply with the
IETF S/MIME v3 specifications and the Federal S/MIME v3 Client Profile. 

The SFL has been integrated into many applications to provide CMS/ESS
security services.  For example, the SFL was integrated into a security
plug-in for a commercial e-mail application that enabled the 
application to meet the Bridge Certification Authority Demonstration 
Phase II requirements including implementing ESS features such as
security labels.

The Internet Mail Consortium (IMC) has established an SFL web page
<http://www.imc.org/imc-sfl>.  The IMC has also established an SFL
mail list which is used to: distribute information regarding SFL
releases; discuss SFL-related issues; and provide a means for SFL
users to provide feedback, comments, bug reports, etc.  Subscription
information for the imc-sfl mailing list is at the IMC web site
listed above.

All comments regarding the SFL source code and documents are welcome.  
This SFL release announcement was sent to several mail lists, but 
please send all messages regarding the SFL to the imc-sfl mail list 
ONLY.  Please do not send messages regarding the SFL to any of the IETF 
mail lists.  We will respond to all messages sent to the imc-sfl mail 
list.
-- 
Matthew J. Bertapelle
DigitalNet Government Solution, LLC
www.DigitalNet.com
--------------040801000409060109070908-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDEWkT055748 for ; Thu, 13 Nov 2003 05:14:33 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADDEWXH055747 for ietf-smime-bks; Thu, 13 Nov 2003 05:14:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp.cs.auckland.ac.nz (csmail.cs.auckland.ac.nz [130.216.33.150]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADDETkT055738 for ; Thu, 13 Nov 2003 05:14:31 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by smtp.cs.auckland.ac.nz (Postfix) with ESMTP id D7EB163C15; Fri, 14 Nov 2003 02:14:27 +1300 (NZDT) Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hADDEVT10649; Fri, 14 Nov 2003 02:14:31 +1300 Date: Fri, 14 Nov 2003 02:14:31 +1300 Message-Id: <200311131314.hADDEVT10649@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-smime@imc.org, lloyd@randombit.net Subject: Re: CMS Implementation Questions Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jack Lloyd writes: >1) I'm pretty sure I understand how to nest CMS structures correctly, but the > existing S/MIME examples draft doesn't have any examples of, say, compress > then encrypt then sign. Are there any examples floating around, or, are > there any free implementations of CMS that do this, which I could use to > generate a few tests? (Preferably PEM or raw binary, rather than MIME, but > I'll take what I can get). You can do it with cryptlib, http://www.cs.auckland.ac.nz/~pgut001/cryptlib/, just run the self-tests and it'll dump one of every kind of CMS message you can think of into /tmp (you need to create this directory first if you're running under Windows). If I hadn't deleted them all in a cleanup about 15 minutes ago I'd send you pre-built examples. >2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption > key that was previously distributed to the sender and one or more > recipients." Is there some typical mechanism for choosing this value? > Obviously, as far as the RFC is concerned, one can do pretty much anything > they please, but if there is a simple and commonly used method, I figure I > might as well go with the crowd. Uhh, go to the PKIX archives and read the recent thread. Basically, this doesn't work properly if used with certain PKIX interpretations of keyIdentifiers. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLTkT053489 for ; Thu, 13 Nov 2003 04:21:29 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hADCLTej053488 for ietf-smime-bks; Thu, 13 Nov 2003 04:21:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from centaur.acm.jhu.edu (postfix@centaur.acm.jhu.edu [128.220.223.65]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hADCLSkT053483 for ; Thu, 13 Nov 2003 04:21:28 -0800 (PST) (envelope-from lloyd@randombit.net) Received: by centaur.acm.jhu.edu (Postfix, from userid 528) id A8A563EB45; Thu, 13 Nov 2003 07:21:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by centaur.acm.jhu.edu (Postfix) with ESMTP id A78A346842 for ; Thu, 13 Nov 2003 07:21:27 -0500 (EST) Date: Thu, 13 Nov 2003 07:21:27 -0500 (EST) From: Jack Lloyd X-X-Sender: lloyd@centaur.acm.jhu.edu To: ietf-smime@imc.org Subject: CMS Implementation Questions Message-ID: X-GPG-Key-ID: 4DCDF398 X-GPG-Key-Fingerprint: 2DD2 95F9 C7E3 A15E AF29 80E1 D6A9 A5B9 4DCD F398 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I've been looking over the various CMS RFCs, and have a few questions, most of which probably have obvious and simple answers, but I could use some help. 1) I'm pretty sure I understand how to nest CMS structures correctly, but the existing S/MIME examples draft doesn't have any examples of, say, compress then encrypt then sign. Are there any examples floating around, or, are there any free implementations of CMS that do this, which I could use to generate a few tests? (Preferably PEM or raw binary, rather than MIME, but I'll take what I can get). 2) In section 6.2.3 of RFC 3369, "keyIdentifier identifies the key-encryption key that was previously distributed to the sender and one or more recipients." Is there some typical mechanism for choosing this value? Obviously, as far as the RFC is concerned, one can do pretty much anything they please, but if there is a simple and commonly used method, I figure I might as well go with the crowd. 3) It is legal to include SignedAttributes and sign everything that way even when signing plain data content, correct? 4) Is the encoding of subjectKeyIdentifier in SignerIdentifier and RecipientIdentifier supposed to be with EXPLICIT or IMPLICIT tags? This is not particularly clear to me from the texts of RFCs 2630 and 3369. 5) Is the RC2 key wrap example in RFC 3217 right? For the KEK/IV/LCEKPADICV given there, I get: 03 5E 97 2A B1 5C C4 C9 C4 A0 3D BA A3 5A 21 66 67 E4 3E BC A2 67 46 AE 86 08 DB C8 9E 64 CA 29 for TEMP1. I found a mention of at least one other person who had the same problem, and am wondering if the RFC is incorrect, or if my RC2 code manages to pass ~30 test vectors while still being wrong. Either way, something needs fixing. Any help would be much appreciated. Jack Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGDkT041134 for ; Wed, 12 Nov 2003 12:16:13 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACKGDL5041133 for ietf-smime-bks; Wed, 12 Nov 2003 12:16:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACKGBkT041126; Wed, 12 Nov 2003 12:16:12 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp2.pacifier.net (Postfix) with ESMTP id 354796ADC1; Wed, 12 Nov 2003 12:16:11 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt Date: Wed, 12 Nov 2003 14:18:41 -0600 Message-ID: <004b01c3a95a$2c52f1d0$fd468182@augustcellars.local> 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: <200310201946.PAA22554@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, I have the following comments on the draft: 1. Section 3 examples passed. 2. Section 4 - Passing - 4.1, 4.2, 4.5, 4.7, 4.11 Untested - 4.3, 4.6, 4.8 Comments - 4.4 - Passes but also includes Alice RSA certificate. 4.9 - Body is not from 4.1, body is modified MIME body 4.10 - Actual list is [unknown OID, contentHints, smimeCapablilties, securityLabel, ContentReference, smimeEncryptKeyPreference, mlExpansionHistory, EquivalentLabel] 3. Section 5 - Passing - 5.1, Untested - 5.3, Comments - 5.2 the encoded and decode examples are not the same item 4. 6.0, 7.1, 7.2 passed 5. I would like to keep section 10 from the old document. I found that there were two example 4.4 in the old message thus the difference between my last message where I said that 4.5 did not exist in the binaries and the fact that I tested it in this message. I will get to the rest of the testing later this week. Jim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTpkT032479 for ; Wed, 12 Nov 2003 08:29:51 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hACGTpOW032478 for ietf-smime-bks; Wed, 12 Nov 2003 08:29:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hACGTlkT032454; Wed, 12 Nov 2003 08:29:48 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (dyn070-253.ietf58.ietf.org [130.129.70.253]) by smtp1.pacifier.net (Postfix) with ESMTP id 339B570049; Wed, 12 Nov 2003 08:29:47 -0800 (PST) Reply-To: From: "Jim Schaad" To: Cc: Subject: RE: I-D ACTION:draft-ietf-smime-examples-12.txt Date: Wed, 12 Nov 2003 10:32:18 -0600 Message-ID: <004a01c3a93a$8ad46b00$fd468182@augustcellars.local> 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: <200310201946.PAA22554@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul, There are three problems I have encountered during extracting the document. 1. Example 3.1.bin has a name mismatch 2. Example 3.2.bin has a name mismatch 3. Example 4.5.bin appears to be missing Jim Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gKkT009163 for ; Mon, 10 Nov 2003 19:42:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hAB3gKnC009162 for ietf-smime-bks; Mon, 10 Nov 2003 19:42:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hAB3gIkT009150; Mon, 10 Nov 2003 19:42:19 -0800 (PST) (envelope-from pmhesse@geminisecurity.com) Received: from WJJCUSCLANGSTO1 ([68.101.35.22]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with SMTP id <20031111034205.OWO2297.lakemtao02.cox.net@WJJCUSCLANGSTO1>; Mon, 10 Nov 2003 22:42:05 -0500 Message-ID: <001101c3a805$c5b5ba70$4d2412ac@jjcus.na.jnj.com> From: "Peter Hesse" To: , Subject: request for change in son-of-rfc2633 Date: Mon, 10 Nov 2003 22:41:52 -0500 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01C3A7DB.D5E6B950" 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@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000D_01C3A7DB.D5E6B950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit All, I have recently run into a problem with signed emails not being able to be verified, because of the presence of the word "From" in the first columns of a line of the email message. This email will serve as an example of this potential problem. If your email client sees this message as signed but the signature is invalid, the next paragraph should start with the word "From"--see if it has been modified. >From appearing as the first characters after a blank line will result in some email delivery agents (such as sendmail or exim) escaping the word--"From" is replaced with ">From". The reason for this behavior has to do with the UNIX mbox mail storage file format. The mbox format stores multiple messages in one file, and the messages are separated by the word "From" as the first characters following a blank line. Some mail delivery agents do not have this problem (i.e. Exchange), because they do not store messages in the mbox format. Many do, however, resulting in a modification of the message and the signature being invalidated. I would like to request that this issue be more directly dealt with in son-of-RFC2633. (Currently, it is mentioned in the example MIME-encoded message, but nowhere in the text.) One recommendation might be to borrow from RFC2015 (MIME Security with PGP), which states: Though not required, it is generally a good idea to use Quoted- Printable encoding in the first step (writing out the data to be signed in MIME canonical format) if any of the lines in the data begin with "From ", and encode the "F". This will avoid an MTA inserting a ">" in front of the line, thus invalidating the signature! Perhaps this might even be a SHOULD, although I will ask the group to weigh in on that. Thanks, --Peter ------=_NextPart_000_000D_01C3A7DB.D5E6B950 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIF1zCCAokw ggHyoAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwWzELMAkGA1UEBhMCVVMxKDAmBgNVBAoTH0dlbWlu aSBTZWN1cml0eSBTb2x1dGlvbnMsIEluYy4xIjAgBgNVBAMTGUdTUyBDZXJ0aWZpY2F0ZSBBdXRo b3JpdHkwHhcNMDIwNDI1MjE1NjI3WhcNMDUwMjEyMjE1NjI3WjBbMQswCQYDVQQGEwJVUzEoMCYG A1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAGA1UEAxMZR1NTIENlcnRp ZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAtl3UwxhHyP05YqIF kyfkWt8669gO/VKxC51PhJaV+hb9swwtaMVtJ9k8WjfQLt3fZpaNCNKB7V61KHxY1K1JCP67AwBy W4TRuGRwEb+PXu5XdpNs3kxKtunlR4/WPsrrvuMx9/R/Fx9ld3TUqXCJ/JN7Zg68IappkcMy9S3w koECAwEAAaNdMFswHQYDVR0OBBYEFJpr3UY3Hh5dngW5n9h72/GKMy7GMB8GA1UdIwQYMBaAFJpr 3UY3Hh5dngW5n9h72/GKMy7GMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEB BAUAA4GBAHSd4BGG4le+QZBw/6bCq6mGpr4aJAE7UuXEW/I5YXqlQs1CkAzEHV8UnnXgDd0xONTQ CdznbzCBNAE1EoxL14Kdp5I6omEeNulMd/tGAvxdw0qbbSaT9LolqtnPL2RbnI3j0JsQlncN1+l2 Dzx8Ka39NU4Gb/P6qo/PKa5+YRHSMIIDRjCCAq+gAwIBAgIBCzANBgkqhkiG9w0BAQUFADBbMQsw CQYDVQQGEwJVUzEoMCYGA1UEChMfR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9ucywgSW5jLjEiMCAG A1UEAxMZR1NTIENlcnRpZmljYXRlIEF1dGhvcml0eTAeFw0wMjA4MDUxODIxMTZaFw0wNDA4MDQx ODIxMTZaMIGNMQswCQYDVQQGEwJVUzEnMCUGA1UEChMeR2VtaW5pIFNlY3VyaXR5IFNvbHV0aW9u cyBJbmMuMRQwEgYDVQQLEwtEZXZlbG9wbWVudDEUMBIGA1UEAxMLUGV0ZXIgSGVzc2UxKTAnBgkq hkiG9w0BCQEWGnBtaGVzc2VAZ2VtaW5pc2VjdXJpdHkuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQCvREu1eU1kCNW+lz+ZV9xvljBC7O6iESK10wzKPlrgnhL87+V5/joAbnwsXt25NsmP 8MIY6tuRxCbZzZn3bFTyPerhIOENWrA/HVdIP29TXfHL1YZn7bqBRHyjKcNdYS02GCw4gR4Fr5QS SQzy62WbLcaoSG/wnhBqBesLxZMsOwIDAQABo4HmMIHjMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEB BAQDAgSwMAsGA1UdDwQEAwIE8DAdBgNVHQ4EFgQUG8pDjEsHMZVS4/sJThNbtamIzEswHwYDVR0j BBgwFoAUmmvdRjceHl2eBbmf2Hvb8YozLsYwJQYDVR0RBB4wHIEacG1oZXNzZUBnZW1pbmlzZWN1 cml0eS5jb20wNwYDVR0fBDAwLjAsoCqgKIYmaHR0cDovL3d3dy5nZW1pbmlzZWN1cml0eS5jb20v cm9vdC5jcmwwFgYDVR0gBA8wDTALBgkrBgEEAe8oAQEwDQYJKoZIhvcNAQEFBQADgYEABOIVgnmX 5u4gHHRMsIG5H9WAbMqUeqjhGiFMxDjFXoS2Fkk6eVS6wLJZiS54mWrT1NLA9UOcqfvX8pdpp+pw IpCwK9ywIco4mrqRdJ5Ja7vuxiO0e0J236mWdTQqPXWxZCOYumBtLkqoOcDFQYjuM4ZPLKSbFiMs j1OYuQnyz6cxggHDMIIBvwIBATBgMFsxCzAJBgNVBAYTAlVTMSgwJgYDVQQKEx9HZW1pbmkgU2Vj dXJpdHkgU29sdXRpb25zLCBJbmMuMSIwIAYDVQQDExlHU1MgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 AgELMAkGBSsOAwIaBQCggbowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMDMxMTExMDM0MTUyWjAjBgkqhkiG9w0BCQQxFgQUiwZyw+XEkLYZTGXX7PJ5QjnYr/0wWwYJ KoZIhvcNAQkPMU4wTDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAw BwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYFKw4DAh0wDQYJKoZIhvcNAQEBBQAEgYCfsEWDj+Vi HEn1kAAVx6yfGTkolRIR7uuC0KS1d4zrT1omaUnVTTKET9QBY7QUqdfb2gcvw9pZuRb4bBtYir0W Rfnmfuob1NwKXaPPSv6inoySZ2/j/LR3nHsMd2GWYQFI5Q9LGyhqahQcyEWV/vSe9YSd0yUl9hSS cL3sbEfE6AAAAAAAAA== ------=_NextPart_000_000D_01C3A7DB.D5E6B950-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8KkT045901 for ; Tue, 4 Nov 2003 02:08:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA4A8KKx045900 for ietf-smime-bks; Tue, 4 Nov 2003 02:08:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.33.151]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA4A8GkT045889; Tue, 4 Nov 2003 02:08:17 -0800 (PST) (envelope-from pgut001@cs.auckland.ac.nz) Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id hA4A8Go9028250; Tue, 4 Nov 2003 23:08:16 +1300 Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id hA4ABfi05617; Tue, 4 Nov 2003 23:11:41 +1300 Date: Tue, 4 Nov 2003 23:11:41 +1300 Message-Id: <200311041011.hA4ABfi05617@cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-pkix@imc.org, ietf-smime@imc.org Subject: Re: Request change in son-of-rfc2633 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I wrote: >Mozilla (and no doubt some others that didn't get any publicity) did the same >thing, and I'm sure they didn't get asked to do that by customers. Actually that's not right, I thought Mozilla (or at least some apps that used the Mozilla/Gecko/NSS/whatever code base) were vulnerable because Konqueror was vulnerable, but it turns out that this was Konqueror with khtml rather than with kmozilla, with OpenSSL supplying the crypto. Apologies for the mixup. Before this gets read as "OpenSSL is vulnerable", that isn't the case either. OpenSSL provides application-defined callbacks that can be used to override some checks (used to handle, as one source aptly described it, "the mass of broken certs out there"). Some apps provide callbacks that ignore all errors, which apparently is what happened here. Standard OpenSSL doesn't have this problem. Peter. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qmkT067053 for ; Mon, 3 Nov 2003 20:52:48 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA44qmdF067052 for ietf-smime-bks; Mon, 3 Nov 2003 20:52:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA44qlkT067044 for ; Mon, 3 Nov 2003 20:52:47 -0800 (PST) (envelope-from jimsch@nwlink.com) Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id D62886DD55; Mon, 3 Nov 2003 20:52:41 -0800 (PST) Reply-To: From: "Jim Schaad" To: "'Blake Ramsdell'" , Subject: RE: WG LAST CALL: draft-ietf-smime-rfc2633bis-04 Date: Mon, 3 Nov 2003 20:55:14 -0800 Message-ID: <00db01c3a28f$d5f5baa0$737eadcf@augustcellars.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Blake, I have now finished (almost) this year's work in the winery. Items of agreement are gone. jim > > > > Comments are on the -05 version of the document. > > > > > 11. Section 2.5.2 - where do we document SMimeCapabilities > for RC2? > > Should be a 40-bit vs 128-bit difference between these > which needs an > > ASN.1 structure and encoding. Based on reading of this document I > > could not correctly encode these values. > > I believe that this definition should be in the CMSALG > document (but it's not). Should we bite the bullet and just > stick it in this one? I agree that it needs to be specified > somewhere, but I feel a bit icky about sticking it in here. [JLS] - I agree that the best place is to put it into the CMSALG draft. This falls into the - Yes, but we can't do it. Since SMimeCapabilities is not defined in the CMS document, CMSALG can't reference it. CMSALG must not reference the S/MIME documents. Unless you want Russ to add SMIMECapabilities to CMS and this to CMSALG then it must go into this document however icky. > > > 15. Section 2.7.1.3: Need to be updated to comment on AES. > > I see your point. The intent is to fall back to something > useful for any version of S/MIME, and the older evil US-only > RC2/40 clients. It's not clear what discussion you'd have > about AES here. > > It may be the case that this rule should be removed > completely. Comments? > > Not changed, but needs discussion. [JLS] I think the best thing to do with be an information reference to "For what we use to do look at .... We no longer provide guidence on this because things have changed so much. > > > 20. Section 3.2.2: I would like to get some rewrites on > this section > > as to the purpose of S/MIME type. I think it is JUST to provide > > information about the information (misspelt in the > document) about the > > contained content. It just happens that for display via UAs, the > > distinction between signed and enveloped was consisted to be an > > important part of the content. Additionally, I think this is the > > correct direction for us to tell people about how to define new > > smime-types in the future. > > > > The next question is weither a compressed only message would > > show up in > > my mailbox. I think that the correct smime-type for a > compressed and > > signed message is actually signed-data not compressed data. > > So I think your position is that the smime-type should have > the "most relevant interpretation of the protected data", > instead of the "actual type that is being protected". I > think the best example is an IMAP client getting the headers > and changing the icon next to the message to indicate what > kind of message you've got. > > We can ask the audience, but I think that the conventional > wisdom is that the smime-type represents the type of the > outermost layer, and that's it -- just a further > clarification of the overloaded application/pkcs7-mime. > > Fixed speling of information, but I want to hear more about > how else we should change this to clarify the semantic (and > what the semantic is). [JLS] I have definitely moved to the position that this information is to tell what is inside the message rather than what security has been added to the message.. This is also the position that is held in several different documents (include ESS with receipts). > > > 23. Section 3.4.3.3: Just for giggles, I think that > adding a section > > with the hex encoding of the acutal bytes hashed for this > sample would > > be a good idea. This is one of the things people always > have problems > > with when doing multipart signed data. Also it might be > interesting > > to make the body a multipart/alternative. On the other hand this > > would probably be better in an appendix. > > I think that getting too far with the examples should be left > to the Examples draft and any successors. I do agree that > adding the hex dump would be a good idea. > > My attempt at the hex dump is this, but I need at least one > other person to double check it. > > Updated: > > The content that is digested (the first part of the > multipart/signed) are the bytes: > > 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 > 6c 61 69 6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c > 65 61 72 2d 73 69 67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a > [JLS] I will look at doing this before next week. > > 26. Appendix B: Refernces need to be divided. > > I'm not sure what you mean by "divided"... Normative vs Informational as you have noted elsewhere. > > Blake > Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433jkT063143 for ; Mon, 3 Nov 2003 19:03:45 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id hA433jJb063142 for ietf-smime-bks; Mon, 3 Nov 2003 19:03:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f Received: from brutesquadlabs.com (gtec136-m.isomedia.com [207.115.67.136] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id hA433ikT063135 for ; Mon, 3 Nov 2003 19:03:44 -0800 (PST) (envelope-from blake@brutesquadlabs.com) Received: from DEXTER ([192.168.0.12]) by brutesquadlabs.com with ESMTP ; Mon, 3 Nov 2003 19:03:41 -0800 From: "Blake Ramsdell" To: , Cc: "'Sean P. Turner'" , "'Russ Housley'" Subject: S/MIME Working Group Agenda for the 58th IETF Date: Mon, 3 Nov 2003 19:03:41 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Here is the agenda for the S/MIME working group meeting at IETF 58. Introductions (Blake Ramsdell) Working group status (Blake Ramsdell) CMS and ESS examples update (Paul Hoffman) MSGbis and CERTbis update (Blake Ramsdell) KEM status (Blake Ramsdell) GOST status (Blake Ramsdell) SEED overview (Jongwook Park) Blake -- Blake Ramsdell | Brute Squad Labs | http://www.brutesquadlabs.com