From tls-bounces@lists.ietf.org Mon May 01 15:39:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeEY-0003om-5d; Mon, 01 May 2006 15:39:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaeEX-0003nW-0q for tls@ietf.org; Mon, 01 May 2006 15:39:01 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaeEU-0000uk-Fd for tls@ietf.org; Mon, 01 May 2006 15:39:01 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0IYL009M6QKQM610@dps.sfvic.sunlabs.com> for tls@ietf.org; Mon, 01 May 2006 12:38:50 -0700 (PDT) Received: from [152.70.69.223] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0IYL00J7AQKMP9Z1@mail.sunlabs.com> for tls@ietf.org; Mon, 01 May 2006 12:38:50 -0700 (PDT) Date: Mon, 01 May 2006 12:39:03 -0700 From: Vipul Gupta To: tls mailing list , Daniel Brown Message-id: <0A4665F3-9EB6-4A03-8134-BC7E1A62E2F8@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.749.3) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20060501191815.6591E222424@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: tls-ads@tools.ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] AUTH48, RFC 4492 NOW AVAILABLE X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org We are in the AUTH48 stage with draft-ietf-tls-ecc-12.txt. The pre-release version of the RFC 4492 is currently available at: ftp://ftp.rfc-editor.org/in-notes/authors/rfc4492.txt The coauthors would like to update the table in Appendix A in response to a new release of X9.62. The suggested change is in the attached email -- it adds a new column for X9.62-2005 and lists aliases that spec defines for 18 of the 25 curves in the draft. This change has no material impact on the specification and is purely informative -- intended to help implementers sort out different names used by NIST, ANSI and SECG for the same curves. If there are good reasons to not include this change, please let us know as soon as possible. We'd like to come to a final decision (either include or leave out the new column) later this week. thank you, vipul Begin forwarded message: > From: Eric Rescorla > Date: May 1, 2006 12:11:47 PM PDT > To: Vipul Gupta > Cc: Alice Hagens , "Nelson B. Bolyard" > , 'Bodo Moeller' , Simon > Blake-Wilson , Chris Hawk > , tls-ads@tools.ietf.org, tls- > chairs@tools.ietf.org, rfc-editor@rfc-editor.org, Daniel Brown > > Subject: Re: AUTH48 [AH]: RFC 4492 NOW > AVAILABLE > > Vipul, > > This is more than a trivial editorial change. Please raise > it on the WG mailing list. > > -Ekr > > Vipul Gupta wrote: > >> Alice, >> >> Here are the only additional changes I'd like to suggest. >> (Background: A new version of ANSI X9.62 was approved in >> Nov 2005 and standardizes many more of the SECG curves >> already used in the draft. The change below updates the >> informative table in Appendix A to reflect this development). >> >> Thanks to Dan Brown (cc'd), the editor of ANSI X9.62, for >> his help in drafting the new text. >> >> thank you, >> >> vipul >> >> ===================================================================== >> === >> ===== >> >> >> Appendix A, 1st paragraph and table >> >> OLD: >> >> All of the NIST curves [11] and several of the ANSI curves [7] >> are >> equivalent to curves listed in Section 5.1.1. In the following >> table, multiple names in one row represent aliases for the same >> curve. >> >> ------------------------------------------ >> Curve names chosen by >> different standards organizations >> ------------+---------------+------------- >> SECG | ANSI X9.62 | NIST >> ------------+---------------+------------- >> sect163k1 | | NIST K-163 >> sect163r1 | | >> sect163r2 | | NIST B-163 >> sect193r1 | | >> sect193r2 | | >> sect233k1 | | NIST K-233 >> sect233r1 | | NIST B-233 >> sect239k1 | | >> sect283k1 | | NIST K-283 >> sect283r1 | | NIST B-283 >> sect409k1 | | NIST K-409 >> sect409r1 | | NIST B-409 >> sect571k1 | | NIST K-571 >> sect571r1 | | NIST B-571 >> secp160k1 | | >> secp160r1 | | >> secp160r2 | | >> secp192k1 | | >> secp192r1 | prime192v1 | NIST P-192 >> secp224k1 | | >> secp224r1 | | NIST P-224 >> secp256k1 | | >> secp256r1 | prime256v1 | NIST P-256 >> secp384r1 | | NIST P-384 >> secp521r1 | | NIST P-521 >> ------------+---------------+------------- >> >> Table 6: Equivalent curves defined by SECG, ANSI, and NIST >> >> NEW: >> >> All of the NIST [11] and ANSI X9.62-2005 [7] curves are >> equivalent >> to curves listed in Section 5.1.1, and some of these were also >> present in the previous revision of [7], ANSI X9.62-1998. In the >> following table, multiple names in one row represent aliases for >> the same curve. >> >> ------------------------------------------------------------- >> Curve names chosen by different standards organizations >> -----------+--------------+-----------------+---------------- >> SECG | NIST | ANSI X9.62-2005 | ANSI X9.62-1998 >> -----------+--------------+-----------------+---------------- >> sect163k1 | NIST K-163 | ansix9t163k1 | >> sect163r1 | | | >> sect163r2 | NIST B-163 | ansix9t163r2 | >> sect193r1 | | | >> sect193r2 | | | >> sect233k1 | NIST K-233 | ansix9t233k1 | >> sect233r1 | NIST B-233 | ansix9t233r1 | >> sect239k1 | | | >> sect283k1 | NIST K-283 | ansix9t283k1 | >> sect283r1 | NIST B-283 | ansix9t283r1 | >> sect409k1 | NIST K-409 | ansix9t409k1 | >> sect409r1 | NIST B-409 | ansix9t409r1 | >> sect571k1 | NIST K-571 | ansix9t571k1 | >> sect571r1 | NIST B-571 | ansix9t571r1 | >> secp160k1 | | | >> secp160r1 | | | >> secp160r2 | | | >> secp192k1 | | ansix9p192k1 | >> secp192r1 | NIST P-192 | ansix9p192r1 | prime192v1 >> secp224k1 | | ansix9p224k1 | >> secp224r1 | NIST P-224 | ansix9p224r1 | >> secp256k1 | | ansix9p256k1 | >> secp256r1 | NIST P-256 | ansix9p256r1 | prime256v1 >> secp384r1 | NIST P-384 | ansix9p384r1 | >> secp521r1 | NIST P-521 | ansix9p521r1 | >> -----------+--------------+-----------------+---------------- >> >> Table 6: Equivalent curves defined by SECG, NIST, and ANSI >> >> >> --------------------------------------------------------------------- >> --- >> ----- >> >> >> References, entry [7] >> >> OLD: >> >> [7] ANSI, "Public Key Cryptography For The Financial Services >> Industry: The Elliptic Curve Digital Signature Algorithm >> (ECDSA)", ANSI X9.62, 1998. >> >> NEW: >> >> [7] ANSI, "Public Key Cryptography For The Financial Services >> Industry: The Elliptic Curve Digital Signature Algorithm >> (ECDSA)", ANSI X9.62, 2005. >> >> >> ===================================================================== >> === >> ===== _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 02 14:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazdM-00083f-8c; Tue, 02 May 2006 14:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FazdK-00083Y-HF for tls@ietf.org; Tue, 02 May 2006 14:30:02 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FazdJ-0000E0-Ad for tls@ietf.org; Tue, 02 May 2006 14:30:02 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k42IU1UK018214 for ; Tue, 2 May 2006 14:30:01 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k42IU0Wf023488 for ; Tue, 2 May 2006 14:30:00 -0400 Received: from [172.16.24.13] (relyea.sfbay.redhat.com [172.16.24.13]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k42ITxpl014375 for ; Tue, 2 May 2006 14:29:59 -0400 Message-ID: <4457A4DE.9060209@redhat.com> Date: Tue, 02 May 2006 11:28:46 -0700 From: Bob Relyea User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: tls@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: [TLS] RFC 4346 - TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0417261836==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0417261836== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010704060808040207050309" This is a cryptographically signed message in MIME format. --------------ms010704060808040207050309 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit The TLS 1.2 spec attempts to define more flexibility in the choice of hashing, and does fix a number of problems in 1.1 when wanting to use hash functions other than SHA-1 and MD5, however there appears to be wording left over from the 1.1 spec that seems to contradict this goal. Shouldn't this wording be removed or changes, or was it left in intentionally: Section 5 ... second paragraph: HMAC can be used with a variety of different hash algorithms. TLS uses it in the handshake with two different algorithms: MD5 and SHA-1, denoting these as HMAC_MD5(secret, data) and HMAC_SHA(secret, data). Additional hash algorithms can be defined by cipher suites and used to protect record data, but MD5 and SHA-1 are hard coded into the description of the handshaking for this version of the protocol. Shouldn't the 'hard coded' wording be removed, or does TLS 1.2 initially expect to continue to use MD5 and SHA-1 for the handshaking? Thanks, bob --------------ms010704060808040207050309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ8zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8wggNUMIICvaADAgECAhArOGv8g+skUjZbhUG7Duav MA0GCSqGSIb3DQEBBAUAMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3Vs dGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNz dWluZyBDQTAeFw0wNTEyMTIyMjE4NDlaFw0wNjEyMTIyMjE4NDlaMIGGMQ8wDQYDVQQEEwZS ZWx5ZWExFDASBgNVBCoTC1JvYmVydCBKb2huMRswGQYDVQQDExJSb2JlcnQgSm9obiBSZWx5 ZWExHTAbBgkqhkiG9w0BCQEWDmJvYkByZWx5ZWEuY29tMSEwHwYJKoZIhvcNAQkBFhJycmVs eWVhQHJlZGhhdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCncfm90ZJD n6fIdtwXZFPt7edR4dYqaQzb1ATpghIjeuoGXoGtQM4loOfTZdy255yz/y6H/1+2ppAYrTeG m7ocvPErG4WihjlMZhcgodn0IzOUk/TQc70XwlTcv8RbL2ww52zHmoDLNR55IfLv5FNQUHnK W6RTqsNTyzHfaRi5allBocGaGnSFoJJKcSX5XCYfxhg28YXWXKEpCZ+G9Q3oh8zITKn7zbRS Bp/DhgeAMnQH86AtVcezTHiGFL6hY3RIlXVz3YCZXZM31ivy3URFJz0VzaPh3cwcHLDWwgNh DTDNpsNtkybzU3zKQRVEFd7ZL1wVMLX2rVembjSqeEVFAgMBAAGjYjBgMA4GA1UdDwEB/wQE AwIDqDARBglghkgBhvhCAQEEBAMCBaAwLQYDVR0RBCYwJIEOYm9iQHJlbHllYS5jb22BEnJy ZWx5ZWFAcmVkaGF0LmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBAKHBG2dK bpuBLISAp7tf9BdoN1rfecy1qIencsLw1wJuQWuCzNIeY+C27kQbY1Kdj+3Kf3y7UfI+3lpC Y7aDtDBNjMGWvQQkJwwhZvn8daEHnlZvN4sjc0x8edNYI0oxOaT5oQ/49Fdd7L1gxWASxCll YKIhwirZVvqp9SZOdoclMIIDVDCCAr2gAwIBAgIQKzhr/IPrJFI2W4VBuw7mrzANBgkqhkiG 9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0 eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0Ew HhcNMDUxMjEyMjIxODQ5WhcNMDYxMjEyMjIxODQ5WjCBhjEPMA0GA1UEBBMGUmVseWVhMRQw EgYDVQQqEwtSb2JlcnQgSm9objEbMBkGA1UEAxMSUm9iZXJ0IEpvaG4gUmVseWVhMR0wGwYJ KoZIhvcNAQkBFg5ib2JAcmVseWVhLmNvbTEhMB8GCSqGSIb3DQEJARYScnJlbHllYUByZWRo YXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp3H5vdGSQ5+nyHbcF2RT 7e3nUeHWKmkM29QE6YISI3rqBl6BrUDOJaDn02Xctuecs/8uh/9ftqaQGK03hpu6HLzxKxuF ooY5TGYXIKHZ9CMzlJP00HO9F8JU3L/EWy9sMOdsx5qAyzUeeSHy7+RTUFB5ylukU6rDU8sx 32kYuWpZQaHBmhp0haCSSnEl+VwmH8YYNvGF1lyhKQmfhvUN6IfMyEyp+820Ugafw4YHgDJ0 B/OgLVXHs0x4hhS+oWN0SJV1c92AmV2TN9Yr8t1ERSc9Fc2j4d3MHByw1sIDYQ0wzabDbZMm 81N8ykEVRBXe2S9cFTC19q1Xpm40qnhFRQIDAQABo2IwYDAOBgNVHQ8BAf8EBAMCA6gwEQYJ YIZIAYb4QgEBBAQDAgWgMC0GA1UdEQQmMCSBDmJvYkByZWx5ZWEuY29tgRJycmVseWVhQHJl ZGhhdC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQChwRtnSm6bgSyEgKe7 X/QXaDda33nMtaiHp3LC8NcCbkFrgszSHmPgtu5EG2NSnY/tyn98u1HyPt5aQmO2g7QwTYzB lr0EJCcMIWb5/HWhB55WbzeLI3NMfHnTWCNKMTmk+aEP+PRXXey9YMVgEsQpZWCiIcIq2Vb6 qfUmTnaHJTGCA2QwggNgAgEBMHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBD b25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFp bCBJc3N1aW5nIENBAhArOGv8g+skUjZbhUG7DuavMAkGBSsOAwIaBQCgggHDMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDUwMjE4Mjg0NlowIwYJKoZI hvcNAQkEMRYEFKEzcA80mQQ1hQdge3Yh7Ze6NiuOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIGFBgkrBgEEAYI3EAQxeDB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQKzhr/IPrJFI2W4VBuw7mrzCBhwYLKoZIhvcNAQkQAgsxeKB2 MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQu MSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQKzhr/IPr JFI2W4VBuw7mrzANBgkqhkiG9w0BAQEFAASCAQBHoMkKaAgAGC9X6tQKbJL9BOSTNyh17R9x kt/zp1N9OIkdriao+5zHFmj8IGNvsRTACig9Mf8m6wRVU+NhHuFG0RAPyBUsT32Os0tJwc5N mfJyhVnb87tMENQvrweSxV/w6HxNA82WMJvrfWgRayUGuYDEXB1KZJZMF7fuSVwa6LflGiPu v+mW8bzJSgH7D5G1gcl/Phrur1CJwDhK1xF32DJAm8xVAda1jNiCUiqZRdw01bvrLsV4oTdx Z6Ym0sPFSNRF3/nh53ZkirC6WbMVFY99d4+egY9KifQro+VxatMjqtMyw4bKjTJeyraB82W4 1gXR2iPLxBC9IQvM+Ge4AAAAAAAA --------------ms010704060808040207050309-- --===============0417261836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0417261836==-- From tls-bounces@lists.ietf.org Tue May 02 14:33:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazgm-0001Po-05; Tue, 02 May 2006 14:33:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fazgk-0001Pi-03 for tls@ietf.org; Tue, 02 May 2006 14:33:34 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fazgi-0000O1-NN for tls@ietf.org; Tue, 02 May 2006 14:33:33 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id E4FC01E8C1F; Tue, 2 May 2006 11:33:28 -0700 (PDT) To: Bob Relyea Subject: Re: [TLS] RFC 4346 - TLS 1.2 References: <4457A4DE.9060209@redhat.com> From: Eric Rescorla Date: Tue, 02 May 2006 11:33:28 -0700 In-Reply-To: <4457A4DE.9060209@redhat.com> (Bob Relyea's message of "Tue, 02 May 2006 11:28:46 -0700") Message-ID: <86r73ctgxz.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Bob Relyea writes: > The TLS 1.2 spec attempts to define more flexibility in the choice of > hashing, and does fix a number of problems in 1.1 when wanting to use > hash functions other than SHA-1 and MD5, however there appears to be > wording left over from the 1.1 spec that seems to contradict this > goal. Shouldn't this wording be removed or changes, or was it left in > intentionally: It's a bug. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 03 06:33:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEfl-0000GJ-3h; Wed, 03 May 2006 06:33:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbEfj-0000GB-JU for tls@lists.ietf.org; Wed, 03 May 2006 06:33:31 -0400 Received: from [193.120.124.138] (helo=mail.anam.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbEfi-0000xX-JX for tls@lists.ietf.org; Wed, 03 May 2006 06:33:31 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 3 May 2006 11:33:26 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Certificate Unknown thread-index: AcZunQMmgsFyJjGBQfeSZsPBqE4xDg== From: "Stephen Corcoran" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: d01c7b9466fe967a5df27b46fdb03146 Cc: Conor Murphy Subject: [TLS] Certificate Unknown X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0404722997==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0404722997== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66E9D.04C5BB09" This is a multi-part message in MIME format. ------_=_NextPart_001_01C66E9D.04C5BB09 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 When I run ethereal trace on our ssl port 443 we receive the following TLS alert over an over . =20 Our platform - 172.24.52.4 =20 The address 193.113.37.7 is a proxy server. =20 How do I stop the " TLS Alert (Level: Fatal, Description: Certificate Unknown) " warning ? =20 Any help much appreciated =20 =20 tethereal -R "tcp.port =3D=3D 443" =20 =20 3.415589 193.113.37.7 -> 172.24.52.4 SSLv2 Client Hello 3.416193 172.24.52.4 -> 193.113.37.7 TLS Server Hello, Certificate, Server Hello Done 3.433146 193.113.37.7 -> 172.24.52.4 TCP 33136 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 Len=3D0 3.455153 193.113.48.7 -> 172.24.52.4 TCP 51983 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 MSS=3D1460 3.455433 172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [SYN, ACK] = Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 MSS=3D1460 3.459320 193.113.37.7 -> 172.24.52.4 TLS Alert (Level: Fatal, Description: Certificate Unknown) 3.459727 172.24.52.4 -> 193.113.37.7 TCP 443 > 33136 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 Len=3D0 3.463295 193.113.48.7 -> 172.24.52.4 TCP 51983 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 Len=3D0 3.472032 193.113.37.7 -> 172.24.52.4 TCP 33136 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.472293 193.113.37.7 -> 172.24.52.4 TCP 33136 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.472385 172.24.52.4 -> 193.113.37.7 TCP 443 > 33136 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 Len=3D0 3.483303 193.113.48.7 -> 172.24.52.4 SSLv2 Client Hello 3.483813 172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done 3.494287 193.113.37.7 -> 172.24.52.4 TCP 33150 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 MSS=3D1460 3.494564 172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [SYN, ACK] = Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 MSS=3D1460 3.499953 193.113.48.7 -> 172.24.52.4 TCP 51983 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 Len=3D0 3.503798 193.113.37.7 -> 172.24.52.4 TCP 33150 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 Len=3D0 3.524528 193.113.48.7 -> 172.24.52.4 TLS Alert (Level: Fatal, Description: Certificate Unknown) 3.524914 172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 Len=3D0 3.533605 193.113.37.7 -> 172.24.52.4 SSLv2 Client Hello 3.534025 193.113.48.7 -> 172.24.52.4 TCP 51983 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.534343 172.24.52.4 -> 193.113.37.7 TLS Server Hello, Certificate, Server Hello Done 3.542732 193.113.48.7 -> 172.24.52.4 TCP 51983 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.542829 172.24.52.4 -> 193.113.48.7 TCP 443 > 51983 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 Len=3D0 3.549016 193.113.48.7 -> 172.24.52.4 TCP 51999 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 MSS=3D1460 3.549284 172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [SYN, ACK] = Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 MSS=3D1460 3.551178 193.113.37.7 -> 172.24.52.4 TCP 33150 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 Len=3D0 3.557709 193.113.48.7 -> 172.24.52.4 TCP 51999 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 Len=3D0 3.576305 193.113.48.7 -> 172.24.52.4 SSLv2 Client Hello 3.576801 172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done 3.579662 193.113.37.7 -> 172.24.52.4 TLS Alert (Level: Fatal, Description: Certificate Unknown) 3.580041 172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 Len=3D0 3.593021 193.113.48.7 -> 172.24.52.4 TCP 51999 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 Len=3D0 3.593379 193.113.37.7 -> 172.24.52.4 TCP 33150 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.594083 193.113.37.7 -> 172.24.52.4 TCP 33150 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.594186 172.24.52.4 -> 193.113.37.7 TCP 443 > 33150 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 Len=3D0 3.612595 193.113.48.7 -> 172.24.52.4 TLS Alert (Level: Fatal, Description: Certificate Unknown) 3.612999 172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 Len=3D0 3.621631 193.113.48.7 -> 172.24.52.4 TCP 51999 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.621906 193.113.48.7 -> 172.24.52.4 TCP 51999 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.621999 172.24.52.4 -> 193.113.48.7 TCP 443 > 51999 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 Len=3D0 3.638459 193.113.48.7 -> 172.24.52.4 TCP 52013 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 MSS=3D1460 3.638745 172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [SYN, ACK] = Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 MSS=3D1460 3.646542 193.113.48.7 -> 172.24.52.4 TCP 52013 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 Len=3D0 3.668297 193.113.48.7 -> 172.24.52.4 SSLv2 Client Hello 3.668821 172.24.52.4 -> 193.113.48.7 TLS Server Hello, Certificate, Server Hello Done 3.684799 193.113.48.7 -> 172.24.52.4 TCP 52013 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 Len=3D0 3.702860 193.113.48.7 -> 172.24.52.4 TLS Alert (Level: Fatal, Description: Certificate Unknown) 3.703250 172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 Len=3D0 3.712084 193.113.48.7 -> 172.24.52.4 TCP 52013 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.712346 193.113.48.7 -> 172.24.52.4 TCP 52013 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 Len=3D0 3.712439 172.24.52.4 -> 193.113.48.7 TCP 443 > 52013 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 Len=3D0 =20 Kind Regards Steve ------_=_NextPart_001_01C66E9D.04C5BB09 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

