From owner-ietf-smime@mail.imc.org Fri Nov 2 11:52:33 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11336 for ; Fri, 2 Nov 2001 11:52:33 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2GBSe21767 for ietf-smime-bks; Fri, 2 Nov 2001 08:11:28 -0800 (PST) Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2GBR821763; Fri, 2 Nov 2001 08:11:27 -0800 (PST) Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id IAA06121; Fri, 2 Nov 2001 08:11:28 -0800 (PST) Message-Id: <200111021611.IAA06121@fionn.es.net> X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net To: ietf-pkix@imc.org, ietf-smime@imc.org Reply-to: helm@fionn.es.net Subject: EmailAddress history question Date: Fri, 02 Nov 2001 08:11:28 -0800 From: Michael Helm Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL From owner-ietf-smime@mail.imc.org Fri Nov 2 13:47:03 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14823 for ; Fri, 2 Nov 2001 13:47:03 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA2I7Ct06117 for ietf-smime-bks; Fri, 2 Nov 2001 10:07:12 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2I7A806112; Fri, 2 Nov 2001 10:07:11 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA27052; Fri, 2 Nov 2001 13:06:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200111021611.IAA06121@fionn.es.net> References: <200111021611.IAA06121@fionn.es.net> Date: Fri, 2 Nov 2001 13:05:57 -0500 To: helm@fionn.es.net From: Stephen Kent Subject: Re: EmailAddress history question Cc: ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:11 AM -0800 11/2/01, Michael Helm wrote: >Once upon a time , email addresses, especially "internet" or >rfc822 addresses, were a common component in X.509 subject names. >But a few years ago they became a deprecated component in PKIX >(RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have >language like this in their respective RFC's: > > The email address SHOULD be in > the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject > distinguished name. > [RFC 2632 sec 3] > >Could someone explain why this happened? I remember the process >at the time... but vaguely. Looking thru old notes & the mail >archives &c led me to a couple of possible explanations: Mike, An e-mail address makes for a good name, but it has its own type, as an alt subject name. An e-mail address is not an appropriate RDN, i.e., people do not construct directory schema in which an e-mail address is a qualifier for a person's directory entry. the e-mail address is an OK directory attribute, but just not an appropriate component of a DN. The convention that arose for embedding an e-mail address in a DN was a short-term fix that has unfortunate implications when considered in a larger context. Thus the PKIX standards deprecate it. Steve From owner-ietf-smime@mail.imc.org Fri Nov 2 14:39:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16241 for ; Fri, 2 Nov 2001 14:39:14 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2J6gb09330 for ietf-smime-bks; Fri, 2 Nov 2001 11:06:42 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2J6e809321; Fri, 2 Nov 2001 11:06:41 -0800 (PST) Received: from arport (t2o69p79.telia.com [62.20.144.199]) by maile.telia.com (8.11.6/8.11.6) with SMTP id fA2J6V928503; Fri, 2 Nov 2001 20:06:31 +0100 (CET) Message-ID: <002901c163d1$9ec04540$0500a8c0@arport> From: "Anders Rundgren" To: , , References: <200111021611.IAA06121@fionn.es.net> Subject: Re: EmailAddress history question Date: Fri, 2 Nov 2001 20:07:28 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0024_01C163D9.FF7930B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C163D9.FF7930B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Michael, The story is that rfc822 addresses in the Subject Field become deprecated for reasons like not fitting into a directory-oriented scheme. PKI-Politics++ The interesting part is that practically no *practitioners* care about this deprecation as this use is the "de-facto" standard. Not even VeriSign care (check their personal e-mail certs as found in this signed mail if you want to confirm this), in spite of being active in the authoring of 2459! I'm pretty sure that this will not change as the problem by having e-mail addresses in the subject field is *unknown* by the majority of certificate issuers. My guess is that you run into *less* problems by using the de-facto standard as there are probably quite a few systems out there ("inferior" but anyway), that don't bother with SubjectAltName. To use duplicate data as 2459 suggests seems like a political thing (follow the "true" and "de-facto" standard at the same time), rather than an example of good engineering. As a conforming PKIX/SMIME-app MUST interpret the "de-facto" standard there are no problems at all by using it. The "deprecation" will BTW have no effect as no SW engineer in his right mind, will ever remove support for the current practice as it is likely to just lead to complaints. Personally I don't think SubjectAltName has any value at all in the long-run, as it just adds confusion (i.e. multiple places to look for identity information). An ID-certificate does typically only need to contain a CN and some unique identity tag and an e-mail address is such an option. OID.2.5.4.5 is another. Once upon a time the idea was that a certificate should contain your entire personal profile but that's got totally out of style since the advent of on-line operation, and then the Subject field continues to be completely satisfactory as the *only* container of identity data. PKI-Politics-- Anders ----- Original Message ----- From: "Michael Helm" To: ; Sent: Friday, November 02, 2001 17:11 Subject: EmailAddress history question Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL ------=_NextPart_000_0024_01C163D9.FF7930B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQSDCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAw0wggK3oAMCAQICCmFWt1cAAgAAAHAwDQYJKoZIhvcNAQEFBQAwgYsxKDAmBgkqhkiG9w0B CQEWGWFuZGVycy5ydW5kZ3JlbkB0ZWxpYS5jb20xCzAJBgNVBAYTAlNFMRAwDgYDVQQHEwdVcHBz YWxhMQ8wDQYDVQQKEwZYLVNpZ24xLzAtBgNVBAMTJlgtU2lnbiBQZXJzb25hbCBFbGVjdHJvbmlj IEtleSBUZXN0LUNBMB4XDTAxMDQwNDA4NTczMFoXDTAyMDQwNDA5MDczMFowczEoMCYGCSqGSIb3 DQEJARYZYW5kZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1Vw cHNhbGExDzANBgNVBAoTBlgtU2lnbjEXMBUGA1UEAxMOQVIgU01JTUUgVEVMSUEwXDANBgkqhkiG 9w0BAQEFAANLADBIAkEAlFB6o+q3ZuHlC2YNnVMnuTTnncmxoyLEazY3SwxY2gE+4AO6LZrBMR1N 074mu/MxMwgzB5IpeCiBILtXIbfafwIDAQABo4IBEjCCAQ4wDgYDVR0PAQH/BAQDAgTwMBMGA1Ud JQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBSCN7msYKhh36djrN0b61Q3yIY7vzCBxwYDVR0jBIG/ MIG8gBQmBkGTiydxP9r5cSoaPxRdzJrARqGBkaSBjjCBizEoMCYGCSqGSIb3DQEJARYZYW5kZXJz LnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGExDzANBgNV BAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5IFRlc3Qt Q0GCEHgYPc/vd9C1ROt6RgVIkm4wDQYJKoZIhvcNAQEFBQADQQCn87bztp9xv5jMp1l9pJd4UJun 5SVjKvtZDPf36TUJ4wxA3KyJHY05Zi0+U4mqnWuXg1R3g45Y1eG/Za1j0sJRMIIDHjCCAsigAwIB AgIQeBg9z+930LVE63pGBUiSbjANBgkqhkiG9w0BAQUFADCBizEoMCYGCSqGSIb3DQEJARYZYW5k ZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGExDzAN BgNVBAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5IFRl c3QtQ0EwHhcNMDAwMzA4MjI0NjA3WhcNMDYwMzIyMTg0OTM4WjCBizEoMCYGCSqGSIb3DQEJARYZ YW5kZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGEx DzANBgNVBAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5 IFRlc3QtQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAyjzzgYvBhX+zmm6v5aMcXpKTCizrdn5R qJUKoknFYGPnanr2PUv8qpFr+vSO+N42Wun3G2cHrnxRsKGM+EYjGwIDAQABo4IBBDCCAQAwCwYD VR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFCYGQZOLJ3E/2vlxKho/FF3MmsBG MIGuBgNVHR8EgaYwgaMwUqBQoE6GTC1odHRwOi8vYXJwb3J0L0NlcnRFbnJvbGwvWC1TaWduJTIw UGVyc29uYWwlMjBFbGVjdHJvbmljJTIwS2V5JTIwVGVzdC1DQS5jcmwwTaBLoEmGRy1maWxlOi8v XFxhcnBvcnRcQ2VydEVucm9sbFxYLVNpZ24gUGVyc29uYWwgRWxlY3Ryb25pYyBLZXkgVGVzdC1D QS5jcmwvMBAGCSsGAQQBgjcVAQQDAgECMA0GCSqGSIb3DQEBBQUAA0EAHI/iB30qaHfi9n6AEmx7 agQG425D6ttndvNPuC32lonYCEJ5YQM/NcpiVXGJtQpOKVwCNnfrpObb9Plqa0z1qDCCA2IwggLL oAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVm LixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRC q8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP8 4GW6p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+ MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmww CwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4 oLje6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulb Larh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr 51a+i+P7FTCCBGswggPUoAMCAQICEG6mb61fMt78LqBdUcww9q4wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVm LixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDExMTAyMDAwMDAwWhcNMDIwMTAx MjM1OTU5WjCCAQ8xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxJzAlBgNVBAsTHkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdDEYMBYGA1UEAxQPQW5k ZXJzIFJ1bmRncmVuMSgwJgYJKoZIhvcNAQkBFhlhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4A40wKMrx/CmNhdJ/sySglgM522w9J/rf8PLn0LiK adedf7IAuJn6UMZJleTcphWZx9Rvlxj30KHzYJZ2NEcilRkv1YqjS06HdecNTPPftJGurM1ZOklj GkIHP0+uGQpKGkTMNRf4fIDWvhf1kHBY9F34QsMO2HFBUkIltH5k4wIDAQABo4IBBjCCAQIwCQYD VR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMu MAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAJkBDijSmThoLYBWQ d+5LkhnvYQv92bFEU965Tf66sxAEvTM2JRkPHDiksl06oifXlqtLuyV71eFoTi8cZJ5lh37BBXkb RlNyChk0N7+0uQ6z1fyMpRvtZ8FVmli5Dl09eyOkezoatjPgSjl+F8ONC0dpXlPJnuRZQWsN9PFu WmwxggL0MIIC8AIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENs YXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQbqZv rV8y3vwuoF1RzDD2rjAJBgUrDgMCGgUAoIIBaDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMTExMDIxOTA3MjhaMCMGCSqGSIb3DQEJBDEWBBT0piMOAY8QU3VWb2nx z0IQXBfUgjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGLMSgwJgYJKoZIhvcNAQkBFhlhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tMQswCQYD VQQGEwJTRTEQMA4GA1UEBxMHVXBwc2FsYTEPMA0GA1UEChMGWC1TaWduMS8wLQYDVQQDEyZYLVNp Z24gUGVyc29uYWwgRWxlY3Ryb25pYyBLZXkgVGVzdC1DQQIKYVa3VwACAAAAcDANBgkqhkiG9w0B AQEFAASBgH8ysjna1pwTcYuEBsBujOGoTZkYgnyQR15Wu8bTgpSTZWyiaCPiFPCu65YbZt2nQAmN GOQ1DZRTBmqorauUxv5clcjYPfxXt47mBxRvt7uvunokNGkh99WOmY5iU1WEnA7I1EeObj0FwedN vZCwScd2Zp9CiVYR5Rgl6esK+f/dAAAAAAAA ------=_NextPart_000_0024_01C163D9.FF7930B0-- From owner-ietf-smime@mail.imc.org Mon Nov 5 05:05:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10284 for ; Mon, 5 Nov 2001 05:05:08 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA59Wix00463 for ietf-smime-bks; Mon, 5 Nov 2001 01:32:44 -0800 (PST) Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA59G3826791; Mon, 5 Nov 2001 01:16:04 -0800 (PST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 15:16:41 +0530 Message-ID: From: "RAGHAVENDRAN H. (SSG) - CTD, Chennai." To: ietf-pkix@imc.org, ietf-smime@imc.org Cc: Anders Rundgren Subject: RE: EmailAddress history question Date: Mon, 5 Nov 2001 14:44:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi List: My view on this is subjectAltName is a good thing. I know this has been an issue for quite some time, but as a programmer I find the concept of putting an email in the DN "obscene". I tend to agree with Steve's posting on this. Email addresses are now being used to uniquely identify persons. In future, it may be IPv6 addresses and still further in the future... who knows. subjectAltName provides a convenient, future-proof way of implementing this instead of "cluttering" your DN. My 2 cents.. Regards, Raghav -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Saturday, November 03, 2001 12:37 AM To: helm@fionn.es.net; ietf-pkix@imc.org; ietf-smime@imc.org Subject: Re: EmailAddress history question Michael, The story is that rfc822 addresses in the Subject Field become deprecated for reasons like not fitting into a directory-oriented scheme. PKI-Politics++ The interesting part is that practically no *practitioners* care about this deprecation as this use is the "de-facto" standard. Not even VeriSign care (check their personal e-mail certs as found in this signed mail if you want to confirm this), in spite of being active in the authoring of 2459! I'm pretty sure that this will not change as the problem by having e-mail addresses in the subject field is *unknown* by the majority of certificate issuers. My guess is that you run into *less* problems by using the de-facto standard as there are probably quite a few systems out there ("inferior" but anyway), that don't bother with SubjectAltName. To use duplicate data as 2459 suggests seems like a political thing (follow the "true" and "de-facto" standard at the same time), rather than an example of good engineering. As a conforming PKIX/SMIME-app MUST interpret the "de-facto" standard there are no problems at all by using it. The "deprecation" will BTW have no effect as no SW engineer in his right mind, will ever remove support for the current practice as it is likely to just lead to complaints. Personally I don't think SubjectAltName has any value at all in the long-run, as it just adds confusion (i.e. multiple places to look for identity information). An ID-certificate does typically only need to contain a CN and some unique identity tag and an e-mail address is such an option. OID.2.5.4.5 is another. Once upon a time the idea was that a certificate should contain your entire personal profile but that's got totally out of style since the advent of on-line operation, and then the Subject field continues to be completely satisfactory as the *only* container of identity data. PKI-Politics-- Anders ----- Original Message ----- From: "Michael Helm" To: ; Sent: Friday, November 02, 2001 17:11 Subject: EmailAddress history question Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL *********************************************************************** Disclaimer: This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. *********************************************************************** From owner-ietf-smime@mail.imc.org Mon Nov 5 07:46:38 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13381 for ; Mon, 5 Nov 2001 07:46:37 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5CIHq15930 for ietf-smime-bks; Mon, 5 Nov 2001 04:18:17 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5CAf815328; Mon, 5 Nov 2001 04:10:41 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA400738; Mon, 5 Nov 2001 07:07:59 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA5CAX793932; Mon, 5 Nov 2001 07:10:33 -0500 Importance: Normal Subject: RE: EmailAddress history question To: "RAGHAVENDRAN H. (SSG) - CTD, Chennai." Cc: ietf-pkix@imc.org, ietf-smime@imc.org, Anders Rundgren X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Mon, 5 Nov 2001 07:10:47 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #s MIAS4UTJ8H JPOS4U8UWQ CMCY4QLP6R |August 29, 2001) at 11/05/2001 07:10:33 AM 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: In this post, I will attempt to avoid personalities and offensive characterizations of views differing from my own. First, the case for banning e-mail addresses from DN's is different between DN's in which at least one personal name attribute (Surname, GivenName, or CommonName) is present is much stronger than the case for banning them from DN's in which no personal name attributes are present. Second, AFAIK the usual motivation for adding e-mail addresses to DN's is to enable directory search by that attribute - neither obscenity nor ignorance have anything to do with it. It is my opinion that rather than deprecating the use of emailAddress in the subject name what should be deprecated is the use of emailAddress in a subject name in which any of the personal name attributes are present. I am aware that this would involve a change to wording inherited from RFC 2459. Tom Gindin "RAGHAVENDRAN H. (SSG) - CTD, Chennai." @mail.imc.org on 11/05/2001 04:14:03 AM Sent by: owner-ietf-pkix@mail.imc.org To: ietf-pkix@imc.org, ietf-smime@imc.org cc: Anders Rundgren Subject: RE: EmailAddress history question Hi List: My view on this is subjectAltName is a good thing. I know this has been an issue for quite some time, but as a programmer I find the concept of putting an email in the DN "obscene". I tend to agree with Steve's posting on this. Email addresses are now being used to uniquely identify persons. In future, it may be IPv6 addresses and still further in the future... who knows. subjectAltName provides a convenient, future-proof way of implementing this instead of "cluttering" your DN. My 2 cents.. Regards, Raghav (snip) From owner-ietf-smime@mail.imc.org Mon Nov 5 08:37:09 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16406 for ; Mon, 5 Nov 2001 08:37:09 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA5D8fa17566 for ietf-smime-bks; Mon, 5 Nov 2001 05:08:41 -0800 (PST) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5D8e817562; Mon, 5 Nov 2001 05:08:40 -0800 (PST) Received: from arport ([212.181.94.147]) by mailb.telia.com (8.11.6/8.11.6) with SMTP id fA5D8d027377; Mon, 5 Nov 2001 14:08:39 +0100 (CET) Message-ID: <00d501c165fb$1d6b9130$0500a8c0@arport> From: "Anders Rundgren" To: , References: Subject: Re: EmailAddress history question Date: Mon, 5 Nov 2001 14:09:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit All, I have no interests in maintaining a debate that leads nowhere. I have simply concluded that the *market* in the form of VeriSign (e-mail certs), Microsoft (CertServ) and lots of more obscure players have opted to [silently] disregard the 2459 in *this* particular case. IMHO the weight of that should have made an impression in son-of-2459. Case closed. We can now all happily go back to our current "best practices" or "favorite deprecations"! :-) Anders From owner-ietf-smime@mail.imc.org Tue Nov 6 08:07:59 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07957 for ; Tue, 6 Nov 2001 08:07:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6CHCq06756 for ietf-smime-bks; Tue, 6 Nov 2001 04:17:12 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6CHB806748 for ; Tue, 6 Nov 2001 04:17:11 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07310; Tue, 6 Nov 2001 07:17:09 -0500 (EST) Message-Id: <200111061217.HAA07310@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-07.txt Date: Tue, 06 Nov 2001 07:17:08 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-07.txt Pages : 8 Date : 05-Nov-01 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011105132420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011105132420.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Tue Nov 6 15:35:58 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02467 for ; Tue, 6 Nov 2001 15:35:58 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6K0HN06958 for ietf-smime-bks; Tue, 6 Nov 2001 12:00:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6K0F806953 for ; Tue, 6 Nov 2001 12:00:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00829; Tue, 6 Nov 2001 15:00:14 -0500 (EST) Message-Id: <200111062000.PAA00829@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Securing X.400 Content with S/MIME to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 06 Nov 2001 15:00:14 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o Securing X.400 Content with S/MIME o Transporting S/MIME Objects in X.400 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 20, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-04.txt http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-04.txt From owner-ietf-smime@mail.imc.org Thu Nov 8 17:26:47 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10113 for ; Thu, 8 Nov 2001 17:26:46 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fA8LkHo18603 for ietf-smime-bks; Thu, 8 Nov 2001 13:46:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8LkG818599 for ; Thu, 8 Nov 2001 13:46:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08784; Thu, 8 Nov 2001 16:46:15 -0500 (EST) Message-Id: <200111082146.QAA08784@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Cryptographic Message Syntax to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 08 Nov 2001 16:46:15 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider the following as Proposed Standards: o Cryptographic Message Syntax o Cryptographic Message Syntax (CMS) Algorithms The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 21, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-05.txt http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-06.txt From owner-ietf-smime@mail.imc.org Mon Nov 19 10:28:14 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04152 for ; Mon, 19 Nov 2001 10:28:13 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJEsik27911 for ietf-smime-bks; Mon, 19 Nov 2001 06:54:44 -0800 (PST) Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAJEsg827906 for ; Mon, 19 Nov 2001 06:54:43 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Nov 2001 14:55:18 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA05013 for ; Mon, 19 Nov 2001 09:54:43 -0500 (EST) Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fAJEsfm08273 for ; Mon, 19 Nov 2001 09:54:42 -0500 (EST) Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 14:54:44 -0000 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.99]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DRFHAS; Mon, 19 Nov 2001 09:54:17 -0500 Message-Id: <5.0.1.4.2.20011119080753.0256f700@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 19 Nov 2001 08:09:12 -0500 To: ietf-smime@imc.org From: "Housley, Russ" Subject: Salt Lake City Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Working Group: I am starting to put together the agenda for our session in Salt Lake City. Please send me a message if you would like to make a presentation. Russ From owner-ietf-smime@mail.imc.org Mon Nov 19 15:30:32 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23202 for ; Mon, 19 Nov 2001 15:30:32 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJJl6H18872 for ietf-smime-bks; Mon, 19 Nov 2001 11:47:06 -0800 (PST) Received: from mail01g.rapidsite.net (mail01g.rapidsite.net [207.158.192.232]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAJJl5818866 for ; Mon, 19 Nov 2001 11:47:05 -0800 (PST) Received: from www.blkk.com (209.130.71.190) by mail01g.rapidsite.net (RS ver 1.0.60s) with SMTP id 07762958 for ; Mon, 19 Nov 2001 14:47:17 -0500 (EST) From: "Ben Littauer" To: Subject: Seeking Blake Ramsdell Date: Mon, 19 Nov 2001 14:44:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C17108.BAF54DC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 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_0004_01C17108.BAF54DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The address I have for Blake, blaker@tumbleweed.com, appears to be bouncing. If anyone knows current contact info, I woul dbe much obliged... -ben- Ben Littauer 1 Moon Hill Road Lexington, MA 02421 781-862-8784 fax: 810-963-6163 littauer@blkk.com http://www.blkk.com ------=_NextPart_000_0004_01C17108.BAF54DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The address I have for Blake, blaker@tumbleweed.com, appears = to be=20 bouncing.  If anyone knows current contact info, I woul dbe much=20 obliged...
 
-ben-
Ben Littauer
1=20 Moon Hill Road
Lexington, MA=20 02421
781-862-8784 =
fax: 810-963-6163
littauer@blkk.com
http://www.blkk.com =
------=_NextPart_000_0004_01C17108.BAF54DC0-- From owner-ietf-smime@mail.imc.org Mon Nov 26 17:26:57 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07239 for ; Mon, 26 Nov 2001 17:26:57 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fAQLWI305899 for ietf-smime-bks; Mon, 26 Nov 2001 13:32:18 -0800 (PST) Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAQLWF805895 for ; Mon, 26 Nov 2001 13:32:16 -0800 (PST) Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Nov 2001 21:32:09 UT Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id fAQLaMq15605 for ; Tue, 27 Nov 2001 07:36:23 +1000 (EST) Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 08:29:28 +1100 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.123]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DR2TFW; Mon, 26 Nov 2001 16:31:44 -0500 Message-Id: <5.0.1.4.2.20011126162823.02c942d0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 26 Nov 2001 16:30:58 -0500 To: ietf-smime@imc.org From: "Housley, Russ" Subject: Draft Agenda for Salt Lake City Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Attached is the draft agenda for the S/MIME WG session in Salt Lake City. I believe that I have given everyone a time slot that asked for one. Please contact me immediately if you would like a slot, but you do not appear on the agenda below. Russ = = = = = = = = = = = Introductions Russ Housley Working Group Status Russ Housley CMS Update Status Russ Housley Interoperability Matrix Jim Schaad CMS and ESS Examples Paul Hoffman AES and RSA-OAEP Jim Schaad Intended Recipient Attribute Russ Housley & Jim Schaad Policy Requirements for TSAs Denis Pinkas Wrap up Russ Housley From owner-ietf-smime@mail.imc.org Wed Nov 28 06:40:24 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01173 for ; Wed, 28 Nov 2001 06:40:24 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASB0JT01485 for ietf-smime-bks; Wed, 28 Nov 2001 03:00:19 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASB0H801481 for ; Wed, 28 Nov 2001 03:00:17 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29271; Wed, 28 Nov 2001 06:00:13 -0500 (EST) Message-Id: <200111281100.GAA29271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-aes-alg-03.txt Date: Wed, 28 Nov 2001 06:00:13 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS Author(s) : J. Schaad, R. Housley Filename : draft-ietf-smime-aes-alg-03.txt Pages : 15 Date : 27-Nov-01 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption and the RSAES-OAEP key transport method [PKCS#1v2.0] for key management with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-aes-alg-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-aes-alg-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127135724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127135724.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@mail.imc.org Wed Nov 28 18:09:46 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22905 for ; Wed, 28 Nov 2001 18:09:45 -0500 (EST) Received: by above.proper.com (8.11.6/8.11.3) id fASMPOI20077 for ietf-smime-bks; Wed, 28 Nov 2001 14:25:24 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMPN820071 for ; Wed, 28 Nov 2001 14:25:23 -0800 (PST) Received: by sentry.gw.tislabs.com; id RAA09333; Wed, 28 Nov 2001 17:30:24 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma009310; Wed, 28 Nov 01 17:29:29 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fASMOT814593 for ietf-smime@imc.org; Wed, 28 Nov 2001 17:24:29 -0500 (EST) Date: Wed, 28 Nov 2001 17:24:29 -0500 (EST) Message-Id: <200111282224.fASMOT814593@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-smime@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-smime@mail.imc.org Fri Nov 30 15:24:50 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04346 for ; Fri, 30 Nov 2001 15:24:49 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAUJjGS17543 for ietf-smime-bks; Fri, 30 Nov 2001 11:45:16 -0800 (PST) Received: from wfhqex03.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJjE817538; Fri, 30 Nov 2001 11:45:14 -0800 (PST) Received: by wfhqex03.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 13:58:44 -0500 Message-ID: <0B95FB5619B3D411817E006008A59259B52080@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v2.0 S/MIME Freeware Library (SFL) Now Available Date: Fri, 30 Nov 2001 13:58:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C179D1.016E5BE0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C179D1.016E5BE0 Content-Type: text/plain; charset="iso-8859-1" All, Getronics Government Solutions has delivered Version 2.0 of the S/MIME Freeware Library (SFL) source code. The SFL source code files are freely available at . The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) security protocol to support the digital signature and encryption of data. It also implements RFC 2634 Enhanced Security Services (ESS) including signed receipts, security labels, secure mail list information, and signing certificate attributes. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. 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 NT/98/2000, Linux and Sun Solaris 2.7 operating systems. Further enhancements of the SFL are still in process. Further releases 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 v4.2 and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.0 SFL uses the v1.3 R7 Enhanced SNACC ASN.1 C++ Library to encode/decode objects. The v2.0 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ 2 CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library; 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.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (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 2630, 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 all of 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.0 SFL is described in the v2.0 SFL Application Programming Interface (API) and v2.0 SDD documents. The v2.0 SMP Components Setup Manual that describes the component installation procedures for the v2.0 SFL, v2.0 Certificate Management Library (CML), and v1.3 R7 Enhanced SNACC libraries. The use of the v2.0 CTIL API is described in the v2.0 CTIL API document. The following enhancements are included in the v2.0 SFL and CTIL releases (compared with the v1.10 releases): 1) Moved common code in LibCert associated with using the CTIL API into a new CTILManager library. Changed SFL to call new CTILManager library instead of LibCert to obtain CTIL-related services. 2) Developed MS CAPI CTIL to provide access to these crypto algorithms provided by MS CAPI v2.0: Triple-DES and RC2 for encryption/decryption; RSA for key management; SHA-1 and MD5 for hashing; DSA and RSA for signature generation/verification. Tested SFL with MS CAPI CTIL using MS CAPI v2.0 with the MS Cryptographic Service Provider (CSP). Tested MS CAPI CTIL using MS CAPI v2.0 with the DataKey CSP and smart card. 3) Enhanced SFL and CTILs to maximize thread-safety. Enhanced the CTILs to be single-threaded in case a user attempts to share a single login. 4) Enhanced SFL to call v2.0 CML to decode certificates, Certificate Revocation Lists, and components thereof. v2.0 SFL API: The v2.0 SFL and CTILs provide the identical APIs as provided by the v1.10 SFL and CTILs except that the SFL and CTIL symbols are each contained in their own namespace (see below). Also, the CSM_OID and CSMIME classes are provided by the v1.3 R7 Enhanced SNACC C++ ASN.1 Library AsnOid class (updated to include CSM_OID, but unchanged from the Enhanced SNACC point of view). Namespace: The v2.0 libraries use the "namespace" feature. The symbols for each library are contained in its own namespace: SFL, CERT, CTIL, SNACC, acl, CML. The namespace feature allows the compiler to isolate the symbols for each library. This enhancement causes a minor impact to the source code developed to use the libraries. The integrator will need to add a few lines of code to each source code file (or, possibly, in an include file) stating that the appropriate namespaces are being used such as: "using namespace SFL;". We are still in the process of enhancing the SFL. Future releases may include: new features of updated S/MIME specifications (such as compression, password-protected RecipientInfo, etc); "Certificate Management Messages over CMS" ASN.1 encode/decode functions; bug fixes; and support for other crypto APIs. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.7, we may port the SFL to other operating systems. The following SFL files are available from : 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) smimeR2.0.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for SFL Hi-Level library. 3) snacc13r7rn.tar.gz (source code and binaries available from Getronics Enhanced SNACC web page: ): Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library that has been enhanced by Getronics to implement the Distinguished Encoding Rules. Source code is compilable for Linux, Solaris 2.7 and MS Windows NT/95/98/2000. This file includes a sample test project demonstrating the use of the SNACC classes. 4) smCTIR2.0.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ 2, PKCS #11 and Microsoft CAPI v2.0. The CTIL source code includes PKCS #12 software developed by the OpenSSL Project for use in the OpenSSL Toolkit 5) smLibCR2.0.tar.gz: Source code, MS Windows NT/98/2000 project files and Unix makefiles for the CTILManager library that provides CTIL-related processing services used by the SFL, ACL and CML. 6) smTest2.0.tar.gz: Source code, MS Windows NT/98/2000 project files and Unix makefiles for test drivers used to test the SFL. This file also includes sample CMS/ESS test data and test X.509 Certificates. This file also includes the CertificateBuilder test utility that can be used to create X.509 Certificates that each include a DSA or RSA public key. 7) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. 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. Getronics 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 Enhanced SNACC ASN.1 Library to encode/decode X.509 certificates, attribute certificates, Certificate Revocation Lists, 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 at: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by Getronics) at . Getronics 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. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== ------_=_NextPart_001_01C179D1.016E5BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable v2.0 S/MIME Freeware Library (SFL) Now Available

All,

Getronics Government Solutions has delivered Version = 2.0 of the
S/MIME Freeware Library (SFL) source code.  The = SFL source code files
are freely available at <http://www.getronicsgov.com/hot/sfl_home.htm>.&= nbsp;  

The SFL implements the IETF S/MIME v3 RFC 2630 = Cryptographic Message
Syntax (CMS) security protocol to support the = digital signature and
encryption of data.  It also implements RFC = 2634 Enhanced Security
Services (ESS) including signed receipts, security = labels, secure mail
list information, and signing certificate = attributes.  It also
implements portions of the RFC 2633 Message = Specification and RFC 2632
Certificate Handling document.  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 = NT/98/2000, Linux
and Sun Solaris 2.7 operating systems.  Further = enhancements of the SFL
are still in process.  Further releases 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 v4.2
and Crypto++ libraries; and Fortezza suite of = algorithms provided by
the Fortezza Crypto Card.  The v2.0 SFL uses = the v1.3 R7 Enhanced SNACC
ASN.1 C++ Library to encode/decode objects. The v2.0 = SFL release includes:
SFL High-level library; Free (a.k.a. Crypto++) = Crypto Token Interface
Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ 2 = CTIL; PKCS #11 CTIL;
Microsoft CAPI v2.0 CTIL; v1.3 R7 Enhanced SNACC = ASN.1 Compiler and Library;
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.7.  =

The SFL has been successfully used to exchange = signedData and envelopedData
messages with the Microsoft (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 2630, 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
all of 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.0 SFL is described in the v2.0 SFL = Application
Programming Interface (API) and v2.0 SDD = documents.  The v2.0 SMP
Components Setup Manual that describes the component = installation
procedures for the v2.0 SFL, v2.0 Certificate = Management Library (CML),
and v1.3 R7 Enhanced SNACC libraries.  The use = of the v2.0 CTIL API is
described in the v2.0 CTIL API document.

The following enhancements are included in the v2.0 = SFL and CTIL releases
(compared with the v1.10 releases):

1) Moved common code in LibCert associated with using = the CTIL API into
a new CTILManager library. Changed SFL to call new = CTILManager library
instead of LibCert to obtain CTIL-related = services.  

2) Developed MS CAPI CTIL to provide access to these = crypto algorithms
provided by MS CAPI v2.0: Triple-DES and RC2 for = encryption/decryption;
RSA for key management; SHA-1 and MD5 for hashing; = DSA and RSA for
signature generation/verification.  Tested SFL = with MS CAPI CTIL using
MS CAPI v2.0 with the MS Cryptographic Service = Provider (CSP).  Tested
MS CAPI CTIL using MS CAPI v2.0 with the DataKey CSP = and smart card. 

3) Enhanced SFL and CTILs to maximize = thread-safety.  Enhanced the CTILs
to be single-threaded in case a user attempts to = share a single login. 

4) Enhanced SFL to call v2.0 CML to decode = certificates, Certificate
Revocation Lists, and components thereof.  =


v2.0 SFL API: The v2.0 SFL and CTILs provide the = identical APIs as
provided by the v1.10 SFL and CTILs except that the = SFL and CTIL symbols
are each contained in their own namespace (see = below).  Also, the CSM_OID
and CSMIME classes are provided by the v1.3 R7 = Enhanced SNACC C++ ASN.1
Library AsnOid class (updated to include CSM_OID, = but unchanged from the
Enhanced SNACC point of view).

Namespace: The v2.0 libraries use the = "namespace" feature.  The symbols for
each library are contained in its own = namespace:  SFL, CERT, CTIL, SNACC,
acl, CML.  The namespace feature allows the = compiler to isolate the symbols
for each library. This enhancement causes a minor = impact to the source code
developed to use the libraries.  The integrator = will need to add a few
lines of code to each source code file (or, = possibly, in an include file)
stating that the appropriate namespaces are being = used such as:
"using namespace SFL;".

We are still in the process of enhancing the = SFL.  Future releases may
include: new features of updated S/MIME = specifications (such as
compression, password-protected RecipientInfo, etc); = "Certificate
Management Messages over CMS" ASN.1 = encode/decode functions; bug fixes;
and support for other crypto APIs.  The SFL is = developed to maximize
portability to 32-bit operating systems.  In = addition to testing on
MS Windows, Linux and Solaris 2.7, we may port the = SFL to other
operating systems.


The following SFL files are available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>:

1) SFL Documents: Fact Sheet, Software Design = Description, API, CTIL
API, Software Test Description, Implementers Guide, = Overview Briefing and
Public License.    

2) smimeR2.0.tar.gz:  Source code, MS Windows = NT/95/98/2000 project files
and Unix makefiles for SFL Hi-Level library.

3) snacc13r7rn.tar.gz (source code and binaries = available from Getronics
Enhanced SNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>= ):
Source code, MS Windows NT/95/98/2000 project files = and Unix makefiles for
v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library = that has been enhanced by
Getronics to implement the Distinguished Encoding = Rules.  Source code is
compilable for Linux, Solaris 2.7 and MS Windows = NT/95/98/2000. This
file includes a sample test project demonstrating = the use of the SNACC
classes. 

4) smCTIR2.0.tar.gz:  Source code, MS Windows = NT/95/98/2000 project files
and Unix makefiles for the following CTILs: Test (no = crypto), Crypto++,
BSAFE, Fortezza, SPEX/ 2, PKCS #11 and Microsoft = CAPI v2.0.  The CTIL
source code includes PKCS #12 software developed by = the OpenSSL Project
for use in the OpenSSL Toolkit <http://www.openssl.org/>

5) smLibCR2.0.tar.gz: Source code, MS Windows = NT/98/2000 project files and
Unix makefiles for the CTILManager library that = provides CTIL-related
processing services used by the SFL, ACL and = CML.

6) smTest2.0.tar.gz: Source code, MS Windows = NT/98/2000 project files and
Unix makefiles for test drivers used to test the = SFL.  This file also
includes sample CMS/ESS test data and test X.509 = Certificates.  This file
also includes the CertificateBuilder test utility = that can be used to
create X.509 Certificates that each include a DSA or = RSA public key. 

7) csmime.mdl contains SFL Class diagrams created = using Microsoft
Visual Modeler (comes with MS Visual Studio 6.0, = Enterprise Tools).
The file can also be viewed using Rational Rose C++ = Demo 4.0
45 day evaluation copy which can be obtained = from
<http://www.rational.com/uml/resources/practice_uml/ind= ex.jtmpl>.
Not all classes are documented in the MDL file at = this time.

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.  Getronics 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 Enhanced SNACC ASN.1 = Library to encode/decode
X.509 certificates, attribute certificates, = Certificate Revocation Lists,
and components thereof.  The CML is freely = available at: <http://www.getronicsgov.com/hot/cml_home.htm>.<= /FONT>

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

The National Institute of Standards and Technology = (NIST) is providing
test S/MIME messages (created by Getronics) at =
<http://csrc.nist.gov/pki/testing/x509paths.html>= ;.  Getronics 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.

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

------_=_NextPart_001_01C179D1.016E5BE0-- From owner-ietf-smime@mail.imc.org Fri Nov 30 17:00:48 2001 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10085 for ; Fri, 30 Nov 2001 17:00:47 -0500 (EST) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAULLbp23362 for ietf-smime-bks; Fri, 30 Nov 2001 13:21:37 -0800 (PST) Received: from wfhqex03.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAULDk823202; Fri, 30 Nov 2001 13:13:46 -0800 (PST) Received: by wfhqex03.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 15:19:22 -0500 Message-ID: <0B95FB5619B3D411817E006008A59259B52087@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 R7 Enhanced SNACC Software Now Available Date: Fri, 30 Nov 2001 15:19:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C179DC.49FC1DB0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C179DC.49FC1DB0 Content-Type: text/plain; charset="iso-8859-1" All, Getronics Government Solutions has delivered the v1.3 R7 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.7 and Microsoft (MS) Windows NT/98/2000. The Enhanced SNACC software is freely available to everyone from: The Enhanced SNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, Getronics enhanced the SNACC library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.3 R7 Enhanced SNACC C++ ASN.1 Library enhancements: 1) Enhanced AsnOcts class to leave large (>100 MB) OCTET STRING content as files. 2) Replaced longjmps with C++ exceptions. 3) Enhanced AsnOid class with features from CSM_OID class. 4) Incorporated recent modifications to C string classes in C++ string classes (i.e., BMPString, IA5String, etc.) 5) Enhanced AsnInt class to handle huge integers. 6) Incorporated all ASN.1 library types into a single header file. 7) Placed all ASN.1 types inside ASN namespace. 8) Added const qualifier to all C++ library member functions that don't change member variables. 9) Added mutable qualifier to the AsnList::curr member variable and add const and non-const versions of the AsnList member functions. 10) Enhanced SNACC C++ library to maximize thread-safety. 11) Implemented 1997 X.690 DER requirement for SET OF components such that the tag and length of each component is ignored for purposes of comparison. 12) Tested with v2.0 S/MIME Freeware Library (SFL) that use the Enhanced SNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. 13) Tested with freeware v2.0 Certificate Management Library (CML) that uses the Enhanced SNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. 14) Tested with freeware v2.0 Access Control Library (ACL) that uses the Enhanced SNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. v1.3 R7 Enhanced SNACC Compiler enhancements: 1) Added support for ASN.1 string classes as built-in types. 2) Replaced longjmps with C++ exceptions in generated code. 3) Incorporated C ANY handling mechanisms. This includes supporting the ANY handler parsing and registration mechanism used by the compiler. 4) Changed generated code to be inside ASN namespace. API Changes: The v1.3 R7 Enhanced SNACC C++ ASN.1 Library provides the identical API as provided by the v1.3 R6 Enhanced SNACC C++ ASN.1 Library except for the following changes: 1) Enhanced SNACC symbols are contained in a SNACC namespace (see below). 2) The CSM_OID class has been replaced with the SNACC::AsnOid class. The AsnOid class now has string handling capabilities (both input and output). The original CSM_OID::GetOidDescription() method was removed; the AsnOid::GetChar() method returns the numeric OID as a string (e.g. "1.2.3.1.1.1"). This will impact applications if they compare the descriptive OIDs provided by the Enhanced SNACC Library. This will not impact the comparison of numeric strings. For example, applications will no longer be able to use "id_dsa", they must now compare the numeric string representation of the id-dsa OID. 3) The CSMIME class was split into two classes: CSM_CtilMgr (with CSM_CtilInst, no certificate details) and CSMIME (with CSM_CSInst, containing certificate details). This only impacts the application code that walks through the linked list of logins in the CSMIME class. The member variable name was changed from "m_pCSInsts" to "m_pCSInsts2". This was done to force the developer to view the logic to see if the simpler, non-certificate based login instance variable can be used. In most cases, the integrator will be able to simply add the "2" to the name and re-build. Namespace: The v2.0 libraries use the "namespace" feature. The symbols for each library are contained in its own namespace: SFL, CERT, CTIL, SNACC, acl, CML. The namespace feature allows the compiler to isolate the symbols for each library. This enhancement causes a minor impact to the source code developed to use the libraries. The integrator will need to add a few lines of code to each source code file (or, possibly, in an include file) stating that the appropriate namespaces are being used such as: "using namespace SNACC;". The Enhanced SNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1994 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are work-arounds that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that support the latest ASN.1 features. Also, many of the IETF specifications, such as PKIX and S/MIME, include 1988-compliant ASN.1 syntax modules that can be compiled using the Enhanced SNACC ASN.1 compiler. The Enhanced SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an Enhanced SNACC web page . The IMC has established an Enhanced SNACC mail list which is used to: distribute information regarding releases; discuss technical issues; and provide a means for users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We welcome all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== ------_=_NextPart_001_01C179DC.49FC1DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable v1.3 R7 Enhanced SNACC Software Now Available

All,

Getronics Government Solutions has delivered the v1.3 = R7 Enhanced SNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ = library and C library
source code compilable for Linux, Sun Solaris 2.7 = and Microsoft (MS)
Windows NT/98/2000.  The Enhanced SNACC = software is freely available to
everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>=

The Enhanced SNACC ASN.1 software can be used to = ASN.1 encode and decode
objects.  In past releases, Getronics enhanced = the SNACC library to
implement the Distinguished Encoding Rules (DER), = support large ASN.1
INTEGERs, and improve memory = usage.   

v1.3 R7 Enhanced SNACC C++ ASN.1 Library = enhancements:

 1) Enhanced AsnOcts class to leave large = (>100 MB) OCTET STRING content
as files.

 2) Replaced longjmps with C++ exceptions. =

 3) Enhanced AsnOid class with features from = CSM_OID class.

 4) Incorporated recent modifications to C = string classes in C++ string
classes (i.e., BMPString, IA5String, etc.)

 5) Enhanced AsnInt class to handle huge = integers.

 6) Incorporated all ASN.1 library types into a = single header file.

 7) Placed all ASN.1 types inside ASN namespace. =

 8) Added const qualifier to all C++ library = member functions that
don't change member variables.

 9) Added mutable qualifier to the AsnList::curr = member variable and
add const and non-const versions of the AsnList = member functions.

10) Enhanced SNACC C++ library to maximize = thread-safety. 

11) Implemented 1997 X.690 DER requirement for SET OF = components such
that the tag and length of each component is ignored = for purposes
of comparison.

12) Tested with v2.0 S/MIME Freeware Library (SFL) =
<http://www.getronicsgov.com/hot/sfl_home.htm> = that use the Enhanced
SNACC ASN.1 software to encode and decode the IETF = S/MIME v3
Cryptographic Message Syntax (RFC 2630) and Enhanced = Security
Services for S/MIME (RFC 2634) security = protocol. 

13) Tested with freeware v2.0 Certificate Management = Library (CML) <http://www.getronicsgov.com/hot/cml_home.htm> = that uses the Enhanced

SNACC ASN.1 software to encode and decode X.509 = certificates,
attribute certificates and Certificate Revocation = Lists as specified
in the 2000 X.509 Recommendation.

14) Tested with freeware v2.0 Access Control Library = (ACL) <http://www.getronicsgov.com/hot/acl_home.htm> = that uses the Enhanced

SNACC ASN.1 software to encode and decode security = labels and other
objects (such as Security Policy Information Files) = required to
provide rule based automated access control as = specified in SDN.801.


v1.3 R7 Enhanced SNACC Compiler enhancements:

1) Added support for ASN.1 string classes as built-in = types.

2) Replaced longjmps with C++ exceptions in generated = code.

3) Incorporated C ANY handling mechanisms.  This = includes supporting
the ANY handler parsing and registration mechanism = used by the
compiler.

4) Changed generated code to be inside ASN namespace. =


API Changes: The v1.3 R7 Enhanced SNACC C++ ASN.1 = Library provides the
identical API as provided by the v1.3 R6 Enhanced = SNACC C++ ASN.1 Library
except for the following changes:

1) Enhanced SNACC symbols are contained in a SNACC = namespace (see below).
 
2) The CSM_OID class has been replaced with the = SNACC::AsnOid class.
The AsnOid class now has string handling = capabilities (both input and
output). The original CSM_OID::GetOidDescription() = method was removed;
the AsnOid::GetChar() method returns the numeric OID = as a string
(e.g. "1.2.3.1.1.1"). This will impact = applications if they
compare the descriptive OIDs provided by the = Enhanced SNACC Library.
This will not impact the comparison of numeric = strings. For example,
applications will no longer be able to use = "id_dsa", they must now
compare the numeric string representation of the = id-dsa OID.

3) The CSMIME class was split into two classes: = CSM_CtilMgr (with
CSM_CtilInst, no certificate details) and CSMIME = (with CSM_CSInst,
containing certificate details). This only impacts = the
application code that walks through the linked list = of logins in
the CSMIME class. The member variable name was = changed from
"m_pCSInsts" to "m_pCSInsts2". = This was done to force the
developer to view the logic to see if the simpler, = non-certificate
based login instance variable can be used. In most = cases, the
integrator will be able to simply add the = "2" to the name and
re-build.

Namespace: The v2.0 libraries use the = "namespace" feature.
The symbols for each library are contained in its = own namespace:
SFL, CERT, CTIL, SNACC, acl, CML.  The = namespace feature allows
the compiler to isolate the symbols for each = library. This
enhancement causes a minor impact to the source code = developed
to use the libraries.  The integrator will need = to add a few
lines of code to each source code file (or, = possibly, in an
include file) stating that the appropriate = namespaces are being
used such as: "using namespace = SNACC;".

The Enhanced SNACC ASN.1 software implements the = majority of the ASN.1
encoding/decoding rules specified in the 1988 X.209 = Recommendation.  It
implements the DER as specified in the 1994 X.690 = Recommendation.  It does
not support all of the latest ASN.1 features, but = there are work-arounds
that allow it to be used to produce ASN.1 hex = encodings that are identical
to those produced by ASN.1 libraries that support = the latest ASN.1
features.  Also, many of the IETF = specifications, such as PKIX and S/MIME,
include 1988-compliant ASN.1 syntax modules that can = be compiled using the
Enhanced SNACC ASN.1 compiler.

The Enhanced SNACC ASN.1 library is totally = unencumbered as stated in the
Enhanced SNACC Software Public License.  All = source code for the Enhanced
SNACC software is being provided at no cost and with = no financial
limitations regarding its use and = distribution.  Organizations can use the
Enhanced SNACC software without paying any royalties = or licensing fees. 

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

We welcome all feedback regarding the Enhanced SNACC = software.  If bugs
are reported, then we will investigate each reported = bug and, if required,
will produce a patch or an updated release of the = software to repair the
bug.

This release announcement was sent to several mail = lists, but please send
all messages regarding the Enhanced SNACC software = to the imc-snacc mail
list ONLY.  Please do not send messages = regarding the Enhanced SNACC
software to any of the IETF mail lists.  We = will respond to all messages
sent to the imc-snacc mail list.

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

------_=_NextPart_001_01C179DC.49FC1DB0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAULLbp23362 for ietf-smime-bks; Fri, 30 Nov 2001 13:21:37 -0800 (PST) Received: from wfhqex03.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAULDk823202; Fri, 30 Nov 2001 13:13:46 -0800 (PST) Received: by wfhqex03.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 15:19:22 -0500 Message-ID: <0B95FB5619B3D411817E006008A59259B52087@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v1.3 R7 Enhanced SNACC Software Now Available Date: Fri, 30 Nov 2001 15:19:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C179DC.49FC1DB0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C179DC.49FC1DB0 Content-Type: text/plain; charset="iso-8859-1" All, Getronics Government Solutions has delivered the v1.3 R7 Enhanced SNACC Abstract Syntax Notation.1 (ASN.1) Compiler, C++ library and C library source code compilable for Linux, Sun Solaris 2.7 and Microsoft (MS) Windows NT/98/2000. The Enhanced SNACC software is freely available to everyone from: The Enhanced SNACC ASN.1 software can be used to ASN.1 encode and decode objects. In past releases, Getronics enhanced the SNACC library to implement the Distinguished Encoding Rules (DER), support large ASN.1 INTEGERs, and improve memory usage. v1.3 R7 Enhanced SNACC C++ ASN.1 Library enhancements: 1) Enhanced AsnOcts class to leave large (>100 MB) OCTET STRING content as files. 2) Replaced longjmps with C++ exceptions. 3) Enhanced AsnOid class with features from CSM_OID class. 4) Incorporated recent modifications to C string classes in C++ string classes (i.e., BMPString, IA5String, etc.) 5) Enhanced AsnInt class to handle huge integers. 6) Incorporated all ASN.1 library types into a single header file. 7) Placed all ASN.1 types inside ASN namespace. 8) Added const qualifier to all C++ library member functions that don't change member variables. 9) Added mutable qualifier to the AsnList::curr member variable and add const and non-const versions of the AsnList member functions. 10) Enhanced SNACC C++ library to maximize thread-safety. 11) Implemented 1997 X.690 DER requirement for SET OF components such that the tag and length of each component is ignored for purposes of comparison. 12) Tested with v2.0 S/MIME Freeware Library (SFL) that use the Enhanced SNACC ASN.1 software to encode and decode the IETF S/MIME v3 Cryptographic Message Syntax (RFC 2630) and Enhanced Security Services for S/MIME (RFC 2634) security protocol. 13) Tested with freeware v2.0 Certificate Management Library (CML) that uses the Enhanced SNACC ASN.1 software to encode and decode X.509 certificates, attribute certificates and Certificate Revocation Lists as specified in the 2000 X.509 Recommendation. 14) Tested with freeware v2.0 Access Control Library (ACL) that uses the Enhanced SNACC ASN.1 software to encode and decode security labels and other objects (such as Security Policy Information Files) required to provide rule based automated access control as specified in SDN.801. v1.3 R7 Enhanced SNACC Compiler enhancements: 1) Added support for ASN.1 string classes as built-in types. 2) Replaced longjmps with C++ exceptions in generated code. 3) Incorporated C ANY handling mechanisms. This includes supporting the ANY handler parsing and registration mechanism used by the compiler. 4) Changed generated code to be inside ASN namespace. API Changes: The v1.3 R7 Enhanced SNACC C++ ASN.1 Library provides the identical API as provided by the v1.3 R6 Enhanced SNACC C++ ASN.1 Library except for the following changes: 1) Enhanced SNACC symbols are contained in a SNACC namespace (see below). 2) The CSM_OID class has been replaced with the SNACC::AsnOid class. The AsnOid class now has string handling capabilities (both input and output). The original CSM_OID::GetOidDescription() method was removed; the AsnOid::GetChar() method returns the numeric OID as a string (e.g. "1.2.3.1.1.1"). This will impact applications if they compare the descriptive OIDs provided by the Enhanced SNACC Library. This will not impact the comparison of numeric strings. For example, applications will no longer be able to use "id_dsa", they must now compare the numeric string representation of the id-dsa OID. 3) The CSMIME class was split into two classes: CSM_CtilMgr (with CSM_CtilInst, no certificate details) and CSMIME (with CSM_CSInst, containing certificate details). This only impacts the application code that walks through the linked list of logins in the CSMIME class. The member variable name was changed from "m_pCSInsts" to "m_pCSInsts2". This was done to force the developer to view the logic to see if the simpler, non-certificate based login instance variable can be used. In most cases, the integrator will be able to simply add the "2" to the name and re-build. Namespace: The v2.0 libraries use the "namespace" feature. The symbols for each library are contained in its own namespace: SFL, CERT, CTIL, SNACC, acl, CML. The namespace feature allows the compiler to isolate the symbols for each library. This enhancement causes a minor impact to the source code developed to use the libraries. The integrator will need to add a few lines of code to each source code file (or, possibly, in an include file) stating that the appropriate namespaces are being used such as: "using namespace SNACC;". The Enhanced SNACC ASN.1 software implements the majority of the ASN.1 encoding/decoding rules specified in the 1988 X.209 Recommendation. It implements the DER as specified in the 1994 X.690 Recommendation. It does not support all of the latest ASN.1 features, but there are work-arounds that allow it to be used to produce ASN.1 hex encodings that are identical to those produced by ASN.1 libraries that support the latest ASN.1 features. Also, many of the IETF specifications, such as PKIX and S/MIME, include 1988-compliant ASN.1 syntax modules that can be compiled using the Enhanced SNACC ASN.1 compiler. The Enhanced SNACC ASN.1 library is totally unencumbered as stated in the Enhanced SNACC Software Public License. All source code for the Enhanced SNACC software is being provided at no cost and with no financial limitations regarding its use and distribution. Organizations can use the Enhanced SNACC software without paying any royalties or licensing fees. The Internet Mail Consortium (IMC) has established an Enhanced SNACC web page . The IMC has established an Enhanced SNACC mail list which is used to: distribute information regarding releases; discuss technical issues; and provide a means for users to provide feedback, comments, bug reports, etc. Subscription information for the imc-snacc mail list is at the IMC web site listed above. We welcome all feedback regarding the Enhanced SNACC software. If bugs are reported, then we will investigate each reported bug and, if required, will produce a patch or an updated release of the software to repair the bug. This release announcement was sent to several mail lists, but please send all messages regarding the Enhanced SNACC software to the imc-snacc mail list ONLY. Please do not send messages regarding the Enhanced SNACC software to any of the IETF mail lists. We will respond to all messages sent to the imc-snacc mail list. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== ------_=_NextPart_001_01C179DC.49FC1DB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable v1.3 R7 Enhanced SNACC Software Now Available

All,

Getronics Government Solutions has delivered the v1.3 = R7 Enhanced SNACC
Abstract Syntax Notation.1 (ASN.1) Compiler, C++ = library and C library
source code compilable for Linux, Sun Solaris 2.7 = and Microsoft (MS)
Windows NT/98/2000.  The Enhanced SNACC = software is freely available to
everyone from: <http://www.getronicsgov.com/hot/snacc_home.htm>=

The Enhanced SNACC ASN.1 software can be used to = ASN.1 encode and decode
objects.  In past releases, Getronics enhanced = the SNACC library to
implement the Distinguished Encoding Rules (DER), = support large ASN.1
INTEGERs, and improve memory = usage.   

v1.3 R7 Enhanced SNACC C++ ASN.1 Library = enhancements:

 1) Enhanced AsnOcts class to leave large = (>100 MB) OCTET STRING content
as files.

 2) Replaced longjmps with C++ exceptions. =

 3) Enhanced AsnOid class with features from = CSM_OID class.

 4) Incorporated recent modifications to C = string classes in C++ string
classes (i.e., BMPString, IA5String, etc.)

 5) Enhanced AsnInt class to handle huge = integers.

 6) Incorporated all ASN.1 library types into a = single header file.

 7) Placed all ASN.1 types inside ASN namespace. =

 8) Added const qualifier to all C++ library = member functions that
don't change member variables.

 9) Added mutable qualifier to the AsnList::curr = member variable and
add const and non-const versions of the AsnList = member functions.

10) Enhanced SNACC C++ library to maximize = thread-safety. 

11) Implemented 1997 X.690 DER requirement for SET OF = components such
that the tag and length of each component is ignored = for purposes
of comparison.

12) Tested with v2.0 S/MIME Freeware Library (SFL) =
<http://www.getronicsgov.com/hot/sfl_home.htm> = that use the Enhanced
SNACC ASN.1 software to encode and decode the IETF = S/MIME v3
Cryptographic Message Syntax (RFC 2630) and Enhanced = Security
Services for S/MIME (RFC 2634) security = protocol. 

13) Tested with freeware v2.0 Certificate Management = Library (CML) <http://www.getronicsgov.com/hot/cml_home.htm> = that uses the Enhanced

SNACC ASN.1 software to encode and decode X.509 = certificates,
attribute certificates and Certificate Revocation = Lists as specified
in the 2000 X.509 Recommendation.

14) Tested with freeware v2.0 Access Control Library = (ACL) <http://www.getronicsgov.com/hot/acl_home.htm> = that uses the Enhanced

SNACC ASN.1 software to encode and decode security = labels and other
objects (such as Security Policy Information Files) = required to
provide rule based automated access control as = specified in SDN.801.


v1.3 R7 Enhanced SNACC Compiler enhancements:

1) Added support for ASN.1 string classes as built-in = types.

2) Replaced longjmps with C++ exceptions in generated = code.

3) Incorporated C ANY handling mechanisms.  This = includes supporting
the ANY handler parsing and registration mechanism = used by the
compiler.

4) Changed generated code to be inside ASN namespace. =


API Changes: The v1.3 R7 Enhanced SNACC C++ ASN.1 = Library provides the
identical API as provided by the v1.3 R6 Enhanced = SNACC C++ ASN.1 Library
except for the following changes:

1) Enhanced SNACC symbols are contained in a SNACC = namespace (see below).
 
2) The CSM_OID class has been replaced with the = SNACC::AsnOid class.
The AsnOid class now has string handling = capabilities (both input and
output). The original CSM_OID::GetOidDescription() = method was removed;
the AsnOid::GetChar() method returns the numeric OID = as a string
(e.g. "1.2.3.1.1.1"). This will impact = applications if they
compare the descriptive OIDs provided by the = Enhanced SNACC Library.
This will not impact the comparison of numeric = strings. For example,
applications will no longer be able to use = "id_dsa", they must now
compare the numeric string representation of the = id-dsa OID.

3) The CSMIME class was split into two classes: = CSM_CtilMgr (with
CSM_CtilInst, no certificate details) and CSMIME = (with CSM_CSInst,
containing certificate details). This only impacts = the
application code that walks through the linked list = of logins in
the CSMIME class. The member variable name was = changed from
"m_pCSInsts" to "m_pCSInsts2". = This was done to force the
developer to view the logic to see if the simpler, = non-certificate
based login instance variable can be used. In most = cases, the
integrator will be able to simply add the = "2" to the name and
re-build.

Namespace: The v2.0 libraries use the = "namespace" feature.
The symbols for each library are contained in its = own namespace:
SFL, CERT, CTIL, SNACC, acl, CML.  The = namespace feature allows
the compiler to isolate the symbols for each = library. This
enhancement causes a minor impact to the source code = developed
to use the libraries.  The integrator will need = to add a few
lines of code to each source code file (or, = possibly, in an
include file) stating that the appropriate = namespaces are being
used such as: "using namespace = SNACC;".

The Enhanced SNACC ASN.1 software implements the = majority of the ASN.1
encoding/decoding rules specified in the 1988 X.209 = Recommendation.  It
implements the DER as specified in the 1994 X.690 = Recommendation.  It does
not support all of the latest ASN.1 features, but = there are work-arounds
that allow it to be used to produce ASN.1 hex = encodings that are identical
to those produced by ASN.1 libraries that support = the latest ASN.1
features.  Also, many of the IETF = specifications, such as PKIX and S/MIME,
include 1988-compliant ASN.1 syntax modules that can = be compiled using the
Enhanced SNACC ASN.1 compiler.

The Enhanced SNACC ASN.1 library is totally = unencumbered as stated in the
Enhanced SNACC Software Public License.  All = source code for the Enhanced
SNACC software is being provided at no cost and with = no financial
limitations regarding its use and = distribution.  Organizations can use the
Enhanced SNACC software without paying any royalties = or licensing fees. 

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

We welcome all feedback regarding the Enhanced SNACC = software.  If bugs
are reported, then we will investigate each reported = bug and, if required,
will produce a patch or an updated release of the = software to repair the
bug.

This release announcement was sent to several mail = lists, but please send
all messages regarding the Enhanced SNACC software = to the imc-snacc mail
list ONLY.  Please do not send messages = regarding the Enhanced SNACC
software to any of the IETF mail lists.  We = will respond to all messages
sent to the imc-snacc mail list.

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

------_=_NextPart_001_01C179DC.49FC1DB0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAUJjGS17543 for ietf-smime-bks; Fri, 30 Nov 2001 11:45:16 -0800 (PST) Received: from wfhqex03.gfgsi.com ([67.105.229.98]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fAUJjE817538; Fri, 30 Nov 2001 11:45:14 -0800 (PST) Received: by wfhqex03.gfgsi.com with Internet Mail Service (5.5.2653.19) id ; Fri, 30 Nov 2001 13:58:44 -0500 Message-ID: <0B95FB5619B3D411817E006008A59259B52080@wfhqex06.gfgsi.com> From: "Pawling, John" To: "Pawling, John" Subject: v2.0 S/MIME Freeware Library (SFL) Now Available Date: Fri, 30 Nov 2001 13:58:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C179D1.016E5BE0" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C179D1.016E5BE0 Content-Type: text/plain; charset="iso-8859-1" All, Getronics Government Solutions has delivered Version 2.0 of the S/MIME Freeware Library (SFL) source code. The SFL source code files are freely available at . The SFL implements the IETF S/MIME v3 RFC 2630 Cryptographic Message Syntax (CMS) security protocol to support the digital signature and encryption of data. It also implements RFC 2634 Enhanced Security Services (ESS) including signed receipts, security labels, secure mail list information, and signing certificate attributes. It also implements portions of the RFC 2633 Message Specification and RFC 2632 Certificate Handling document. 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 NT/98/2000, Linux and Sun Solaris 2.7 operating systems. Further enhancements of the SFL are still in process. Further releases 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 v4.2 and Crypto++ libraries; and Fortezza suite of algorithms provided by the Fortezza Crypto Card. The v2.0 SFL uses the v1.3 R7 Enhanced SNACC ASN.1 C++ Library to encode/decode objects. The v2.0 SFL release includes: SFL High-level library; Free (a.k.a. Crypto++) Crypto Token Interface Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ 2 CTIL; PKCS #11 CTIL; Microsoft CAPI v2.0 CTIL; v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library; 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.7. The SFL has been successfully used to exchange signedData and envelopedData messages with the Microsoft (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 2630, 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 all of 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.0 SFL is described in the v2.0 SFL Application Programming Interface (API) and v2.0 SDD documents. The v2.0 SMP Components Setup Manual that describes the component installation procedures for the v2.0 SFL, v2.0 Certificate Management Library (CML), and v1.3 R7 Enhanced SNACC libraries. The use of the v2.0 CTIL API is described in the v2.0 CTIL API document. The following enhancements are included in the v2.0 SFL and CTIL releases (compared with the v1.10 releases): 1) Moved common code in LibCert associated with using the CTIL API into a new CTILManager library. Changed SFL to call new CTILManager library instead of LibCert to obtain CTIL-related services. 2) Developed MS CAPI CTIL to provide access to these crypto algorithms provided by MS CAPI v2.0: Triple-DES and RC2 for encryption/decryption; RSA for key management; SHA-1 and MD5 for hashing; DSA and RSA for signature generation/verification. Tested SFL with MS CAPI CTIL using MS CAPI v2.0 with the MS Cryptographic Service Provider (CSP). Tested MS CAPI CTIL using MS CAPI v2.0 with the DataKey CSP and smart card. 3) Enhanced SFL and CTILs to maximize thread-safety. Enhanced the CTILs to be single-threaded in case a user attempts to share a single login. 4) Enhanced SFL to call v2.0 CML to decode certificates, Certificate Revocation Lists, and components thereof. v2.0 SFL API: The v2.0 SFL and CTILs provide the identical APIs as provided by the v1.10 SFL and CTILs except that the SFL and CTIL symbols are each contained in their own namespace (see below). Also, the CSM_OID and CSMIME classes are provided by the v1.3 R7 Enhanced SNACC C++ ASN.1 Library AsnOid class (updated to include CSM_OID, but unchanged from the Enhanced SNACC point of view). Namespace: The v2.0 libraries use the "namespace" feature. The symbols for each library are contained in its own namespace: SFL, CERT, CTIL, SNACC, acl, CML. The namespace feature allows the compiler to isolate the symbols for each library. This enhancement causes a minor impact to the source code developed to use the libraries. The integrator will need to add a few lines of code to each source code file (or, possibly, in an include file) stating that the appropriate namespaces are being used such as: "using namespace SFL;". We are still in the process of enhancing the SFL. Future releases may include: new features of updated S/MIME specifications (such as compression, password-protected RecipientInfo, etc); "Certificate Management Messages over CMS" ASN.1 encode/decode functions; bug fixes; and support for other crypto APIs. The SFL is developed to maximize portability to 32-bit operating systems. In addition to testing on MS Windows, Linux and Solaris 2.7, we may port the SFL to other operating systems. The following SFL files are available from : 1) SFL Documents: Fact Sheet, Software Design Description, API, CTIL API, Software Test Description, Implementers Guide, Overview Briefing and Public License. 2) smimeR2.0.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for SFL Hi-Level library. 3) snacc13r7rn.tar.gz (source code and binaries available from Getronics Enhanced SNACC web page: ): Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library that has been enhanced by Getronics to implement the Distinguished Encoding Rules. Source code is compilable for Linux, Solaris 2.7 and MS Windows NT/95/98/2000. This file includes a sample test project demonstrating the use of the SNACC classes. 4) smCTIR2.0.tar.gz: Source code, MS Windows NT/95/98/2000 project files and Unix makefiles for the following CTILs: Test (no crypto), Crypto++, BSAFE, Fortezza, SPEX/ 2, PKCS #11 and Microsoft CAPI v2.0. The CTIL source code includes PKCS #12 software developed by the OpenSSL Project for use in the OpenSSL Toolkit 5) smLibCR2.0.tar.gz: Source code, MS Windows NT/98/2000 project files and Unix makefiles for the CTILManager library that provides CTIL-related processing services used by the SFL, ACL and CML. 6) smTest2.0.tar.gz: Source code, MS Windows NT/98/2000 project files and Unix makefiles for test drivers used to test the SFL. This file also includes sample CMS/ESS test data and test X.509 Certificates. This file also includes the CertificateBuilder test utility that can be used to create X.509 Certificates that each include a DSA or RSA public key. 7) csmime.mdl contains SFL Class diagrams created using Microsoft Visual Modeler (comes with MS Visual Studio 6.0, Enterprise Tools). The file can also be viewed using Rational Rose C++ Demo 4.0 45 day evaluation copy which can be obtained from . Not all classes are documented in the MDL file at this time. 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. Getronics 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 Enhanced SNACC ASN.1 Library to encode/decode X.509 certificates, attribute certificates, Certificate Revocation Lists, 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 at: . The National Institute of Standards and Technology (NIST) is providing test S/MIME messages (created by Getronics) at . Getronics 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. =========================================== John Pawling, John.Pawling@GetronicsGov.com Getronics Government Solutions, LLC =========================================== ------_=_NextPart_001_01C179D1.016E5BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable v2.0 S/MIME Freeware Library (SFL) Now Available

All,

Getronics Government Solutions has delivered Version = 2.0 of the
S/MIME Freeware Library (SFL) source code.  The = SFL source code files
are freely available at <http://www.getronicsgov.com/hot/sfl_home.htm>.&= nbsp;  

The SFL implements the IETF S/MIME v3 RFC 2630 = Cryptographic Message
Syntax (CMS) security protocol to support the = digital signature and
encryption of data.  It also implements RFC = 2634 Enhanced Security
Services (ESS) including signed receipts, security = labels, secure mail
list information, and signing certificate = attributes.  It also
implements portions of the RFC 2633 Message = Specification and RFC 2632
Certificate Handling document.  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 = NT/98/2000, Linux
and Sun Solaris 2.7 operating systems.  Further = enhancements of the SFL
are still in process.  Further releases 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 v4.2
and Crypto++ libraries; and Fortezza suite of = algorithms provided by
the Fortezza Crypto Card.  The v2.0 SFL uses = the v1.3 R7 Enhanced SNACC
ASN.1 C++ Library to encode/decode objects. The v2.0 = SFL release includes:
SFL High-level library; Free (a.k.a. Crypto++) = Crypto Token Interface
Library (CTIL); BSAFE CTIL; Fortezza CTIL; SPEX/ 2 = CTIL; PKCS #11 CTIL;
Microsoft CAPI v2.0 CTIL; v1.3 R7 Enhanced SNACC = ASN.1 Compiler and Library;
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.7.  =

The SFL has been successfully used to exchange = signedData and envelopedData
messages with the Microsoft (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 2630, 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
all of 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.0 SFL is described in the v2.0 SFL = Application
Programming Interface (API) and v2.0 SDD = documents.  The v2.0 SMP
Components Setup Manual that describes the component = installation
procedures for the v2.0 SFL, v2.0 Certificate = Management Library (CML),
and v1.3 R7 Enhanced SNACC libraries.  The use = of the v2.0 CTIL API is
described in the v2.0 CTIL API document.

The following enhancements are included in the v2.0 = SFL and CTIL releases
(compared with the v1.10 releases):

1) Moved common code in LibCert associated with using = the CTIL API into
a new CTILManager library. Changed SFL to call new = CTILManager library
instead of LibCert to obtain CTIL-related = services.  

2) Developed MS CAPI CTIL to provide access to these = crypto algorithms
provided by MS CAPI v2.0: Triple-DES and RC2 for = encryption/decryption;
RSA for key management; SHA-1 and MD5 for hashing; = DSA and RSA for
signature generation/verification.  Tested SFL = with MS CAPI CTIL using
MS CAPI v2.0 with the MS Cryptographic Service = Provider (CSP).  Tested
MS CAPI CTIL using MS CAPI v2.0 with the DataKey CSP = and smart card. 

3) Enhanced SFL and CTILs to maximize = thread-safety.  Enhanced the CTILs
to be single-threaded in case a user attempts to = share a single login. 

4) Enhanced SFL to call v2.0 CML to decode = certificates, Certificate
Revocation Lists, and components thereof.  =


v2.0 SFL API: The v2.0 SFL and CTILs provide the = identical APIs as
provided by the v1.10 SFL and CTILs except that the = SFL and CTIL symbols
are each contained in their own namespace (see = below).  Also, the CSM_OID
and CSMIME classes are provided by the v1.3 R7 = Enhanced SNACC C++ ASN.1
Library AsnOid class (updated to include CSM_OID, = but unchanged from the
Enhanced SNACC point of view).

Namespace: The v2.0 libraries use the = "namespace" feature.  The symbols for
each library are contained in its own = namespace:  SFL, CERT, CTIL, SNACC,
acl, CML.  The namespace feature allows the = compiler to isolate the symbols
for each library. This enhancement causes a minor = impact to the source code
developed to use the libraries.  The integrator = will need to add a few
lines of code to each source code file (or, = possibly, in an include file)
stating that the appropriate namespaces are being = used such as:
"using namespace SFL;".

We are still in the process of enhancing the = SFL.  Future releases may
include: new features of updated S/MIME = specifications (such as
compression, password-protected RecipientInfo, etc); = "Certificate
Management Messages over CMS" ASN.1 = encode/decode functions; bug fixes;
and support for other crypto APIs.  The SFL is = developed to maximize
portability to 32-bit operating systems.  In = addition to testing on
MS Windows, Linux and Solaris 2.7, we may port the = SFL to other
operating systems.


The following SFL files are available from
<http://www.getronicsgov.com/hot/sfl_lib.htm>:

1) SFL Documents: Fact Sheet, Software Design = Description, API, CTIL
API, Software Test Description, Implementers Guide, = Overview Briefing and
Public License.    

2) smimeR2.0.tar.gz:  Source code, MS Windows = NT/95/98/2000 project files
and Unix makefiles for SFL Hi-Level library.

3) snacc13r7rn.tar.gz (source code and binaries = available from Getronics
Enhanced SNACC web page: <http://www.getronicsgov.com/hot/snacc_home.htm>= ):
Source code, MS Windows NT/95/98/2000 project files = and Unix makefiles for
v1.3 R7 Enhanced SNACC ASN.1 Compiler and Library = that has been enhanced by
Getronics to implement the Distinguished Encoding = Rules.  Source code is
compilable for Linux, Solaris 2.7 and MS Windows = NT/95/98/2000. This
file includes a sample test project demonstrating = the use of the SNACC
classes. 

4) smCTIR2.0.tar.gz:  Source code, MS Windows = NT/95/98/2000 project files
and Unix makefiles for the following CTILs: Test (no = crypto), Crypto++,
BSAFE, Fortezza, SPEX/ 2, PKCS #11 and Microsoft = CAPI v2.0.  The CTIL
source code includes PKCS #12 software developed by = the OpenSSL Project
for use in the OpenSSL Toolkit <http://www.openssl.org/>

5) smLibCR2.0.tar.gz: Source code, MS Windows = NT/98/2000 project files and
Unix makefiles for the CTILManager library that = provides CTIL-related
processing services used by the SFL, ACL and = CML.

6) smTest2.0.tar.gz: Source code, MS Windows = NT/98/2000 project files and
Unix makefiles for test drivers used to test the = SFL.  This file also
includes sample CMS/ESS test data and test X.509 = Certificates.  This file
also includes the CertificateBuilder test utility = that can be used to
create X.509 Certificates that each include a DSA or = RSA public key. 

7) csmime.mdl contains SFL Class diagrams created = using Microsoft
Visual Modeler (comes with MS Visual Studio 6.0, = Enterprise Tools).
The file can also be viewed using Rational Rose C++ = Demo 4.0
45 day evaluation copy which can be obtained = from
<http://www.rational.com/uml/resources/practice_uml/ind= ex.jtmpl>.
Not all classes are documented in the MDL file at = this time.

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.  Getronics 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 Enhanced SNACC ASN.1 = Library to encode/decode
X.509 certificates, attribute certificates, = Certificate Revocation Lists,
and components thereof.  The CML is freely = available at: <http://www.getronicsgov.com/hot/cml_home.htm>.<= /FONT>

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

The National Institute of Standards and Technology = (NIST) is providing
test S/MIME messages (created by Getronics) at =
<http://csrc.nist.gov/pki/testing/x509paths.html>= ;.  Getronics 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.

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

------_=_NextPart_001_01C179D1.016E5BE0-- Received: by above.proper.com (8.11.6/8.11.3) id fASMPOI20077 for ietf-smime-bks; Wed, 28 Nov 2001 14:25:24 -0800 (PST) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASMPN820071 for ; Wed, 28 Nov 2001 14:25:23 -0800 (PST) Received: by sentry.gw.tislabs.com; id RAA09333; Wed, 28 Nov 2001 17:30:24 -0500 (EST) Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma009310; Wed, 28 Nov 01 17:29:29 -0500 Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id fASMOT814593 for ietf-smime@imc.org; Wed, 28 Nov 2001 17:24:29 -0500 (EST) Date: Wed, 28 Nov 2001 17:24:29 -0500 (EST) Message-Id: <200111282224.fASMOT814593@raven.gw.tislabs.com> From: balenson@tislabs.com To: ietf-smime@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'02) Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) February 7-8, 2002 Catamaran Resort Hotel, San Diego, California General Chair: Cliff Neuman, USC Information Sciences Institute Program Chairs: Paul Van Oorschot, Entrust Virgil Gligor, University of Maryland ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss02 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2002 The 9th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * Wireless Security * Analyzing the Anonymity of Anonymous Networking Protocols * Intrusion Detection and Defending Against Network Attacks * Detecting Steganographic Content on the Web * Server-Aided Digital Signatures * PKI, Certificates and Privilege Management * Various Aspects of Transport Layer Security/TLS PRE-CONFERENCE TECHNICAL TUTORIALS: * Major IETF Security Standards: PKIX, IPsec, SSL/TLS, Dr. Stephen Kent * Crash Course in SSL and TLS, Mr. Eric Rescorla * Building Secure Software, Dr. Gary McGraw * Wirelss LAN Security: Problems & Solutions, Dr. William Arbaugh * Group Security, Dr. Thomas Harjono and Mr. Hugh Harney For further information about NDSS'02 REGISTRATION contact Michele Estadt at the Internet Society at +1-703-326-9880 ext 104 or send e-mail to infondss@isoc.org SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Martin Kupres at the Internet Society EMEA office at +41 22 807 1444 or send e-mail to sponsorndss@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fASB0JT01485 for ietf-smime-bks; Wed, 28 Nov 2001 03:00:19 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fASB0H801481 for ; Wed, 28 Nov 2001 03:00:17 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29271; Wed, 28 Nov 2001 06:00:13 -0500 (EST) Message-Id: <200111281100.GAA29271@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-aes-alg-03.txt Date: Wed, 28 Nov 2001 06:00:13 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS Author(s) : J. Schaad, R. Housley Filename : draft-ietf-smime-aes-alg-03.txt Pages : 15 Date : 27-Nov-01 This document specifies the conventions for using the Advanced Encryption Standard (AES) algorithm [AES] for encryption and the RSAES-OAEP key transport method [PKCS#1v2.0] for key management with the Cryptographic Message Syntax (CMS) [CMS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-aes-alg-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-aes-alg-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011127135724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-aes-alg-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-aes-alg-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011127135724.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id fAQLWI305899 for ietf-smime-bks; Mon, 26 Nov 2001 13:32:18 -0800 (PST) Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAQLWF805895 for ; Mon, 26 Nov 2001 13:32:16 -0800 (PST) Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Nov 2001 21:32:09 UT Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id fAQLaMq15605 for ; Tue, 27 Nov 2001 07:36:23 +1000 (EST) Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Nov 2001 08:29:28 +1100 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.123]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DR2TFW; Mon, 26 Nov 2001 16:31:44 -0500 Message-Id: <5.0.1.4.2.20011126162823.02c942d0@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 26 Nov 2001 16:30:58 -0500 To: ietf-smime@imc.org From: "Housley, Russ" Subject: Draft Agenda for Salt Lake City Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Attached is the draft agenda for the S/MIME WG session in Salt Lake City. I believe that I have given everyone a time slot that asked for one. Please contact me immediately if you would like a slot, but you do not appear on the agenda below. Russ = = = = = = = = = = = Introductions Russ Housley Working Group Status Russ Housley CMS Update Status Russ Housley Interoperability Matrix Jim Schaad CMS and ESS Examples Paul Hoffman AES and RSA-OAEP Jim Schaad Intended Recipient Attribute Russ Housley & Jim Schaad Policy Requirements for TSAs Denis Pinkas Wrap up Russ Housley Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJJl6H18872 for ietf-smime-bks; Mon, 19 Nov 2001 11:47:06 -0800 (PST) Received: from mail01g.rapidsite.net (mail01g.rapidsite.net [207.158.192.232]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAJJl5818866 for ; Mon, 19 Nov 2001 11:47:05 -0800 (PST) Received: from www.blkk.com (209.130.71.190) by mail01g.rapidsite.net (RS ver 1.0.60s) with SMTP id 07762958 for ; Mon, 19 Nov 2001 14:47:17 -0500 (EST) From: "Ben Littauer" To: Subject: Seeking Blake Ramsdell Date: Mon, 19 Nov 2001 14:44:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C17108.BAF54DC0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Loop-Detect: 1 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_0004_01C17108.BAF54DC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit The address I have for Blake, blaker@tumbleweed.com, appears to be bouncing. If anyone knows current contact info, I woul dbe much obliged... -ben- Ben Littauer 1 Moon Hill Road Lexington, MA 02421 781-862-8784 fax: 810-963-6163 littauer@blkk.com http://www.blkk.com ------=_NextPart_000_0004_01C17108.BAF54DC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The address I have for Blake, blaker@tumbleweed.com, appears = to be=20 bouncing.  If anyone knows current contact info, I woul dbe much=20 obliged...
 
-ben-
Ben Littauer
1=20 Moon Hill Road
Lexington, MA=20 02421
781-862-8784 =
fax: 810-963-6163
littauer@blkk.com
http://www.blkk.com =
------=_NextPart_000_0004_01C17108.BAF54DC0-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fAJEsik27911 for ietf-smime-bks; Mon, 19 Nov 2001 06:54:44 -0800 (PST) Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id fAJEsg827906 for ; Mon, 19 Nov 2001 06:54:43 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Nov 2001 14:55:18 UT Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA05013 for ; Mon, 19 Nov 2001 09:54:43 -0500 (EST) Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id fAJEsfm08273 for ; Mon, 19 Nov 2001 09:54:42 -0500 (EST) Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Nov 2001 14:54:44 -0000 Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.99]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T1DRFHAS; Mon, 19 Nov 2001 09:54:17 -0500 Message-Id: <5.0.1.4.2.20011119080753.0256f700@exna07.securitydynamics.com> X-Sender: rhousley@exna07.securitydynamics.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.1 Date: Mon, 19 Nov 2001 08:09:12 -0500 To: ietf-smime@imc.org From: "Housley, Russ" Subject: Salt Lake City Agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear Working Group: I am starting to put together the agenda for our session in Salt Lake City. Please send me a message if you would like to make a presentation. Russ Received: by above.proper.com (8.11.6/8.11.3) id fA8LkHo18603 for ietf-smime-bks; Thu, 8 Nov 2001 13:46:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA8LkG818599 for ; Thu, 8 Nov 2001 13:46:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08784; Thu, 8 Nov 2001 16:46:15 -0500 (EST) Message-Id: <200111082146.QAA08784@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Cryptographic Message Syntax to Proposed Standard Reply-to: iesg@ietf.org Date: Thu, 08 Nov 2001 16:46:15 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider the following as Proposed Standards: o Cryptographic Message Syntax o Cryptographic Message Syntax (CMS) Algorithms The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 21, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-rfc2630bis-05.txt http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-06.txt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6K0HN06958 for ietf-smime-bks; Tue, 6 Nov 2001 12:00:17 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6K0F806953 for ; Tue, 6 Nov 2001 12:00:16 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00829; Tue, 6 Nov 2001 15:00:14 -0500 (EST) Message-Id: <200111062000.PAA00829@ietf.org> To: IETF-Announce: ; Cc: ietf-smime@imc.org From: The IESG SUBJECT: Last Call: Securing X.400 Content with S/MIME to Proposed Standard Reply-to: iesg@ietf.org Date: Tue, 06 Nov 2001 15:00:14 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The IESG has received a request from the S/MIME Mail Security Working Group to consider publication of the following Internet-Drafts as Proposed Standards: o Securing X.400 Content with S/MIME o Transporting S/MIME Objects in X.400 The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by November 20, 2001. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-smime-x400wrap-04.txt http://www.ietf.org/internet-drafts/draft-ietf-smime-x400transport-04.txt Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA6CHCq06756 for ietf-smime-bks; Tue, 6 Nov 2001 04:17:12 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA6CHB806748 for ; Tue, 6 Nov 2001 04:17:11 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07310; Tue, 6 Nov 2001 07:17:09 -0500 (EST) Message-Id: <200111061217.HAA07310@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-examples-07.txt Date: Tue, 06 Nov 2001 07:17:08 -0500 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : Examples of S/MIME Messages Author(s) : P. Hoffman Filename : draft-ietf-smime-examples-07.txt Pages : 8 Date : 05-Nov-01 This document gives examples of message bodies formatted using S/MIME. Specifically, it has examples of Cryptographic Message Syntax (CMS) objects, S/MIME messages (including the MIME formatting), and Enhanced Security Services for S/MIME (ESS). It includes examples of most or all common CMS and ESS formats; in addition, it gives examples that show common pitfalls in implementing CMS. The purpose of this document is to help increase interoperability for S/MIME and other protocols that rely on CMS. This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . This draft is being discussed on the 'ietf-smime' mailing list. To join the list, send a message to with the single word 'subscribe' in the body of the message. Also, there is a Web site for the mailing list at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-examples-07.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-examples-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-examples-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011105132420.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-examples-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-examples-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011105132420.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id fA5D8fa17566 for ietf-smime-bks; Mon, 5 Nov 2001 05:08:41 -0800 (PST) Received: from mailb.telia.com (mailb.telia.com [194.22.194.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5D8e817562; Mon, 5 Nov 2001 05:08:40 -0800 (PST) Received: from arport ([212.181.94.147]) by mailb.telia.com (8.11.6/8.11.6) with SMTP id fA5D8d027377; Mon, 5 Nov 2001 14:08:39 +0100 (CET) Message-ID: <00d501c165fb$1d6b9130$0500a8c0@arport> From: "Anders Rundgren" To: , References: Subject: Re: EmailAddress history question Date: Mon, 5 Nov 2001 14:09:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: All, I have no interests in maintaining a debate that leads nowhere. I have simply concluded that the *market* in the form of VeriSign (e-mail certs), Microsoft (CertServ) and lots of more obscure players have opted to [silently] disregard the 2459 in *this* particular case. IMHO the weight of that should have made an impression in son-of-2459. Case closed. We can now all happily go back to our current "best practices" or "favorite deprecations"! :-) Anders Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA5CIHq15930 for ietf-smime-bks; Mon, 5 Nov 2001 04:18:17 -0800 (PST) Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA5CAf815328; Mon, 5 Nov 2001 04:10:41 -0800 (PST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA400738; Mon, 5 Nov 2001 07:07:59 -0500 Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.00) with ESMTP id fA5CAX793932; Mon, 5 Nov 2001 07:10:33 -0500 Importance: Normal Subject: RE: EmailAddress history question To: "RAGHAVENDRAN H. (SSG) - CTD, Chennai." Cc: ietf-pkix@imc.org, ietf-smime@imc.org, Anders Rundgren X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 Message-ID: From: "Tom Gindin" Date: Mon, 5 Nov 2001 07:10:47 -0500 X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.8 SPR #s MIAS4UTJ8H JPOS4U8UWQ CMCY4QLP6R |August 29, 2001) at 11/05/2001 07:10:33 AM 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: In this post, I will attempt to avoid personalities and offensive characterizations of views differing from my own. First, the case for banning e-mail addresses from DN's is different between DN's in which at least one personal name attribute (Surname, GivenName, or CommonName) is present is much stronger than the case for banning them from DN's in which no personal name attributes are present. Second, AFAIK the usual motivation for adding e-mail addresses to DN's is to enable directory search by that attribute - neither obscenity nor ignorance have anything to do with it. It is my opinion that rather than deprecating the use of emailAddress in the subject name what should be deprecated is the use of emailAddress in a subject name in which any of the personal name attributes are present. I am aware that this would involve a change to wording inherited from RFC 2459. Tom Gindin "RAGHAVENDRAN H. (SSG) - CTD, Chennai." @mail.imc.org on 11/05/2001 04:14:03 AM Sent by: owner-ietf-pkix@mail.imc.org To: ietf-pkix@imc.org, ietf-smime@imc.org cc: Anders Rundgren Subject: RE: EmailAddress history question Hi List: My view on this is subjectAltName is a good thing. I know this has been an issue for quite some time, but as a programmer I find the concept of putting an email in the DN "obscene". I tend to agree with Steve's posting on this. Email addresses are now being used to uniquely identify persons. In future, it may be IPv6 addresses and still further in the future... who knows. subjectAltName provides a convenient, future-proof way of implementing this instead of "cluttering" your DN. My 2 cents.. Regards, Raghav (snip) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA59Wix00463 for ietf-smime-bks; Mon, 5 Nov 2001 01:32:44 -0800 (PST) Received: from ganesh.ctd.hctech.com ([202.54.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA59G3826791; Mon, 5 Nov 2001 01:16:04 -0800 (PST) Received: by GANESH with Internet Mail Service (5.5.2653.19) id ; Mon, 5 Nov 2001 15:16:41 +0530 Message-ID: From: "RAGHAVENDRAN H. (SSG) - CTD, Chennai." To: ietf-pkix@imc.org, ietf-smime@imc.org Cc: Anders Rundgren Subject: RE: EmailAddress history question Date: Mon, 5 Nov 2001 14:44:03 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Hi List: My view on this is subjectAltName is a good thing. I know this has been an issue for quite some time, but as a programmer I find the concept of putting an email in the DN "obscene". I tend to agree with Steve's posting on this. Email addresses are now being used to uniquely identify persons. In future, it may be IPv6 addresses and still further in the future... who knows. subjectAltName provides a convenient, future-proof way of implementing this instead of "cluttering" your DN. My 2 cents.. Regards, Raghav -----Original Message----- From: Anders Rundgren [mailto:anders.rundgren@telia.com] Sent: Saturday, November 03, 2001 12:37 AM To: helm@fionn.es.net; ietf-pkix@imc.org; ietf-smime@imc.org Subject: Re: EmailAddress history question Michael, The story is that rfc822 addresses in the Subject Field become deprecated for reasons like not fitting into a directory-oriented scheme. PKI-Politics++ The interesting part is that practically no *practitioners* care about this deprecation as this use is the "de-facto" standard. Not even VeriSign care (check their personal e-mail certs as found in this signed mail if you want to confirm this), in spite of being active in the authoring of 2459! I'm pretty sure that this will not change as the problem by having e-mail addresses in the subject field is *unknown* by the majority of certificate issuers. My guess is that you run into *less* problems by using the de-facto standard as there are probably quite a few systems out there ("inferior" but anyway), that don't bother with SubjectAltName. To use duplicate data as 2459 suggests seems like a political thing (follow the "true" and "de-facto" standard at the same time), rather than an example of good engineering. As a conforming PKIX/SMIME-app MUST interpret the "de-facto" standard there are no problems at all by using it. The "deprecation" will BTW have no effect as no SW engineer in his right mind, will ever remove support for the current practice as it is likely to just lead to complaints. Personally I don't think SubjectAltName has any value at all in the long-run, as it just adds confusion (i.e. multiple places to look for identity information). An ID-certificate does typically only need to contain a CN and some unique identity tag and an e-mail address is such an option. OID.2.5.4.5 is another. Once upon a time the idea was that a certificate should contain your entire personal profile but that's got totally out of style since the advent of on-line operation, and then the Subject field continues to be completely satisfactory as the *only* container of identity data. PKI-Politics-- Anders ----- Original Message ----- From: "Michael Helm" To: ; Sent: Friday, November 02, 2001 17:11 Subject: EmailAddress history question Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL *********************************************************************** Disclaimer: This document is intended for transmission to the named recipient only. If you are not that person, you should note that legal rights reside in this document and you are not authorized to access, read, disclose, copy, use or otherwise deal with it and any such actions are prohibited and may be unlawful. The views expressed in this document are not necessarily those of HCL Technologies Ltd. Notice is hereby given that no representation, contract or other binding obligation shall be created by this e-mail, which must be interpreted accordingly. Any representations, contractual rights or obligations shall be separately communicated in writing and signed in the original by a duly authorized officer of the relevant company. *********************************************************************** Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2J6gb09330 for ietf-smime-bks; Fri, 2 Nov 2001 11:06:42 -0800 (PST) Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2J6e809321; Fri, 2 Nov 2001 11:06:41 -0800 (PST) Received: from arport (t2o69p79.telia.com [62.20.144.199]) by maile.telia.com (8.11.6/8.11.6) with SMTP id fA2J6V928503; Fri, 2 Nov 2001 20:06:31 +0100 (CET) Message-ID: <002901c163d1$9ec04540$0500a8c0@arport> From: "Anders Rundgren" To: , , References: <200111021611.IAA06121@fionn.es.net> Subject: Re: EmailAddress history question Date: Fri, 2 Nov 2001 20:07:28 +0100 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0024_01C163D9.FF7930B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0024_01C163D9.FF7930B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Michael, The story is that rfc822 addresses in the Subject Field become deprecated for reasons like not fitting into a directory-oriented scheme. PKI-Politics++ The interesting part is that practically no *practitioners* care about this deprecation as this use is the "de-facto" standard. Not even VeriSign care (check their personal e-mail certs as found in this signed mail if you want to confirm this), in spite of being active in the authoring of 2459! I'm pretty sure that this will not change as the problem by having e-mail addresses in the subject field is *unknown* by the majority of certificate issuers. My guess is that you run into *less* problems by using the de-facto standard as there are probably quite a few systems out there ("inferior" but anyway), that don't bother with SubjectAltName. To use duplicate data as 2459 suggests seems like a political thing (follow the "true" and "de-facto" standard at the same time), rather than an example of good engineering. As a conforming PKIX/SMIME-app MUST interpret the "de-facto" standard there are no problems at all by using it. The "deprecation" will BTW have no effect as no SW engineer in his right mind, will ever remove support for the current practice as it is likely to just lead to complaints. Personally I don't think SubjectAltName has any value at all in the long-run, as it just adds confusion (i.e. multiple places to look for identity information). An ID-certificate does typically only need to contain a CN and some unique identity tag and an e-mail address is such an option. OID.2.5.4.5 is another. Once upon a time the idea was that a certificate should contain your entire personal profile but that's got totally out of style since the advent of on-line operation, and then the Subject field continues to be completely satisfactory as the *only* container of identity data. PKI-Politics-- Anders ----- Original Message ----- From: "Michael Helm" To: ; Sent: Friday, November 02, 2001 17:11 Subject: EmailAddress history question Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL ------=_NextPart_000_0024_01C163D9.FF7930B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQSDCCAjww ggGlAhAyUDPPUNFW81yBrWVcT8glMA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yMDAxMDcyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQIFAAOBgQBLRGZgaGTkmBvzsHLm lYl83XuzlcAdLtjYGdAtND3GUJoQhoyqPzuoBPw3UpXD2cnbzfKGBsSxG/CCiDBCjhdQHGR6uD6Z SXSX/KwCQ/uWDFYEJQx8fIedJKfY8DIptaTfXaJMxRYyqEL2Raa2Nrngv2U2k8LS12vc3lnWojX4 RTCCAw0wggK3oAMCAQICCmFWt1cAAgAAAHAwDQYJKoZIhvcNAQEFBQAwgYsxKDAmBgkqhkiG9w0B CQEWGWFuZGVycy5ydW5kZ3JlbkB0ZWxpYS5jb20xCzAJBgNVBAYTAlNFMRAwDgYDVQQHEwdVcHBz YWxhMQ8wDQYDVQQKEwZYLVNpZ24xLzAtBgNVBAMTJlgtU2lnbiBQZXJzb25hbCBFbGVjdHJvbmlj IEtleSBUZXN0LUNBMB4XDTAxMDQwNDA4NTczMFoXDTAyMDQwNDA5MDczMFowczEoMCYGCSqGSIb3 DQEJARYZYW5kZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1Vw cHNhbGExDzANBgNVBAoTBlgtU2lnbjEXMBUGA1UEAxMOQVIgU01JTUUgVEVMSUEwXDANBgkqhkiG 9w0BAQEFAANLADBIAkEAlFB6o+q3ZuHlC2YNnVMnuTTnncmxoyLEazY3SwxY2gE+4AO6LZrBMR1N 074mu/MxMwgzB5IpeCiBILtXIbfafwIDAQABo4IBEjCCAQ4wDgYDVR0PAQH/BAQDAgTwMBMGA1Ud JQQMMAoGCCsGAQUFBwMEMB0GA1UdDgQWBBSCN7msYKhh36djrN0b61Q3yIY7vzCBxwYDVR0jBIG/ MIG8gBQmBkGTiydxP9r5cSoaPxRdzJrARqGBkaSBjjCBizEoMCYGCSqGSIb3DQEJARYZYW5kZXJz LnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGExDzANBgNV BAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5IFRlc3Qt Q0GCEHgYPc/vd9C1ROt6RgVIkm4wDQYJKoZIhvcNAQEFBQADQQCn87bztp9xv5jMp1l9pJd4UJun 5SVjKvtZDPf36TUJ4wxA3KyJHY05Zi0+U4mqnWuXg1R3g45Y1eG/Za1j0sJRMIIDHjCCAsigAwIB AgIQeBg9z+930LVE63pGBUiSbjANBgkqhkiG9w0BAQUFADCBizEoMCYGCSqGSIb3DQEJARYZYW5k ZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGExDzAN BgNVBAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5IFRl c3QtQ0EwHhcNMDAwMzA4MjI0NjA3WhcNMDYwMzIyMTg0OTM4WjCBizEoMCYGCSqGSIb3DQEJARYZ YW5kZXJzLnJ1bmRncmVuQHRlbGlhLmNvbTELMAkGA1UEBhMCU0UxEDAOBgNVBAcTB1VwcHNhbGEx DzANBgNVBAoTBlgtU2lnbjEvMC0GA1UEAxMmWC1TaWduIFBlcnNvbmFsIEVsZWN0cm9uaWMgS2V5 IFRlc3QtQ0EwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAyjzzgYvBhX+zmm6v5aMcXpKTCizrdn5R qJUKoknFYGPnanr2PUv8qpFr+vSO+N42Wun3G2cHrnxRsKGM+EYjGwIDAQABo4IBBDCCAQAwCwYD VR0PBAQDAgHGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFCYGQZOLJ3E/2vlxKho/FF3MmsBG MIGuBgNVHR8EgaYwgaMwUqBQoE6GTC1odHRwOi8vYXJwb3J0L0NlcnRFbnJvbGwvWC1TaWduJTIw UGVyc29uYWwlMjBFbGVjdHJvbmljJTIwS2V5JTIwVGVzdC1DQS5jcmwwTaBLoEmGRy1maWxlOi8v XFxhcnBvcnRcQ2VydEVucm9sbFxYLVNpZ24gUGVyc29uYWwgRWxlY3Ryb25pYyBLZXkgVGVzdC1D QS5jcmwvMBAGCSsGAQQBgjcVAQQDAgECMA0GCSqGSIb3DQEBBQUAA0EAHI/iB30qaHfi9n6AEmx7 agQG425D6ttndvNPuC32lonYCEJ5YQM/NcpiVXGJtQpOKVwCNnfrpObb9Plqa0z1qDCCA2IwggLL oAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UEBhMCVVMxFzAV BgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4MDUxMjIzNTk1OVowgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVm LixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJ AoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJvnFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRC q8CikqtEXKpC8IIOAukv+8I7u77JJwpdtrA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP8 4GW6p7F+78nbN2rISsgJBuSZAgMBAAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+ MDwGC2CGSAGG+EUBBwEBMC0wKwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEwMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmww CwYDVR0PBAQDAgEGMBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4 oLje6VNkIbzkTCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulb Larh3s+sMVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr 51a+i+P7FTCCBGswggPUoAMCAQICEG6mb61fMt78LqBdUcww9q4wDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gQnkgUmVm LixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIEluZGl2aWR1YWwg U3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDExMTAyMDAwMDAwWhcNMDIwMTAx MjM1OTU5WjCCAQ8xFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIElu Y29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxJzAlBgNVBAsTHkRpZ2l0YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdDEYMBYGA1UEAxQPQW5k ZXJzIFJ1bmRncmVuMSgwJgYJKoZIhvcNAQkBFhlhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4A40wKMrx/CmNhdJ/sySglgM522w9J/rf8PLn0LiK adedf7IAuJn6UMZJleTcphWZx9Rvlxj30KHzYJZ2NEcilRkv1YqjS06HdecNTPPftJGurM1ZOklj GkIHP0+uGQpKGkTMNRf4fIDWvhf1kHBY9F34QsMO2HFBUkIltH5k4wIDAQABo4IBBjCCAQIwCQYD VR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMu MAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAJkBDijSmThoLYBWQ d+5LkhnvYQv92bFEU965Tf66sxAEvTM2JRkPHDiksl06oifXlqtLuyV71eFoTi8cZJ5lh37BBXkb RlNyChk0N7+0uQ6z1fyMpRvtZ8FVmli5Dl09eyOkezoatjPgSjl+F8ONC0dpXlPJnuRZQWsN9PFu WmwxggL0MIIC8AIBATCB4TCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9y eS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENs YXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQbqZv rV8y3vwuoF1RzDD2rjAJBgUrDgMCGgUAoIIBaDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwG CSqGSIb3DQEJBTEPFw0wMTExMDIxOTA3MjhaMCMGCSqGSIb3DQEJBDEWBBT0piMOAY8QU3VWb2nx z0IQXBfUgjBbBgkqhkiG9w0BCQ8xTjBMMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCHTCBqwYJKwYBBAGCNxAE MYGdMIGaMIGLMSgwJgYJKoZIhvcNAQkBFhlhbmRlcnMucnVuZGdyZW5AdGVsaWEuY29tMQswCQYD VQQGEwJTRTEQMA4GA1UEBxMHVXBwc2FsYTEPMA0GA1UEChMGWC1TaWduMS8wLQYDVQQDEyZYLVNp Z24gUGVyc29uYWwgRWxlY3Ryb25pYyBLZXkgVGVzdC1DQQIKYVa3VwACAAAAcDANBgkqhkiG9w0B AQEFAASBgH8ysjna1pwTcYuEBsBujOGoTZkYgnyQR15Wu8bTgpSTZWyiaCPiFPCu65YbZt2nQAmN GOQ1DZRTBmqorauUxv5clcjYPfxXt47mBxRvt7uvunokNGkh99WOmY5iU1WEnA7I1EeObj0FwedN vZCwScd2Zp9CiVYR5Rgl6esK+f/dAAAAAAAA ------=_NextPart_000_0024_01C163D9.FF7930B0-- Received: by above.proper.com (8.11.6/8.11.3) id fA2I7Ct06117 for ietf-smime-bks; Fri, 2 Nov 2001 10:07:12 -0800 (PST) Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2I7A806112; Fri, 2 Nov 2001 10:07:11 -0800 (PST) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id NAA27052; Fri, 2 Nov 2001 13:06:32 -0500 (EST) Mime-Version: 1.0 X-Sender: kent@po1.bbn.com Message-Id: In-Reply-To: <200111021611.IAA06121@fionn.es.net> References: <200111021611.IAA06121@fionn.es.net> Date: Fri, 2 Nov 2001 13:05:57 -0500 To: helm@fionn.es.net From: Stephen Kent Subject: Re: EmailAddress history question Cc: ietf-pkix@imc.org, ietf-smime@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 8:11 AM -0800 11/2/01, Michael Helm wrote: >Once upon a time , email addresses, especially "internet" or >rfc822 addresses, were a common component in X.509 subject names. >But a few years ago they became a deprecated component in PKIX >(RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have >language like this in their respective RFC's: > > The email address SHOULD be in > the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject > distinguished name. > [RFC 2632 sec 3] > >Could someone explain why this happened? I remember the process >at the time... but vaguely. Looking thru old notes & the mail >archives &c led me to a couple of possible explanations: Mike, An e-mail address makes for a good name, but it has its own type, as an alt subject name. An e-mail address is not an appropriate RDN, i.e., people do not construct directory schema in which an e-mail address is a qualifier for a person's directory entry. the e-mail address is an OK directory attribute, but just not an appropriate component of a DN. The convention that arose for embedding an e-mail address in a DN was a short-term fix that has unfortunate implications when considered in a larger context. Thus the PKIX standards deprecate it. Steve Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id fA2GBSe21767 for ietf-smime-bks; Fri, 2 Nov 2001 08:11:28 -0800 (PST) Received: from fionn.es.net (fionn.es.net [198.128.1.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id fA2GBR821763; Fri, 2 Nov 2001 08:11:27 -0800 (PST) Received: from fionn.es.net (localhost.es.net [127.0.0.1]) by fionn.es.net (LBNLMWH19/LBNLMWH11/ESOCF2) with ESMTP id IAA06121; Fri, 2 Nov 2001 08:11:28 -0800 (PST) Message-Id: <200111021611.IAA06121@fionn.es.net> X-Authentication-Warning: fionn.es.net: Host localhost.es.net [127.0.0.1] claimed to be fionn.es.net To: ietf-pkix@imc.org, ietf-smime@imc.org Reply-to: helm@fionn.es.net Subject: EmailAddress history question Date: Fri, 02 Nov 2001 08:11:28 -0800 From: Michael Helm Sender: owner-ietf-smime@mail.imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Once upon a time , email addresses, especially "internet" or rfc822 addresses, were a common component in X.509 subject names. But a few years ago they became a deprecated component in PKIX (RFC 2459 sec 4.1.2.6) and S/MIME v3. Both of these have language like this in their respective RFC's: The email address SHOULD be in the subjectAltName [X.509v3] extension, and SHOULD NOT be in the subject distinguished name. [RFC 2632 sec 3] Could someone explain why this happened? I remember the process at the time... but vaguely. Looking thru old notes & the mail archives &c led me to a couple of possible explanations: attribute EmailAddress added another string type, complicating parsing [but what about other allowed attributes] email addresses in general usually bring in their own hierarchy, which may be askew from the directory [so?] the email address + common name implies a path thru the directory, which doesn't really exist ; eg cn=mike,e=mike@foo implies there is a node e=mike@foo containing a leaf node cn=mike [As a directory person, _I_ wouldn't think that way:^)] None of these seem terribly convincing, except perhaps the middle one. Are there better arguments? I need to explain this to folks who know this capability exists in CA's and / or remember using or seeing cert subjects with email attributes in them. During the period when this was being debated I really wasn't much concerned with it & don't remember the issues very well. For that matter I personally don't care one way or the other but don't want to issue certs with deprecated contents any longer than necessary. Thanks, ==mwh Michael Helm ESnet/LBNL