From owner-ietf-smime@imc.org Wed Dec 1 18:02:42 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08844 for ; Wed, 1 Dec 1999 18:02:41 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA29539 for ietf-smime-bks; Wed, 1 Dec 1999 14:12:55 -0800 (PST) Received: from gandalf.trustpoint.com (IDENT:root@gandalf.trustpoint.com [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29535 for ; Wed, 1 Dec 1999 14:12:53 -0800 (PST) Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id OAA12502; Wed, 1 Dec 1999 14:15:24 -0800 From: "John C. Kennedy" To: "Robert Zuccherato" , Cc: "'Burt Kaliski'" , "'Linn, John'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Wed, 1 Dec 1999 14:20:42 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0050_01BF3C07.3DDAF2A0" In-Reply-To: <01E1D01C12D7D211AFC70090273D20B101063182@sothmxs06.entrust.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0050_01BF3C07.3DDAF2A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0051_01BF3C07.3DDAF2A0" ------=_NextPart_001_0051_01BF3C07.3DDAF2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, My concerns about alignment and attribution with the X9.42 draft stated recently on the mailing list are applicable here. I suggest replacing [x942] with [RFC2631], or something similar. RFC 2631 is currently, and presumably will remain, the normative reference; not the ANSI draft. Even if X9.42 ever becomes a standard, RFC2631 will continue to profile or otherwise approximate it but still remain the normative reference. -John ------=_NextPart_001_0051_01BF3C07.3DDAF2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

Robert,

My concerns about = alignment and attribution with the X9.42 draft=20 stated recently on the = mailing list=20 are applicable here.  I = suggest=20 replacing [x942] with [RFC2631], = or=20 something similar. RFC 2631 is=20 currently,=20 and presumably will remain, the normative reference; not the ANSI draft.  Even if X9.42 ever becomes a standard, = RFC2631=20 will continue to profile or otherwise approximate it but still = remain the=20 normative reference.

-John

------=_NextPart_001_0051_01BF3C07.3DDAF2A0-- ------=_NextPart_000_0050_01BF3C07.3DDAF2A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMjAxMjIy MDM4WjAjBgkqhkiG9w0BCQQxFgQUZ8pIkCg/YcTD6w7yjV/WgdfyH6YwWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgEmxugXn2tk7dXrJZSbLRYJh4qvIvOT/moZiNrT+KBdWKbUiKcYmCylX G0JzOGT0dDdr4Ts00nj3OeQaPsu/7utRtnpyX17JVfgiGQ1dnPFAumg/SnM74wvEqylDoHRf9EKh HGXfSIZL4my7s04wq75rfK1L/8dfLPg7qAM+UfGiAAAAAAAA ------=_NextPart_000_0050_01BF3C07.3DDAF2A0-- From owner-ietf-smime@imc.org Thu Dec 2 12:01:16 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26460 for ; Thu, 2 Dec 1999 12:01:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01371 for ietf-smime-bks; Thu, 2 Dec 1999 08:09:00 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01367 for ; Thu, 2 Dec 1999 08:08:59 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Dec 1999 16:09:49 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA01916; Thu, 2 Dec 1999 11:11:26 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Dec 1999 11:13:02 -0500 Message-ID: From: "Linn, John" To: "'Robert Zuccherato'" , ietf-smime@imc.org Cc: "'Burt Kaliski'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 11:17:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert, Thanks for your quick and thoughful consideration of the comments. Your responses look good; we've a residual content-level observation to make on only one item: [Sec. 4] Re: "This isn't clear to me. For example, if an attacker modified both public keys to be yb=ya=1 and the parties authenticated each other over a telephone conversation in which they read out the agreed upon key. Now, they will both agree on the same key and they will have a certain level of authentication, but the attacker will be able to eavesdrop. Thus, it is important that each party's *public key* be authenticated, which is the point I was trying to make with this section. However, I agree that the way things are presently worded may be misleading. I will change the first sentence of the second paragraph to "In some ephemeral-ephemeral key agreements protection may be required for both entities." " Good points. As you observe, E-E gives an attacker more flexibility since both parties' public keys can be changed and they can be coerced into computing the same key from a small space. In E-S, only the sender's public key can be changed, and only the recipient can be coerced by an outsider attacker into computing a key from a small space. While this may be apparent, it seems useful to state explicitly for purposes of clarifying comparison. [Sec. 3, minor editorial] Re: How about if I add a sentence following the first paragraph of Section 3 stating "Implementer's should note that some of the procedures described in this section may be the subject of patents or pending patents." "Implementer's" -> "Implementers". --jl From owner-ietf-smime@imc.org Thu Dec 2 12:53:04 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23501 for ; Thu, 2 Dec 1999 12:53:03 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01992 for ietf-smime-bks; Thu, 2 Dec 1999 08:59:53 -0800 (PST) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01988 for ; Thu, 2 Dec 1999 08:59:51 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 12:02:00 -0500 Message-ID: <01E1D01C12D7D211AFC70090273D20B101063194@sothmxs06.entrust.com> From: Robert Zuccherato To: ietf-smime@imc.org, "'John C. Kennedy'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 12:01:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3CE6.F23F871C" Sender: owner-ietf-smime@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_01BF3CE6.F23F871C Content-Type: text/plain John; Actually, the [x942] reference points to: [x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in progress. Which was the Internet Draft for RFC 2631, not the X9.42 draft. All of the references are being updated to point to the appropriate RFCs. Robert. > ---------- > From: John C. Kennedy[SMTP:jkennedy@trustpoint.com] > Sent: Wednesday, December 01, 1999 5:20 PM > To: Robert Zuccherato; ietf-smime@imc.org > Cc: 'Burt Kaliski'; 'Linn, John' > Subject: RE: Working Group Last Call: > draft-ietf-smime-small-subgroup-02.t xt > > RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t > xtRobert, > > My concerns about alignment and attribution with the X9.42 draft stated > recently on the mailing list are applicable here. I suggest replacing > [x942] with [RFC2631], or something similar. RFC 2631 is currently, and > presumably will remain, the normative reference; not the ANSI draft. Even > if X9.42 ever becomes a standard, RFC2631 will continue to profile or > otherwise approximate it but still remain the normative reference. > > -John > > > ------_=_NextPart_001_01BF3CE6.F23F871C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

John;

Actually, the [x942] = reference points to:

[x942] E. Rescorla, = "Diffie-Hellman Key Agreement Method", = draft-ietf-smime-x942-0X.txt, work in progress.

Which was the = Internet Draft for RFC 2631, not the X9.42 draft.  All of the = references are being updated to point to the appropriate = RFCs.

        Robert.

    ----------
    From:   = John C. = Kennedy[SMTP:jkennedy@trustpoint.com]
    Sent:   = Wednesday, December 01, 1999 5:20 = PM
    To: =     Robert = Zuccherato; ietf-smime@imc.org
    Cc: =     'Burt = Kaliski'; 'Linn, John'
    Subject: =        RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

    RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t
    xtRobert,

    My concerns about alignment and = attribution with the X9.42 draft stated
    recently on the mailing list are = applicable here.  I suggest replacing
    [x942] with [RFC2631], or something = similar. RFC 2631 is currently, and
    presumably will remain, the normative = reference; not the ANSI draft.  Even
    if X9.42 ever becomes a standard, = RFC2631 will continue to profile or
    otherwise approximate it but still = remain the normative reference.

    -John



------_=_NextPart_001_01BF3CE6.F23F871C-- From owner-ietf-smime@imc.org Thu Dec 2 13:53:11 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23443 for ; Thu, 2 Dec 1999 13:53:09 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02654 for ietf-smime-bks; Thu, 2 Dec 1999 09:51:18 -0800 (PST) Received: from gandalf.trustpoint.com (IDENT:root@gandalf.trustpoint.com [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02648 for ; Thu, 2 Dec 1999 09:51:17 -0800 (PST) Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id JAA15698; Thu, 2 Dec 1999 09:53:51 -0800 From: "John C. Kennedy" To: "Robert Zuccherato" Cc: Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.txt Date: Thu, 2 Dec 1999 09:59:10 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <01E1D01C12D7D211AFC70090273D20B101063194@sothmxs06.entrust.com> Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000B_01BF3CAB.DDAF7180" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF3CAB.DDAF7180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01BF3CAB.DDB40560" ------=_NextPart_001_000C_01BF3CAB.DDB40560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, I understand what it was pointing to. My suggestion was simply to change the reference tag itself, not the reference. Referencing RFC 2631 by [x942] is misleading since the former is only a profiled approximation of the latter. Regards, -John -----Original Message----- From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com] Sent: Thursday, December 02, 1999 9:02 AM To: ietf-smime@imc.org; 'John C. Kennedy' Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt John; Actually, the [x942] reference points to: [x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in progress. Which was the Internet Draft for RFC 2631, not the X9.42 draft. All of the references are being updated to point to the appropriate RFCs. Robert. ---------- From: John C. Kennedy[SMTP:jkennedy@trustpoint.com] Sent: Wednesday, December 01, 1999 5:20 PM To: Robert Zuccherato; ietf-smime@imc.org Cc: 'Burt Kaliski'; 'Linn, John' Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, My concerns about alignment and attribution with the X9.42 draft stated recently on the mailing list are applicable here. I suggest replacing [x942] with [RFC2631], or something similar. RFC 2631 is currently, and presumably will remain, the normative reference; not the ANSI draft. Even if X9.42 ever becomes a standard, RFC2631 will continue to profile or otherwise approximate it but still remain the normative reference. -John ------=_NextPart_001_000C_01BF3CAB.DDB40560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt
Robert,
 
I=20 understand what it was pointing to.  My suggestion was simply to = change the=20 reference tag itself, not the reference.  Referencing RFC 2631 by = [x942] is=20 misleading since the former is only a profiled approximation of the=20 latter.
 
Regards,
 
-John
 
-----Original Message-----
From: Robert Zuccherato=20 [mailto:robert.zuccherato@entrust.com]
Sent: Thursday, = December 02,=20 1999 9:02 AM
To: ietf-smime@imc.org; 'John C.=20 Kennedy'
Subject: RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t xt

John;

Actually, the [x942] = reference points=20 to:

[x942] E. Rescorla, = "Diffie-Hellman=20 Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in = progress.=20

Which was the Internet = Draft for RFC=20 2631, not the X9.42 draft.  All of the references are being = updated to=20 point to the appropriate RFCs.

        Robert.

    ---------- =
    From:   John C.=20 Kennedy[SMTP:jkennedy@trustpoint.com]
    Sent:   Wednesday, December 01, 1999 5:20 = PM=20
    To: =    =20 Robert Zuccherato;=20 ietf-smime@imc.org
    Cc:     'Burt Kaliski'; 'Linn, John'
    Subject:        = RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t xt

    RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t
    xtRobert,

    My concerns about alignment and = attribution with=20 the X9.42 draft stated
    recently on the=20 mailing list are applicable here.  I suggest replacing =
    [x942] with [RFC2631], or something similar. = RFC 2631 is=20 currently, and
    presumably = will remain,=20 the normative reference; not the ANSI draft.  Even =
    if X9.42 ever becomes a standard, RFC2631 will = continue to=20 profile or
    otherwise = approximate it but=20 still remain the normative reference.

    -John=20



------=_NextPart_001_000C_01BF3CAB.DDB40560-- ------=_NextPart_000_000B_01BF3CAB.DDAF7180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMjAyMTc1 OTA0WjAjBgkqhkiG9w0BCQQxFgQU/R6wG84SN5XeYyZW6bHC1NymRn8wWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgCgajzJQ7XoxzFy/FUYFPzrBHEj/sAWJgRfZn4JDxWn0Rc8Ji7TOIBU6 W8na1o2sdVIaD2lHrJ6K18FQuRwSaQ1FgI/JAkAtLDwePvRHOrVsAewCphYnOou7nz3DruTAPiTV xstRMSLc7jZb2tF9ilvZQTnKapEK6c+lXOoCcPXFAAAAAAAA ------=_NextPart_000_000B_01BF3CAB.DDAF7180-- From owner-ietf-smime@imc.org Thu Dec 2 15:05:01 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28676 for ; Thu, 2 Dec 1999 15:05:00 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03899 for ietf-smime-bks; Thu, 2 Dec 1999 11:15:39 -0800 (PST) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03895 for ; Thu, 2 Dec 1999 11:15:37 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 14:17:46 -0500 Message-ID: <01E1D01C12D7D211AFC70090273D20B101063196@sothmxs06.entrust.com> From: Robert Zuccherato To: ietf-smime@imc.org, "'Linn, John'" Cc: "'Burt Kaliski'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 14:17:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3CF9.EA2CB528" Sender: owner-ietf-smime@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_01BF3CF9.EA2CB528 Content-Type: text/plain John; I will add your comment below as the second paragraph of Section 4. You are correct, it does clarify the discussion. Robert. > ---------- > From: Linn, John[SMTP:jlinn@rsasecurity.com] > Sent: Thursday, December 02, 1999 11:17 AM > To: 'Robert Zuccherato'; ietf-smime@imc.org > Cc: 'Burt Kaliski' > Subject: RE: Working Group Last Call: > draft-ietf-smime-small-subgroup-02.t xt > > Robert, > > Thanks for your quick and thoughful consideration of the comments. Your > responses look good; we've a residual content-level observation to make on > only one item: > > [Sec. 4] > > Re: "This isn't clear to me. For example, if an attacker modified both > public keys to be yb=ya=1 and the parties authenticated each other over a > telephone conversation in which they read out the agreed upon key. Now, > they > will both agree on the same key and they will have a certain level of > authentication, but the attacker will be able to eavesdrop. Thus, it is > important that each party's *public key* be authenticated, which is the > point I was trying to make with this section. However, I agree that the > way > things are presently worded may be misleading. I will change the first > sentence of the second paragraph to "In some ephemeral-ephemeral key > agreements protection may be required for both entities." " > > Good points. As you observe, E-E gives an attacker more flexibility since > both parties' public keys can be changed and they can be coerced into > computing the same key from a small space. In E-S, only the sender's > public > key can be changed, and only the recipient can be coerced by an outsider > attacker into computing a key from a small space. While this may be > apparent, it seems useful to state explicitly for purposes of clarifying > comparison. > > [Sec. 3, minor editorial] > > Re: How about if I add a sentence following the first paragraph of Section > 3 > stating "Implementer's should note that some of the procedures described > in > this section may be the subject of patents or pending patents." > > "Implementer's" -> "Implementers". > > --jl > > ------_=_NextPart_001_01BF3CF9.EA2CB528 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

John;

I will add your = comment below as the second paragraph of Section 4.  You are = correct, it does clarify the discussion.

        Robert.

    ----------
    From:   = Linn, = John[SMTP:jlinn@rsasecurity.com]
    Sent:   = Thursday, December 02, 1999 11:17 = AM
    To: =     'Robert = Zuccherato'; ietf-smime@imc.org
    Cc: =     'Burt = Kaliski'
    Subject: =        RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

    Robert,

    Thanks for your quick and thoughful = consideration of the comments.  Your
    responses look good; we've a residual = content-level observation to make on
    only one item:

    [Sec. 4]

    Re: "This isn't clear to me. For = example, if an attacker modified both
    public keys to be yb=3Dya=3D1 and the = parties authenticated each other over a
    telephone conversation in which they = read out the agreed upon key. Now, they
    will both agree on the same key and = they will have a certain level of
    authentication, but the attacker will = be able to eavesdrop. Thus, it is
    important that each party's *public = key* be authenticated, which is the
    point I was trying to make with this = section. However, I agree that the way
    things are presently worded may be = misleading. I will change the first
    sentence of the second paragraph to = "In some ephemeral-ephemeral key
    agreements protection may be required = for both entities." "

    Good points. As you observe, E-E gives = an attacker more flexibility since
    both parties' public keys can be = changed and they can be coerced into
    computing the same key from a small = space. In E-S, only the sender's public
    key can be changed, and only the = recipient can be coerced by an outsider
    attacker into computing a key from a = small space.  While this may be
    apparent, it seems useful to state = explicitly for purposes of clarifying
    comparison.

    [Sec. 3, minor editorial]

    Re: How about if I add a sentence = following the first paragraph of Section 3
    stating "Implementer's should = note that some of the procedures described in
    this section may be the subject of = patents or pending patents."

    "Implementer's" -> = "Implementers".

    --jl
     

------_=_NextPart_001_01BF3CF9.EA2CB528-- From owner-ietf-smime@imc.org Mon Dec 6 07:38:03 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02365 for ; Mon, 6 Dec 1999 07:38:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13573 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13569 for ; Mon, 6 Dec 1999 04:02:55 -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 HAA15961; Mon, 6 Dec 1999 07:05:51 -0500 (EST) Message-Id: <199912061205.HAA15961@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-password-01.txt Date: Mon, 06 Dec 1999 07:05:51 -0500 Sender: owner-ietf-smime@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 : Password-based Encryption for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-password-01.txt Pages : 8 Date : 03-Dec-99 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords (and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key). 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-password-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-password-01.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-password-01.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: <19991203121643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-password-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-password-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121643.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Mon Dec 6 07:38:04 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02375 for ; Mon, 6 Dec 1999 07:38:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13567 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13563 for ; Mon, 6 Dec 1999 04:02:49 -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 HAA15887; Mon, 6 Dec 1999 07:05:45 -0500 (EST) Message-Id: <199912061205.HAA15887@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-small-subgroup-03.txt Date: Mon, 06 Dec 1999 07:05:44 -0500 Sender: owner-ietf-smime@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 : Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME Author(s) : R. Zuccherato Filename : draft-ietf-smime-small-subgroup-03.txt Pages : 9 Date : 03-Dec-99 In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as 'small-subgroup' attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-small-subgroup-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-small-subgroup-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-small-subgroup-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: <19991203121631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-small-subgroup-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-small-subgroup-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121631.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Mon Dec 6 07:38:55 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02909 for ; Mon, 6 Dec 1999 07:38:55 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13559 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:41 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13555 for ; Mon, 6 Dec 1999 04:02:40 -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 HAA15802; Mon, 6 Dec 1999 07:05:36 -0500 (EST) Message-Id: <199912061205.HAA15802@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-compression-00.txt Date: Mon, 06 Dec 1999 07:05:35 -0500 Sender: owner-ietf-smime@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 : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-00.txt Pages : 4 Date : 03-Dec-99 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. This document defines a format for using compressed data as a CMS content type. 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-compression-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991203121618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121618.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Mon Dec 6 08:11:43 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02372 for ; Mon, 6 Dec 1999 07:38:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13552 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:34 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13548 for ; Mon, 6 Dec 1999 04:02:32 -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 HAA15719; Mon, 6 Dec 1999 07:05:28 -0500 (EST) Message-Id: <199912061205.HAA15719@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-cmskea-03.txt Date: Mon, 06 Dec 1999 07:05:27 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-03.txt Pages : 10 Date : 03-Dec-99 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word 'subscribe' in the body of the message. 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-cmskea-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-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-cmskea-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: <19991203121601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121601.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Tue Dec 7 15:06:07 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25314 for ; Tue, 7 Dec 1999 15:06:05 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00460 for ietf-smime-bks; Tue, 7 Dec 1999 11:24:30 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00456 for ; Tue, 7 Dec 1999 11:24:29 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA09436; Tue, 7 Dec 1999 11:19:10 -0800 (PST) Message-Id: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 07 Dec 1999 14:17:17 -0500 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: This document has completed Working Group Last Call, and it represents the consensus of the S/MIME Mail Security Working Group. It is ready for IETF Last Call and subsequent publication as an Informational RFC. Title : Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME Author(s) : R. Zuccherato Filename : draft-ietf-smime-small-subgroup-03.txt Pages : 9 Date : 03-Dec-99 Russ From owner-ietf-smime@imc.org Thu Dec 9 15:45:59 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01561 for ; Thu, 9 Dec 1999 15:45:58 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA01623 for ietf-smime-bks; Thu, 9 Dec 1999 12:14:35 -0800 (PST) Received: from 157.22.235.99 ([157.22.235.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA01619; Thu, 9 Dec 1999 12:14:32 -0800 (PST) Received: from [157.22.235.84] by 157.22.235.99 (AppleShare IP Mail Server 6.2) id 30901 via TCP with SMTP; Thu, 09 Dec 1999 12:14:29 -0800 Message-id: <991209121429.3b44e7f.9d16eb63.ASIP6.2.30901@157.22.235.99> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 09 Dec 1999 12:14:29 -0800 Subject: Subscription Request From: "Heidi Slominski" To: Subscriptions Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit I'd greatly appreciate it if you would please forward me the appropriate information for subscribing to/getting the digest for your mail list. Thank you very much! Warm Regards, Heidi Slominski Marketing Coordinator -- Mactivity, Inc. Conference Organizers Tel: 408-354-2500 Fax: 408-354-2571 www.mactivity.com From owner-ietf-smime@imc.org Fri Dec 10 08:42:09 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25788 for ; Fri, 10 Dec 1999 08:42:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA19436 for ietf-smime-bks; Fri, 10 Dec 1999 05:04:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19432 for ; Fri, 10 Dec 1999 05:04:20 -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 IAA09467; Fri, 10 Dec 1999 08:07:37 -0500 (EST) Message-Id: <199912101307.IAA09467@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-cmskea-04.txt Date: Fri, 10 Dec 1999 08:07:36 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-04.txt Pages : 10 Date : 09-Dec-99 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word 'subscribe' in the body of the message. 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-cmskea-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-04.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-cmskea-04.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: <19991209121016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991209121016.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Fri Dec 10 12:39:10 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28531 for ; Fri, 10 Dec 1999 12:39:09 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22156 for ietf-smime-bks; Fri, 10 Dec 1999 08:53:06 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22152 for ; Fri, 10 Dec 1999 08:53:05 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA05812 for ; Fri, 10 Dec 1999 08:54:29 -0800 (PST) Message-Id: <4.2.0.58.19991210114832.009fc220@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 11:53:37 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Elliptic Curve Key Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Lambert briefed the "Elliptic Curve S/MIME" Internet-Draft at the IETF meeting in November. The document is stored in draft-ietf-smime-ecc-00.txt, and it includes EC algorithms for digital signatures and key management. The EC Diffie-Hellman (D-H) is based on ANSI X9.63, and the EC Digital Signature Algorithm is based on ANSI X9.62. During his briefing, Paul stated that there is one issue. The Internet-Draft includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. I want this thread to begin the discussion for the selection... From owner-ietf-smime@imc.org Fri Dec 10 15:43:31 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02787 for ; Fri, 10 Dec 1999 15:43:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA24758 for ietf-smime-bks; Fri, 10 Dec 1999 12:08:36 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24754 for ; Fri, 10 Dec 1999 12:08:32 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA09680; Fri, 10 Dec 1999 11:58:02 -0800 (PST) Message-Id: <4.2.0.58.19991210145504.009fabf0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 14:56:28 -0500 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Ready for IETF Last Call: draft-ietf-smime-cmskea-04.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: This document has completed Working Group Last Call, and it represents the consensus of the S/MIME Mail Security Working Group. It is ready for IETF Last Call and subsequent publication as an Informational RFC. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-04.txt Pages : 10 Date : 09-Dec-99 Russ From owner-ietf-smime@imc.org Sat Dec 11 19:33:30 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00319 for ; Sat, 11 Dec 1999 19:33:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15287 for ietf-smime-bks; Sat, 11 Dec 1999 15:38:10 -0800 (PST) Received: from jis.ne.mediaone.net (jis.ne.mediaone.net [24.218.230.94]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15283 for ; Sat, 11 Dec 1999 15:38:08 -0800 (PST) Received: from jis.ne.mediaone.net (localhost [127.0.0.1]) by jis.ne.mediaone.net (8.8.7/8.8.7) with SMTP id RAA01652; Sat, 11 Dec 1999 17:30:20 -0500 From: Jeffrey Schiller Date: Sat, 11 Dec 1999 22:30:20 GMT Message-ID: <19991211.22302000@jis.ne.mediaone.net> Subject: Re: Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt To: Russ Housley CC: jis@mit.edu, MLeech@nortel.ca, ietf-smime@imc.org In-Reply-To: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> References: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> X-Mailer: Mozilla/4.5 [en] (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA15284 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 8bit I have requested that this document be placed on this week's agenda. -Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 12/7/99, 7:17:17 PM, Russ Housley wrote regarding Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt: > Jeff and Marcus: > This document has completed Working Group Last Call, and it represents the > consensus of the S/MIME Mail Security Working Group. It is ready for IETF > Last Call and subsequent publication as an Informational RFC. > Title : Methods for Avoiding the 'Small-Subgroup' Attacks on > the Diffie-Hellman Key Agreement Method for S/MIME > Author(s) : R. Zuccherato > Filename : draft-ietf-smime-small-subgroup-03.txt > Pages : 9 > Date : 03-Dec-99 > > Russ From owner-ietf-smime@imc.org Wed Dec 15 10:12:58 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04300 for ; Wed, 15 Dec 1999 10:12:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA28486 for ietf-smime-bks; Wed, 15 Dec 1999 06:39:49 -0800 (PST) Received: from gauntlet.corecom.com ([206.74.64.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28475 for ; Wed, 15 Dec 1999 06:39:46 -0800 (PST) Received: by gauntlet.corecom.com; id KAA18584; Wed, 15 Dec 1999 10:07:31 -0500 (EST) Received: from unknown(207.86.152.184) by gauntlet.corecom.com via smap (V4.2) id xmad18567; Wed, 15 Dec 99 10:06:47 -0500 Message-Id: <4.1.19991215091557.00a9da60@mail2.netreach.net> X-Sender: davep@hargray.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 15 Dec 1999 09:16:27 -0500 To: ietf-smime@imc.org From: Dave Piscitello Subject: Internet Security Conference, Call for Papers, Abstracts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Fourth Internet Security Conference will be held April 24-28, 2000 in San Jose, CA, at the Fairmont Hotel. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. For April, we have invited a few original papers from past TISC workshop instructors and speakers. Accepted papers will be presented at the conference. We cordially invite you to submit a session abstract for consideration, or if you prefer, to present a topic as a panel member. We encourage you to submit abstracts and topics by December 20. Further information can be found at http://tisc.corecom.com. Or send your proposal to me directly (mailto:dave@corecom.com). We look forward to your participation. Thank you. Warm Regards, Dave Piscitello On behalf of the TISC Advisory Board From owner-ietf-smime@imc.org Wed Dec 15 11:27:07 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17892 for ; Wed, 15 Dec 1999 11:27:06 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA02767 for ietf-smime-bks; Wed, 15 Dec 1999 07:43:29 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02762 for ; Wed, 15 Dec 1999 07:43:28 -0800 (PST) Received: by sentry; id KAA01228; Wed, 15 Dec 1999 10:48:14 -0500 (EST) Received: from unknown(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001222; Wed, 15 Dec 99 10:47:18 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id KAA29904 for ietf-smime@imc.org; Wed, 15 Dec 1999 10:46:32 -0500 (EST) Date: Wed, 15 Dec 1999 10:46:32 -0500 (EST) From: "David M. Balenson" Message-Id: <199912151546.KAA29904@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ietf-smime@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 Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th 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. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@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@imc.org Mon Dec 20 13:50:30 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11733 for ; Mon, 20 Dec 1999 13:50:29 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23891 for ietf-smime-bks; Mon, 20 Dec 1999 09:35:28 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23887 for ; Mon, 20 Dec 1999 09:35:26 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Dec 1999 12:40:18 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF315A05E5@wfhqex03.wang.com> From: "Pawling, John" To: "'SMIME WG'" Subject: Final 11 November 1999 S/MIME WG Minutes Date: Mon, 20 Dec 1999 12:40:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message includes the minutes of the IETF S/MIME Working Group meeting held on 11 November 1999 in Washington, D.C. All briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters. Reported by John Pawling. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody objected to the agenda. Introductions Russ Housley RFC 2630 - 2634 Status Russ Housley Charter Revision Russ Housley Small Subgroup Attack Mike Just CERTDIST Draft Discussion Jim Schaad DOMSEC Draft Discussion Bill Ottaway CMS/ESS Examples Paul Hoffman Security Policies and Labels Weston Nicolls KEA and SKIPJACK Algorithms John Pawling CAST-128 Algorithm Carlisle Adams Elliptic Curve Algorithms Paul Lambert ETSI Electronic Signatures Denis Pinkas S/MIME Freeware Library John Pawling Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RFC 2630-2634 Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 The aforementioned documents must meet the following requirements to become Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases Stable, Mature, and Useful: - Strong belief that the specification is mature and will be useful - Must be well-understood and known to be quite stable - semantics and basis for developing an implementation - may still require additional or more widespread field experience - Considered to be a final specification - changes are likely to be made only to solve specific problems - reasonable for vendors to deploy implementations Russ noted that no significant errors had been reported to the aforementioned RFCs. Implementations: - At least two independent and interoperable implementations from different code bases: - interoperable means to be functionally equivalent or interchangeable - applies to all of the options and features - Working Group chair responsible for documenting specific implementations and interoperability testing: - support of each of the individual options and features - submitted to Area Director with protocol action request Way Forward: - CMS and ESS Examples I-D providing informal inputs - Jim Schaad is developing matrices for RFCs 2630-2634 - Paul Hoffman has offered to coordinate interoperability testing Paul Hoffman stated that another requirement for a Proposed Standard to become a Draft Standard is that all normative references to other RFCs must refer to Draft Standards. RFC 2632 includes a normative reference to RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not become a Draft Standard until RFC 2459 becomes one. Russ agreed with Paul's statement that a Draft Standard cannot include a normative reference to a document that has not achieved at least Draft Standard status. Russ agreed that since RFC 2632 relies on RFC 2459, then RFC 2459 will have to become a Draft Standard before or at the same time as RFC 2632. Paul pointed out that each requirement must be implemented by at least two independent code bases such that they are interoperable, but a single code base does not need to implement all of the requirements. Russ agreed that the entire set of requirements could be implemented by a variety of sources. The matrices being initiated by Jim Schaad will indicate which features have and have not been implemented. John Pawling asked if there were any plans to change the Attribute Certificate (AC) syntax used in RFC 2630. Currently, RFC 2630 imports the AC syntax from the 1997 X.509 Recommendation, but the draft IETF PKIX Attribute Certificate Profile Internet Draft specifies a different AC syntax. Russ pointed out that if RFC 2630 imported the AC syntax from the PKIX AC Profile, then RFC 2630 could not achieve Draft Standard status until the PKIX AC Profile achieved that status (which Russ believes will be at least six months). Russ stated that he believed that RFC 2630 should continue to import the AC syntax from the 1997 X.509 Recommendation because the other AC syntax is still not stable. He stated that the new features of the new AC syntax don't apply to RFC 2630. The new AC syntax allows for binding attributes to arbitrary objects identified by object identifiers. John pointed out that a new CMS specification could be drafted in the future which could include the new AC syntax once it is stable. Nobody disagreed with Russ' statement that the RFC 2630 AC syntax should not be changed. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Charter Revision - Russ Housley Russ stated that the following work items have been approved since the July S/MIME working group meeting: - Small Subgroup Attack Informational RFC - Additional Algorithm Support: - KEA, SKIPJACK Informational RFC - IDEA, CAST, and ECC Standards Track RFCs - CMS and ESS Examples Informational RFC - CERTDIST Standards Track RFC - Password-based Key Management RecipientInfo Extension Standards Track RFC - Mail List Key Distribution Standards Track RFC - Security Label Usage Informational RFC - DOMSEC Experimental RFC Russ stated that there is another proposed addition: CMS Compressed Proposed Standard RFC. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compression will provide all of these advantages. The proposed schedule is as follows: Oct 1999 - First Compression I-D. Jan 2000 - Compression Last Call. Apr 2000 - Compression Proposed Standard RFC. Russ stated that both IETF Security Area Directors have expressed support for this addition. Russ asked if any attendees knew of any issues, had comments or wished to discuss any related topics, and no one raised anything. Russ asked if there were any patent concerns, and no one raised any patent concerns. Paul Hoffman stated that the previous IP Compression working group had already worked on a compression standard and that the previous MIME working group had purposely avoided the issue of compression. Russ asked if the meeting attendees approved the addition of compression. The majority approved. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Small Subgroup Attack - Mike Just Mike stated that there had not been a new draft of the "Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D since the last meeting. One minor comment was received regarding wordsmithing. Russ asked if the attendees believed that the I-D was ready for working group last call. Nobody objected, so Russ asked that the aforementioned comment be incorporated into a new I-D and then that I-D would be submitted for last call. Russ asked that people please carefully review the I-D. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D (CERTDIST-04), October 20, 1999. He stated that "directory people" had criticized CERTDIST, but had not proposed an alternate solution. Russ noted that the directory folks were complaining because certificates are stored in the directory twice within different attributes. He said that they are concerned that the certificates stored within the two attributes will be different. He also said that they proposed that SupportedAlgorithms could be used. Jim pointed out that the SMIMECapabilities signed attribute could be used to point to a certificate rather than storing the entire certificate. Jim also stated that the method proposed in CERTDIST allows each certificate to claim different algorithm preferences. Carlisle Adams asked if the SMIMECapabilities signed attribute is supposed to be tied to a specific certificate. Jim answered that SMIMECapabilities must be tied to a specific key management certificate. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the Domain Security Services Using S/MIME I-D (DOMSEC-03). Bill provided an overview of the DOMSEC concepts and the new features. The new features included: Naming conventions for signing and encryption, and the creation of a NULL signature when there is no originator signature present. Bill's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes the details regarding the issues and proposed solution for each new feature. Bill's goal is that DOMSEC should achieve RFC status in 2000. He would like DOMSEC to describe a solution that will work for a wide variety of organizations. He has received significant feedback from Baltimore, but would like to hear feedback from others. Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CMS/ESS Examples - Paul Hoffman Paul stated that there has been much progress with the "Examples of S/MIME Messages" I-D and that almost all of the examples have been provided for incorporation into the document. He stated that there needs to be more testers of the sample data. He asked that folks please publicize their progress with verifying the sample data. Paul asked if there was any interest in a PKIX Examples Document. There was not much interest shown by the attendees. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Security Policies and Labels - Weston Nicolls Weston stated that he is developing an I-D that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will describe how the ESSSecurityLabel can be used to implement those corporate security policies. It is planned that the document will be an Informational RFC. Weston stated that he has been provided with classification policies for: - Amoco Corporation: - General, Confidential, Highly Confidential - Minimum, Medium, Maximum Integrity - Caterpillar Inc - Public, Confidential Green, Confidential Yellow, Confidential Red - Whirlpool Corporation - Public, Internal, Confidential - Privacy Labels - Security Categories? Jim Schaad pointed out that an example security policy is needed to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. The implication of Jim's statement is that one of the security policies described in Weston's document could be used to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ KEA and SKIPJACK Algorithms - John Pawling John presented the CMS KEA and SKIPJACK Conventions I-D (CMSKEA-02), 29 July 1999. The goal of CMSKEA is to promote interoperability between implementations using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithms with the RFC 2630 enveloped-data and encrypted-data content types. CMSKEA describes a profile for using SKIPJACK and KEA with CMS. It describes modes, key lengths, object identifiers and parameter formats associated with the use of SKIPJACK and KEA with CMS. J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has used the S/MIME Freeware Library with the Fortezza Cryptologic Interface (CI) Library and Fortezza Card to successfully perform interoperability testing with Microsoft. This testing verifies the correctness of the CMSKEA I-D. The "FORTEZZA Card\CI Library Usage With CMS KEA SKIPJACK I-D" text file (available from http://www.jgvandyke.com/services/infosec/sfl.htm) contains hints for using the FORTEZZA Card and FORTEZZA CI Library to meet the CMSKEA requirements. Russ pointed out that CMSKEA is planned to be an Informational RFC. He stated that he would like to issue the working group last call for CMSKEA. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CAST-128 Algorithm for S/MIME - Carlisle Adams Carlisle discussed the "Use of the CAST-128 Encryption Algorithm in S/MIME" I-D, September 1999 (cast-128-00). He stated that this is a short, simple specification. It documents how to use CAST-128 as a content encryption algorithm and a key encryption algorithm. The relevant algorithm object identifiers and parameters are specified. Carlisle stated that there are patents issued and pending regarding the CAST design procedure, but CAST-128 (described in RFC 2144) may be used by anyone for any purpose without paying any royalties or obtaining any licenses as stated in www.ietf.org/ipr.html. He stated that there is no encumbrance in using CAST-128. The same is true for CAST-256 (RFC 2612). Russ pointed out that the CAST-128 document is planned to be on Standards Track. He stated that he would like to issue the working group last call for the document as soon as possible. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Elliptic Curve Algorithms - Paul Lambert Paul briefed the "Elliptic Curve S/MIME" I-D, October 1999 (ECC-00). He stated that the EC algorithms support digital signatures and key management. EC Diffie-Hellman (D-H) is based on ANSI X9.63 and EC Digital Signature Algorithm is based on ANSI X9.62. Paul stated that there is one issue. The I-D includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. Paul's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EC S/MIME I-D. Paul Hoffmann stated his concerns about the patent issues regarding the EC algorithms. He stated that the IPR for the EC algorithms is insufficient for the WG to decide what to do. Paul Lambert stated that Certicom has patents and patent applications that may cover the specification and will include a pointer to the IPR statement in the EC S/MIME I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ETSI Electronic Signatures - Denis Pinkas Denis briefed the "European Electronic Signature Standardisation Initiative". He stated that the European Community plans to vote on the EESSI directive. The directive will cover anything in digital form that can prove the identity of the signer. The goal is to specify technology and standards that are equivalent to a manual signature. The ETSI definition provides "Evidence in a digital form than can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role." The ETSI draft Standard builds upon RFC 2630 and RFC 2634. It defines new signed and unsigned attributes. The Electronic Signature uses signed attributes defined in RFC 2630, RFC 2634 and the draft ETSI standard including: - signature policy ID (reference and hash) (new), - commitment type (new), - content Type [RFC 2630], - signer's physical location (new), - signing time [RFC 2630], - signing certificate reference [RFC 2634], - role attribute (claimed or certified) (new). Denis also briefed regarding the role of time stamping in the EESSI. His briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EESSI. An attendee asked how the verifier can prove the signer's physical location. Denis said that the EESSI specification replicates the services provided by the paper hard copy which is no authentication of the signer's location value. Phillip Hallam-Baker stated that the requirement for the signer to state her location is bogus and is not required in the United Kingdom. An attendee stated that a 760-bit signing key could be compromised in 20 years, so the time stamp signature could be compromised too. Denis said that an authority can re-sign the time stamps with a longer length key or could apply two stamps. Chris Bonatti asked if the signature policy is selected by the signer, what guarantee is there that the verifier will recognize the signature policy. Denis said that the verifier will look for specific values. An attendee asked whether there will be a signature policy distribution point from which people could obtain defined policies. Denis said that service might be provided by the International Chamber of Commerce. An attendee asked if XML would be more useful to describe the signature policy than ASN.1. Denis said that ASN.1 will be used for now, but XML may be used in the future. Phillip Hallam-Baker stated that XML is better for future use. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Freeware Library (SFL) - John Pawling John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. It uses the Crypto++ freeware library to implement RFC 2631. It provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL. The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is now developing the capability for the SFL to use any security library that provides a PKCS #11 interface. Version 1.3 of the SFL was released in October 1999. It was tested on MS Windows 95/NT and Sun Solaris 2.6. It was tested using the mandatory and RSA algorithm suites. VDA continues to enhance the SFL. Organizations can use the SFL as part of their applications without paying any royalties or licensing fees (see SFL Public License). All source code is provided. The VDA-enhanced SNACC ASN.1 software is freely available at http://www.jgvandyke.com/services/infosec/sfl.htm. All other portions of the SFL are available at: http://www.armadillo.huntsville.al.us/software/smime and are export controlled as per U.S. Government Export Administration Regulations (see: http://www.bxa.doc.gov/Encryption/Default.htm). John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software. John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ discussed the work item proposing the use of password-based key management for file encryption. This is documented in the "Password-based Encryption for S/MIME" I-D. The proposal uses PKCS #5 techniques. Russ stated that the working group needs to decide if that proposal will be accepted. He encouraged people to read the document and provide comments. Bob Jueneman stated his concern with the processing of name forms. Bob is concerned that not all applications display all address spec texts. He stated that they may omit, abbreviate or truncate the address spec text. He believes that this should be a joint work item between the PKIX and S/MIME working groups. He stated that properly supporting the address spec requirements is important. He recommends that we allow the use of a personal name form that precedes the address spec. For example, a husband and wife may share an e-mail address, but use different certificates. Paul Hoffman stated that RFC 822 includes a third option that allows comments to be included in parentheses. The third option must be included in any solution. He agreed that this issue needs to be resolved. Bob Jueneman also stated his concern regarding using the same object identifier to indicate two-key triple-DES and three-key triple-DES. He believes that separate object identifiers must be used for export control reasons. Two-key triple-DES may be exportable, but 3-key triple-DES may not be exportable. He said that 168-bit keys (112 effective) need a separate object identifier. Paul Hoffman stated that his understanding is that two-key is 80-bit and three-key is 112 bit (effective). He does not believe that the object identifier should be changed. Russ asked if it would be acceptable to examine the contents of the key to determine if the first and third keys are the same. Bob said that he has to enforce that they are the same. Russ said that it seems to be a receive-side issue, since the send-side controls the formation of the keys. Russ asked if the receive side could examine the keys and stop processing if the first and third keys are different. Paul Hoffman noted the creation of the S/MIME developers mail list for discussing implementation of S/MIME. The new list is a good place to send sample S/MIME messages for interoperability testing. The list is called imc-smime-dev@imc.org. To subscribe, send a message to imc-smime-dev-request@imc.org with the single word "subscribe" in the body of the message. Russ noted that members of the S/MIME mail list don't necessarily need to use S/MIME-enabled e-mail products. Meeting adjourned. From owner-ietf-smime@imc.org Tue Dec 21 10:43:34 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26061 for ; Tue, 21 Dec 1999 10:43:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15031 for ietf-smime-bks; Tue, 21 Dec 1999 07:02:50 -0800 (PST) Received: from v4j31 (user@ts035d22.par-nj.concentric.net [216.112.174.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15026 for ; Tue, 21 Dec 1999 07:02:48 -0800 (PST) Message-Id: <4.2.1.19991220132931.00bbb930@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 20 Dec 1999 16:35:32 -0500 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Mail addresses in S/MIME certs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the DC IETF meeting, Bob Jueneman brought up the issue of different certs for the same address. For instance, two people might use one email address and thus want different certificates. The current S/MIME and PKIX specs allow the email address, not the informational kruft around it, in the subjectAltName for a cert. Do we want to change this? The arguments we heard against this in the PKIX group included: - A CA might check the validity of the email address but not the name - The many formats for the additional information are incredibly confusing and likely to promote lack of interoperability The arguments in favor of using full addresses include: - Ability for multiple people with access to the mailbox to have unique certificates - Increased identification for systems that do more than just check the mailbox Comments? --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-smime@imc.org Tue Dec 21 11:23:16 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09946 for ; Tue, 21 Dec 1999 11:23:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15713 for ietf-smime-bks; Tue, 21 Dec 1999 07:49:01 -0800 (PST) Received: from mail.maxware.nl (mail.maxware.nl [195.193.216.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15707; Tue, 21 Dec 1999 07:48:58 -0800 (PST) X-Internal-ID: 38576DAE0000022F Received: from taita.maxware.nl (195.193.216.133) by mail.maxware.nl (NPlex 2.0.098); 21 Dec 1999 16:58:44 +0100 Message-ID: <04c001bf4bcc$336a9da0$85d8c1c3@maxware.nl> From: "Frank W. Nolden" To: , "Paul Hoffman / IMC" References: <4.2.1.19991220132931.00bbb930@mail.imc.org> Subject: Re: Mail addresses in S/MIME certs Date: Tue, 21 Dec 1999 16:58:19 +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.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-ietf-smime@imc.org Tue Dec 21 22:28:11 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18699 for ; Tue, 21 Dec 1999 22:28:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02070 for ietf-smime-bks; Tue, 21 Dec 1999 18:50:04 -0800 (PST) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02061; Tue, 21 Dec 1999 18:50:02 -0800 (PST) Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991222025417.IWJS26939.mail.rdc1.md.home.com@home.com>; Tue, 21 Dec 1999 18:54:17 -0800 Message-ID: <38603C73.98AF409F@home.com> Date: Tue, 21 Dec 1999 21:50:27 -0500 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs References: <4.2.1.19991220132931.00bbb930@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Paul Hoffman / IMC wrote: > > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium Count me in the "The many formats for the additional information are incredibly confusing and likely to promote lack of interoperability" camp. This, combined with the fact that that cruft is almost infinitely changeable today, and almost never checked by anybody, seems to me to be a sure guarantee of interoperability problems. I don't have any philosophical objections to allowing this, though, and if the S/MIME vendors are convinced that they can get it right and make it all interoperate, I'm willing to be outvoted. But it just strikes me as begging for a failure to communicate. Al Arsenault From owner-ietf-smime@imc.org Tue Dec 21 23:22:51 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20124 for ; Tue, 21 Dec 1999 23:22:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10309 for ietf-smime-bks; Tue, 21 Dec 1999 19:50:09 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10302 for ; Tue, 21 Dec 1999 19:50:07 -0800 (PST) From: John_Payne@motorcity2.lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id XAA21234; Tue, 21 Dec 1999 23:08:22 -0500 (EST) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet2.lotus.com (8.9.3/8.9.3) with SMTP id WAA04476; Tue, 21 Dec 1999 22:51:44 -0500 (EST) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (926.1 11-18-1999)) id 8525684F.00153591 ; Tue, 21 Dec 1999 22:51:39 -0500 X-Lotus-FromDomain: NOTES@ALPHABETA To: "Frank W. Nolden" cc: ietf-smime@imc.org Message-ID: <8525684F.0015354D.00@motorcity2.lotus.com> Date: Tue, 21 Dec 1999 23:59:04 -0500 Subject: Re: Mail addresses in S/MIME certs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry, I am also new to this thread. Where are we going here? A certificate ties a group of attributes (in this case the Subject Alternate Identity of RFC821(or 2) address to public key). Should we be looking at some other binding? Surely in the case described the alternate identity should be some form of Role or MailingList. More than one identity using the same MailingAddress completely blows non-repudiation out of the water unless there is some (out of scope?) work flow process or role identity "Frank W. Nolden" on 12/21/99 10:58:19 AM To: ietf-smime@imc.org, Paul Hoffman/ IMC cc: (bcc: John Payne/CAM/Lotus) Subject: Re: Mail addresses in S/MIME certs Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-ietf-smime@imc.org Wed Dec 22 01:15:21 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22607 for ; Wed, 22 Dec 1999 01:15:20 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA21114 for ietf-smime-bks; Tue, 21 Dec 1999 21:33:14 -0800 (PST) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21106 for ; Tue, 21 Dec 1999 21:33:13 -0800 (PST) Received: from WWILLIAMS1 ([128.33.211.196]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id AAA20572; Wed, 22 Dec 1999 00:37:27 -0500 (EST) From: "Walter Williams" To: , "Frank W. Nolden" Cc: Subject: RE: Mail addresses in S/MIME certs Date: Tue, 21 Dec 1999 23:33:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <8525684F.0015354D.00@motorcity2.lotus.com> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another lurker jumps into the ring..... This begs the question: do certificates identify an individual or a role? There is no effective way for a single certificate to do both. A second question becomes are certificates appropriate for role definition? Certificates are usually valid for a span of years. My role changes constantly, who I am never really has. Role definition might be best left to other objects within a public key infrastructure, such as a directory leaf entry as an example. After all, certificates, while important, do not a pki comprise. The important thing to get right, and this is process not technology, is that the email alias is mine, not ours, if you catch the drift. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of John_Payne@motorcity2.lotus.com Sent: Tuesday, December 21, 1999 11:59 PM To: Frank W. Nolden Cc: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs Sorry, I am also new to this thread. Where are we going here? A certificate ties a group of attributes (in this case the Subject Alternate Identity of RFC821(or 2) address to public key). Should we be looking at some other binding? Surely in the case described the alternate identity should be some form of Role or MailingList. More than one identity using the same MailingAddress completely blows non-repudiation out of the water unless there is some (out of scope?) work flow process or role identity "Frank W. Nolden" on 12/21/99 10:58:19 AM To: ietf-smime@imc.org, Paul Hoffman/ IMC cc: (bcc: John Payne/CAM/Lotus) Subject: Re: Mail addresses in S/MIME certs Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > From owner-ietf-smime@imc.org Wed Dec 22 02:00:40 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26594 for ; Wed, 22 Dec 1999 02:00:40 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22364 for ietf-smime-bks; Tue, 21 Dec 1999 22:28:42 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22360 for ; Tue, 21 Dec 1999 22:28:39 -0800 (PST) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by piglet.dstc.edu.au (8.9.3/8.9.3) with ESMTP id QAA13138; Wed, 22 Dec 1999 16:32:47 +1000 (EST) Message-Id: <199912220632.QAA13138@piglet.dstc.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Walter Williams" Cc: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs In-reply-to: Your message of "Tue, 21 Dec 1999 23:33:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Dec 1999 16:32:47 +1000 From: Dean Povey Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Another lurker jumps into the ring..... > >This begs the question: do certificates identify an individual or a role? >There is no effective way for a single certificate to do both. > >A second question becomes are certificates appropriate for role definition? >Certificates are usually valid for a span of years. My role changes >constantly, who I am never really has. Role definition might be best left >to other objects within a public key infrastructure, such as a directory >leaf entry as an example. After all, certificates, while important, do not >a pki comprise. The important thing to get right, and this is process not >technology, is that the email alias is mine, not ours, if you catch the >drift. > Certificates identify whatever you choose to identify. Certificate Policies specifiythe meaning of the naming in the cert. Attribute Certs are better for dynamic things like roles, as they allow you to separate the management of the role/credential/attribute from the management of the key. An attribute cert is rather like a normal Certificate but does not contain a public key (although it does contain a pointer to it). Unfortunately there is not a lot of support in vendor products yet, but they will get there eventually. From owner-ietf-smime@imc.org Wed Dec 22 07:34:04 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06930 for ; Wed, 22 Dec 1999 07:34:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14540 for ietf-smime-bks; Wed, 22 Dec 1999 03:54:41 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14536 for ; Wed, 22 Dec 1999 03:54:39 -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 GAA06044; Wed, 22 Dec 1999 06:58:54 -0500 (EST) Message-Id: <199912221158.GAA06044@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-seclabel-00.txt Date: Wed, 22 Dec 1999 06:58:54 -0500 Sender: owner-ietf-smime@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 : Implementing Company Classification Policy with the S/MIME Security Label Author(s) : W. Nicolls Filename : draft-ietf-smime-seclabel-00.txt Pages : 8 Date : 21-Dec-99 This document discusses how company security policy for data classification can be mapped to the S/MIME classification label. Actual policies from 3 companies are used to provide worked examples. Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be a bound attribute of the original message content, the encrypted body, or both. The syntax and processing rules for security labels are described in [ESS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-seclabel-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-seclabel-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-seclabel-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991221121534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-seclabel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-seclabel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121534.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-smime@imc.org Wed Dec 22 08:35:40 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09505 for ; Wed, 22 Dec 1999 08:35:39 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA14918 for ietf-smime-bks; Wed, 22 Dec 1999 04:31:34 -0800 (PST) Received: from zeus.nexor.com (zeus.nexor.com [207.86.50.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA14914 for ; Wed, 22 Dec 1999 04:31:33 -0800 (PST) Received: from odysseus.nexor.com by zeus.nexor.com with SMTP (Mailer); Wed, 22 Dec 1999 07:34:47 -0500 Reply-To: "Bob.Johnson" From: Bob Johnson To: Walter Williams , John_Payne , "Frank W. Nolden" Cc: ietf-smime Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 07:36:21 -0500 Message-ID: <000101bf4c79$27568a80$893256cf@odysseus.nexor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit And another de-lurks (apologies in advance for the length)... I won't offer my opinion on the S/MIME technical issues, but perhaps I can cast a bit of light on some of the operational requirements driving this discussion. In the military, you have a definite concept of an organizational role which has to do with the command structure. That role, perhaps "Base Commander", is stable. However, the personnel who are responsible for that role come and go. Much official correspondence is sent and received by this role. Let's say that Col. Smith is currently filling the role of "Base Commander". When he sends an official notice as the Base Commander, it should be signed by that role - not the individual person, Col. Smith. The plot thickens when you realize that "Base Commander" probably has a half-dozen people who are authorized to read messages addressed to the role, and at least 3 or 4 who can send official messages signed by that role. Typically, Col. Smith would draft a message and forward it to a Duty Officer (or secretary) who would "release" it under the authority of the Base Commander (ergo, the concept of an "Organizational Release Authority" shared by several people). And, if Col. Smith is TDY, you can bet that Lt. Col Jones, the Duty Officer, and the base Messaging Center can all read messages addressed to the Base Commander. Remember, however, that Col. Smith also has an identity of his own. If Brig. Gen. Brown wants to send over an itenerary for an upcoming visit that includes dinner, golf, and drinks afterward - he would probably send it to Col. Smith, not "Base Commander". Also, just to confuse things, you might want to send an "eyes-only" type of message to the Base Commander, which could ONLY be read by Col Smith (or whomever happens to "own" that role at the time). So what you have, in data structure terms, would be a network of one-to-many relationships. The Base Commander role is "owned" by Col. Smith. There are a set of individuals who are allowed to read messages addressed to this role, in addition to Col. Smith. There are also a set of individuals who are allowed to release messages signed by this role. These two sets may not be, and in fact usualy are not, identical (e.g. the Messaging Center could read a message to this role, but couldn't release one from this role). Each individual, by inference, could be part of any number of these role release and/or reading lists. For instance, the set of people authorized to work in the base messaging center might be authorized to read messages addressed to darn near every "role" on base. Adding to the confusion - any individual could also be an e-mail administrator, network administrator, directory administrator, security officer, etc, etc, etc. Each of these is an additional role - defined by function, not necessary by command structure. Believe it or not, the above description is exactly what the Canadian Department of National Defence will have to sort out in order to deploy their classified Military Message Handling System (MMHS). So, these are actual, real-world operational requirements that need to be met by S/MIME. By the way - the security will be based on Entrust, which adds a whole 'nother level of complexity. But (as they say) that's another story, for another day. Bob Johnson, NEXOR > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of Walter Williams > Sent: Tuesday, December 21, 1999 11:34 PM > To: John_Payne; Frank W. Nolden > Cc: ietf-smime > Subject: RE: Mail addresses in S/MIME certs > > > Another lurker jumps into the ring..... > > This begs the question: do certificates identify an individual or a role? > There is no effective way for a single certificate to do both. > > A second question becomes are certificates appropriate for role > definition? > Certificates are usually valid for a span of years. My role changes > constantly, who I am never really has. Role definition might be best left > to other objects within a public key infrastructure, such as a directory > leaf entry as an example. After all, certificates, while > important, do not > a pki comprise. The important thing to get right, and this is process not > technology, is that the email alias is mine, not ours, if you catch the > drift. > > Walt Williams > GTE Internetworking > > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of John_Payne@motorcity2.lotus.com > Sent: Tuesday, December 21, 1999 11:59 PM > To: Frank W. Nolden > Cc: ietf-smime@imc.org > Subject: Re: Mail addresses in S/MIME certs > > > > > Sorry, I am also new to this thread. > > Where are we going here? > A certificate ties a group of attributes (in this case the > Subject Alternate > Identity of RFC821(or 2) > address to public key). > Should we be looking at some other binding? > Surely in the case described the alternate identity should be some form of > Role > or MailingList. More than one > identity using the same MailingAddress completely blows > non-repudiation out > of > the water unless there is > some (out of scope?) work flow process or role identity > > > > > "Frank W. Nolden" on 12/21/99 10:58:19 AM > > To: ietf-smime@imc.org, Paul Hoffman/ IMC > cc: (bcc: John Payne/CAM/Lotus) > Subject: Re: Mail addresses in S/MIME certs > > > > Dear All, > > I would see it as follows (but then again I am very new to this discussion > and maybe I am completely off track): > > When two people are using the same email address, the email > address is used > as a role which can be filled by more than one person. In this case there > will be a certificate for the role and certificates for each person. The > certificates for the people will be used in private (or mail sent on > personal title) situations, while the certificate for the role > will be used > in correspondence for this role only. > > This means that both persons can have two certs, i.e. one for the role and > one for themselves, and each of these certs has to be stored in a separate > account or something like that. > > When it is used on this way there is no problem when having the > informational stuff in the subjectAltName. > Regards, > > Frank Nolden > MaXware Benelux BV > > ----- Original Message ----- > From: Paul Hoffman / IMC > To: > Sent: Monday, December 20, 1999 22:35 > Subject: Mail addresses in S/MIME certs > > > > At the DC IETF meeting, Bob Jueneman brought up the issue of different > > certs for the same address. For instance, two people might use one email > > address and thus want different certificates. The current > S/MIME and PKIX > > specs allow the email address, not the informational kruft around it, in > > the subjectAltName for a cert. > > > > Do we want to change this? The arguments we heard against this > in the PKIX > > group included: > > - A CA might check the validity of the email address but not the name > > - The many formats for the additional information are > incredibly confusing > > and likely to promote lack of interoperability > > The arguments in favor of using full addresses include: > > - Ability for multiple people with access to the mailbox to have unique > > certificates > > - Increased identification for systems that do more than just check the > mailbox > > > > Comments? > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > > > > > > > > > From owner-ietf-smime@imc.org Wed Dec 22 10:50:28 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15629 for ; Wed, 22 Dec 1999 10:50:27 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17507 for ietf-smime-bks; Wed, 22 Dec 1999 07:14:10 -0800 (PST) Received: from francesco.stelvio.nl (francesco.stelvio.nl [195.169.54.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17502 for ; Wed, 22 Dec 1999 07:14:08 -0800 (PST) X-Internal-ID: 384A5222000008B4 Received: from passo.stelvio.nl (195.169.54.130) by francesco.stelvio.nl (NPlex 2.0.108) for ietf-smime@imc.org; 22 Dec 1999 16:27:46 +0100 X-Internal-ID: 3851170F0000059E Received: from haddock (192.87.119.9) by passo.stelvio.nl (NPlex 2.0.119) for ietf-smime@imc.org; Wed, 22 Dec 1999 16:17:55 +0100 From: "Bert Stals" To: "ietf-smime" Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 16:17:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <000101bf4c79$27568a80$893256cf@odysseus.nexor.com> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Content-Transfer-Encoding: 7bit It seems to me that identity and responsibility are mixed. A serious problem with certificates is that they say who you are, not what you are responsible for. No-one can determine from my certificate whether I'm authorised to represent my company. And even when my certificate would say "managing director" that still doesn't have to mean I can take all decisions on my own. Regards, Bert > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of Bob Johnson > Sent: woensdag 22 december 1999 13:36 > To: Walter Williams; John_Payne; Frank W. Nolden > Cc: ietf-smime > Subject: RE: Mail addresses in S/MIME certs > > > And another de-lurks (apologies in advance for the length)... > > I won't offer my opinion on the S/MIME technical issues, but > perhaps I can > cast a bit of light on some of the operational requirements > driving this > discussion. [rest deleted] From owner-ietf-smime@imc.org Wed Dec 22 16:27:35 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28099 for ; Wed, 22 Dec 1999 16:27:34 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA23418 for ietf-smime-bks; Wed, 22 Dec 1999 12:34:36 -0800 (PST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23414 for ; Wed, 22 Dec 1999 12:34:34 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Dec 1999 12:38:24 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Dec 1999 12:38:24 -0800 Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC50106D458@dino.platinum.corp.microsoft.com> From: "Jim Schaad (Exchange)" To: "'Al Arsenault'" , Paul Hoffman / IMC Cc: ietf-smime@imc.org Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 11:55:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4CBC.7E274F32" Sender: owner-ietf-smime@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_01BF4CBC.7E274F32 Content-Type: text/plain I am in complete agreement with Al. I looked at this issue back when the drafts were first getting started and I was just scared by the concept of allowing more that I could reasonably verify into the RFC822 address field. I had a chance as a mail program of looking at the RFC822 name, but not all of the "comments" that go along with it. While I agree that there may be some issues for display of RFC822 names vs the comment fields that are in messages, I think this is true no matter what is done and is more of a presentation/application issue than a standard issue. This is one of the things that different applications will do well or not do well, but should not really be part of the standard. We have the ability to look at and think about the RFC822 name (or what ever type of name is being used as the delivery address i.e. an X500 name in the Microsoft Exchange Server world), but have no way of doing any type of reasonable verification on the comment sections. Lets just leave things the way they are. jim > -----Original Message----- > From: Al Arsenault [mailto:awa1@home.com] > Sent: Tuesday, December 21, 1999 6:50 PM > To: Paul Hoffman / IMC > Cc: ietf-smime@imc.org > Subject: Re: Mail addresses in S/MIME certs > > > > > Paul Hoffman / IMC wrote: > > > > At the DC IETF meeting, Bob Jueneman brought up the issue > of different > > certs for the same address. For instance, two people might > use one email > > address and thus want different certificates. The current > S/MIME and PKIX > > specs allow the email address, not the informational kruft > around it, in > > the subjectAltName for a cert. > > > > Do we want to change this? The arguments we heard against > this in the PKIX > > group included: > > - A CA might check the validity of the email address but > not the name > > - The many formats for the additional information are > incredibly confusing > > and likely to promote lack of interoperability > > The arguments in favor of using full addresses include: > > - Ability for multiple people with access to the mailbox to > have unique > > certificates > > - Increased identification for systems that do more than > just check the mailbox > > > > Comments? > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > Count me in the > > "The many formats for the additional information are incredibly > confusing and likely to promote lack of interoperability" > > camp. This, combined with the fact that that cruft is almost > infinitely > changeable today, and almost never checked by anybody, seems > to me to be > a sure guarantee of interoperability problems. > > I don't have any philosophical objections to allowing this, > though, and > if the S/MIME vendors are convinced that they can get it > right and make > it all interoperate, I'm willing to be outvoted. But it just > strikes me > as begging for a failure to communicate. > > Al Arsenault > ------_=_NextPart_001_01BF4CBC.7E274F32 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Mail addresses in S/MIME certs

I am in complete agreement with Al.  I looked at = this issue back when the drafts were first getting started and I was = just scared by the concept of allowing more that I could reasonably = verify into the RFC822 address field.  I had a chance as a mail = program of looking at the RFC822 name, but not all of the = "comments" that go along with it.  While I agree that = there may be some issues for display of RFC822 names vs the comment = fields that are in messages, I think this is true no matter what is = done and is more of a presentation/application issue than a standard = issue.  This is one of the things that different applications will = do well or not do well, but should not really be part of the = standard.  We have the ability to look at and think about the = RFC822 name (or what ever type of name is being used as the delivery = address i.e. an X500 name in the Microsoft Exchange Server world), but = have no way of doing any type of reasonable verification on the comment = sections.  Lets just leave things the way they are.

jim


> -----Original Message-----
> From: Al Arsenault [mailto:awa1@home.com]
> Sent: Tuesday, December 21, 1999 6:50 PM
> To: Paul Hoffman / IMC
> Cc: ietf-smime@imc.org
> Subject: Re: Mail addresses in S/MIME = certs
>
>
>
>
> Paul Hoffman / IMC wrote:
> >
> > At the DC IETF meeting, Bob Jueneman = brought up the issue
> of different
> > certs for the same address. For instance, = two people might
> use one email
> > address and thus want different = certificates. The current
> S/MIME and PKIX
> > specs allow the email address, not the = informational kruft
> around it, in
> > the subjectAltName for a cert.
> >
> > Do we want to change this? The arguments = we heard against
> this in the PKIX
> > group included:
> > - A CA might check the validity of the = email address but
> not the name
> > - The many formats for the additional = information are
> incredibly confusing
> > and likely to promote lack of = interoperability
> > The arguments in favor of using full = addresses include:
> > - Ability for multiple people with access = to the mailbox to
> have unique
> > certificates
> > - Increased identification for systems = that do more than
> just check the mailbox
> >
> > Comments?
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> Count me in the
>
> "The many formats for the additional = information are incredibly
> confusing and likely to promote lack of = interoperability"
>
> camp.  This, combined with the fact that = that cruft is almost
> infinitely
> changeable today, and almost never checked by = anybody, seems
> to me to be
> a sure guarantee of interoperability = problems.
>
> I don't have any philosophical objections to = allowing this,
> though, and
> if the S/MIME vendors are convinced that they = can get it
> right and make
> it all interoperate, I'm willing to be = outvoted.  But it just
> strikes me
> as begging for a failure to communicate.
>
>       =         =         =         Al Arsenault
>

------_=_NextPart_001_01BF4CBC.7E274F32-- From owner-ietf-smime@imc.org Wed Dec 22 16:42:11 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28380 for ; Wed, 22 Dec 1999 16:42:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23753 for ietf-smime-bks; Wed, 22 Dec 1999 12:59:33 -0800 (PST) Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23749 for ; Wed, 22 Dec 1999 12:59:32 -0800 (PST) Received: from dcrocker (free.88.106.bayarea.net [205.219.88.106]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA51056 for ; Wed, 22 Dec 1999 13:03:50 -0800 (PST) (envelope-from dcrocker@brandenburg.com) Message-Id: <4.2.2.19991222125154.00b68bc0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 Dec 1999 13:02:58 -0800 To: ietf-smime@imc.org From: Dave Crocker Subject: RE: Mail addresses in S/MIME certs In-Reply-To: <9BE3A7FF0D67C341819FCA57736D5BC50106D458@dino.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:55 AM 12/22/1999 , Jim Schaad (Exchange) wrote: >I am in complete agreement with Al. I looked at this issue back when the >drafts were first getting started and I was just scared by the concept of >allowing more that I could reasonably verify into the RFC822 address >field. I had a chance as a mail program of looking at the RFC822 name, >but not all of the "comments" that go along with it. While I agree that >there may be some issues for display of RFC822 names vs the comment fields >that are in messages, I think this is true no matter what is done and is >more of a presentation/application issue Folks, If one insists on specific semantics to the string(s) being used, then the task is probably difficult and all the stated fears are likely valid. To the extent that the only real issue is ensuring uniqueness, then there are emerging enhancements to the RFC822 address string that might prove useful. In effect the enhancement is retrofitting a schema template onto the mailbox (local-part) to the address. The rough style is . (Apologies for the shudders this no doubt engendered among those with an X.400 background.) Also, there is still some flux in the work and so I could imagine that it will also permit without the keyword preface. The real point behind mentioning this is to suggest that you probably can choose to defer dealing with the issue, since it really involves matters that are larger than certs: Things like shared mailboxes, roles vs. people, etc., need to be dealt with much more generally. And they will be. And it is looking likely that they will be dealt with in ways that will be compatible with (and transparent to) the current RFC822 address format. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-ietf-smime@imc.org Thu Dec 23 07:27:05 1999 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21050 for ; Thu, 23 Dec 1999 07:27:04 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06855 for ietf-smime-bks; Thu, 23 Dec 1999 03:32:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06851 for ; Thu, 23 Dec 1999 03:32:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20121; Thu, 23 Dec 1999 06:36:51 -0500 (EST) Message-Id: <199912231136.GAA20121@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-00.txt Date: Thu, 23 Dec 1999 06:36:51 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-00.txt Pages : 19 Date : 22-Dec-99 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. The mechanisms use the CMSCryptographic Message Syntax (CMS) protocol [CMS] to encrypt the key for each member of the group. Any member of the group can then later use this key to decrypt other CMS encrypted objects with the symmetric or 'group' key. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. 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-symkeydist-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991222095752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991222095752.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id DAA06855 for ietf-smime-bks; Thu, 23 Dec 1999 03:32:31 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA06851 for ; Thu, 23 Dec 1999 03:32:29 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20121; Thu, 23 Dec 1999 06:36:51 -0500 (EST) Message-Id: <199912231136.GAA20121@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-smime@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-smime-symkeydist-00.txt Date: Thu, 23 Dec 1999 06:36:51 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : S/MIME Symmetric Key Distribution Author(s) : S. Turner Filename : draft-ietf-smime-symkeydist-00.txt Pages : 19 Date : 22-Dec-99 This document describes a mechanism to manage (i.e., setup, distribute, and rekey) keys used with symmetric cryptographic algorithms. The mechanisms use the CMSCryptographic Message Syntax (CMS) protocol [CMS] to encrypt the key for each member of the group. Any member of the group can then later use this key to decrypt other CMS encrypted objects with the symmetric or 'group' key. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to: ietf-smime-request@imc.org with the single word subscribe in the body of the message. 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-symkeydist-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-symkeydist-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-symkeydist-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991222095752.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-symkeydist-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-symkeydist-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991222095752.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA23753 for ietf-smime-bks; Wed, 22 Dec 1999 12:59:33 -0800 (PST) Received: from postman.bayarea.net (postman.bayarea.net [205.219.84.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA23749 for ; Wed, 22 Dec 1999 12:59:32 -0800 (PST) Received: from dcrocker (free.88.106.bayarea.net [205.219.88.106]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA51056 for ; Wed, 22 Dec 1999 13:03:50 -0800 (PST) (envelope-from dcrocker@brandenburg.com) Message-Id: <4.2.2.19991222125154.00b68bc0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 22 Dec 1999 13:02:58 -0800 To: ietf-smime@imc.org From: Dave Crocker Subject: RE: Mail addresses in S/MIME certs In-Reply-To: <9BE3A7FF0D67C341819FCA57736D5BC50106D458@dino.platinum.cor p.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At 11:55 AM 12/22/1999 , Jim Schaad (Exchange) wrote: >I am in complete agreement with Al. I looked at this issue back when the >drafts were first getting started and I was just scared by the concept of >allowing more that I could reasonably verify into the RFC822 address >field. I had a chance as a mail program of looking at the RFC822 name, >but not all of the "comments" that go along with it. While I agree that >there may be some issues for display of RFC822 names vs the comment fields >that are in messages, I think this is true no matter what is done and is >more of a presentation/application issue Folks, If one insists on specific semantics to the string(s) being used, then the task is probably difficult and all the stated fears are likely valid. To the extent that the only real issue is ensuring uniqueness, then there are emerging enhancements to the RFC822 address string that might prove useful. In effect the enhancement is retrofitting a schema template onto the mailbox (local-part) to the address. The rough style is . (Apologies for the shudders this no doubt engendered among those with an X.400 background.) Also, there is still some flux in the work and so I could imagine that it will also permit without the keyword preface. The real point behind mentioning this is to suggest that you probably can choose to defer dealing with the issue, since it really involves matters that are larger than certs: Things like shared mailboxes, roles vs. people, etc., need to be dealt with much more generally. And they will be. And it is looking likely that they will be dealt with in ways that will be compatible with (and transparent to) the current RFC822 address format. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA23418 for ietf-smime-bks; Wed, 22 Dec 1999 12:34:36 -0800 (PST) Received: from dfssl.exchange.microsoft.com (dfssl.exchange.microsoft.com [131.107.88.59]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA23414 for ; Wed, 22 Dec 1999 12:34:34 -0800 (PST) Received: from 127.0.0.1 by dfssl.exchange.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 22 Dec 1999 12:38:24 -0800 (Pacific Standard Time) Received: by dfssl with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Dec 1999 12:38:24 -0800 Message-ID: <9BE3A7FF0D67C341819FCA57736D5BC50106D458@dino.platinum.corp.microsoft.com> From: "Jim Schaad (Exchange)" To: "'Al Arsenault'" , Paul Hoffman / IMC Cc: ietf-smime@imc.org Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 11:55:23 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF4CBC.7E274F32" Sender: owner-ietf-smime@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_01BF4CBC.7E274F32 Content-Type: text/plain I am in complete agreement with Al. I looked at this issue back when the drafts were first getting started and I was just scared by the concept of allowing more that I could reasonably verify into the RFC822 address field. I had a chance as a mail program of looking at the RFC822 name, but not all of the "comments" that go along with it. While I agree that there may be some issues for display of RFC822 names vs the comment fields that are in messages, I think this is true no matter what is done and is more of a presentation/application issue than a standard issue. This is one of the things that different applications will do well or not do well, but should not really be part of the standard. We have the ability to look at and think about the RFC822 name (or what ever type of name is being used as the delivery address i.e. an X500 name in the Microsoft Exchange Server world), but have no way of doing any type of reasonable verification on the comment sections. Lets just leave things the way they are. jim > -----Original Message----- > From: Al Arsenault [mailto:awa1@home.com] > Sent: Tuesday, December 21, 1999 6:50 PM > To: Paul Hoffman / IMC > Cc: ietf-smime@imc.org > Subject: Re: Mail addresses in S/MIME certs > > > > > Paul Hoffman / IMC wrote: > > > > At the DC IETF meeting, Bob Jueneman brought up the issue > of different > > certs for the same address. For instance, two people might > use one email > > address and thus want different certificates. The current > S/MIME and PKIX > > specs allow the email address, not the informational kruft > around it, in > > the subjectAltName for a cert. > > > > Do we want to change this? The arguments we heard against > this in the PKIX > > group included: > > - A CA might check the validity of the email address but > not the name > > - The many formats for the additional information are > incredibly confusing > > and likely to promote lack of interoperability > > The arguments in favor of using full addresses include: > > - Ability for multiple people with access to the mailbox to > have unique > > certificates > > - Increased identification for systems that do more than > just check the mailbox > > > > Comments? > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > Count me in the > > "The many formats for the additional information are incredibly > confusing and likely to promote lack of interoperability" > > camp. This, combined with the fact that that cruft is almost > infinitely > changeable today, and almost never checked by anybody, seems > to me to be > a sure guarantee of interoperability problems. > > I don't have any philosophical objections to allowing this, > though, and > if the S/MIME vendors are convinced that they can get it > right and make > it all interoperate, I'm willing to be outvoted. But it just > strikes me > as begging for a failure to communicate. > > Al Arsenault > ------_=_NextPart_001_01BF4CBC.7E274F32 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Mail addresses in S/MIME certs

I am in complete agreement with Al.  I looked at = this issue back when the drafts were first getting started and I was = just scared by the concept of allowing more that I could reasonably = verify into the RFC822 address field.  I had a chance as a mail = program of looking at the RFC822 name, but not all of the = "comments" that go along with it.  While I agree that = there may be some issues for display of RFC822 names vs the comment = fields that are in messages, I think this is true no matter what is = done and is more of a presentation/application issue than a standard = issue.  This is one of the things that different applications will = do well or not do well, but should not really be part of the = standard.  We have the ability to look at and think about the = RFC822 name (or what ever type of name is being used as the delivery = address i.e. an X500 name in the Microsoft Exchange Server world), but = have no way of doing any type of reasonable verification on the comment = sections.  Lets just leave things the way they are.

jim


> -----Original Message-----
> From: Al Arsenault [mailto:awa1@home.com]
> Sent: Tuesday, December 21, 1999 6:50 PM
> To: Paul Hoffman / IMC
> Cc: ietf-smime@imc.org
> Subject: Re: Mail addresses in S/MIME = certs
>
>
>
>
> Paul Hoffman / IMC wrote:
> >
> > At the DC IETF meeting, Bob Jueneman = brought up the issue
> of different
> > certs for the same address. For instance, = two people might
> use one email
> > address and thus want different = certificates. The current
> S/MIME and PKIX
> > specs allow the email address, not the = informational kruft
> around it, in
> > the subjectAltName for a cert.
> >
> > Do we want to change this? The arguments = we heard against
> this in the PKIX
> > group included:
> > - A CA might check the validity of the = email address but
> not the name
> > - The many formats for the additional = information are
> incredibly confusing
> > and likely to promote lack of = interoperability
> > The arguments in favor of using full = addresses include:
> > - Ability for multiple people with access = to the mailbox to
> have unique
> > certificates
> > - Increased identification for systems = that do more than
> just check the mailbox
> >
> > Comments?
> >
> > --Paul Hoffman, Director
> > --Internet Mail Consortium
>
> Count me in the
>
> "The many formats for the additional = information are incredibly
> confusing and likely to promote lack of = interoperability"
>
> camp.  This, combined with the fact that = that cruft is almost
> infinitely
> changeable today, and almost never checked by = anybody, seems
> to me to be
> a sure guarantee of interoperability = problems.
>
> I don't have any philosophical objections to = allowing this,
> though, and
> if the S/MIME vendors are convinced that they = can get it
> right and make
> it all interoperate, I'm willing to be = outvoted.  But it just
> strikes me
> as begging for a failure to communicate.
>
>       =         =         =         Al Arsenault
>

------_=_NextPart_001_01BF4CBC.7E274F32-- Received: by ns.secondary.com (8.9.3/8.9.3) id HAA17507 for ietf-smime-bks; Wed, 22 Dec 1999 07:14:10 -0800 (PST) Received: from francesco.stelvio.nl (francesco.stelvio.nl [195.169.54.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA17502 for ; Wed, 22 Dec 1999 07:14:08 -0800 (PST) X-Internal-ID: 384A5222000008B4 Received: from passo.stelvio.nl (195.169.54.130) by francesco.stelvio.nl (NPlex 2.0.108) for ietf-smime@imc.org; 22 Dec 1999 16:27:46 +0100 X-Internal-ID: 3851170F0000059E Received: from haddock (192.87.119.9) by passo.stelvio.nl (NPlex 2.0.119) for ietf-smime@imc.org; Wed, 22 Dec 1999 16:17:55 +0100 From: "Bert Stals" To: "ietf-smime" Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 16:17:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <000101bf4c79$27568a80$893256cf@odysseus.nexor.com> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: It seems to me that identity and responsibility are mixed. A serious problem with certificates is that they say who you are, not what you are responsible for. No-one can determine from my certificate whether I'm authorised to represent my company. And even when my certificate would say "managing director" that still doesn't have to mean I can take all decisions on my own. Regards, Bert > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of Bob Johnson > Sent: woensdag 22 december 1999 13:36 > To: Walter Williams; John_Payne; Frank W. Nolden > Cc: ietf-smime > Subject: RE: Mail addresses in S/MIME certs > > > And another de-lurks (apologies in advance for the length)... > > I won't offer my opinion on the S/MIME technical issues, but > perhaps I can > cast a bit of light on some of the operational requirements > driving this > discussion. [rest deleted] Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA14918 for ietf-smime-bks; Wed, 22 Dec 1999 04:31:34 -0800 (PST) Received: from zeus.nexor.com (zeus.nexor.com [207.86.50.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA14914 for ; Wed, 22 Dec 1999 04:31:33 -0800 (PST) Received: from odysseus.nexor.com by zeus.nexor.com with SMTP (Mailer); Wed, 22 Dec 1999 07:34:47 -0500 Reply-To: "Bob.Johnson" From: Bob Johnson To: Walter Williams , John_Payne , "Frank W. Nolden" Cc: ietf-smime Subject: RE: Mail addresses in S/MIME certs Date: Wed, 22 Dec 1999 07:36:21 -0500 Message-ID: <000101bf4c79$27568a80$893256cf@odysseus.nexor.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: And another de-lurks (apologies in advance for the length)... I won't offer my opinion on the S/MIME technical issues, but perhaps I can cast a bit of light on some of the operational requirements driving this discussion. In the military, you have a definite concept of an organizational role which has to do with the command structure. That role, perhaps "Base Commander", is stable. However, the personnel who are responsible for that role come and go. Much official correspondence is sent and received by this role. Let's say that Col. Smith is currently filling the role of "Base Commander". When he sends an official notice as the Base Commander, it should be signed by that role - not the individual person, Col. Smith. The plot thickens when you realize that "Base Commander" probably has a half-dozen people who are authorized to read messages addressed to the role, and at least 3 or 4 who can send official messages signed by that role. Typically, Col. Smith would draft a message and forward it to a Duty Officer (or secretary) who would "release" it under the authority of the Base Commander (ergo, the concept of an "Organizational Release Authority" shared by several people). And, if Col. Smith is TDY, you can bet that Lt. Col Jones, the Duty Officer, and the base Messaging Center can all read messages addressed to the Base Commander. Remember, however, that Col. Smith also has an identity of his own. If Brig. Gen. Brown wants to send over an itenerary for an upcoming visit that includes dinner, golf, and drinks afterward - he would probably send it to Col. Smith, not "Base Commander". Also, just to confuse things, you might want to send an "eyes-only" type of message to the Base Commander, which could ONLY be read by Col Smith (or whomever happens to "own" that role at the time). So what you have, in data structure terms, would be a network of one-to-many relationships. The Base Commander role is "owned" by Col. Smith. There are a set of individuals who are allowed to read messages addressed to this role, in addition to Col. Smith. There are also a set of individuals who are allowed to release messages signed by this role. These two sets may not be, and in fact usualy are not, identical (e.g. the Messaging Center could read a message to this role, but couldn't release one from this role). Each individual, by inference, could be part of any number of these role release and/or reading lists. For instance, the set of people authorized to work in the base messaging center might be authorized to read messages addressed to darn near every "role" on base. Adding to the confusion - any individual could also be an e-mail administrator, network administrator, directory administrator, security officer, etc, etc, etc. Each of these is an additional role - defined by function, not necessary by command structure. Believe it or not, the above description is exactly what the Canadian Department of National Defence will have to sort out in order to deploy their classified Military Message Handling System (MMHS). So, these are actual, real-world operational requirements that need to be met by S/MIME. By the way - the security will be based on Entrust, which adds a whole 'nother level of complexity. But (as they say) that's another story, for another day. Bob Johnson, NEXOR > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of Walter Williams > Sent: Tuesday, December 21, 1999 11:34 PM > To: John_Payne; Frank W. Nolden > Cc: ietf-smime > Subject: RE: Mail addresses in S/MIME certs > > > Another lurker jumps into the ring..... > > This begs the question: do certificates identify an individual or a role? > There is no effective way for a single certificate to do both. > > A second question becomes are certificates appropriate for role > definition? > Certificates are usually valid for a span of years. My role changes > constantly, who I am never really has. Role definition might be best left > to other objects within a public key infrastructure, such as a directory > leaf entry as an example. After all, certificates, while > important, do not > a pki comprise. The important thing to get right, and this is process not > technology, is that the email alias is mine, not ours, if you catch the > drift. > > Walt Williams > GTE Internetworking > > -----Original Message----- > From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On > Behalf Of John_Payne@motorcity2.lotus.com > Sent: Tuesday, December 21, 1999 11:59 PM > To: Frank W. Nolden > Cc: ietf-smime@imc.org > Subject: Re: Mail addresses in S/MIME certs > > > > > Sorry, I am also new to this thread. > > Where are we going here? > A certificate ties a group of attributes (in this case the > Subject Alternate > Identity of RFC821(or 2) > address to public key). > Should we be looking at some other binding? > Surely in the case described the alternate identity should be some form of > Role > or MailingList. More than one > identity using the same MailingAddress completely blows > non-repudiation out > of > the water unless there is > some (out of scope?) work flow process or role identity > > > > > "Frank W. Nolden" on 12/21/99 10:58:19 AM > > To: ietf-smime@imc.org, Paul Hoffman/ IMC > cc: (bcc: John Payne/CAM/Lotus) > Subject: Re: Mail addresses in S/MIME certs > > > > Dear All, > > I would see it as follows (but then again I am very new to this discussion > and maybe I am completely off track): > > When two people are using the same email address, the email > address is used > as a role which can be filled by more than one person. In this case there > will be a certificate for the role and certificates for each person. The > certificates for the people will be used in private (or mail sent on > personal title) situations, while the certificate for the role > will be used > in correspondence for this role only. > > This means that both persons can have two certs, i.e. one for the role and > one for themselves, and each of these certs has to be stored in a separate > account or something like that. > > When it is used on this way there is no problem when having the > informational stuff in the subjectAltName. > Regards, > > Frank Nolden > MaXware Benelux BV > > ----- Original Message ----- > From: Paul Hoffman / IMC > To: > Sent: Monday, December 20, 1999 22:35 > Subject: Mail addresses in S/MIME certs > > > > At the DC IETF meeting, Bob Jueneman brought up the issue of different > > certs for the same address. For instance, two people might use one email > > address and thus want different certificates. The current > S/MIME and PKIX > > specs allow the email address, not the informational kruft around it, in > > the subjectAltName for a cert. > > > > Do we want to change this? The arguments we heard against this > in the PKIX > > group included: > > - A CA might check the validity of the email address but not the name > > - The many formats for the additional information are > incredibly confusing > > and likely to promote lack of interoperability > > The arguments in favor of using full addresses include: > > - Ability for multiple people with access to the mailbox to have unique > > certificates > > - Increased identification for systems that do more than just check the > mailbox > > > > Comments? > > > > --Paul Hoffman, Director > > --Internet Mail Consortium > > > > > > > > > > Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14540 for ietf-smime-bks; Wed, 22 Dec 1999 03:54:41 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14536 for ; Wed, 22 Dec 1999 03:54:39 -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 GAA06044; Wed, 22 Dec 1999 06:58:54 -0500 (EST) Message-Id: <199912221158.GAA06044@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-seclabel-00.txt Date: Wed, 22 Dec 1999 06:58:54 -0500 Sender: owner-ietf-smime@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 : Implementing Company Classification Policy with the S/MIME Security Label Author(s) : W. Nicolls Filename : draft-ietf-smime-seclabel-00.txt Pages : 8 Date : 21-Dec-99 This document discusses how company security policy for data classification can be mapped to the S/MIME classification label. Actual policies from 3 companies are used to provide worked examples. Security labels are an optional security service for S/MIME. A security label is a set of security information regarding the sensitivity of the content that is protected by S/MIME encapsulation. A security label can be a bound attribute of the original message content, the encrypted body, or both. The syntax and processing rules for security labels are described in [ESS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-seclabel-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-seclabel-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-seclabel-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991221121534.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-seclabel-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-seclabel-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991221121534.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22364 for ietf-smime-bks; Tue, 21 Dec 1999 22:28:42 -0800 (PST) Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22360 for ; Tue, 21 Dec 1999 22:28:39 -0800 (PST) Received: from dstc.qut.edu.au (tornado.dstc.qut.edu.au [131.181.71.3]) by piglet.dstc.edu.au (8.9.3/8.9.3) with ESMTP id QAA13138; Wed, 22 Dec 1999 16:32:47 +1000 (EST) Message-Id: <199912220632.QAA13138@piglet.dstc.edu.au> X-Mailer: exmh version 2.0.2 2/24/98 To: "Walter Williams" Cc: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs In-reply-to: Your message of "Tue, 21 Dec 1999 23:33:33 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 22 Dec 1999 16:32:47 +1000 From: Dean Povey Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: >Another lurker jumps into the ring..... > >This begs the question: do certificates identify an individual or a role? >There is no effective way for a single certificate to do both. > >A second question becomes are certificates appropriate for role definition? >Certificates are usually valid for a span of years. My role changes >constantly, who I am never really has. Role definition might be best left >to other objects within a public key infrastructure, such as a directory >leaf entry as an example. After all, certificates, while important, do not >a pki comprise. The important thing to get right, and this is process not >technology, is that the email alias is mine, not ours, if you catch the >drift. > Certificates identify whatever you choose to identify. Certificate Policies specifiythe meaning of the naming in the cert. Attribute Certs are better for dynamic things like roles, as they allow you to separate the management of the role/credential/attribute from the management of the key. An attribute cert is rather like a normal Certificate but does not contain a public key (although it does contain a pointer to it). Unfortunately there is not a lot of support in vendor products yet, but they will get there eventually. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id VAA21114 for ietf-smime-bks; Tue, 21 Dec 1999 21:33:14 -0800 (PST) Received: from po2.bbn.com (PO2.BBN.COM [192.1.50.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA21106 for ; Tue, 21 Dec 1999 21:33:13 -0800 (PST) Received: from WWILLIAMS1 ([128.33.211.196]) by po2.bbn.com (8.9.1/8.9.1) with SMTP id AAA20572; Wed, 22 Dec 1999 00:37:27 -0500 (EST) From: "Walter Williams" To: , "Frank W. Nolden" Cc: Subject: RE: Mail addresses in S/MIME certs Date: Tue, 21 Dec 1999 23:33:33 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-Reply-To: <8525684F.0015354D.00@motorcity2.lotus.com> Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Another lurker jumps into the ring..... This begs the question: do certificates identify an individual or a role? There is no effective way for a single certificate to do both. A second question becomes are certificates appropriate for role definition? Certificates are usually valid for a span of years. My role changes constantly, who I am never really has. Role definition might be best left to other objects within a public key infrastructure, such as a directory leaf entry as an example. After all, certificates, while important, do not a pki comprise. The important thing to get right, and this is process not technology, is that the email alias is mine, not ours, if you catch the drift. Walt Williams GTE Internetworking -----Original Message----- From: owner-ietf-smime@imc.org [mailto:owner-ietf-smime@imc.org]On Behalf Of John_Payne@motorcity2.lotus.com Sent: Tuesday, December 21, 1999 11:59 PM To: Frank W. Nolden Cc: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs Sorry, I am also new to this thread. Where are we going here? A certificate ties a group of attributes (in this case the Subject Alternate Identity of RFC821(or 2) address to public key). Should we be looking at some other binding? Surely in the case described the alternate identity should be some form of Role or MailingList. More than one identity using the same MailingAddress completely blows non-repudiation out of the water unless there is some (out of scope?) work flow process or role identity "Frank W. Nolden" on 12/21/99 10:58:19 AM To: ietf-smime@imc.org, Paul Hoffman/ IMC cc: (bcc: John Payne/CAM/Lotus) Subject: Re: Mail addresses in S/MIME certs Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > Received: by ns.secondary.com (8.9.3/8.9.3) id TAA10309 for ietf-smime-bks; Tue, 21 Dec 1999 19:50:09 -0800 (PST) Received: from lotus2.lotus.com (lotus2.lotus.com [192.233.136.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA10302 for ; Tue, 21 Dec 1999 19:50:07 -0800 (PST) From: John_Payne@motorcity2.lotus.com Received: from internet2.lotus.com (internet2 [9.95.4.236]) by lotus2.lotus.com (8.9.3/8.9.3) with ESMTP id XAA21234; Tue, 21 Dec 1999 23:08:22 -0500 (EST) Received: from motorcity2.lotus.com (motorcity2.lotus.com [9.95.19.177]) by internet2.lotus.com (8.9.3/8.9.3) with SMTP id WAA04476; Tue, 21 Dec 1999 22:51:44 -0500 (EST) Received: by motorcity2.lotus.com(Lotus SMTP MTA v4.6.7 (926.1 11-18-1999)) id 8525684F.00153591 ; Tue, 21 Dec 1999 22:51:39 -0500 X-Lotus-FromDomain: NOTES@ALPHABETA To: "Frank W. Nolden" cc: ietf-smime@imc.org Message-ID: <8525684F.0015354D.00@motorcity2.lotus.com> Date: Tue, 21 Dec 1999 23:59:04 -0500 Subject: Re: Mail addresses in S/MIME certs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Sorry, I am also new to this thread. Where are we going here? A certificate ties a group of attributes (in this case the Subject Alternate Identity of RFC821(or 2) address to public key). Should we be looking at some other binding? Surely in the case described the alternate identity should be some form of Role or MailingList. More than one identity using the same MailingAddress completely blows non-repudiation out of the water unless there is some (out of scope?) work flow process or role identity "Frank W. Nolden" on 12/21/99 10:58:19 AM To: ietf-smime@imc.org, Paul Hoffman/ IMC cc: (bcc: John Payne/CAM/Lotus) Subject: Re: Mail addresses in S/MIME certs Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > Received: by ns.secondary.com (8.9.3/8.9.3) id SAA02070 for ietf-smime-bks; Tue, 21 Dec 1999 18:50:04 -0800 (PST) Received: from mail.rdc1.md.home.com (imail@ha1.rdc1.md.home.com [24.2.2.66]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA02061; Tue, 21 Dec 1999 18:50:02 -0800 (PST) Received: from home.com ([24.4.133.54]) by mail.rdc1.md.home.com (InterMail v4.01.01.00 201-229-111) with ESMTP id <19991222025417.IWJS26939.mail.rdc1.md.home.com@home.com>; Tue, 21 Dec 1999 18:54:17 -0800 Message-ID: <38603C73.98AF409F@home.com> Date: Tue, 21 Dec 1999 21:50:27 -0500 From: Al Arsenault Organization: @Home Network X-Mailer: Mozilla 4.61 [en]C-AtHome0407 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Paul Hoffman / IMC CC: ietf-smime@imc.org Subject: Re: Mail addresses in S/MIME certs References: <4.2.1.19991220132931.00bbb930@mail.imc.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Hoffman / IMC wrote: > > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium Count me in the "The many formats for the additional information are incredibly confusing and likely to promote lack of interoperability" camp. This, combined with the fact that that cruft is almost infinitely changeable today, and almost never checked by anybody, seems to me to be a sure guarantee of interoperability problems. I don't have any philosophical objections to allowing this, though, and if the S/MIME vendors are convinced that they can get it right and make it all interoperate, I'm willing to be outvoted. But it just strikes me as begging for a failure to communicate. Al Arsenault Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15713 for ietf-smime-bks; Tue, 21 Dec 1999 07:49:01 -0800 (PST) Received: from mail.maxware.nl (mail.maxware.nl [195.193.216.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15707; Tue, 21 Dec 1999 07:48:58 -0800 (PST) X-Internal-ID: 38576DAE0000022F Received: from taita.maxware.nl (195.193.216.133) by mail.maxware.nl (NPlex 2.0.098); 21 Dec 1999 16:58:44 +0100 Message-ID: <04c001bf4bcc$336a9da0$85d8c1c3@maxware.nl> From: "Frank W. Nolden" To: , "Paul Hoffman / IMC" References: <4.2.1.19991220132931.00bbb930@mail.imc.org> Subject: Re: Mail addresses in S/MIME certs Date: Tue, 21 Dec 1999 16:58:19 +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.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Dear All, I would see it as follows (but then again I am very new to this discussion and maybe I am completely off track): When two people are using the same email address, the email address is used as a role which can be filled by more than one person. In this case there will be a certificate for the role and certificates for each person. The certificates for the people will be used in private (or mail sent on personal title) situations, while the certificate for the role will be used in correspondence for this role only. This means that both persons can have two certs, i.e. one for the role and one for themselves, and each of these certs has to be stored in a separate account or something like that. When it is used on this way there is no problem when having the informational stuff in the subjectAltName. Regards, Frank Nolden MaXware Benelux BV ----- Original Message ----- From: Paul Hoffman / IMC To: Sent: Monday, December 20, 1999 22:35 Subject: Mail addresses in S/MIME certs > At the DC IETF meeting, Bob Jueneman brought up the issue of different > certs for the same address. For instance, two people might use one email > address and thus want different certificates. The current S/MIME and PKIX > specs allow the email address, not the informational kruft around it, in > the subjectAltName for a cert. > > Do we want to change this? The arguments we heard against this in the PKIX > group included: > - A CA might check the validity of the email address but not the name > - The many formats for the additional information are incredibly confusing > and likely to promote lack of interoperability > The arguments in favor of using full addresses include: > - Ability for multiple people with access to the mailbox to have unique > certificates > - Increased identification for systems that do more than just check the mailbox > > Comments? > > --Paul Hoffman, Director > --Internet Mail Consortium > > Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15031 for ietf-smime-bks; Tue, 21 Dec 1999 07:02:50 -0800 (PST) Received: from v4j31 (user@ts035d22.par-nj.concentric.net [216.112.174.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15026 for ; Tue, 21 Dec 1999 07:02:48 -0800 (PST) Message-Id: <4.2.1.19991220132931.00bbb930@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.1 Date: Mon, 20 Dec 1999 16:35:32 -0500 To: ietf-smime@imc.org From: Paul Hoffman / IMC Subject: Mail addresses in S/MIME certs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: At the DC IETF meeting, Bob Jueneman brought up the issue of different certs for the same address. For instance, two people might use one email address and thus want different certificates. The current S/MIME and PKIX specs allow the email address, not the informational kruft around it, in the subjectAltName for a cert. Do we want to change this? The arguments we heard against this in the PKIX group included: - A CA might check the validity of the email address but not the name - The many formats for the additional information are incredibly confusing and likely to promote lack of interoperability The arguments in favor of using full addresses include: - Ability for multiple people with access to the mailbox to have unique certificates - Increased identification for systems that do more than just check the mailbox Comments? --Paul Hoffman, Director --Internet Mail Consortium Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA23891 for ietf-smime-bks; Mon, 20 Dec 1999 09:35:28 -0800 (PST) Received: from wfhqex05.wangfed.com (netva01.wangfed.com [206.137.100.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA23887 for ; Mon, 20 Dec 1999 09:35:26 -0800 (PST) Received: by wfhqex05.wangfed.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Dec 1999 12:40:18 -0500 Message-ID: <33BD629222C0D211B6DB0060085ACF315A05E5@wfhqex03.wang.com> From: "Pawling, John" To: "'SMIME WG'" Subject: Final 11 November 1999 S/MIME WG Minutes Date: Mon, 20 Dec 1999 12:40:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This message includes the minutes of the IETF S/MIME Working Group meeting held on 11 November 1999 in Washington, D.C. All briefing slides are stored at: ftp://ftp.ietf.org/ietf/smime/. These minutes include comments from the briefing presenters. Reported by John Pawling. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Introductions - Russ Housley Russ reviewed the agenda as follows. Nobody objected to the agenda. Introductions Russ Housley RFC 2630 - 2634 Status Russ Housley Charter Revision Russ Housley Small Subgroup Attack Mike Just CERTDIST Draft Discussion Jim Schaad DOMSEC Draft Discussion Bill Ottaway CMS/ESS Examples Paul Hoffman Security Policies and Labels Weston Nicolls KEA and SKIPJACK Algorithms John Pawling CAST-128 Algorithm Carlisle Adams Elliptic Curve Algorithms Paul Lambert ETSI Electronic Signatures Denis Pinkas S/MIME Freeware Library John Pawling Wrap up Russ Housley +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ RFC 2630-2634 Status - Russ Housley Russ outlined the strategy for advancing the following RFCs from Internet Proposed Standards to Internet Draft Standards: RFC 2630 Cryptographic Message Syntax, R. Housley, June 1999 RFC 2631 Diffie-Hellman Key Agreement Method, E. Rescorla, June 1999 RFC 2632 S/MIME Version 3 Certificate Handling, B. Ramsdell, June 1999 RFC 2633 S/MIME Version 3 Message Specification, B. Ramsdell, June 1999 RFC 2634 Enhanced Security Services for S/MIME, P. Hoffman, June 1999 The aforementioned documents must meet the following requirements to become Draft Standards: 1) Meet requirements documented in RFC 2026 2) Stable, mature, and useful specification 3) At least two independent and interoperable implementations from different code bases Stable, Mature, and Useful: - Strong belief that the specification is mature and will be useful - Must be well-understood and known to be quite stable - semantics and basis for developing an implementation - may still require additional or more widespread field experience - Considered to be a final specification - changes are likely to be made only to solve specific problems - reasonable for vendors to deploy implementations Russ noted that no significant errors had been reported to the aforementioned RFCs. Implementations: - At least two independent and interoperable implementations from different code bases: - interoperable means to be functionally equivalent or interchangeable - applies to all of the options and features - Working Group chair responsible for documenting specific implementations and interoperability testing: - support of each of the individual options and features - submitted to Area Director with protocol action request Way Forward: - CMS and ESS Examples I-D providing informal inputs - Jim Schaad is developing matrices for RFCs 2630-2634 - Paul Hoffman has offered to coordinate interoperability testing Paul Hoffman stated that another requirement for a Proposed Standard to become a Draft Standard is that all normative references to other RFCs must refer to Draft Standards. RFC 2632 includes a normative reference to RFC 2459 (Internet X.509 Public Key Infrastructure Certificate and CRL Profile), so RFC 2632 can not become a Draft Standard until RFC 2459 becomes one. Russ agreed with Paul's statement that a Draft Standard cannot include a normative reference to a document that has not achieved at least Draft Standard status. Russ agreed that since RFC 2632 relies on RFC 2459, then RFC 2459 will have to become a Draft Standard before or at the same time as RFC 2632. Paul pointed out that each requirement must be implemented by at least two independent code bases such that they are interoperable, but a single code base does not need to implement all of the requirements. Russ agreed that the entire set of requirements could be implemented by a variety of sources. The matrices being initiated by Jim Schaad will indicate which features have and have not been implemented. John Pawling asked if there were any plans to change the Attribute Certificate (AC) syntax used in RFC 2630. Currently, RFC 2630 imports the AC syntax from the 1997 X.509 Recommendation, but the draft IETF PKIX Attribute Certificate Profile Internet Draft specifies a different AC syntax. Russ pointed out that if RFC 2630 imported the AC syntax from the PKIX AC Profile, then RFC 2630 could not achieve Draft Standard status until the PKIX AC Profile achieved that status (which Russ believes will be at least six months). Russ stated that he believed that RFC 2630 should continue to import the AC syntax from the 1997 X.509 Recommendation because the other AC syntax is still not stable. He stated that the new features of the new AC syntax don't apply to RFC 2630. The new AC syntax allows for binding attributes to arbitrary objects identified by object identifiers. John pointed out that a new CMS specification could be drafted in the future which could include the new AC syntax once it is stable. Nobody disagreed with Russ' statement that the RFC 2630 AC syntax should not be changed. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Charter Revision - Russ Housley Russ stated that the following work items have been approved since the July S/MIME working group meeting: - Small Subgroup Attack Informational RFC - Additional Algorithm Support: - KEA, SKIPJACK Informational RFC - IDEA, CAST, and ECC Standards Track RFCs - CMS and ESS Examples Informational RFC - CERTDIST Standards Track RFC - Password-based Key Management RecipientInfo Extension Standards Track RFC - Mail List Key Distribution Standards Track RFC - Security Label Usage Informational RFC - DOMSEC Experimental RFC Russ stated that there is another proposed addition: CMS Compressed Proposed Standard RFC. Compression improves security by removing known data patterns, improves throughput by reducing the amount of data which needs to be encrypted or hashed, and reduces the overall message size. Enabling S/MIME version 3 to use compression will provide all of these advantages. The proposed schedule is as follows: Oct 1999 - First Compression I-D. Jan 2000 - Compression Last Call. Apr 2000 - Compression Proposed Standard RFC. Russ stated that both IETF Security Area Directors have expressed support for this addition. Russ asked if any attendees knew of any issues, had comments or wished to discuss any related topics, and no one raised anything. Russ asked if there were any patent concerns, and no one raised any patent concerns. Paul Hoffman stated that the previous IP Compression working group had already worked on a compression standard and that the previous MIME working group had purposely avoided the issue of compression. Russ asked if the meeting attendees approved the addition of compression. The majority approved. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Small Subgroup Attack - Mike Just Mike stated that there had not been a new draft of the "Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME" I-D since the last meeting. One minor comment was received regarding wordsmithing. Russ asked if the attendees believed that the I-D was ready for working group last call. Nobody objected, so Russ asked that the aforementioned comment be incorporated into a new I-D and then that I-D would be submitted for last call. Russ asked that people please carefully review the I-D. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CERTDIST Draft Discussion - Jim Schaad Jim discussed the Certificate Distribution Specification I-D (CERTDIST-04), October 20, 1999. He stated that "directory people" had criticized CERTDIST, but had not proposed an alternate solution. Russ noted that the directory folks were complaining because certificates are stored in the directory twice within different attributes. He said that they are concerned that the certificates stored within the two attributes will be different. He also said that they proposed that SupportedAlgorithms could be used. Jim pointed out that the SMIMECapabilities signed attribute could be used to point to a certificate rather than storing the entire certificate. Jim also stated that the method proposed in CERTDIST allows each certificate to claim different algorithm preferences. Carlisle Adams asked if the SMIMECapabilities signed attribute is supposed to be tied to a specific certificate. Jim answered that SMIMECapabilities must be tied to a specific key management certificate. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ DOMSEC Draft Discussion - Bill Ottaway Bill presented a briefing regarding the Domain Security Services Using S/MIME I-D (DOMSEC-03). Bill provided an overview of the DOMSEC concepts and the new features. The new features included: Naming conventions for signing and encryption, and the creation of a NULL signature when there is no originator signature present. Bill's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes the details regarding the issues and proposed solution for each new feature. Bill's goal is that DOMSEC should achieve RFC status in 2000. He would like DOMSEC to describe a solution that will work for a wide variety of organizations. He has received significant feedback from Baltimore, but would like to hear feedback from others. Jim Schaad recommended that the domain name should be exactly matched. Jim also pointed out that RFC 2630 states that the content type should be id-data when there are no signers of a signedData object. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CMS/ESS Examples - Paul Hoffman Paul stated that there has been much progress with the "Examples of S/MIME Messages" I-D and that almost all of the examples have been provided for incorporation into the document. He stated that there needs to be more testers of the sample data. He asked that folks please publicize their progress with verifying the sample data. Paul asked if there was any interest in a PKIX Examples Document. There was not much interest shown by the attendees. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Security Policies and Labels - Weston Nicolls Weston stated that he is developing an I-D that will document the security policies of Whirlpool, Caterpillar and Amoco. The draft will describe how the ESSSecurityLabel can be used to implement those corporate security policies. It is planned that the document will be an Informational RFC. Weston stated that he has been provided with classification policies for: - Amoco Corporation: - General, Confidential, Highly Confidential - Minimum, Medium, Maximum Integrity - Caterpillar Inc - Public, Confidential Green, Confidential Yellow, Confidential Red - Whirlpool Corporation - Public, Internal, Confidential - Privacy Labels - Security Categories? Jim Schaad pointed out that an example security policy is needed to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. The implication of Jim's statement is that one of the security policies described in Weston's document could be used to populate sample ESSSecurityLabel attributes to be included in the "Examples of S/MIME Messages" I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ KEA and SKIPJACK Algorithms - John Pawling John presented the CMS KEA and SKIPJACK Conventions I-D (CMSKEA-02), 29 July 1999. The goal of CMSKEA is to promote interoperability between implementations using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithms with the RFC 2630 enveloped-data and encrypted-data content types. CMSKEA describes a profile for using SKIPJACK and KEA with CMS. It describes modes, key lengths, object identifiers and parameter formats associated with the use of SKIPJACK and KEA with CMS. J.G. Van Dyke and Associates (VDA), a Wang Government Services Company, has used the S/MIME Freeware Library with the Fortezza Cryptologic Interface (CI) Library and Fortezza Card to successfully perform interoperability testing with Microsoft. This testing verifies the correctness of the CMSKEA I-D. The "FORTEZZA Card\CI Library Usage With CMS KEA SKIPJACK I-D" text file (available from http://www.jgvandyke.com/services/infosec/sfl.htm) contains hints for using the FORTEZZA Card and FORTEZZA CI Library to meet the CMSKEA requirements. Russ pointed out that CMSKEA is planned to be an Informational RFC. He stated that he would like to issue the working group last call for CMSKEA. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ CAST-128 Algorithm for S/MIME - Carlisle Adams Carlisle discussed the "Use of the CAST-128 Encryption Algorithm in S/MIME" I-D, September 1999 (cast-128-00). He stated that this is a short, simple specification. It documents how to use CAST-128 as a content encryption algorithm and a key encryption algorithm. The relevant algorithm object identifiers and parameters are specified. Carlisle stated that there are patents issued and pending regarding the CAST design procedure, but CAST-128 (described in RFC 2144) may be used by anyone for any purpose without paying any royalties or obtaining any licenses as stated in www.ietf.org/ipr.html. He stated that there is no encumbrance in using CAST-128. The same is true for CAST-256 (RFC 2612). Russ pointed out that the CAST-128 document is planned to be on Standards Track. He stated that he would like to issue the working group last call for the document as soon as possible. Nobody objected. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Elliptic Curve Algorithms - Paul Lambert Paul briefed the "Elliptic Curve S/MIME" I-D, October 1999 (ECC-00). He stated that the EC algorithms support digital signatures and key management. EC Diffie-Hellman (D-H) is based on ANSI X9.63 and EC Digital Signature Algorithm is based on ANSI X9.62. Paul stated that there is one issue. The I-D includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. Paul's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EC S/MIME I-D. Paul Hoffmann stated his concerns about the patent issues regarding the EC algorithms. He stated that the IPR for the EC algorithms is insufficient for the WG to decide what to do. Paul Lambert stated that Certicom has patents and patent applications that may cover the specification and will include a pointer to the IPR statement in the EC S/MIME I-D. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ETSI Electronic Signatures - Denis Pinkas Denis briefed the "European Electronic Signature Standardisation Initiative". He stated that the European Community plans to vote on the EESSI directive. The directive will cover anything in digital form that can prove the identity of the signer. The goal is to specify technology and standards that are equivalent to a manual signature. The ETSI definition provides "Evidence in a digital form than can be processed to get confidence that some commitment has been explicitly endorsed under a signature policy, at a given time, by a signer under an identifier, e.g. a name or a pseudonym, and optionally a role." The ETSI draft Standard builds upon RFC 2630 and RFC 2634. It defines new signed and unsigned attributes. The Electronic Signature uses signed attributes defined in RFC 2630, RFC 2634 and the draft ETSI standard including: - signature policy ID (reference and hash) (new), - commitment type (new), - content Type [RFC 2630], - signer's physical location (new), - signing time [RFC 2630], - signing certificate reference [RFC 2634], - role attribute (claimed or certified) (new). Denis also briefed regarding the role of time stamping in the EESSI. His briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the EESSI. An attendee asked how the verifier can prove the signer's physical location. Denis said that the EESSI specification replicates the services provided by the paper hard copy which is no authentication of the signer's location value. Phillip Hallam-Baker stated that the requirement for the signer to state her location is bogus and is not required in the United Kingdom. An attendee stated that a 760-bit signing key could be compromised in 20 years, so the time stamp signature could be compromised too. Denis said that an authority can re-sign the time stamps with a longer length key or could apply two stamps. Chris Bonatti asked if the signature policy is selected by the signer, what guarantee is there that the verifier will recognize the signature policy. Denis said that the verifier will look for specific values. An attendee asked whether there will be a signature policy distribution point from which people could obtain defined policies. Denis said that service might be provided by the International Chamber of Commerce. An attendee asked if XML would be more useful to describe the signature policy than ASN.1. Denis said that ASN.1 will be used for now, but XML may be used in the future. Phillip Hallam-Baker stated that XML is better for future use. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ S/MIME Freeware Library (SFL) - John Pawling John provided an update briefing regarding the SFL which is a freeware implementation of RFC 2630 and RFC 2634. It uses the Crypto++ freeware library to implement RFC 2631. It provides functions to support use of RFC 2632 and RFC 2633. The goal of the SFL is to provide a reference implementation of RFC 2630 and RFC 2634 to encourage their acceptance as Internet Standards. VDA is developing the SFL. The SFL implements the optional RFC 2634 security services such as signed receipts, security labels, mail list information, signing certificate attribute and equivalent security labels. It has been used with the RSA BSAFE v4.2, Crypto++ v3.1, Fortezza CI and SPYRUS SPEX/ libraries. VDA is now developing the capability for the SFL to use any security library that provides a PKCS #11 interface. Version 1.3 of the SFL was released in October 1999. It was tested on MS Windows 95/NT and Sun Solaris 2.6. It was tested using the mandatory and RSA algorithm suites. VDA continues to enhance the SFL. Organizations can use the SFL as part of their applications without paying any royalties or licensing fees (see SFL Public License). All source code is provided. The VDA-enhanced SNACC ASN.1 software is freely available at http://www.jgvandyke.com/services/infosec/sfl.htm. All other portions of the SFL are available at: http://www.armadillo.huntsville.al.us/software/smime and are export controlled as per U.S. Government Export Administration Regulations (see: http://www.bxa.doc.gov/Encryption/Default.htm). John also provided information regarding the Certificate Management Library (CML) that is a freeware implementation of X.509 version 3 certification path verification as specified in the 1997 X.509 Recommendation (except Delta CRLs are not implemented). The CML: validates X.509 certification paths and CRLs; provides local certificate/CRL storage functions; and provides remote directory retrieval via LDAP. The CML uses the Certificate Path Development Library (CPDL) developed by Cygnacom Solutions to robustly build certification paths including cross certificates. The CML complies with the majority of the RFC 2459 requirements. Organizations can use the CML as part of their applications without paying any royalties or licensing fees (see CML Public License). All CML source code is provided. CML is available at: http://www.armadillo.huntsville.al.us/software. John's briefing is stored at ftp://ftp.ietf.org/ietf/smime/ and includes additional details regarding the SFL and CML. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Wrap Up - Russ Housley Russ discussed the work item proposing the use of password-based key management for file encryption. This is documented in the "Password-based Encryption for S/MIME" I-D. The proposal uses PKCS #5 techniques. Russ stated that the working group needs to decide if that proposal will be accepted. He encouraged people to read the document and provide comments. Bob Jueneman stated his concern with the processing of name forms. Bob is concerned that not all applications display all address spec texts. He stated that they may omit, abbreviate or truncate the address spec text. He believes that this should be a joint work item between the PKIX and S/MIME working groups. He stated that properly supporting the address spec requirements is important. He recommends that we allow the use of a personal name form that precedes the address spec. For example, a husband and wife may share an e-mail address, but use different certificates. Paul Hoffman stated that RFC 822 includes a third option that allows comments to be included in parentheses. The third option must be included in any solution. He agreed that this issue needs to be resolved. Bob Jueneman also stated his concern regarding using the same object identifier to indicate two-key triple-DES and three-key triple-DES. He believes that separate object identifiers must be used for export control reasons. Two-key triple-DES may be exportable, but 3-key triple-DES may not be exportable. He said that 168-bit keys (112 effective) need a separate object identifier. Paul Hoffman stated that his understanding is that two-key is 80-bit and three-key is 112 bit (effective). He does not believe that the object identifier should be changed. Russ asked if it would be acceptable to examine the contents of the key to determine if the first and third keys are the same. Bob said that he has to enforce that they are the same. Russ said that it seems to be a receive-side issue, since the send-side controls the formation of the keys. Russ asked if the receive side could examine the keys and stop processing if the first and third keys are different. Paul Hoffman noted the creation of the S/MIME developers mail list for discussing implementation of S/MIME. The new list is a good place to send sample S/MIME messages for interoperability testing. The list is called imc-smime-dev@imc.org. To subscribe, send a message to imc-smime-dev-request@imc.org with the single word "subscribe" in the body of the message. Russ noted that members of the S/MIME mail list don't necessarily need to use S/MIME-enabled e-mail products. Meeting adjourned. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA02767 for ietf-smime-bks; Wed, 15 Dec 1999 07:43:29 -0800 (PST) Received: from sentry (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02762 for ; Wed, 15 Dec 1999 07:43:28 -0800 (PST) Received: by sentry; id KAA01228; Wed, 15 Dec 1999 10:48:14 -0500 (EST) Received: from unknown(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma001222; Wed, 15 Dec 99 10:47:18 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id KAA29904 for ietf-smime@imc.org; Wed, 15 Dec 1999 10:46:32 -0500 (EST) Date: Wed, 15 Dec 1999 10:46:32 -0500 (EST) From: "David M. Balenson" Message-Id: <199912151546.KAA29904@clipper.gw.tislabs.com> To: ietf-smime@imc.org Subject: ISOC Netw. & Distr. Sys. Security Symp. (NDSS 2000) Sender: owner-ietf-smime@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 Year 2000 NETWORK AND DISTRIBUTED SYSTEM SECURITY (NDSS) SYMPOSIUM February 2-4, 2000 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Gene Tsudik, USC/Information Sciences Institute Avi Rubin, AT&T Labs - Research ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss2000 EARLY REGISTRATION DISCOUNT DEADLINE: January 6, 2000 The 7th 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. KEYNOTE SPEAKER: Gene Spafford, Professor of Computer Sciences at Purdue University, an expert in information security, computer crime investigation and information ethics. Spaf (as he is known to his friends, colleagues, and students) is director of the Purdue CERIAS (Center for Education and Research in Information Assurance and Security), and was the founder and director of the (now superseded) COAST Laboratory. THIS YEAR'S TOPICS INCLUDE: - Automated Detection of Buffer Overrun Vulnerabilities - User-Level Infrastructure for System Call Interposition - Optimized Group Rekey for Group Communication Systems - IPSec-based Host Architecture for Secure Internet Multicast - The Economics of Security - Automatic Generation of Security Protocols - Security Protocols for SPKI-based Delegation Systems - Secure Border Gateway Protocol (S-BGP) - Analysis of a Fair Exchange Protocol - Secure Password-Based Protocols for TLS - Chameleon Signatures - Lightweight Tool for Detecting Web Server Attacks - Adaptive and Agile Applications Using Intrusion Detection - Secure Virtual Enclaves - Encrypted rlogin Connections Created With Kerberos IV - Accountability and Control of Process Creation in Metasystems - Red Teaming and Network Security PRE-CONFERENCE TECHNICAL TUTORIALS: - Network Security Protocol Standards, Dr. Stephen T. Kent - Deployed and Emerging Security Systems for the Internet, Dr. Radia Perlman and Charlie Kaufman - Mobile Code Security and Java 2 Architecture, Dr. Gary McGraw - Cryptography 101, Dr. Aviel D. Rubin - Public Key Infrastructure - The Truth and How to Find It, Dr. Daniel E. Geer, Jr. - An Introduction to Intrusion Detection Technology, Mr. Mark Wood FOR MORE INFORMATION contact the Internet Society: Internet Society, 11150 Sunset Hills Road, Reston, VA, 20190 USA Phone: +1-703-326-9880 Fax: +1-703-326-9881 E-mail: ndss2000reg@isoc.org URL: http://www.isoc.org/ndss2000/ SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Carla Rosenfeld at the Internet Society at +1-703-326-9880 or send e-mail to carla@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: by ns.secondary.com (8.9.3/8.9.3) id GAA28486 for ietf-smime-bks; Wed, 15 Dec 1999 06:39:49 -0800 (PST) Received: from gauntlet.corecom.com ([206.74.64.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA28475 for ; Wed, 15 Dec 1999 06:39:46 -0800 (PST) Received: by gauntlet.corecom.com; id KAA18584; Wed, 15 Dec 1999 10:07:31 -0500 (EST) Received: from unknown(207.86.152.184) by gauntlet.corecom.com via smap (V4.2) id xmad18567; Wed, 15 Dec 99 10:06:47 -0500 Message-Id: <4.1.19991215091557.00a9da60@mail2.netreach.net> X-Sender: davep@hargray.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 15 Dec 1999 09:16:27 -0500 To: ietf-smime@imc.org From: Dave Piscitello Subject: Internet Security Conference, Call for Papers, Abstracts Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: The Fourth Internet Security Conference will be held April 24-28, 2000 in San Jose, CA, at the Fairmont Hotel. TISC is an educational forum for security professionals and practitioners. The TISC Security Symposium is an opportunity for individuals to share their expertise and practical experience with others involved in the design, implementation and deployment of networked security systems. For April, we have invited a few original papers from past TISC workshop instructors and speakers. Accepted papers will be presented at the conference. We cordially invite you to submit a session abstract for consideration, or if you prefer, to present a topic as a panel member. We encourage you to submit abstracts and topics by December 20. Further information can be found at http://tisc.corecom.com. Or send your proposal to me directly (mailto:dave@corecom.com). We look forward to your participation. Thank you. Warm Regards, Dave Piscitello On behalf of the TISC Advisory Board Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15287 for ietf-smime-bks; Sat, 11 Dec 1999 15:38:10 -0800 (PST) Received: from jis.ne.mediaone.net (jis.ne.mediaone.net [24.218.230.94]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15283 for ; Sat, 11 Dec 1999 15:38:08 -0800 (PST) Received: from jis.ne.mediaone.net (localhost [127.0.0.1]) by jis.ne.mediaone.net (8.8.7/8.8.7) with SMTP id RAA01652; Sat, 11 Dec 1999 17:30:20 -0500 From: Jeffrey Schiller Date: Sat, 11 Dec 1999 22:30:20 GMT Message-ID: <19991211.22302000@jis.ne.mediaone.net> Subject: Re: Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt To: Russ Housley CC: jis@mit.edu, MLeech@nortel.ca, ietf-smime@imc.org In-Reply-To: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> References: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> X-Mailer: Mozilla/4.5 [en] (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id PAA15284 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I have requested that this document be placed on this week's agenda. -Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 12/7/99, 7:17:17 PM, Russ Housley wrote regarding Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt: > Jeff and Marcus: > This document has completed Working Group Last Call, and it represents the > consensus of the S/MIME Mail Security Working Group. It is ready for IETF > Last Call and subsequent publication as an Informational RFC. > Title : Methods for Avoiding the 'Small-Subgroup' Attacks on > the Diffie-Hellman Key Agreement Method for S/MIME > Author(s) : R. Zuccherato > Filename : draft-ietf-smime-small-subgroup-03.txt > Pages : 9 > Date : 03-Dec-99 > > Russ Received: by ns.secondary.com (8.9.3/8.9.3) id MAA24758 for ietf-smime-bks; Fri, 10 Dec 1999 12:08:36 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA24754 for ; Fri, 10 Dec 1999 12:08:32 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA09680; Fri, 10 Dec 1999 11:58:02 -0800 (PST) Message-Id: <4.2.0.58.19991210145504.009fabf0@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 14:56:28 -0500 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Ready for IETF Last Call: draft-ietf-smime-cmskea-04.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: This document has completed Working Group Last Call, and it represents the consensus of the S/MIME Mail Security Working Group. It is ready for IETF Last Call and subsequent publication as an Informational RFC. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-04.txt Pages : 10 Date : 09-Dec-99 Russ Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22156 for ietf-smime-bks; Fri, 10 Dec 1999 08:53:06 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22152 for ; Fri, 10 Dec 1999 08:53:05 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id IAA05812 for ; Fri, 10 Dec 1999 08:54:29 -0800 (PST) Message-Id: <4.2.0.58.19991210114832.009fc220@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 10 Dec 1999 11:53:37 -0500 To: ietf-smime@imc.org From: Russ Housley Subject: Elliptic Curve Key Management Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Paul Lambert briefed the "Elliptic Curve S/MIME" Internet-Draft at the IETF meeting in November. The document is stored in draft-ietf-smime-ecc-00.txt, and it includes EC algorithms for digital signatures and key management. The EC Diffie-Hellman (D-H) is based on ANSI X9.63, and the EC Digital Signature Algorithm is based on ANSI X9.62. During his briefing, Paul stated that there is one issue. The Internet-Draft includes two recommendations for ECDH: one-pass D-H and cofactor D-H. Paul recommends that the S/MIME working group pick one or the other, but not both. I want this thread to begin the discussion for the selection... Received: by ns.secondary.com (8.9.3/8.9.3) id FAA19436 for ietf-smime-bks; Fri, 10 Dec 1999 05:04:22 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA19432 for ; Fri, 10 Dec 1999 05:04:20 -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 IAA09467; Fri, 10 Dec 1999 08:07:37 -0500 (EST) Message-Id: <199912101307.IAA09467@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-cmskea-04.txt Date: Fri, 10 Dec 1999 08:07:36 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-04.txt Pages : 10 Date : 09-Dec-99 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word 'subscribe' in the body of the message. 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-cmskea-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-04.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-cmskea-04.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: <19991209121016.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991209121016.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA01623 for ietf-smime-bks; Thu, 9 Dec 1999 12:14:35 -0800 (PST) Received: from 157.22.235.99 ([157.22.235.99]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA01619; Thu, 9 Dec 1999 12:14:32 -0800 (PST) Received: from [157.22.235.84] by 157.22.235.99 (AppleShare IP Mail Server 6.2) id 30901 via TCP with SMTP; Thu, 09 Dec 1999 12:14:29 -0800 Message-id: <991209121429.3b44e7f.9d16eb63.ASIP6.2.30901@157.22.235.99> X-Mailer: Microsoft Outlook Express Macintosh Edition - 4.5 (0410) Date: Thu, 09 Dec 1999 12:14:29 -0800 Subject: Subscription Request From: "Heidi Slominski" To: Subscriptions Mime-version: 1.0 X-Priority: 3 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: I'd greatly appreciate it if you would please forward me the appropriate information for subscribing to/getting the digest for your mail list. Thank you very much! Warm Regards, Heidi Slominski Marketing Coordinator -- Mactivity, Inc. Conference Organizers Tel: 408-354-2500 Fax: 408-354-2571 www.mactivity.com Received: by ns.secondary.com (8.9.3/8.9.3) id LAA00460 for ietf-smime-bks; Tue, 7 Dec 1999 11:24:30 -0800 (PST) Received: from mail.spyrus.com (mail.spyrus.com [207.212.34.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA00456 for ; Tue, 7 Dec 1999 11:24:29 -0800 (PST) Received: from rhousley_laptop.spyrus.com ([209.172.119.101]) by mail.spyrus.com (8.9.3/8.9.3) with ESMTP id LAA09436; Tue, 7 Dec 1999 11:19:10 -0800 (PST) Message-Id: <4.2.0.58.19991207141311.009db160@mail.spyrus.com> X-Sender: rhousley@mail.spyrus.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 07 Dec 1999 14:17:17 -0500 To: jis@mit.edu, MLeech@nortel.ca From: Russ Housley Subject: Ready for IETF Last Call: draft-ietf-smime-small-subgroup-03.txt Cc: ietf-smime@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Jeff and Marcus: This document has completed Working Group Last Call, and it represents the consensus of the S/MIME Mail Security Working Group. It is ready for IETF Last Call and subsequent publication as an Informational RFC. Title : Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME Author(s) : R. Zuccherato Filename : draft-ietf-smime-small-subgroup-03.txt Pages : 9 Date : 03-Dec-99 Russ Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13573 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:57 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13569 for ; Mon, 6 Dec 1999 04:02:55 -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 HAA15961; Mon, 6 Dec 1999 07:05:51 -0500 (EST) Message-Id: <199912061205.HAA15961@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-password-01.txt Date: Mon, 06 Dec 1999 07:05:51 -0500 Sender: owner-ietf-smime@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 : Password-based Encryption for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-password-01.txt Pages : 8 Date : 03-Dec-99 The Cryptographic Message Syntax data format doesn't currently contain any provisions for password-based data encryption. This document provides a method of encrypting data using user-supplied passwords (and, by extension, any form of variable-length keying material which isn't necessarily an algorithm-specific fixed-format key). 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-password-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-password-01.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-password-01.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: <19991203121643.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-password-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-password-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121643.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13567 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:50 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13563 for ; Mon, 6 Dec 1999 04:02:49 -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 HAA15887; Mon, 6 Dec 1999 07:05:45 -0500 (EST) Message-Id: <199912061205.HAA15887@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-small-subgroup-03.txt Date: Mon, 06 Dec 1999 07:05:44 -0500 Sender: owner-ietf-smime@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 : Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME Author(s) : R. Zuccherato Filename : draft-ietf-smime-small-subgroup-03.txt Pages : 9 Date : 03-Dec-99 In some circumstances the use of the Diffie-Hellman key agreement scheme in a prime order subgroup of a large prime p is vulnerable to certain attacks known as 'small-subgroup' attacks. Methods exist, however, to prevent these attacks. This document will describe the situations relevant to implementations of S/MIME version 3 in which protection is necessary and the methods that can be used to prevent these attacks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-smime-small-subgroup-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-small-subgroup-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-small-subgroup-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: <19991203121631.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-small-subgroup-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-small-subgroup-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121631.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13559 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:41 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13555 for ; Mon, 6 Dec 1999 04:02:40 -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 HAA15802; Mon, 6 Dec 1999 07:05:36 -0500 (EST) Message-Id: <199912061205.HAA15802@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-compression-00.txt Date: Mon, 06 Dec 1999 07:05:35 -0500 Sender: owner-ietf-smime@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 : Compressed Data Content Type for S/MIME Author(s) : P. Gutmann Filename : draft-ietf-smime-compression-00.txt Pages : 4 Date : 03-Dec-99 The Cryptographic Message Syntax data format doesn't currently contain any provisions for compressing data before processing it. Compressing data before transmission provides a number of advantages including the elimination of data redundancy which could help an attacker, speeding up processing by reducing the amount of data to be processed by later steps such as signing or encryption, and reducing overall message size. This document defines a format for using compressed data as a CMS content type. 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-compression-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-compression-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-smime-compression-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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: <19991203121618.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-compression-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-compression-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121618.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA13552 for ietf-smime-bks; Mon, 6 Dec 1999 04:02:34 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA13548 for ; Mon, 6 Dec 1999 04:02:32 -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 HAA15719; Mon, 6 Dec 1999 07:05:28 -0500 (EST) Message-Id: <199912061205.HAA15719@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-cmskea-03.txt Date: Mon, 06 Dec 1999 07:05:27 -0500 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the S/MIME Mail Security Working Group of the IETF. Title : CMS KEA and SKIPJACK Conventions Author(s) : J. Pawling Filename : draft-ietf-smime-cmskea-03.txt Pages : 10 Date : 03-Dec-99 This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types. This draft is being discussed on the 'ietf-smime' mailing list. To subscribe, send a message to ietf-smime-request@imc.org with the single word 'subscribe' in the body of the message. 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-cmskea-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-smime-cmskea-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-cmskea-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: <19991203121601.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-smime-cmskea-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-smime-cmskea-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19991203121601.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA03899 for ietf-smime-bks; Thu, 2 Dec 1999 11:15:39 -0800 (PST) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03895 for ; Thu, 2 Dec 1999 11:15:37 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 14:17:46 -0500 Message-ID: <01E1D01C12D7D211AFC70090273D20B101063196@sothmxs06.entrust.com> From: Robert Zuccherato To: ietf-smime@imc.org, "'Linn, John'" Cc: "'Burt Kaliski'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 14:17:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3CF9.EA2CB528" Sender: owner-ietf-smime@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_01BF3CF9.EA2CB528 Content-Type: text/plain John; I will add your comment below as the second paragraph of Section 4. You are correct, it does clarify the discussion. Robert. > ---------- > From: Linn, John[SMTP:jlinn@rsasecurity.com] > Sent: Thursday, December 02, 1999 11:17 AM > To: 'Robert Zuccherato'; ietf-smime@imc.org > Cc: 'Burt Kaliski' > Subject: RE: Working Group Last Call: > draft-ietf-smime-small-subgroup-02.t xt > > Robert, > > Thanks for your quick and thoughful consideration of the comments. Your > responses look good; we've a residual content-level observation to make on > only one item: > > [Sec. 4] > > Re: "This isn't clear to me. For example, if an attacker modified both > public keys to be yb=ya=1 and the parties authenticated each other over a > telephone conversation in which they read out the agreed upon key. Now, > they > will both agree on the same key and they will have a certain level of > authentication, but the attacker will be able to eavesdrop. Thus, it is > important that each party's *public key* be authenticated, which is the > point I was trying to make with this section. However, I agree that the > way > things are presently worded may be misleading. I will change the first > sentence of the second paragraph to "In some ephemeral-ephemeral key > agreements protection may be required for both entities." " > > Good points. As you observe, E-E gives an attacker more flexibility since > both parties' public keys can be changed and they can be coerced into > computing the same key from a small space. In E-S, only the sender's > public > key can be changed, and only the recipient can be coerced by an outsider > attacker into computing a key from a small space. While this may be > apparent, it seems useful to state explicitly for purposes of clarifying > comparison. > > [Sec. 3, minor editorial] > > Re: How about if I add a sentence following the first paragraph of Section > 3 > stating "Implementer's should note that some of the procedures described > in > this section may be the subject of patents or pending patents." > > "Implementer's" -> "Implementers". > > --jl > > ------_=_NextPart_001_01BF3CF9.EA2CB528 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

John;

I will add your = comment below as the second paragraph of Section 4.  You are = correct, it does clarify the discussion.

        Robert.

    ----------
    From:   = Linn, = John[SMTP:jlinn@rsasecurity.com]
    Sent:   = Thursday, December 02, 1999 11:17 = AM
    To: =     'Robert = Zuccherato'; ietf-smime@imc.org
    Cc: =     'Burt = Kaliski'
    Subject: =        RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

    Robert,

    Thanks for your quick and thoughful = consideration of the comments.  Your
    responses look good; we've a residual = content-level observation to make on
    only one item:

    [Sec. 4]

    Re: "This isn't clear to me. For = example, if an attacker modified both
    public keys to be yb=3Dya=3D1 and the = parties authenticated each other over a
    telephone conversation in which they = read out the agreed upon key. Now, they
    will both agree on the same key and = they will have a certain level of
    authentication, but the attacker will = be able to eavesdrop. Thus, it is
    important that each party's *public = key* be authenticated, which is the
    point I was trying to make with this = section. However, I agree that the way
    things are presently worded may be = misleading. I will change the first
    sentence of the second paragraph to = "In some ephemeral-ephemeral key
    agreements protection may be required = for both entities." "

    Good points. As you observe, E-E gives = an attacker more flexibility since
    both parties' public keys can be = changed and they can be coerced into
    computing the same key from a small = space. In E-S, only the sender's public
    key can be changed, and only the = recipient can be coerced by an outsider
    attacker into computing a key from a = small space.  While this may be
    apparent, it seems useful to state = explicitly for purposes of clarifying
    comparison.

    [Sec. 3, minor editorial]

    Re: How about if I add a sentence = following the first paragraph of Section 3
    stating "Implementer's should = note that some of the procedures described in
    this section may be the subject of = patents or pending patents."

    "Implementer's" -> = "Implementers".

    --jl
     

------_=_NextPart_001_01BF3CF9.EA2CB528-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA02654 for ietf-smime-bks; Thu, 2 Dec 1999 09:51:18 -0800 (PST) Received: from gandalf.trustpoint.com (IDENT:root@gandalf.trustpoint.com [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA02648 for ; Thu, 2 Dec 1999 09:51:17 -0800 (PST) Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id JAA15698; Thu, 2 Dec 1999 09:53:51 -0800 From: "John C. Kennedy" To: "Robert Zuccherato" Cc: Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.txt Date: Thu, 2 Dec 1999 09:59:10 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <01E1D01C12D7D211AFC70090273D20B101063194@sothmxs06.entrust.com> Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_000B_01BF3CAB.DDAF7180" Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000B_01BF3CAB.DDAF7180 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000C_01BF3CAB.DDB40560" ------=_NextPart_001_000C_01BF3CAB.DDB40560 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, I understand what it was pointing to. My suggestion was simply to change the reference tag itself, not the reference. Referencing RFC 2631 by [x942] is misleading since the former is only a profiled approximation of the latter. Regards, -John -----Original Message----- From: Robert Zuccherato [mailto:robert.zuccherato@entrust.com] Sent: Thursday, December 02, 1999 9:02 AM To: ietf-smime@imc.org; 'John C. Kennedy' Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt John; Actually, the [x942] reference points to: [x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in progress. Which was the Internet Draft for RFC 2631, not the X9.42 draft. All of the references are being updated to point to the appropriate RFCs. Robert. ---------- From: John C. Kennedy[SMTP:jkennedy@trustpoint.com] Sent: Wednesday, December 01, 1999 5:20 PM To: Robert Zuccherato; ietf-smime@imc.org Cc: 'Burt Kaliski'; 'Linn, John' Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, My concerns about alignment and attribution with the X9.42 draft stated recently on the mailing list are applicable here. I suggest replacing [x942] with [RFC2631], or something similar. RFC 2631 is currently, and presumably will remain, the normative reference; not the ANSI draft. Even if X9.42 ever becomes a standard, RFC2631 will continue to profile or otherwise approximate it but still remain the normative reference. -John ------=_NextPart_001_000C_01BF3CAB.DDB40560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt
Robert,
 
I=20 understand what it was pointing to.  My suggestion was simply to = change the=20 reference tag itself, not the reference.  Referencing RFC 2631 by = [x942] is=20 misleading since the former is only a profiled approximation of the=20 latter.
 
Regards,
 
-John
 
-----Original Message-----
From: Robert Zuccherato=20 [mailto:robert.zuccherato@entrust.com]
Sent: Thursday, = December 02,=20 1999 9:02 AM
To: ietf-smime@imc.org; 'John C.=20 Kennedy'
Subject: RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t xt

John;

Actually, the [x942] = reference points=20 to:

[x942] E. Rescorla, = "Diffie-Hellman=20 Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in = progress.=20

Which was the Internet = Draft for RFC=20 2631, not the X9.42 draft.  All of the references are being = updated to=20 point to the appropriate RFCs.

        Robert.

    ---------- =
    From:   John C.=20 Kennedy[SMTP:jkennedy@trustpoint.com]
    Sent:   Wednesday, December 01, 1999 5:20 = PM=20
    To: =    =20 Robert Zuccherato;=20 ietf-smime@imc.org
    Cc:     'Burt Kaliski'; 'Linn, John'
    Subject:        = RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t xt

    RE: Working Group Last Call:=20 draft-ietf-smime-small-subgroup-02.t
    xtRobert,

    My concerns about alignment and = attribution with=20 the X9.42 draft stated
    recently on the=20 mailing list are applicable here.  I suggest replacing =
    [x942] with [RFC2631], or something similar. = RFC 2631 is=20 currently, and
    presumably = will remain,=20 the normative reference; not the ANSI draft.  Even =
    if X9.42 ever becomes a standard, RFC2631 will = continue to=20 profile or
    otherwise = approximate it but=20 still remain the normative reference.

    -John=20



------=_NextPart_001_000C_01BF3CAB.DDB40560-- ------=_NextPart_000_000B_01BF3CAB.DDAF7180 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMjAyMTc1 OTA0WjAjBgkqhkiG9w0BCQQxFgQU/R6wG84SN5XeYyZW6bHC1NymRn8wWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgCgajzJQ7XoxzFy/FUYFPzrBHEj/sAWJgRfZn4JDxWn0Rc8Ji7TOIBU6 W8na1o2sdVIaD2lHrJ6K18FQuRwSaQ1FgI/JAkAtLDwePvRHOrVsAewCphYnOou7nz3DruTAPiTV xstRMSLc7jZb2tF9ilvZQTnKapEK6c+lXOoCcPXFAAAAAAAA ------=_NextPart_000_000B_01BF3CAB.DDAF7180-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA01992 for ietf-smime-bks; Thu, 2 Dec 1999 08:59:53 -0800 (PST) Received: from sothmxs01.entrust.com (gatekeeper.entrust.com [204.101.128.170]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01988 for ; Thu, 2 Dec 1999 08:59:51 -0800 (PST) Received: by sothmxs01.entrust.com with Internet Mail Service (5.5.2650.21) id ; Thu, 2 Dec 1999 12:02:00 -0500 Message-ID: <01E1D01C12D7D211AFC70090273D20B101063194@sothmxs06.entrust.com> From: Robert Zuccherato To: ietf-smime@imc.org, "'John C. Kennedy'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 12:01:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF3CE6.F23F871C" Sender: owner-ietf-smime@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_01BF3CE6.F23F871C Content-Type: text/plain John; Actually, the [x942] reference points to: [x942] E. Rescorla, "Diffie-Hellman Key Agreement Method", draft-ietf-smime-x942-0X.txt, work in progress. Which was the Internet Draft for RFC 2631, not the X9.42 draft. All of the references are being updated to point to the appropriate RFCs. Robert. > ---------- > From: John C. Kennedy[SMTP:jkennedy@trustpoint.com] > Sent: Wednesday, December 01, 1999 5:20 PM > To: Robert Zuccherato; ietf-smime@imc.org > Cc: 'Burt Kaliski'; 'Linn, John' > Subject: RE: Working Group Last Call: > draft-ietf-smime-small-subgroup-02.t xt > > RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t > xtRobert, > > My concerns about alignment and attribution with the X9.42 draft stated > recently on the mailing list are applicable here. I suggest replacing > [x942] with [RFC2631], or something similar. RFC 2631 is currently, and > presumably will remain, the normative reference; not the ANSI draft. Even > if X9.42 ever becomes a standard, RFC2631 will continue to profile or > otherwise approximate it but still remain the normative reference. > > -John > > > ------_=_NextPart_001_01BF3CE6.F23F871C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

John;

Actually, the [x942] = reference points to:

[x942] E. Rescorla, = "Diffie-Hellman Key Agreement Method", = draft-ietf-smime-x942-0X.txt, work in progress.

Which was the = Internet Draft for RFC 2631, not the X9.42 draft.  All of the = references are being updated to point to the appropriate = RFCs.

        Robert.

    ----------
    From:   = John C. = Kennedy[SMTP:jkennedy@trustpoint.com]
    Sent:   = Wednesday, December 01, 1999 5:20 = PM
    To: =     Robert = Zuccherato; ietf-smime@imc.org
    Cc: =     'Burt = Kaliski'; 'Linn, John'
    Subject: =        RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

    RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t
    xtRobert,

    My concerns about alignment and = attribution with the X9.42 draft stated
    recently on the mailing list are = applicable here.  I suggest replacing
    [x942] with [RFC2631], or something = similar. RFC 2631 is currently, and
    presumably will remain, the normative = reference; not the ANSI draft.  Even
    if X9.42 ever becomes a standard, = RFC2631 will continue to profile or
    otherwise approximate it but still = remain the normative reference.

    -John



------_=_NextPart_001_01BF3CE6.F23F871C-- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01371 for ietf-smime-bks; Thu, 2 Dec 1999 08:09:00 -0800 (PST) Received: from tholian.securitydynamics.com (tholian.securid.com [204.167.112.129]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA01367 for ; Thu, 2 Dec 1999 08:08:59 -0800 (PST) Received: from sdtihq24.securitydynamics.com by tholian.securitydynamics.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Dec 1999 16:09:49 UT Received: from exna00.securitydynamics.com (exna00.securitydynamics.com [10.2.1.110]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA01916; Thu, 2 Dec 1999 11:11:26 -0500 (EST) Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2448.0) id ; Thu, 2 Dec 1999 11:13:02 -0500 Message-ID: From: "Linn, John" To: "'Robert Zuccherato'" , ietf-smime@imc.org Cc: "'Burt Kaliski'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Thu, 2 Dec 1999 11:17:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: Robert, Thanks for your quick and thoughful consideration of the comments. Your responses look good; we've a residual content-level observation to make on only one item: [Sec. 4] Re: "This isn't clear to me. For example, if an attacker modified both public keys to be yb=ya=1 and the parties authenticated each other over a telephone conversation in which they read out the agreed upon key. Now, they will both agree on the same key and they will have a certain level of authentication, but the attacker will be able to eavesdrop. Thus, it is important that each party's *public key* be authenticated, which is the point I was trying to make with this section. However, I agree that the way things are presently worded may be misleading. I will change the first sentence of the second paragraph to "In some ephemeral-ephemeral key agreements protection may be required for both entities." " Good points. As you observe, E-E gives an attacker more flexibility since both parties' public keys can be changed and they can be coerced into computing the same key from a small space. In E-S, only the sender's public key can be changed, and only the recipient can be coerced by an outsider attacker into computing a key from a small space. While this may be apparent, it seems useful to state explicitly for purposes of clarifying comparison. [Sec. 3, minor editorial] Re: How about if I add a sentence following the first paragraph of Section 3 stating "Implementer's should note that some of the procedures described in this section may be the subject of patents or pending patents." "Implementer's" -> "Implementers". --jl Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA29539 for ietf-smime-bks; Wed, 1 Dec 1999 14:12:55 -0800 (PST) Received: from gandalf.trustpoint.com (IDENT:root@gandalf.trustpoint.com [216.100.231.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA29535 for ; Wed, 1 Dec 1999 14:12:53 -0800 (PST) Received: from himansu (himansu [192.168.42.5]) by gandalf.trustpoint.com (8.8.7/8.8.7) with SMTP id OAA12502; Wed, 1 Dec 1999 14:15:24 -0800 From: "John C. Kennedy" To: "Robert Zuccherato" , Cc: "'Burt Kaliski'" , "'Linn, John'" Subject: RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xt Date: Wed, 1 Dec 1999 14:20:42 -0800 MIME-Version: 1.0 Message-ID: X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-Type: multipart/signed; micalg=SHA1; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_0050_01BF3C07.3DDAF2A0" In-Reply-To: <01E1D01C12D7D211AFC70090273D20B101063182@sothmxs06.entrust.com> Importance: Normal X-Mimeole: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ietf-smime@imc.org Precedence: bulk List-Archive: List-ID: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0050_01BF3C07.3DDAF2A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0051_01BF3C07.3DDAF2A0" ------=_NextPart_001_0051_01BF3C07.3DDAF2A0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Working Group Last Call: draft-ietf-smime-small-subgroup-02.t xtRobert, My concerns about alignment and attribution with the X9.42 draft stated recently on the mailing list are applicable here. I suggest replacing [x942] with [RFC2631], or something similar. RFC 2631 is currently, and presumably will remain, the normative reference; not the ANSI draft. Even if X9.42 ever becomes a standard, RFC2631 will continue to profile or otherwise approximate it but still remain the normative reference. -John ------=_NextPart_001_0051_01BF3C07.3DDAF2A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Working Group Last Call: = draft-ietf-smime-small-subgroup-02.t xt

Robert,

My concerns about = alignment and attribution with the X9.42 draft=20 stated recently on the = mailing list=20 are applicable here.  I = suggest=20 replacing [x942] with [RFC2631], = or=20 something similar. RFC 2631 is=20 currently,=20 and presumably will remain, the normative reference; not the ANSI draft.  Even if X9.42 ever becomes a standard, = RFC2631=20 will continue to profile or otherwise approximate it but still = remain the=20 normative reference.

-John

------=_NextPart_001_0051_01BF3C07.3DDAF2A0-- ------=_NextPart_000_0050_01BF3C07.3DDAF2A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGhzCCAo8w ggH6oAMCAQICFQDZ+E/k9gGxjXStLkDx9Qm6iCXqjTALBgkqhkiG9w0BAQUwNTEWMBQGA1UEAxMN U01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01lbWUxCzAJBgNVBAYTAlVTMB4XDTk5MDYyNDIzNDQw OFoXDTE0MDYyNDIzNDQwOFowNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwGA1UEChMFU01l bWUxCzAJBgNVBAYTAlVTMIGdMAsGCSqGSIb3DQEBAQOBjQAwgYkCgYEAoh2u/ZzVrjTtXzowWcH1 vVHqUSJRsAF+TunEsqbZsn755D6Y0xe2ruYlNMEW7sExSoUYPQNR7cTQWwcFSyE3FtDhGGkYUt5O UgPXZ5HVuG/Q4UwocCbOx4CIIfNJJevfEw9MvthYugg2J13XBW5iUonP5aY5rO6VrQedIa1+q8kC AwEAAaOBoDCBnTAPBgNVHRMBAf8EBTADAQH/MB8GA1UdIwQYMBaAFNn4T+T2AbGNdK0uQPH1CbqI JeqNMB0GA1UdDgQWBBTZ+E/k9gGxjXStLkDx9Qm6iCXqjTAOBgNVHQ8BAf8EBAMCAP4wJwYDVR0l BCAwHgYIKwYBBQUHAwIGCCsGAQUFBwMDBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMCALcwCwYJ KoZIhvcNAQEFA4GBAJLpYU+A1SKEVesAvpylZ//Fhq/fOZrVnxBgEVHC0RpLMnlPG/Y2XaZqmr42 bIwvqZ50m6R5o41mob2N4a78ty30kAOLEvsxFaK06iezfHFJGn9TbLPEi2BTaIWCJv77skLSVjUe zzm5JAmaKwJ3txI6s4sbM6/rrnQ2oPa2/n+JMIID8DCCA1ugAwIBAgIVANnXVOID136qfHqgNaDC u+cYaTDNMAsGCSqGSIb3DQEBBTA1MRYwFAYDVQQDEw1TTWVtZSBSb290IENBMQ4wDAYDVQQKEwVT TWVtZTELMAkGA1UEBhMCVVMwHhcNOTkwODI1MDEzNjEyWhcNMDAwODI1MDEzNjEyWjBkMQswCQYD VQQGEwJVUzETMBEGA1UEChMKVHJ1c3Rwb2ludDEYMBYGA1UEAxMPSm9obiBDLiBLZW5uZWR5MSYw JAYJKoZIhvcNAQkBFhdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEAm/78rZZNYaJ67AZjKMwFb3ky+57qdCpI0oAbPpQQqYJOAzm0f2Y4Nlz3QMC0scMp lGvIpxr8qwMoPIReFo+X4e7QiyumvXfNkKSgFw43rA6ne0zACHX7dbx0U4c6NLLDYer+3lFAGe8M 9y2ICgWk9aBnRaPaUKKIJhDpp4zEepMCAwEAAaOCAc8wggHLMB0GA1UdDgQWBBRBz7sIilZiDESP GwAbpRjKtTIrajAhBgNVHSMEGgQYMBaAFNn4T+T2AbGNdK0uQPH1CbqIJeqNMA4GA1UdDwEB/wQE AwIA+DAnBgNVHSUEIDAeBggrBgEFBQcDAgYIKwYBBQUHAwMGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIAsDAiBgNVHREEGzAZgRdqa2VubmVkeUB0cnVzdHBvaW50LmNvbTBRBgNVHSAESjBIMEYG CCsGBAGYVB4BMDowOAYIKwYBBQUHAgEWLGh0dHA6Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3Jl ZW1lbnRfMS5odG1sMEQGCWCGSAGG+EIBAwQ3FjVodHRwOi8vd3d3LnNtZW1lLmNvbS9zZXJ2bGV0 cy9zbWVtZV9jYS9jaGVja19yZXZva2VkPzBBBglghkgBhvhCAQcENBYyaHR0cDovL3d3dy5zbWVt ZS5jb20vc2VydmxldHMvc21lbWVfY2EvcmVuZXdfY2VydD8wOwYJYIZIAYb4QgEIBC4WLGh0dHA6 Ly93d3cuc21lbWUuY29tL3NlcnZpY2VhZ3JlZW1lbnRfMS5odG1sMAsGCSqGSIb3DQEBBQOBgQB3 OYc+W2F6MemxaU4Udxf7CRVZ/fR8/zEs+mpb9WIT2Dsft7XRVKP/XWZeQwx5iBoFOaU6/Xf3yqr4 k6nqhEoj1sPYD5QuTS9M/NhPYovbyf/zzUcXGTV+JRK6TgTMbIbfyuMDfBKKfHXIv5gmJfZUCNhY N8C00T8yX9sEVYpzfzGCAg4wggIKAgEBME4wNTEWMBQGA1UEAxMNU01lbWUgUm9vdCBDQTEOMAwG A1UEChMFU01lbWUxCzAJBgNVBAYTAlVTAhUA2ddU4gPXfqp8eqA1oMK75xhpMM0wCQYFKw4DAhoF AKCCARYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNOTkxMjAxMjIy MDM4WjAjBgkqhkiG9w0BCQQxFgQUZ8pIkCg/YcTD6w7yjV/WgdfyH6YwWAYJKoZIhvcNAQkPMUsw STAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwBwYF Kw4DAhowCgYIKoZIhvcNAgUwXQYJKwYBBAGCNxAEMVAwTjA1MRYwFAYDVQQDEw1TTWVtZSBSb290 IENBMQ4wDAYDVQQKEwVTTWVtZTELMAkGA1UEBhMCVVMCFQDZ11TiA9d+qnx6oDWgwrvnGGkwzTAN BgkqhkiG9w0BAQEFAASBgEmxugXn2tk7dXrJZSbLRYJh4qvIvOT/moZiNrT+KBdWKbUiKcYmCylX G0JzOGT0dDdr4Ts00nj3OeQaPsu/7utRtnpyX17JVfgiGQ1dnPFAumg/SnM74wvEqylDoHRf9EKh HGXfSIZL4my7s04wq75rfK1L/8dfLPg7qAM+UfGiAAAAAAAA ------=_NextPart_000_0050_01BF3C07.3DDAF2A0--