When I run ethereal trace on our ssl port 443 = we receive the following TLS alert over an over = .

 

Our platform - 172.24.52.4

 

The  address 193.113.37.7 =  is a proxy server.

 

How do I stop the  “ TLS Alert (Level: Fatal, Description: Certificate Unknown) “ = warning ?

 

Any help much = appreciated

 

 

tethereal -R "tcp.port =3D=3D = 443"   

 

3.415589 193.113.37.7 -> 172.24.52.4  = SSLv2 Client Hello

  3.416193  172.24.52.4 -> = 193.113.37.7 TLS Server Hello, Certificate, Server Hello = Done

  3.433146 193.113.37.7 -> = 172.24.52.4  TCP 33136 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 = Len=3D0

  3.455153 193.113.48.7 -> = 172.24.52.4  TCP 51983 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 = MSS=3D1460

  3.455433  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51983 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 = MSS=3D1460

  3.459320 193.113.37.7 -> = 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate = Unknown)

  3.459727  172.24.52.4 -> = 193.113.37.7 TCP 443 > 33136 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 = Len=3D0

  3.463295 193.113.48.7 -> = 172.24.52.4  TCP 51983 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 = Len=3D0

  3.472032 193.113.37.7 -> = 172.24.52.4  TCP 33136 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.472293 193.113.37.7 -> = 172.24.52.4  TCP 33136 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.472385  172.24.52.4 -> = 193.113.37.7 TCP 443 > 33136 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 = Len=3D0

  3.483303 193.113.48.7 -> 172.24.52.4  SSLv2 Client Hello

  3.483813  172.24.52.4 -> = 193.113.48.7 TLS Server Hello, Certificate, Server Hello = Done

  3.494287 193.113.37.7 -> = 172.24.52.4  TCP 33150 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 = MSS=3D1460

  3.494564  172.24.52.4 -> = 193.113.37.7 TCP 443 > 33150 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 = MSS=3D1460

  3.499953 193.113.48.7 -> = 172.24.52.4  TCP 51983 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 = Len=3D0

  3.503798 193.113.37.7 -> = 172.24.52.4  TCP 33150 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 = Len=3D0

  3.524528 193.113.48.7 -> = 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate = Unknown)

  3.524914  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51983 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 = Len=3D0

  3.533605 193.113.37.7 -> = 172.24.52.4  SSLv2 Client Hello

  3.534025 193.113.48.7 -> = 172.24.52.4  TCP 51983 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.534343  172.24.52.4 -> = 193.113.37.7 TLS Server Hello, Certificate, Server Hello = Done

  3.542732 193.113.48.7 -> = 172.24.52.4  TCP 51983 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.542829  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51983 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 = Len=3D0

  3.549016 193.113.48.7 -> = 172.24.52.4  TCP 51999 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 = MSS=3D1460

  3.549284  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51999 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 = MSS=3D1460

  3.551178 193.113.37.7 -> = 172.24.52.4  TCP 33150 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 = Len=3D0

  3.557709 193.113.48.7 -> = 172.24.52.4  TCP 51999 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 = Len=3D0

  3.576305 193.113.48.7 -> = 172.24.52.4  SSLv2 Client Hello

  3.576801  172.24.52.4 -> = 193.113.48.7 TLS Server Hello, Certificate, Server Hello = Done

  3.579662 193.113.37.7 -> = 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate = Unknown)

  3.580041  172.24.52.4 -> = 193.113.37.7 TCP 443 > 33150 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 = Len=3D0

  3.593021 193.113.48.7 -> = 172.24.52.4  TCP 51999 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 = Len=3D0

  3.593379 193.113.37.7 -> = 172.24.52.4  TCP 33150 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.594083 193.113.37.7 -> = 172.24.52.4  TCP 33150 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.594186  172.24.52.4 -> = 193.113.37.7 TCP 443 > 33150 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 = Len=3D0

  3.612595 193.113.48.7 -> = 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate = Unknown)

  3.612999  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51999 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 = Len=3D0

  3.621631 193.113.48.7 -> = 172.24.52.4  TCP 51999 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.621906 193.113.48.7 -> = 172.24.52.4  TCP 51999 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.621999  172.24.52.4 -> = 193.113.48.7 TCP 443 > 51999 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 = Len=3D0

  3.638459 193.113.48.7 -> = 172.24.52.4  TCP 52013 > 443 [SYN] Seq=3D0 Ack=3D0 Win=3D24820 Len=3D0 = MSS=3D1460

  3.638745  172.24.52.4 -> = 193.113.48.7 TCP 443 > 52013 [SYN, ACK] Seq=3D0 Ack=3D1 Win=3D32768 Len=3D0 = MSS=3D1460

  3.646542 193.113.48.7 -> = 172.24.52.4  TCP 52013 > 443 [ACK] Seq=3D1 Ack=3D1 Win=3D24820 = Len=3D0

  3.668297 193.113.48.7 -> = 172.24.52.4  SSLv2 Client Hello

  3.668821  172.24.52.4 -> = 193.113.48.7 TLS Server Hello, Certificate, Server Hello = Done

  3.684799 193.113.48.7 -> = 172.24.52.4  TCP 52013 > 443 [ACK] Seq=3D101 Ack=3D1274 Win=3D24820 = Len=3D0

  3.702860 193.113.48.7 -> = 172.24.52.4  TLS Alert (Level: Fatal, Description: Certificate = Unknown)

  3.703250  172.24.52.4 -> = 193.113.48.7 TCP 443 > 52013 [FIN, ACK] Seq=3D1274 Ack=3D108 Win=3D32768 = Len=3D0

  3.712084 193.113.48.7 -> = 172.24.52.4  TCP 52013 > 443 [ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.712346 193.113.48.7 -> = 172.24.52.4  TCP 52013 > 443 [FIN, ACK] Seq=3D108 Ack=3D1275 Win=3D24820 = Len=3D0

  3.712439  172.24.52.4 -> = 193.113.48.7 TCP 443 > 52013 [ACK] Seq=3D1275 Ack=3D109 Win=3D32768 = Len=3D0

 

Kind Regards

Steve

------_=_NextPart_001_01C66E9D.04C5BB09-- --===============0404722997== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0404722997==-- From tls-bounces@lists.ietf.org Fri May 05 06:16:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxMD-0003pm-R6; Fri, 05 May 2006 06:16:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxMC-0003oR-7b for tls@ietf.org; Fri, 05 May 2006 06:16:20 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbxMA-0004NM-Qj for tls@ietf.org; Fri, 05 May 2006 06:16:20 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k45AGHmZ001477 for ; Fri, 5 May 2006 13:16:17 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 13:15:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 13:15:22 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 May 2006 13:15:24 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG last call on draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZwLNKhnA8hBbR2SLmbhlSNykWvIQ== From: To: X-OriginalArrivalTime: 05 May 2006 10:15:22.0310 (UTC) FILETIME=[D18BA660:01C6702C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Subject: [TLS] WG last call on draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org This message starts a TLS WG last call on "Using OpenPGP keys for TLS authentication" (draft-ietf-tls-openpgp-keys-08), prior to sending the document to the IESG for consideration as Experimental.=20 Please send your comments to the WG mailing list by Sunday May 21st. Comments along the lines "I've read it and it looks OK" are helpful and encouraged. Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri May 05 06:29:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxYU-0004jI-B3; Fri, 05 May 2006 06:29:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxYT-0004jD-7Y for tls@ietf.org; Fri, 05 May 2006 06:29:01 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbxYR-0004tD-Po for tls@ietf.org; Fri, 05 May 2006 06:29:01 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k45ASuAC002813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 12:28:57 +0200 From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060505:tls@ietf.org::v71j1+WBEmgCNp59:75XB X-Hashcash: 1:22:060505:pasi.eronen@nokia.com::uoCjaLQKbUc1i7SQ:66Jy Date: Fri, 05 May 2006 12:28:56 +0200 In-Reply-To: (Pasi Eronen's message of "Fri, 5 May 2006 13:15:24 +0300") Message-ID: <87hd44sr2v.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Subject: [TLS] Re: WG last call on draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > This message starts a TLS WG last call on "Using OpenPGP keys for TLS > authentication" (draft-ietf-tls-openpgp-keys-08), prior to sending the > document to the IESG for consideration as Experimental. > > Please send your comments to the WG mailing list by Sunday May 21st. > Comments along the lines "I've read it and it looks OK" are helpful > and encouraged. I've read it and it looks OK. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 09 10:02:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSlT-0000J6-07; Tue, 09 May 2006 10:00:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdSlR-0000J1-HG for tls@lists.ietf.org; Tue, 09 May 2006 10:00:37 -0400 Received: from mail.billhoefer.de ([213.95.25.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdSlP-0002CF-1J for tls@lists.ietf.org; Tue, 09 May 2006 10:00:37 -0400 Received: from [192.168.99.170] (mcp.billhoefer.de [213.95.25.106]) (authenticated bits=0) by mail.billhoefer.de (8.12.3/8.12.3/Debian-6.6) with ESMTP id k49E0PY7030378 for ; Tue, 9 May 2006 16:00:28 +0200 Message-ID: <4460A078.70609@billhoefer.de> Date: Tue, 09 May 2006 16:00:24 +0200 From: Systemadministration Organization: Maschinenfabrik =?ISO-8859-15?Q?Billh=F6fer_GmbH_=26_?= =?ISO-8859-15?Q?Co=2E_KG?= User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed X-billhoefer-MailScanner-Information: Informationen unter admin@billhoefer.de X-billhoefer-MailScanner: Found to be clean - Virenfrei X-billhoefer-MailScanner-SpamCheck: X-MailScanner-From: systemadministration@billhoefer.de Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mail.billhoefer.de id k49E0PY7030378 X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [TLS] STARTTLS sendmail Errors X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: systemadministration@billhoefer.de List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Sollten Sie noch weitere Fragen haben, stehe ich Ihnen nat=FCrlich gerne=20 jederzeit zur Verf=FCgung. Mit freundlichen Gr=FC=DFen Thomas Bennek Systemadministrator ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Billh=F6fer Maschinenfabrik GmbH & Co. KG Gutenstetter Strasse 20 90449 Nuremberg =20 phone: + 49 911 65785-208 fax: + 49 911 65785 -50 www: http://www.billhoefer.com mail: bennek@billhoefer.de ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hello to all! I?m new to this list, and I had a question about a lot of errors with starttls in my log. My E-Mail communication seems not to be affected, but it is really unattractive. The error - messages look like these Apr 26 17:11:52 mail2 sendmail[19576]: STARTTLS=3Dclient, start=3Dok Apr 26 17:11:52 mail2 sendmail[19576]: STARTTLS=3Dclient, info: fds=3D9/8= , err=3D2 Apr 26 17:11:53 mail2 sendmail[19572]: STARTTLS=3Dwrite, info: fds=3D9/8,= err=3D3 Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=3Dclient, info: fds=3D9/8= , err=3D2 Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=3Dclient, info: fds=3D9/8= , err=3D2 Apr 26 17:11:53 mail2 sendmail[19572]: STARTTLS=3Dwrite, info: fds=3D9/8,= err=3D3 Apr 26 17:11:53 mail2 sendmail[19576]: STARTTLS=3Dclient, info: fds=3D9/8= , err=3D2 Apr 26 17:11:54 mail2 sendmail[19572]: STARTTLS=3Dwrite, info: fds=3D9/8,= err=3D3 Apr 26 17:11:54 mail2 sendmail[19576]: STARTTLS=3Dclient, info: fds=3D9/8= , err=3D2 Apr 26 17:11:54 mail2 sendmail[19576]: STARTTLS=3Dclient, get_verify: 0 get_peer: 0x8194868 or like this: May 9 14:21:32 mail2 sm-mta[7461]: STARTTLS=3Dread, info: fds=3D8/3, err= =3D2 May 9 14:26:10 mail2 sm-mta[7611]: STARTTLS=3Dread, info: fds=3D8/3, err= =3D2 May 9 14:26:10 mail2 last message repeated 125 times The numbers behind fds will vary from time to time. I have no idea from where it will come from - so can anyone give me a hint about these errors?! Many thanks Thomas _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 10 13:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsNi-00050K-8v; Wed, 10 May 2006 13:21:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdsNh-0004yM-5B for tls@ietf.org; Wed, 10 May 2006 13:21:49 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdsNe-0007ls-Kh for tls@ietf.org; Wed, 10 May 2006 13:21:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4AHLj5E011062 for ; Wed, 10 May 2006 20:21:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 20:21:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 20:21:45 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 May 2006 20:21:46 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ0VjcYzQVrx2j2RLC8mjAin9T0MQ== From: To: X-OriginalArrivalTime: 10 May 2006 17:21:45.0600 (UTC) FILETIME=[3670A800:01C67456] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [TLS] Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The document looks mostly OK, but I think some details need=20 clarification/polishing before we send this to the IESG. Somewhat substantive comments: 1) Section 3.3: The TLS Certificate message defined in RFC4346=20 contains a list of X.509 certificates, while this section allows only a single PGPKey structure. IMHO we should keep this aligned with RFC4346, even though usually one key is enough. In other=20 words, something like this: struct { PGPKeyDescriptorType descriptorType; select (descriptorType) { case key_fingerprint: opaque fingerprint<16..20>;=20 case key: opaque key<0..2^24-1>;=20 } } PGPCert; struct { PGPCert certificate_list<0..2^24-1>; } Certificate; 2) Section 3.5: "then a Certificate that contains an empty PGPKey should be sent": If the change suggested above is made, a=20 Certificate message that contains one zero-length PGPKey is=20 not the same thing as a Certificate message that contains zero=20 certificates (and it's the latter that should be sent). 3) Section 3.4: I don't think there is any need to define a new CertificateRequest message (the "certificate_authorities" part doesn't make much sense for OpenPGP, but RFC4346 clarified that it can be empty; and I believe many TLS 1.0 implementations also did this). So I'd suggest rewriting this section as follows: "If the certificate request message is sent, and the negotiated certificate type is OpenPGP, the certificate_authorities list=20 MUST be empty." 4) I'd suggest moving whole Section 2 to later in the document=20 (e.g., after Security Considerations), renaming it to "IANA Considerations", and rewriting it something like this: "This document defines a new TLS extension, "cert_type", assigned a value of TBD-BY-IANA (the value 7 is suggested) from the TLS ExtensionType registry defined in [RFC4366]. =20 This document establishes a new registry, to be maintained by IANA, for TLS certificate types. Initially, the registry contains the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223 are assigned via IETF Consensus [RFC2434]. Values from the range 224-255 are reserved for Private Use [RFC2434]." 5) Section 3.1: "...extension SHOULD be omitted if the client only supports X.509 certificates" and "Servers that only support X.509 certificates MAY omit... ": Unnecessary options are a recipe for interoperability problems; unless there are good reasons to keep these, I'd suggest changing these to MUSTs. 6) Section 4: I'd suggest merging this section (only four lines) with Section 3.1. Also, the text should apply to all ciphersuites using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just those in RFC 2246. (And with this change, the text about exportable ciphersuites is no longer necessary.) Purely editorial comments: 7) Overall: I believe nowadays the RFC Editor recommends using=20 symbolic citations [RFC2119] instead of numeric ones [1]. 8) Section 1, 2nd paragraph: extra comma before "provide" 9) Sections 3.6..3.8: I'd suggest removing these. =20 10) Section 3.3: "The process of fingerprint generation is described=20 in OpenPGP [2]": I'd suggest adding a more specific pointer: Section 11.2 of [RFC2440]. 11) Section 6.1: RFC 3546 is obsoleted by RFC 4366. 12) Section 6.1: Should include RFC 2119 and RFC 2434 here. 13) Section 6.2: Reference [5] is never cited in the text (and IMHO could be removed) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 11 10:44:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCO1-0005iP-9y; Thu, 11 May 2006 10:43:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCO0-0005iK-HC for tls@ietf.org; Thu, 11 May 2006 10:43:28 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCNz-0004zq-5k for tls@ietf.org; Thu, 11 May 2006 10:43:28 -0400 Received: by ug-out-1314.google.com with SMTP id m2so160873uge for ; Thu, 11 May 2006 07:43:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:x-spam-checker-version:x-spam-status:x-gmail-received:from:to:subject:in-reply-to:mime-version:content-disposition:references:delivered-to:date:content-type:content-transfer-encoding:message-id:sender; b=F7/KzCBBcpwwkAhDMAd/jrYjqPw6HqHiEuNu9cks2jIif890V446n07895KcSeCbMfmnv8ljkBgmXjChWZg/MdIU6iL+fGk6wuIehKKiN8oTWdt2Ftun1uNLYVdKho/BlLsEUvAfCTY2xi9gzSaoBPFQK63qT7UMpqU4W3fZv5k= Received: by 10.67.128.4 with SMTP id f4mr706612ugn; Thu, 11 May 2006 07:43:26 -0700 (PDT) Received: from ?172.16.1.206? ( [81.175.93.238]) by mx.gmail.com with ESMTP id m1sm1768562ugc.2006.05.11.07.43.25; Thu, 11 May 2006 07:43:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on turtle.i-net.gr X-Spam-Status: No, score=0.3 required=5.0 tests=AWL,NO_RELAYS,RCVD_BY_IP autolearn=no version=3.1.0 X-Gmail-Received: f7cb71e352b19065c4507726035a9f6c6e8c5a88 Received: by 10.70.58.20 with HTTP; Wed, 10 May 2006 23:42:39 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08 In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline References: Delivered-To: n.mavrogiannopoulos@gmail.com Date: Thu, 11 May 2006 16:42:56 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200605111642.57275.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 5/10/06, Pasi.Eronen@nokia.com wrote: Hello Pasi, Thank you for the comments. I address them below. > Somewhat substantive comments: > 1) Section 3.3: The TLS Certificate message defined in RFC4346 > contains a list of X.509 certificates, while this section allows > only a single PGPKey structure. IMHO we should keep this aligned This was a deliberate change. The rationale behind this change was that there is no point in sending more than one pgp keys. There is no notion of certificate chain in openpgp, thus having a list of certificates would confuse on what should be sent. > 3) Section 3.4: I don't think there is any need to define a new > CertificateRequest message (the "certificate_authorities" part > doesn't make much sense for OpenPGP, but RFC4346 clarified that > it can be empty; and I believe many TLS 1.0 implementations also > did this). So I'd suggest rewriting this section as follows: > "If the certificate request message is sent, and the negotiated > certificate type is OpenPGP, the certificate_authorities list > MUST be empty." I will address this. > 4) I'd suggest moving whole Section 2 to later in the document > (e.g., after Security Considerations), renaming it to "IANA > Considerations", and rewriting it something like this: > "This document defines a new TLS extension, "cert_type", assigned > a value of TBD-BY-IANA (the value 7 is suggested) from the TLS > ExtensionType registry defined in [RFC4366]. > This document establishes a new registry, to be maintained by > IANA, for TLS certificate types. Initially, the registry contains > the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223 > are assigned via IETF Consensus [RFC2434]. Values from the range > 224-255 are reserved for Private Use [RFC2434]." Will be addressed. (I just noticed that in http://www.iana.org/numbers.html there is nothing about the TLS extension numbers. Is restristration possible?) > 5) Section 3.1: "...extension SHOULD be omitted if the client only > supports X.509 certificates" and "Servers that only support X.509 > certificates MAY omit... ": Unnecessary options are a recipe for > interoperability problems; unless there are good reasons to keep > these, I'd suggest changing these to MUSTs. I agree for the first one. But the second is only to address the case where the server doesn't support this extension (thus he doesn't add the extension reply to his hello). But I'd expect a server that is aware of this extension to properly reply with an extension that indicates that he selected the X509 certificate choice. > 6) Section 4: I'd suggest merging this section (only four lines) > with Section 3.1. Also, the text should apply to all ciphersuites > using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just > those in RFC 2246. (And with this change, the text about > exportable ciphersuites is no longer necessary.) True. I'll update it. > 9) Sections 3.6..3.8: I'd suggest removing these. > 10) Section 3.3: "The process of fingerprint generation is described > in OpenPGP [2]": I'd suggest adding a more specific pointer: > Section 11.2 of [RFC2440]. > 11) Section 6.1: RFC 3546 is obsoleted by RFC 4366. > 12) Section 6.1: Should include RFC 2119 and RFC 2434 here. > 13) Section 6.2: Reference [5] is never cited in the text (and > IMHO could be removed) Thanks I'll try to address the comments in a new draft. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 11 18:49:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJxd-000472-Kh; Thu, 11 May 2006 18:48:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeJxb-00046w-VZ for tls@ietf.org; Thu, 11 May 2006 18:48:43 -0400 Received: from smtp-out2.blueyonder.co.uk ([195.188.213.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeJxa-0002X6-NW for tls@ietf.org; Thu, 11 May 2006 18:48:43 -0400 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out2.blueyonder.co.uk with smtp (Exim 4.52) id 1FeJxa-0002wc-2B; Thu, 11 May 2006 23:48:42 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1FeJxZ-0004ra-IJ; Thu, 11 May 2006 23:48:41 +0100 Message-ID: <4463BF47.9070909@blueyonder.co.uk> Date: Thu, 11 May 2006 23:48:39 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: rfc-editor@rfc-editor.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org Subject: [TLS] Errata for RFC 4346 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Section 6: # See Section 11 for IANA Considerations for ContentType values. Section 7.2.2: # See Section 11 for IANA Considerations for alert values. Section 7.4: # See Section 11 for IANA Considerations for these values. Section 7.4.4: # Additional information describing the role of IANA in the allocation # of ClientCertificateType code points is described in Section 11. These references should all be to Section 12. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon May 15 15:52:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj5j-00078M-IC; Mon, 15 May 2006 15:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffj51-0005aH-S8; Mon, 15 May 2006 15:50:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffj51-00055B-Pv; Mon, 15 May 2006 15:50:11 -0400 Received: from chsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.24.129] helo=willow.neustar.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffj4t-00034r-9m; Mon, 15 May 2006 15:50:11 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4FJo21I002883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 May 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Ffj4s-0007WW-Ph; Mon, 15 May 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 15 May 2006 15:50:02 -0400 X-Spam-Score: -5.9 (-----) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-openpgp-keys-09.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using OpenPGP keys for TLS authentication Author(s) : N. Mavroyanopoulos Filename : draft-ietf-tls-openpgp-keys-09.txt Pages : 11 Date : 2006-5-15 This memo proposes extensions to the TLS protocol to support the OpenPGP trust model and keys. The extensions discussed here include a certificate type negotiation mechanism, and the required modifications to the TLS Handshake Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-openpgp-keys-09.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tls-openpgp-keys-09.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-openpgp-keys-09.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-5-15125404.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-openpgp-keys-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-openpgp-keys-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-15125404.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue May 16 03:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftlq-0007ru-6B; Tue, 16 May 2006 03:15:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fftlo-0007kN-8K for tls@ietf.org; Tue, 16 May 2006 03:15:04 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fftlm-0005KB-Ol for tls@ietf.org; Tue, 16 May 2006 03:15:04 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G7ErMJ021555; Tue, 16 May 2006 10:14:53 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:14:52 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:14:51 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Date: Tue, 16 May 2006 10:14:47 +0300 Message-ID: In-Reply-To: <200605111642.57275.nmav@gnutls.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ1Cd5+q5I0mCBsTYmtGvNbu5KfugDrBxNw From: To: , X-OriginalArrivalTime: 16 May 2006 07:14:51.0646 (UTC) FILETIME=[6C82B9E0:01C678B8] X-Spam-Score: 0.2 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nikos Mavrogiannopoulos wrote: > > Somewhat substantive comments: > > 1) Section 3.3: The TLS Certificate message defined in RFC4346 > > contains a list of X.509 certificates, while this section allows > > only a single PGPKey structure. IMHO we should keep this aligned >=20 > This was a deliberate change. The rationale behind this change was > that there is no point in sending more than one pgp keys. There is no > notion of certificate chain in openpgp, thus having a list of=20 > certificates would confuse on what should be sent. If Alice signs (certifies) Bob's key, and Bob signs Carol's key, isn't that a certificate chain? (The whole notion of "web of trust" seems to imply a certificate graph, which again implies chains...) > > 4) I'd suggest moving whole Section 2 to later in the document > > (e.g., after Security Considerations), renaming it to "IANA > > Considerations", and rewriting it something like this: > > "This document defines a new TLS extension, "cert_type", assigned > > a value of TBD-BY-IANA (the value 7 is suggested) from the TLS > > ExtensionType registry defined in [RFC4366]. > > This document establishes a new registry, to be maintained by > > IANA, for TLS certificate types. Initially, the registry contains > > the values 0 (X.509) and 1 (OpenPGP). Values from the range 2-223 > > are assigned via IETF Consensus [RFC2434]. Values from the range > > 224-255 are reserved for Private Use [RFC2434]." >=20 > Will be addressed. > (I just noticed that in http://www.iana.org/numbers.html there is=20 > nothing about the TLS extension numbers. Is restristration possible?) For some reason, the index page doesn't have a link to the registry (I'll notify IANA about this), but the registry is there: http://www.iana.org/assignments/tls-extensiontype-values > > 5) Section 3.1: "...extension SHOULD be omitted if the client only > > supports X.509 certificates" and "Servers that only support X.509 > > certificates MAY omit... ": Unnecessary options are a recipe for > > interoperability problems; unless there are good reasons to keep > > these, I'd suggest changing these to MUSTs. >=20 > I agree for the first one. But the second is only to address the case=20 > where the server doesn't support this extension (thus he doesn't add=20 > the extension reply to his hello). But I'd expect a server that is=20 > aware of this extension to properly reply with an extension that=20 > indicates that he selected the X509 certificate choice. Sounds reasonable to me. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 05:36:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvxh-0003Sg-3M; Tue, 16 May 2006 05:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffvxf-0003Sb-DB for tls@ietf.org; Tue, 16 May 2006 05:35:27 -0400 Received: from wx-out-0102.google.com ([66.249.82.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffvxb-0002w9-5v for tls@ietf.org; Tue, 16 May 2006 05:35:27 -0400 Received: by wx-out-0102.google.com with SMTP id s12so919551wxc for ; Tue, 16 May 2006 02:35:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=JdQVs7SjXLdmtsD90DG62EcyHzePZ6V1PAfHn0qNhaI5siMpdkjqHA8cM9zZPXU/DBXPUMvSHeKP9k8hJBrTlZ/h+o/6/Q13K1tfF9XX8gLAS3GxD9xbm8XyF+0THrPoXUYElqAefl8UQK2YVbrSwhdWyFSLeERaP7p9epLgV1A= Received: by 10.70.40.1 with SMTP id n1mr4952368wxn; Tue, 16 May 2006 02:35:22 -0700 (PDT) Received: by 10.70.58.20 with HTTP; Tue, 16 May 2006 02:35:22 -0700 (PDT) Message-ID: Date: Tue, 16 May 2006 11:35:22 +0200 From: "Nikos Mavrogiannopoulos" To: "Pasi.Eronen@nokia.com" Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200605111642.57275.nmav@gnutls.org> X-Google-Sender-Auth: ed4829b0c11d3ecf X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 5/16/06, Pasi.Eronen@nokia.com wrote: > > > Somewhat substantive comments: > > > 1) Section 3.3: The TLS Certificate message defined in RFC4346 > > > contains a list of X.509 certificates, while this section allows > > > only a single PGPKey structure. IMHO we should keep this aligned > > This was a deliberate change. The rationale behind this change was > > that there is no point in sending more than one pgp keys. There is no > > notion of certificate chain in openpgp, thus having a list of > > certificates would confuse on what should be sent. > If Alice signs (certifies) Bob's key, and Bob signs Carol's key, > isn't that a certificate chain? (The whole notion of "web of trust" > seems to imply a certificate graph, which again implies chains...) Indeed that's true.But it is also not very practical to include signers in the key sent. That is because a key might be signed by tens or hundrends of keys, that ar= e not compact either. I also see not much usage of the extra keys. The typical way for the receipient to verify an openpgp key is by retrieving by himself the required chain, if needed. A similar matter was discussed in the early days of the draft... i just found a link: http://www.mhonarc.org/archive/html/ietf-openpgp/1997-12/msg00105.html regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 05:48:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffw9M-000768-C5; Tue, 16 May 2006 05:47:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffw9K-000763-Ui for tls@ietf.org; Tue, 16 May 2006 05:47:30 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffw9J-0003gp-FR for tls@ietf.org; Tue, 16 May 2006 05:47:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4G9lMkA030778; Tue, 16 May 2006 12:47:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 12:47:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 12:47:18 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Date: Tue, 16 May 2006 12:47:19 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ4zDDR0BnIOpTbQEq3spOET+5XUgAAI11w From: To: X-OriginalArrivalTime: 16 May 2006 09:47:18.0763 (UTC) FILETIME=[B89E03B0:01C678CD] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nikos Mavrogiannopoulos wrote: > > If Alice signs (certifies) Bob's key, and Bob signs Carol's key, > > isn't that a certificate chain? (The whole notion of "web of trust" > > seems to imply a certificate graph, which again implies chains...) >=20 > Indeed that's true.But it is also not very practical to include > signers in the key sent. That is because a key might be signed by > tens or hundrends of keys, that are not compact either. I also see > not much usage of the extra keys. The typical way for the receipient > to verify an openpgp key is by retrieving by himself the required > chain, if needed. All this ("typical way" etc, "might be signed by tens", ..) seems to indicate that usually a single certificate is enough, but there may be situations where several would be useful. In other words, the=20 situation is not that different from X.509, and we should keep the=20 Certificate payload as a list... > A similar matter was discussed in the early days of the draft...=20 > i just found a link: > http://www.mhonarc.org/archive/html/ietf-openpgp/1997-12/msg00105.html Thanks for the pointer; it looks like Eric raised exactly this issue already over 8 years ago! Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 06:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffwck-0006E8-Pm; Tue, 16 May 2006 06:17:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffwcj-0006E3-FD for tls@ietf.org; Tue, 16 May 2006 06:17:53 -0400 Received: from wx-out-0102.google.com ([66.249.82.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffwci-0005BM-9B for tls@ietf.org; Tue, 16 May 2006 06:17:53 -0400 Received: by wx-out-0102.google.com with SMTP id s6so856859wxc for ; Tue, 16 May 2006 03:17:51 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lz0zp+IsdiqWgW78FoZQlJalp3fv/LIU3OQRKjpycwY1FnxI2cIa+QU+SfkVtdYpdefd6VSAijBnE7ElOXivf4G3I4/3MTWeQBduYfUE3+HkGi05l+Cy4U0BqkxTRNvhcDphxHzS24ZIDPf+Wq/WON1O3CfJ+RINvxiNp3pT/xI= Received: by 10.70.80.2 with SMTP id d2mr8209855wxb; Tue, 16 May 2006 03:17:51 -0700 (PDT) Received: by 10.70.58.20 with HTTP; Tue, 16 May 2006 03:17:51 -0700 (PDT) Message-ID: Date: Tue, 16 May 2006 12:17:51 +0200 From: "Nikos Mavrogiannopoulos" To: "Pasi.Eronen@nokia.com" Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Google-Sender-Auth: ae74f52f463b8010 X-Spam-Score: 0.5 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On 5/16/06, Pasi.Eronen@nokia.com wrote: > All this ("typical way" etc, "might be signed by tens", ..) seems to > indicate that usually a single certificate is enough, but there may > be situations where several would be useful. In other words, the > situation is not that different from X.509, and we should keep the > Certificate payload as a list... Indeed there are situations were a list might do, but there are also situat= ions where a graph would be better, or just a single one might do. The idea in t= his draft is to keep the key exchange separate from any local verification poli= cy. If one wants to use the web of trust, he can use it. If somebody else wants to use openpgp keys the same way as PKIX certificates, he can also use the current draft. In all cases unknown keys are retrieved via a key server or by other means. That approach follows the way openpgp keys are used in electronic mail and I see no good reason to change it by introducing an openpgp key chain in this draft. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 08:00:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyDN-0006ON-5r; Tue, 16 May 2006 07:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfyDM-0006OF-9W; Tue, 16 May 2006 07:59:48 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfyDL-0002WQ-Q9; Tue, 16 May 2006 07:59:48 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4GBxcaF012470; Tue, 16 May 2006 14:59:41 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:59:39 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:59:39 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Date: Tue, 16 May 2006 14:59:38 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ4zDDR0BnIOpTbQEq3spOET+5XUgAAI11wAAPkJYA= From: To: , X-OriginalArrivalTime: 16 May 2006 11:59:39.0523 (UTC) FILETIME=[35ADD530:01C678E0] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nikos Mavrogiannopoulos wrote: > Indeed there are situations were a list might do, but there are also > situations where a graph would be better, or just a single one might > do. The idea in this draft is to keep the key exchange separate > from any local verification policy. If one wants to use the web of > trust, he can use it. If somebody else wants to use openpgp keys the > same way as PKIX certificates, he can also use the current draft. > In all cases unknown keys are retrieved via a key server or by other > means. This argument would also suggest that the ability to send multiple X.509 certificates is unnecessary, since all the other certs could (in theory at least) be retrieved from directory servers.=20 You can't use this draft "the same way as PKIX certificates" unless you have the key server or "other means" working in practice. In=20 current uses of TLS with X.509 certificates, this infrastructure=20 is not necessarily present, and the ability to send several=20 certificates is used. Thus, I would not hard-code this limitation in the specification, especially when it's very easy to avoid (just allow a list just as in normal TLS), and there's just 3 bytes of overhead for=20 implementations that send only one PGP key... (and in fact even this overhead could be avoided if we remove the redundant length field by stating that the "key descriptor type" is the first byte of the key data) > That approach follows the way openpgp keys are used in electronic mail > and I see no good reason to change it by introducing an openpgp key > chain in this draft. It does not follow the email way of using PGP: most email messages don't contain the public key at all (only the signature), and when=20 the public key is included, a single message can contain several=20 keys (see e.g. RFC 3156 Section 7), presumably forming some kind of=20 graph (not necessarily a single chain). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 09:54:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzzl-0003nP-3A; Tue, 16 May 2006 09:53:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffzzk-0003nH-JE; Tue, 16 May 2006 09:53:52 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffzzj-0007WT-5X; Tue, 16 May 2006 09:53:52 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4GDrd2L001417 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2006 15:53:39 +0200 From: Simon Josefsson To: References: OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060516:nmav@gnutls.org::q3RvZToBIBZUorM6:ZDV X-Hashcash: 1:22:060516:tls-bounces@lists.ietf.org::G7ijCKdX0udYprAi:1lF2 X-Hashcash: 1:22:060516:pasi.eronen@nokia.com::G9QJfW+ve8vhCdQd:9Wbp X-Hashcash: 1:22:060516:tls@ietf.org::XnMKC0lZWdahDeYW:QtUU Date: Tue, 16 May 2006 15:53:39 +0200 In-Reply-To: (Pasi Eronen's message of "Tue, 16 May 2006 14:59:38 +0300") Message-ID: <87slna3wkc.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: tls-bounces@lists.ietf.org, tls@ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org writes: > Nikos Mavrogiannopoulos wrote: > >> Indeed there are situations were a list might do, but there are also >> situations where a graph would be better, or just a single one might >> do. The idea in this draft is to keep the key exchange separate >> from any local verification policy. If one wants to use the web of >> trust, he can use it. If somebody else wants to use openpgp keys the >> same way as PKIX certificates, he can also use the current draft. >> In all cases unknown keys are retrieved via a key server or by other >> means. > > This argument would also suggest that the ability to send multiple > X.509 certificates is unnecessary, since all the other certs could > (in theory at least) be retrieved from directory servers. > > You can't use this draft "the same way as PKIX certificates" unless > you have the key server or "other means" working in practice. I believe PGP key servers are working in practice. > In current uses of TLS with X.509 certificates, this infrastructure > is not necessarily present, and the ability to send several > certificates is used. > > Thus, I would not hard-code this limitation in the specification, > especially when it's very easy to avoid (just allow a list just > as in normal TLS), and there's just 3 bytes of overhead for > implementations that send only one PGP key... (and in fact > even this overhead could be avoided if we remove the redundant > length field by stating that the "key descriptor type" is the > first byte of the key data) I'd disagree that it is that simple to fix that: If the draft permit more than one key, I believe it has to describe how implementations are supposed to use more than one key to build the chain, or at least mandate some specific behaviour. I agree that limiting the protocol to carry one key is a theoretic limitation, although I don't see anyone describing a practical scenario where this limitation is critical. Regards, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 10:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0sO-0003N4-7O; Tue, 16 May 2006 10:50:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0sN-0003Mu-IR for tls@ietf.org; Tue, 16 May 2006 10:50:19 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0sM-000298-8a for tls@ietf.org; Tue, 16 May 2006 10:50:19 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 240EF1E8C1F; Tue, 16 May 2006 07:50:15 -0700 (PDT) To: Simon Josefsson Subject: Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 References: <87slna3wkc.fsf@latte.josefsson.org> From: Eric Rescorla Date: Tue, 16 May 2006 07:50:15 -0700 In-Reply-To: <87slna3wkc.fsf@latte.josefsson.org> (Simon Josefsson's message of "Tue, 16 May 2006 15:53:39 +0200") Message-ID: <86mzdiowgo.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls-bounces@lists.ietf.org, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson writes: > writes: >> In current uses of TLS with X.509 certificates, this infrastructure >> is not necessarily present, and the ability to send several >> certificates is used. >> >> Thus, I would not hard-code this limitation in the specification, >> especially when it's very easy to avoid (just allow a list just >> as in normal TLS), and there's just 3 bytes of overhead for >> implementations that send only one PGP key... (and in fact >> even this overhead could be avoided if we remove the redundant >> length field by stating that the "key descriptor type" is the >> first byte of the key data) > > I'd disagree that it is that simple to fix that: If the draft permit > more than one key, I believe it has to describe how implementations > are supposed to use more than one key to build the chain, or at least > mandate some specific behaviour. I don't agree with this. PGP at least theoretically knows how to build cert chains from a "bucket of keys". -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 13:09:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg326-0002Mg-Nx; Tue, 16 May 2006 13:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg325-0002Mb-1l for tls@lists.ietf.org; Tue, 16 May 2006 13:08:29 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg31z-00020z-L7 for tls@lists.ietf.org; Tue, 16 May 2006 13:08:29 -0400 Received: by ug-out-1314.google.com with SMTP id m2so23881uge for ; Tue, 16 May 2006 10:08:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=OXm8AMODzSep1zJuwAtvKmwx4A1kubRbUHtIfJvcRL8i2GsCBnGRIblHocizq/QGm3DBAC6Kyc1nGcbqt2q8vxJHpLF4FCeauWD+v9wqzBxKOtfcavrdKrWbSW13vPpdB3V27wnH03mCCVhLsnqLmwG0B9PHN+qeSR5dioNslEY= Received: by 10.67.124.1 with SMTP id b1mr5382730ugn; Tue, 16 May 2006 10:08:22 -0700 (PDT) Received: from ?172.16.1.206? ( [81.175.93.238]) by mx.gmail.com with ESMTP id m1sm1278919uge.2006.05.16.10.08.21; Tue, 16 May 2006 10:08:22 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 Date: Tue, 16 May 2006 19:07:51 +0200 User-Agent: KMail/1.9.1 References: <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> In-Reply-To: <86mzdiowgo.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605161907.51448.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue 16 May 2006 16:50, Eric Rescorla wrote: > > I'd disagree that it is that simple to fix that: If the draft > > permit more than one key, I believe it has to describe how > > implementations are supposed to use more than one key to build the > > chain, or at least mandate some specific behaviour. > I don't agree with this. PGP at least theoretically knows how > to build cert chains from a "bucket of keys". Maybe but I still find no point in sending a bucket of keys just like that. If it is to be sent it has to be clearly defined what it is expected in this bucket and so on. I'm quite reluctant to do it because I don't need nor find a use for this functionality. It can be easily added by anyone that need it[0], and I would be willing to include the required changes in this or a future update, if somebody needs it and defines the semantics of a key list. regards, Nikos [0]. the PGPKeyDescriptorType allows for extra functionality such as key_lists(2) to be added if needed. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 13:33:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3Q2-0000tL-IW; Tue, 16 May 2006 13:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3Q1-0000tG-Dt for tls@ietf.org; Tue, 16 May 2006 13:33:13 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3Q0-00032l-49 for tls@ietf.org; Tue, 16 May 2006 13:33:13 -0400 Received: by ug-out-1314.google.com with SMTP id k3so28312ugf for ; Tue, 16 May 2006 10:33:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=k9pIiVdi5pW2JWt4Y0sS7XOaePGb3QuK9cyKcMPB5ABnOkcDx6v9D3Lfki1h5IPRCtxsKz0Khk69pWUnu5rTFDpln1mNznGAEjiNoPdASi2N2JElZpod9WnkCxMUryz0l8QfSBvV2/+EE4g6LBVWR5npJEDJCsADjqRc1pj0Brc= Received: by 10.67.87.4 with SMTP id p4mr3492894ugl; Tue, 16 May 2006 10:33:11 -0700 (PDT) Received: from ?172.16.1.206? ( [81.175.93.238]) by mx.gmail.com with ESMTP id m1sm1303544uge.2006.05.16.10.33.10; Tue, 16 May 2006 10:33:10 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Date: Tue, 16 May 2006 19:32:41 +0200 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200605161932.41460.nmav@gnutls.org> X-Spam-Score: 1.9 (+) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue 16 May 2006 13:59, Pasi.Eronen@nokia.com wrote: > Thus, I would not hard-code this limitation in the specification, > especially when it's very easy to avoid (just allow a list just > as in normal TLS), and there's just 3 bytes of overhead for > implementations that send only one PGP key... (and in fact > even this overhead could be avoided if we remove the redundant > length field by stating that the "key descriptor type" is the > first byte of the key data) It is not about the byte overhead. It is about defining what a key chain is how is it going to be used, what is an implementor going to put there etc. Otherwise it would be a pandoras box, waiting to be opened. Given the feedback I've got all the years this draft exists, it seems that nobody so far had a need for it. If in the future this proves to be a limitation, it is easy to add an extra key descriptor type with a key list, that follows some rules, or none. > > That approach follows the way openpgp keys are used in electronic > > mail and I see no good reason to change it by introducing an > > openpgp key chain in this draft. > It does not follow the email way of using PGP: most email messages > don't contain the public key at all (only the signature), and when + the fingerprint of the signer, because that's what is needed for authentication. The receipient is responsible for retrieving the keys based on the fingerprint. regards, Nikos ps. I hope I didn't get rude or personal in this or previous mails, but my point is that since we have no use of this functionality today, I see no point in adding it. If needed it might be better to be added from people who would use it because they will define it the way the really need it. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 17:00:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6bt-0003JX-GM; Tue, 16 May 2006 16:57:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6bs-0003JS-7P for tls@lists.ietf.org; Tue, 16 May 2006 16:57:40 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6bq-0006rD-SI for tls@lists.ietf.org; Tue, 16 May 2006 16:57:40 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id F0D0CFB29B; Tue, 16 May 2006 16:57:37 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id C57023C0469; Tue, 16 May 2006 16:57:36 -0400 (EDT) Date: Tue, 16 May 2006 16:57:36 -0400 From: "Steven M. Bellovin" To: Nikos Mavrogiannopoulos Subject: Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 Message-Id: <20060516165736.ddc57b83.smb@cs.columbia.edu> In-Reply-To: <200605161907.51448.nmav@gnutls.org> References: <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> <200605161907.51448.nmav@gnutls.org> Organization: Columbia University X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos wrote: > On Tue 16 May 2006 16:50, Eric Rescorla wrote: > > > > I'd disagree that it is that simple to fix that: If the draft > > > permit more than one key, I believe it has to describe how > > > implementations are supposed to use more than one key to build the > > > chain, or at least mandate some specific behaviour. > > I don't agree with this. PGP at least theoretically knows how > > to build cert chains from a "bucket of keys". > > Maybe but I still find no point in sending a bucket of keys just like > that. If it is to be sent it has to be clearly defined what it is > expected in this bucket and so on. I'm quite reluctant to do it because > I don't need nor find a use for this functionality. It can be easily > added by anyone that need it[0], and I would be willing to include the > required changes in this or a future update, if somebody needs it and > defines the semantics of a key list. > The problem is that you don't know the recipient's trust anchors or trust metrics. Without that, you have to send the whole graph (or at least as much of it as you have), to maximize the chances of the key being accepted. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 16 17:06:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6ho-00054X-ED; Tue, 16 May 2006 17:03:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6hn-00054S-5o for tls@lists.ietf.org; Tue, 16 May 2006 17:03:47 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6hm-0007DH-Rf for tls@lists.ietf.org; Tue, 16 May 2006 17:03:47 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F21EE1E8C1F; Tue, 16 May 2006 14:03:45 -0700 (PDT) To: "Steven M. Bellovin" Subject: Re: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 References: <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> <200605161907.51448.nmav@gnutls.org> <20060516165736.ddc57b83.smb@cs.columbia.edu> From: Eric Rescorla Date: Tue, 16 May 2006 14:03:45 -0700 In-Reply-To: <20060516165736.ddc57b83.smb@cs.columbia.edu> (Steven M. Bellovin's message of "Tue, 16 May 2006 16:57:36 -0400") Message-ID: <867j4lptqm.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org "Steven M. Bellovin" writes: > On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos > wrote: > >> On Tue 16 May 2006 16:50, Eric Rescorla wrote: >> >> > > I'd disagree that it is that simple to fix that: If the draft >> > > permit more than one key, I believe it has to describe how >> > > implementations are supposed to use more than one key to build the >> > > chain, or at least mandate some specific behaviour. >> > I don't agree with this. PGP at least theoretically knows how >> > to build cert chains from a "bucket of keys". >> >> Maybe but I still find no point in sending a bucket of keys just like >> that. If it is to be sent it has to be clearly defined what it is >> expected in this bucket and so on. I'm quite reluctant to do it because >> I don't need nor find a use for this functionality. It can be easily >> added by anyone that need it[0], and I would be willing to include the >> required changes in this or a future update, if somebody needs it and >> defines the semantics of a key list. >> > The problem is that you don't know the recipient's trust anchors or trust > metrics. Without that, you have to send the whole graph (or at least as > much of it as you have), to maximize the chances of the key being accepted. Right, I understand that this is a problem in principle, but I'm not sure that it's a problem in practice. In particular, I'm not sure that it's so bad a problem in practice that the protocol should be explicitly designed to prohibit people who think they understand the trust graph from giving hints. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 05:51:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIdq-0008CR-Ou; Wed, 17 May 2006 05:48:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIdp-0008CH-3L for tls@lists.ietf.org; Wed, 17 May 2006 05:48:29 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIdo-00061t-Lt for tls@lists.ietf.org; Wed, 17 May 2006 05:48:29 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4H9lq7M019522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 11:47:52 +0200 From: Simon Josefsson To: EKR References: <87slna3wkc.fsf@latte.josefsson.org> <86mzdiowgo.fsf@raman.networkresonance.com> <200605161907.51448.nmav@gnutls.org> <20060516165736.ddc57b83.smb@cs.columbia.edu> <867j4lptqm.fsf@raman.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060517:ekr@networkresonance.com::rY70MpE5I76IBhqj:r9G X-Hashcash: 1:22:060517:smb@cs.columbia.edu::TM1IaFElGBIjU+OX:2SuH X-Hashcash: 1:22:060517:tls@lists.ietf.org::ggt16xlM4mWo6o7e:vbM8 Date: Wed, 17 May 2006 11:47:52 +0200 In-Reply-To: <867j4lptqm.fsf@raman.networkresonance.com> (Eric Rescorla's message of "Tue, 16 May 2006 14:03:45 -0700") Message-ID: <87psid6kzb.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@lists.ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > "Steven M. Bellovin" writes: > >> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos >> wrote: >> >>> On Tue 16 May 2006 16:50, Eric Rescorla wrote: >>> >>> > > I'd disagree that it is that simple to fix that: If the draft >>> > > permit more than one key, I believe it has to describe how >>> > > implementations are supposed to use more than one key to build the >>> > > chain, or at least mandate some specific behaviour. >>> > I don't agree with this. PGP at least theoretically knows how >>> > to build cert chains from a "bucket of keys". >>> >>> Maybe but I still find no point in sending a bucket of keys just like >>> that. If it is to be sent it has to be clearly defined what it is >>> expected in this bucket and so on. I'm quite reluctant to do it because >>> I don't need nor find a use for this functionality. It can be easily >>> added by anyone that need it[0], and I would be willing to include the >>> required changes in this or a future update, if somebody needs it and >>> defines the semantics of a key list. >>> >> The problem is that you don't know the recipient's trust anchors or trust >> metrics. Without that, you have to send the whole graph (or at least as >> much of it as you have), to maximize the chances of the key being accepted. > > Right, I understand that this is a problem in principle, but I'm > not sure that it's a problem in practice. In particular, I'm not > sure that it's so bad a problem in practice that the protocol should > be explicitly designed to prohibit people who think they understand > the trust graph from giving hints. I believe that protocol fields with undocumented semantics, and where the algorithms that make use of those fields are not documented [1], leads to poor interoperability. As Nikos said, if someone wants this, it is easy to extend the PGPKeyDescriptorType enum to add a key_list(2), and then describe the semantics related to it. If someone volunteers to write that, we could review that text to see if it seems correct, but, IMHO, the onus to write this should be on those who proposed this change in the document. Regards, Simon [1] I'm guessing here. If what PGP does is documented and part of some standard, the situation would be different. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 10:35:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN6S-0003Mq-2n; Wed, 17 May 2006 10:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgN6R-0003Ml-5H for tls@ietf.org; Wed, 17 May 2006 10:34:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgN6O-000410-C8 for tls@ietf.org; Wed, 17 May 2006 10:34:19 -0400 Received: from [217.164.68.88] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1FgN6G16uA-0008JK; Wed, 17 May 2006 16:34:09 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 500D43D672; Wed, 17 May 2006 18:33:59 +0400 (GST) Date: Wed, 17 May 2006 18:33:59 +0400 From: Bodo Moeller To: tls@ietf.org Message-ID: <20060517143359.GA4575@iota.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [TLS] RFC 4492 on Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org RFC 4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)", is now available at the usual locations: http://www.ietf.org/rfc/rfc4492.txt http://www.rfc-editor.org/rfc/rfc4492.txt The official announcement can be found at http://www1.ietf.org/mail-archive/web/ietf-announce/current/msg02506.html It was copied to the present list, but following a well-known pattern did not arrive here and does not show up on the list archives http://www1.ietf.org/mail-archive/web/tls/current/ , presumably because this list only accepts messages from subscribers and has not been configured to make an exception for the RFC Editor. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 11:22:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqU-0006yD-M6; Wed, 17 May 2006 11:21:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgNqT-0006y8-LH for tls@lists.ietf.org; Wed, 17 May 2006 11:21:53 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgNqS-0006tf-9B for tls@lists.ietf.org; Wed, 17 May 2006 11:21:53 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 1E222222418; Wed, 17 May 2006 08:28:13 -0700 (PDT) To: Simon Josefsson In-reply-to: Your message of "Wed, 17 May 2006 11:47:52 +0200." <87psid6kzb.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Wed, 17 May 2006 08:22:29 -0700 From: Eric Rescorla Message-Id: <20060517152813.1E222222418@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@lists.ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Eric Rescorla writes: > > > "Steven M. Bellovin" writes: > > > >> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos > >> wrote: > >> > >>> On Tue 16 May 2006 16:50, Eric Rescorla wrote: > >>> > >>> > > I'd disagree that it is that simple to fix that: If the draft > >>> > > permit more than one key, I believe it has to describe how > >>> > > implementations are supposed to use more than one key to build the > >>> > > chain, or at least mandate some specific behaviour. > >>> > I don't agree with this. PGP at least theoretically knows how > >>> > to build cert chains from a "bucket of keys". > >>> > >>> Maybe but I still find no point in sending a bucket of keys just like > >>> that. If it is to be sent it has to be clearly defined what it is > >>> expected in this bucket and so on. I'm quite reluctant to do it because > >>> I don't need nor find a use for this functionality. It can be easily > >>> added by anyone that need it[0], and I would be willing to include the > >>> required changes in this or a future update, if somebody needs it and > >>> defines the semantics of a key list. > >>> > >> The problem is that you don't know the recipient's trust anchors or trust > >> metrics. Without that, you have to send the whole graph (or at least as > >> much of it as you have), to maximize the chances of the key being accepted. > > > > Right, I understand that this is a problem in principle, but I'm > > not sure that it's a problem in practice. In particular, I'm not > > sure that it's so bad a problem in practice that the protocol should > > be explicitly designed to prohibit people who think they understand > > the trust graph from giving hints. > > I believe that protocol fields with undocumented semantics, and where > the algorithms that make use of those fields are not documented [1], > leads to poor interoperability. It's not undocumented. It's "add these certs to your bucket of certs" and use them in whatever resolution mechanism you have. > As Nikos said, if someone wants this, it is easy to extend the > PGPKeyDescriptorType enum to add a key_list(2), and then describe the > semantics related to it. If someone volunteers to write that, we > could review that text to see if it seems correct, but, IMHO, the onus > to write this should be on those who proposed this change in the > document. I don't agree that this should be an extension, but I am willing to go along with the burden of work argument. Pasi, you want to contribute text? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 12:30:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOtd-00054l-Vi; Wed, 17 May 2006 12:29:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOtd-00052w-Hd for tls@lists.ietf.org; Wed, 17 May 2006 12:29:13 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOtc-0001Kp-2W for tls@lists.ietf.org; Wed, 17 May 2006 12:29:13 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4HGSv3o014571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 18:28:58 +0200 From: Simon Josefsson To: Eric Rescorla References: <87psid6kzb.fsf@latte.josefsson.org> <20060517152813.1E222222418@laser.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060517:ekr@networkresonance.com::6LQdAmzfbkHksksj:AYK7 X-Hashcash: 1:22:060517:tls@lists.ietf.org::mumWBUACOEo8Iynq:Q8Uw Date: Wed, 17 May 2006 18:28:57 +0200 In-Reply-To: <20060517152813.1E222222418@laser.networkresonance.com> (Eric Rescorla's message of "Wed, 17 May 2006 08:22:29 -0700") Message-ID: <87y7x0ipiu.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@lists.ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > Simon Josefsson wrote: > >> Eric Rescorla writes: >> >> > "Steven M. Bellovin" writes: >> > >> >> On Tue, 16 May 2006 19:07:51 +0200, Nikos Mavrogiannopoulos >> >> wrote: >> >> >> >>> On Tue 16 May 2006 16:50, Eric Rescorla wrote: >> >>> >> >>> > > I'd disagree that it is that simple to fix that: If the draft >> >>> > > permit more than one key, I believe it has to describe how >> >>> > > implementations are supposed to use more than one key to build the >> >>> > > chain, or at least mandate some specific behaviour. >> >>> > I don't agree with this. PGP at least theoretically knows how >> >>> > to build cert chains from a "bucket of keys". >> >>> >> >>> Maybe but I still find no point in sending a bucket of keys just like >> >>> that. If it is to be sent it has to be clearly defined what it is >> >>> expected in this bucket and so on. I'm quite reluctant to do it because >> >>> I don't need nor find a use for this functionality. It can be easily >> >>> added by anyone that need it[0], and I would be willing to include the >> >>> required changes in this or a future update, if somebody needs it and >> >>> defines the semantics of a key list. >> >>> >> >> The problem is that you don't know the recipient's trust anchors or trust >> >> metrics. Without that, you have to send the whole graph (or at least as >> >> much of it as you have), to maximize the chances of the key being accepted. >> > >> > Right, I understand that this is a problem in principle, but I'm >> > not sure that it's a problem in practice. In particular, I'm not >> > sure that it's so bad a problem in practice that the protocol should >> > be explicitly designed to prohibit people who think they understand >> > the trust graph from giving hints. >> >> I believe that protocol fields with undocumented semantics, and where >> the algorithms that make use of those fields are not documented [1], >> leads to poor interoperability. > > It's not undocumented. It's "add these certs to your bucket of certs" > and use them in whatever resolution mechanism you have. How are clients and servers, respectively, supposed to figure out which keys to include? Presumably, they should not send their entire key ring, right? Some properties of the resolution algorithms appear to be needed to pick the "appropriate" keys, and limit the set of keys to send. Compare RFC 4346, which says on X.509 certs: certificate_list This is a sequence (chain) of X.509v3 certificates. The sender's certificate must come first in the list. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. What I'm looking for are similar guidelines to decide which OpenPGP keys to include, but I'm skeptical about the existence of useful such guidelines. Regards, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 12:32:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOw5-0006TO-2w; Wed, 17 May 2006 12:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgOw3-0006TJ-Q4 for tls@lists.ietf.org; Wed, 17 May 2006 12:31:43 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgOw2-0001TX-Fh for tls@lists.ietf.org; Wed, 17 May 2006 12:31:43 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 9811E22245C; Wed, 17 May 2006 09:38:05 -0700 (PDT) To: Simon Josefsson In-reply-to: Your message of "Wed, 17 May 2006 18:28:57 +0200." <87y7x0ipiu.fsf@latte.josefsson.org> X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Wed, 17 May 2006 09:31:41 -0700 From: Eric Rescorla Message-Id: <20060517163805.9811E22245C@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@lists.ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Eric Rescorla writes: > > It's not undocumented. It's "add these certs to your bucket of certs" > > and use them in whatever resolution mechanism you have. > > How are clients and servers, respectively, supposed to figure out > which keys to include? > > Presumably, they should not send their entire key ring, right? Some > properties of the resolution algorithms appear to be needed to pick > the "appropriate" keys, and limit the set of keys to send. > > Compare RFC 4346, which says on X.509 certs: > > certificate_list > This is a sequence (chain) of X.509v3 certificates. The sender's > certificate must come first in the list. Each following > certificate must directly certify the one preceding it. Because > certificate validation requires that root keys be distributed > independently, the self-signed certificate that specifies the root > certificate authority may optionally be omitted from the chain, > under the assumption that the remote end must already possess it > in order to validate it in any case. > > What I'm looking for are similar guidelines to decide which OpenPGP > keys to include, but I'm skeptical about the existence of useful such > guidelines. Rather than arguing about whether such rules are possible (though I think they are in practice), why don't we see if Pasi wants to try to write something? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 17 12:58:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPLh-0001Tq-Qb; Wed, 17 May 2006 12:58:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgPLg-0001Tl-Bx for tls@lists.ietf.org; Wed, 17 May 2006 12:58:12 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgPLf-0002n7-UK for tls@lists.ietf.org; Wed, 17 May 2006 12:58:12 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4HGw2ES018980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 May 2006 18:58:05 +0200 From: Simon Josefsson To: Eric Rescorla References: <20060517163805.9811E22245C@laser.networkresonance.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:060517:ekr@networkresonance.com::Vb49l82LkM9CDv+m:/pD X-Hashcash: 1:22:060517:tls@lists.ietf.org::1rOnENs4OMHq4uQd:68fB Date: Wed, 17 May 2006 18:58:02 +0200 In-Reply-To: <20060517163805.9811E22245C@laser.networkresonance.com> (Eric Rescorla's message of "Wed, 17 May 2006 09:31:41 -0700") Message-ID: <87u07oio6d.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tls@lists.ietf.org Subject: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > Simon Josefsson wrote: >> Eric Rescorla writes: >> > It's not undocumented. It's "add these certs to your bucket of certs" >> > and use them in whatever resolution mechanism you have. >> >> How are clients and servers, respectively, supposed to figure out >> which keys to include? >> >> Presumably, they should not send their entire key ring, right? Some >> properties of the resolution algorithms appear to be needed to pick >> the "appropriate" keys, and limit the set of keys to send. >> >> Compare RFC 4346, which says on X.509 certs: >> >> certificate_list >> This is a sequence (chain) of X.509v3 certificates. The sender's >> certificate must come first in the list. Each following >> certificate must directly certify the one preceding it. Because >> certificate validation requires that root keys be distributed >> independently, the self-signed certificate that specifies the root >> certificate authority may optionally be omitted from the chain, >> under the assumption that the remote end must already possess it >> in order to validate it in any case. >> >> What I'm looking for are similar guidelines to decide which OpenPGP >> keys to include, but I'm skeptical about the existence of useful such >> guidelines. > > Rather than arguing about whether such rules are possible (though > I think they are in practice), why don't we see if Pasi wants to > try to write something? Yup, agreed. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 18 03:33:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgczE-0006sk-S6; Thu, 18 May 2006 03:31:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgczD-0006sf-Pj for tls@lists.ietf.org; Thu, 18 May 2006 03:31:55 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgczD-0004P3-0u for tls@lists.ietf.org; Thu, 18 May 2006 03:31:55 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4I7VbBF014703 for ; Thu, 18 May 2006 10:31:54 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:30:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:30:54 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 Date: Thu, 18 May 2006 10:30:54 +0300 Message-ID: In-Reply-To: <20060517163805.9811E22245C@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ5z3waoJvRqQNES1y65ZwOSWN74gAel48g From: To: X-OriginalArrivalTime: 18 May 2006 07:30:54.0837 (UTC) FILETIME=[FF718250:01C67A4C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > Rather than arguing about whether such rules are possible (though=20 > I think they are in practice), why don't we see if Pasi wants to > try to write something? As far as I know, there is no RFC that really describes how PGP key validation works (RFC 2440 describes the on-the-wire formats, but not much more). Thus, even the current version of draft-ietf-tls-openpgp-keys=20 can't do any better than saying "The key validation procedure is a=20 local matter outside the scope of this document". So if we're really worrying about unspecified semantics, that's certainly one huge missing part... If the key validation rules would be described somewhere, I think handling multiple keys/certificates could be as simple as saying "the=20 sender MAY include additional keys/certificates it believes to be useful to the recipient (how this is determined is a matter of local policy and configuration)" and "the recipient incorporates all the received keys/certificates (not just the first one) in the key validation procedure". Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu May 18 16:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeX-0000ao-Fv; Thu, 18 May 2006 15:59:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoeL-0000T9-3c; Thu, 18 May 2006 15:59:09 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgoVV-0000CT-LC; Thu, 18 May 2006 15:50:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k4IJo11I030169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 May 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FgoVV-0008G9-Eb; Thu, 18 May 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Thu, 18 May 2006 15:50:01 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-srp-11.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Using SRP for TLS Authentication Author(s) : D. Taylor, et al. Filename : draft-ietf-tls-srp-11.txt Pages : 25 Date : 2006-5-18 This memo presents a technique for using the Secure Remote Password protocol ([SRP], [SRP-6]) as an authentication method for the Transport Layer Security protocol [TLS]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-tls-srp-11.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-tls-srp-11.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: <2006-5-18115536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-srp-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-srp-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-5-18115536.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon May 22 04:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi5M9-0000Nj-LG; Mon, 22 May 2006 04:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi5M8-0000Ne-KA for tls@ietf.org; Mon, 22 May 2006 04:01:36 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi5M7-0002ys-6d for tls@ietf.org; Mon, 22 May 2006 04:01:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4M81Ydw029782 for ; Mon, 22 May 2006 11:01:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 11:01:33 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 May 2006 11:01:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Date: Mon, 22 May 2006 11:01:33 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Review of draft-ietf-tls-openpgp-keys-08 Thread-Index: AcZ0xj7Uv3RS02H2RC29CzjkFyP6HwIrixeA From: To: X-OriginalArrivalTime: 22 May 2006 08:01:33.0628 (UTC) FILETIME=[F119BFC0:01C67D75] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Nikos Mavrogiannopoulos wrote: > > 6) Section 4: I'd suggest merging this section (only four lines) > > with Section 3.1. Also, the text should apply to all ciphersuites > > using the RSA/DHE_DSS/DHE_RSA key exchange methods, not just > > those in RFC 2246. (And with this change, the text about > > exportable ciphersuites is no longer necessary.) >=20 > True. I'll update it. It looks like this wasn't properly updated in -09: "No new cipher suites are required to use OpenPGP keys. All existing cipher suites defined in [TLS] that support a compatible, with the key, key exchange method can be used in combination with OpenPGP keys." We should remove the "defined in [TLS]" part so that OpenPGP keys can be used with, for example, RFC4132 and RFC4162. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 23 04:01:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRp6-0002RH-MR; Tue, 23 May 2006 04:01:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiRp4-0002R9-OV; Tue, 23 May 2006 04:00:58 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiRp3-0001Or-AN; Tue, 23 May 2006 04:00:58 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4N80rGY027440; Tue, 23 May 2006 11:00:56 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 11:00:56 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 11:00:56 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 May 2006 11:00:52 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-housley-tls-authz-extns-05 Thread-Index: AcZ+PwMNZPkennagT/SoqPhXKQtzFg== From: To: X-OriginalArrivalTime: 23 May 2006 08:00:56.0037 (UTC) FILETIME=[051B9150:01C67E3F] X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@ietf.org Subject: [TLS] Review of draft-housley-tls-authz-extns-05 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org The part about X.509 attribute certificates looks fine, but at least the SAML part still needs some work: 1) I think the document needs to discuss the security considerations of bearer SAML assertions in more detail. While the countermeasures described in 3.3.2 may help against passive eavesdroppers, they=20 still allow an active MiTM to "steal" the permission. This is IMHO=20 a significant difference to typical SAML usage with HTTP-over-TLS, where the server is authenticated before the bearer assertion is sent. 2) Section 3.3.2: "When SAMLAssertion is used, the field contains XML=20 constructs with a nested structure defined in [SAML1.1][SAML2.0]." This needs to be much more specific than "some XML from these=20 documents". What element/elements? Is this an XML document (with XML declaration etc.), or just a "fragment"? Which encoding?=20 And so on... 3) The document is last called for Proposed Standard, but contains a normative reference to Informational RFC (RFC 2704). I'd=20 suggest removing the KeyNote stuff from this document (if someone really wants to do KeyNote, it can be a separate document). Minor editorial comments: 4) Section 2.3: the list type is "AuthorizationDataFormats" but enum is spelled "AuthzDataFormat". Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat May 27 13:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2vJ-0006vd-82; Sat, 27 May 2006 13:50:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fk2vH-0006vO-LX for tls@lists.ietf.org; Sat, 27 May 2006 13:49:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fk2vH-0002XN-K4 for tls@lists.ietf.org; Sat, 27 May 2006 13:49:59 -0400 Received: from ug-out-1314.google.com ([66.249.92.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fk2lm-0000aL-Ny for tls@lists.ietf.org; Sat, 27 May 2006 13:40:12 -0400 Received: by ug-out-1314.google.com with SMTP id m3so145388uge for ; Sat, 27 May 2006 10:40:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:user-agent:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=bFfrWt8LOMakrKFkHln2/N3zLj+RAnz7CLku/HRqsiDg+XYHlOLyIre5+NRTZdVb8VFhxsItIqBCy4nQyHmecWNtwFz2mJbMr01nqqRySatD6oyHNkOiqLDAyw8NPGTPeV6N/GdWmYk3vbSxqiE8Da6nr6ucaUBZg5rGVXddFvk= Received: by 10.67.89.6 with SMTP id r6mr508599ugl; Sat, 27 May 2006 10:40:07 -0700 (PDT) Received: from ?172.16.1.206? ( [81.175.93.238]) by mx.gmail.com with ESMTP id s1sm1760951uge.2006.05.27.10.40.06; Sat, 27 May 2006 10:40:06 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Review of draft-ietf-tls-openpgp-keys-08 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Date: Sat, 27 May 2006 19:39:30 +0200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200605271939.30280.nmav@gnutls.org> X-Spam-Score: -1.3 (-) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Mon 22 May 2006 10:01, Pasi.Eronen@nokia.com wrote: > It looks like this wasn't properly updated in -09: > "No new cipher suites are required to use OpenPGP keys. All > existing cipher suites defined in [TLS] that support a compatible, > with the key, key exchange method can be used in combination with > OpenPGP keys." > We should remove the "defined in [TLS]" part so that OpenPGP keys > can be used with, for example, RFC4132 and RFC4162. I seems I missed that. Thank you for spotting it. Should I submit a new version before the last call or it can wait? regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 30 08:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl36a-0007Vp-5q; Tue, 30 May 2006 08:13:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl36Y-0007VW-Vo for tls@lists.ietf.org; Tue, 30 May 2006 08:13:46 -0400 Received: from revol1.enst.fr ([137.194.2.7] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl36V-0003Vw-Mm for tls@lists.ietf.org; Tue, 30 May 2006 08:13:46 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id D1E86166265; Tue, 30 May 2006 14:13:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmXza-xZPJQo; Tue, 30 May 2006 14:13:42 +0200 (CEST) Received: from enst.fr (mechmech.enst.fr [137.194.164.56]) by smtp2.enst.fr (Postfix) with ESMTP id 5F12F16625A; Tue, 30 May 2006 14:13:42 +0200 (CEST) Message-ID: <447C36EF.8030308@enst.fr> Date: Tue, 30 May 2006 14:13:35 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Eric Rescorla Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@lists.ietf.org Subject: [TLS] Empty ClientKeyExchange X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Eric and all, May you please clarify the need of replacing the *will be* with the *MUST* in the following text: In RFC4346, Section 7.4.7.2, second paragraph: In this case, the client key exchange message will be sent, but it MUST be empty. In RFC2246, Section 7.4.7.2, second paragraph: In this case, the Client Key Exchange message will be sent, but will be empty. I don't think that *will be* is equivalent to "MUST*, isn't it? Thanks Best regards, Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue May 30 10:07:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4rX-0003Q4-Qx; Tue, 30 May 2006 10:06:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fl4rW-0003Pz-W9 for tls@lists.ietf.org; Tue, 30 May 2006 10:06:22 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fl4rV-0005JU-Go for tls@lists.ietf.org; Tue, 30 May 2006 10:06:22 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4UE6JTl003006; Tue, 30 May 2006 17:06:19 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 17:06:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 May 2006 17:06:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Empty ClientKeyExchange Date: Tue, 30 May 2006 17:06:20 +0300 Message-ID: In-Reply-To: <447C36EF.8030308@enst.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Empty ClientKeyExchange Thread-Index: AcaD6MzQjB7yXldMTvmOgOiabwQJ7QAB1uNw From: To: X-OriginalArrivalTime: 30 May 2006 14:06:19.0050 (UTC) FILETIME=[392220A0:01C683F2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Mohamad, Both versions of this sentence seem to say exactly the same thing: when you do client authentication with DH_DSS or DH_RSA ciphersuites, the client certificate already contains Yc (the client's public DH value), and the same value is not sent again in ClientKeyExchange. (And sending a different value would not make any sense.)=20 The RFC2246 version states this as a simple fact; RFC4346 prefers=20 a RFC2119 keyword. IMHO neither version leaves much room for interpretation... but it seems that you have a different opinion? Are you aware of existing TLS 1.0 implementations that do send=20 Yc again in ClientKeyExchange? Best regards, Pasi > -----Original Message----- > From: ext Mohamad Badra [mailto:badra@enst.fr]=20 > Sent: 30 May, 2006 15:14 > To: Eric Rescorla > Cc: tls@lists.ietf.org > Subject: [TLS] Empty ClientKeyExchange >=20 > Hi Eric and all, >=20 > May you please clarify the need of replacing the *will be* with the=20 > *MUST* in the following text: >=20 > In RFC4346, Section 7.4.7.2, second paragraph: >=20 > In this case, the client key exchange message will be > sent, but it MUST be empty. >=20 > In RFC2246, Section 7.4.7.2, second paragraph: >=20 > In this case, the Client Key Exchange message > will be sent, but will be empty. >=20 > I don't think that *will be* is equivalent to "MUST*, isn't it? >=20 > Thanks > Best regards, >=20 > Badra _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 31 09:06:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQOI-0006hc-Vl; Wed, 31 May 2006 09:05:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlQOH-0006hP-2z for tls@lists.ietf.org; Wed, 31 May 2006 09:05:37 -0400 Received: from revol2.enst.fr ([137.194.2.14] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlQOE-0002RO-Oj for tls@lists.ietf.org; Wed, 31 May 2006 09:05:37 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id B94801A88; Wed, 31 May 2006 15:05:33 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol2.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOJ3U6nff9pJ; Wed, 31 May 2006 15:05:32 +0200 (CEST) Received: from enst.fr (mechmech.enst.fr [137.194.164.56]) by smtp2.enst.fr (Postfix) with ESMTP id 24B555AE; Wed, 31 May 2006 15:04:45 +0200 (CEST) Message-ID: <447D9466.9050901@enst.fr> Date: Wed, 31 May 2006 15:04:38 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Empty ClientKeyExchange References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Dear Pasi, Sorry for the late reply, my mail server had some problems... In fact, Urien and I wrote a document (will be published by IETF=20 secretariat) providing the client's identity protection. To do that, we=20 propose to encrypt the certificate using a "symmetric key" derived from=20 the master_secret [1] (please keep in mind the EAP-TLS handshake). Thus,=20 if the client uses a DH_DSS or DH_RSA, the server will not be able to=20 compute the premaster secret and the master_secret. If the Yc will be sent again, it will break the TLS specs. Hence, I=20 think sending the Yc in an TLS extension when identity protection is=20 desired. Finally, I don't know any implementation of TLS1.0 that sends Yc again in ClientKeyExchange. Best regards, Badra [1] we sent a draft to the IETF secretariat, and it is disponible at http://www.infres.enst.fr/~badra/draft-urien-badra-eap-tls-identity-prote= ction-00.txt Pasi.Eronen@nokia.com a =E9crit: > Hi Mohamad, > > Both versions of this sentence seem to say exactly the same thing: > when you do client authentication with DH_DSS or DH_RSA ciphersuites, > the client certificate already contains Yc (the client's public DH > value), and the same value is not sent again in ClientKeyExchange. > (And sending a different value would not make any sense.) > > The RFC2246 version states this as a simple fact; RFC4346 prefers > a RFC2119 keyword. IMHO neither version leaves much room for > interpretation... but it seems that you have a different opinion? > Are you aware of existing TLS 1.0 implementations that do send > Yc again in ClientKeyExchange? > > Best regards, > Pasi > > >>-----Original Message----- >>From: ext Mohamad Badra [mailto:badra@enst.fr] >>Sent: 30 May, 2006 15:14 >>To: Eric Rescorla >>Cc: tls@lists.ietf.org >>Subject: [TLS] Empty ClientKeyExchange >> >>Hi Eric and all, >> >>May you please clarify the need of replacing the *will be* with the >>*MUST* in the following text: >> >>In RFC4346, Section 7.4.7.2, second paragraph: >> >> In this case, the client key exchange message will be >> sent, but it MUST be empty. >> >>In RFC2246, Section 7.4.7.2, second paragraph: >> >> In this case, the Client Key Exchange message >> will be sent, but will be empty. >> >>I don't think that *will be* is equivalent to "MUST*, isn't it? >> >>Thanks >>Best regards, >> >>Badra > > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 31 12:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTGu-0002vn-WB; Wed, 31 May 2006 12:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTGt-0002vE-6g for tls@lists.ietf.org; Wed, 31 May 2006 12:10:11 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTGr-00047U-Ne for tls@lists.ietf.org; Wed, 31 May 2006 12:10:11 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k4VGA0w6025971; Wed, 31 May 2006 19:10:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 19:10:05 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 May 2006 19:10:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Empty ClientKeyExchange Date: Wed, 31 May 2006 19:10:03 +0300 Message-ID: In-Reply-To: <447D9466.9050901@enst.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Empty ClientKeyExchange Thread-Index: AcaEszUYi8npxRfVQC2fPsM0mKvboAAF/6sQ From: To: X-OriginalArrivalTime: 31 May 2006 16:10:04.0656 (UTC) FILETIME=[AD8D6F00:01C684CC] X-Spam-Score: 0.2 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Mohamad, Since you're presumably negotiating this identity protection feature with TLS extensions, you could negotiate different syntax for ClientKeyExchange as well (along the lines "if the identity protection feature is used with DH_DSS/DH_RSA ciphersuites, the ClientKeyExchange message always contains explicit Diffie-Hellman public value"). (However, in the case of DH_DSS/DH_RSA ciphersuites with client authentication, Yc is a permanent identifier for the client, so while it's not human-readable, an eavesdropper could still correlate sessions by the same client.) Best regards,=20 Pasi > -----Original Message----- > From: ext Mohamad Badra [mailto:badra@enst.fr]=20 > Sent: 31 May, 2006 16:05 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: tls@lists.ietf.org > Subject: Re: [TLS] Empty ClientKeyExchange >=20 > Dear Pasi, >=20 > Sorry for the late reply, my mail server had some problems... >=20 > In fact, Urien and I wrote a document (will be published by IETF > secretariat) providing the client's identity protection. To do that, > we propose to encrypt the certificate using a "symmetric key" > derived from the master_secret [1] (please keep in mind the EAP-TLS > handshake). Thus, if the client uses a DH_DSS or DH_RSA, the server > will not be able to compute the premaster secret and the > master_secret. >=20 > If the Yc will be sent again, it will break the TLS specs. Hence, I=20 > think sending the Yc in an TLS extension when identity protection is=20 > desired. >=20 > Finally, I don't know any implementation of TLS1.0 that sends Yc again > in ClientKeyExchange. >=20 > Best regards, > Badra >=20 > [1] we sent a draft to the IETF secretariat, and it is disponible at > http://www.infres.enst.fr/~badra/draft-urien-badra-eap-tls-identity-prot ection-00.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 31 12:53:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTvu-0000AV-Cf; Wed, 31 May 2006 12:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlTvt-00005g-1J for tls@lists.ietf.org; Wed, 31 May 2006 12:52:33 -0400 Received: from smtp6-g19.free.fr ([212.27.42.36]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlTvr-0008S5-Ja for tls@lists.ietf.org; Wed, 31 May 2006 12:52:33 -0400 Received: from enst.fr (mar92-11-82-245-209-5.fbx.proxad.net [82.245.209.5]) by smtp6-g19.free.fr (Postfix) with ESMTP id B57162252D; Wed, 31 May 2006 18:52:30 +0200 (CEST) Message-ID: <447DC9C2.6090902@enst.fr> Date: Wed, 31 May 2006 18:52:18 +0200 From: Mohamad Badra User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: fr-fr, fr MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Empty ClientKeyExchange References: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Pasi, Pasi.Eronen@nokia.com a =E9crit: > Hi Mohamad, >=20 > Since you're presumably negotiating this identity protection feature > with TLS extensions, you could negotiate different syntax for > ClientKeyExchange as well (along the lines "if the identity protection > feature is used with DH_DSS/DH_RSA ciphersuites, the ClientKeyExchange > message always contains explicit Diffie-Hellman public value"). I agree. This is what I tried to say in my last mail. >=20 > (However, in the case of DH_DSS/DH_RSA ciphersuites with client > authentication, Yc is a permanent identifier for the client, so while > it's not human-readable, an eavesdropper could still correlate > sessions by the same client.) That's correcte. Identity protection must not be used in this case. But=20 it can be used if the client and the server agree on using signed=20 ephemeral Yc (DHE_RSA or DHE_DSS). Best regards, Badra >=20 > Best regards,=20 > Pasi >=20 >=20 >>-----Original Message----- >>From: ext Mohamad Badra [mailto:badra@enst.fr]=20 >>Sent: 31 May, 2006 16:05 >>To: Eronen Pasi (Nokia-NRC/Helsinki) >>Cc: tls@lists.ietf.org >>Subject: Re: [TLS] Empty ClientKeyExchange >> >>Dear Pasi, >> >>Sorry for the late reply, my mail server had some problems... >> >>In fact, Urien and I wrote a document (will be published by IETF >>secretariat) providing the client's identity protection. To do that, >>we propose to encrypt the certificate using a "symmetric key" >>derived from the master_secret [1] (please keep in mind the EAP-TLS >>handshake). Thus, if the client uses a DH_DSS or DH_RSA, the server >>will not be able to compute the premaster secret and the >>master_secret. >> >>If the Yc will be sent again, it will break the TLS specs. Hence, I=20 >>think sending the Yc in an TLS extension when identity protection is=20 >>desired. >> >>Finally, I don't know any implementation of TLS1.0 that sends Yc again >>in ClientKeyExchange. >> >>Best regards, >>Badra >> >>[1] we sent a draft to the IETF secretariat, and it is disponible at >> >=20 > http://www.infres.enst.fr/~badra/draft-urien-badra-eap-tls-identity-pro= t > ection-00.txt >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed May 31 18:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYlU-0007xG-Vs; Wed, 31 May 2006 18:02:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlYlT-0007x8-7P for tls@ietf.org; Wed, 31 May 2006 18:02:07 -0400 Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FlYlQ-0006dd-W4 for tls@ietf.org; Wed, 31 May 2006 18:02:07 -0400 Received: (qmail 11190 invoked by uid 0); 31 May 2006 22:01:57 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.46) by woodstock.binhost.com with SMTP; 31 May 2006 22:01:57 -0000 Message-Id: <7.0.0.16.2.20060531173828.07a36e28@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 31 May 2006 18:02:02 -0400 To: From: Russ Housley Subject: Re: [TLS] Review of draft-housley-tls-authz-extns-05 In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: hartmans-ietf@mit.edu, mark@redphonesecurity.com, tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Pasi: >The part about X.509 attribute certificates looks fine, but >at least the SAML part still needs some work: > >1) I think the document needs to discuss the security considerations > of bearer SAML assertions in more detail. While the countermeasures > described in 3.3.2 may help against passive eavesdroppers, they > still allow an active MiTM to "steal" the permission. This is IMHO > a significant difference to typical SAML usage with HTTP-over-TLS, > where the server is authenticated before the bearer assertion is > sent. Does this proposed text solve your concern? The use of bearer SAML assertions allows an eavesdropper or a man-in-the-middle to capture the SAML assertion and try to reuse it in another context. The constraints discussed in Section 3.3.2 might be effective against an eavesdropper, but they are less likely to be effective against a man-in-the-middle. Authentication of both parties in the TLS session, which involves the use of client authentication, will prevent an undetected man-in the-middle, and the use of the double handshake illustrated in Figure 2 will prevent the disclosure of the bearer SAML assertion to any party other than the TLS peer. >2) Section 3.3.2: "When SAMLAssertion is used, the field contains XML > constructs with a nested structure defined in [SAML1.1][SAML2.0]." > This needs to be much more specific than "some XML from these > documents". What element/elements? Is this an XML document > (with XML declaration etc.), or just a "fragment"? Which encoding? > And so on... Does this proposed text solve your concern? When SAMLAssertion is used, the field contains an XML-encoded element using the AssertionType complex type as defined in [SAML1.1][SAML2.0]. >3) The document is last called for Proposed Standard, but contains > a normative reference to Informational RFC (RFC 2704). I'd > suggest removing the KeyNote stuff from this document (if someone > really wants to do KeyNote, it can be a separate document). Draft -06 was posted to remove all references to KeyNote. >Minor editorial comments: > >4) Section 2.3: the list type is "AuthorizationDataFormats" but > enum is spelled "AuthzDataFormat". This was fixed in draft -06 too. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls