From ve7jtb@ve7jtb.com Thu Feb 9 13:03:17 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6559521E805B for ; Thu, 9 Feb 2012 13:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.535 X-Spam-Level: X-Spam-Status: No, score=-3.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3ax8cgb-WMF for ; Thu, 9 Feb 2012 13:03:15 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 789E121E8061 for ; Thu, 9 Feb 2012 13:03:14 -0800 (PST) Received: by yenm3 with SMTP id m3so1341897yen.31 for ; Thu, 09 Feb 2012 13:03:13 -0800 (PST) Received: by 10.101.170.2 with SMTP id x2mr1554211ano.45.1328821393495; Thu, 09 Feb 2012 13:03:13 -0800 (PST) Received: from [192.168.1.213] ([190.22.41.248]) by mx.google.com with ESMTPS id h29sm8591640ann.16.2012.02.09.13.03.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 09 Feb 2012 13:03:11 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_02091F8E-3980-454F-81B6-4B184DEEF0B8"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <397B382EC2E6D9479F9A5D6D050FB707033ABB@WO-SFOEXCH-02.wideorbit.com> Date: Thu, 9 Feb 2012 18:03:06 -0300 Message-Id: <25CABF36-27D0-4DDB-8644-58EBFEDFC4EC@ve7jtb.com> References: <397B382EC2E6D9479F9A5D6D050FB707033ABB@WO-SFOEXCH-02.wideorbit.com> To: Steffen Yount X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQm+kMqM7LIU8HZPSfe7vUjG4m9JmyX8JYB8tEc1BY7PkmsDvB0YgCzdLx90zOs04uwyPdyn X-Mailman-Approved-At: Thu, 09 Feb 2012 13:20:11 -0800 Cc: Eric Rescorla , Dirk Balfanz , "jose@ietf.org" , John Panzer , Brian Campbell , "Yaron Y. Goland" , "Michael B. Jones" , Joe Hildebrand , Paul Tarjan , Nat Sakimura , Chuck Mortimore Subject: Re: [jose] Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 21:03:17 -0000 --Apple-Mail=_02091F8E-3980-454F-81B6-4B184DEEF0B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 We do currently have the option of RFC1952 compression of the plain text = before encryption.=20 Personally I think compression before encryption should be the default. = Others prefer it as a option. We didn't add it to signing as there are existing ways to compress = content in http. =20 If you think it needs to be added to signing then let us know. Regards John Bradley On 2012-02-09, at 4:21 PM, Steffen Yount wrote: > Hi, > =20 > I hope this email reaches someone who can respond. I=92ve included = authors from the various JWT specs. > =20 > I was thinking through JSON Web Token (JWT) Bearer Token Profiles for = OAuth 2.0 draft spec ( = http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 ) while = researching options for a REST based SSO implementation. > =20 > One of the stated motivators for the JWT/JWS/JWE formats is = compactness. And, I want compactness in my HTTP headers. > =20 > It has been pointed out that HTTP load times can be dramatically = effected by relatively small amounts of data in the HTTP headers. = (see:http://mike.bailey.net.au/2010/07/tcp-and-the-lower-bound-of-web-perf= ormance/ ) > =20 > Would it be possible to add DEFLATE compression for the JWT payload = into the JWT/JWS/JWE specs? > =20 > My suggestion here has 2 parts, each can be considered separately: > 1. Add the option to apply DEFLATE compression (omitting the ZLIB = header and checksum fields) on the payload before encryption/signing. = (It is important to apply the compression before the encryption, since = an encrypted payload will contain a bunch of pseudo-random noise that = isn=92t easily compressed.) This feature should be accompanied by a JWT = header option to toggle compression on/off. (Maybe something like =93dfl=94= : true/false) > 2. Make the DEFLATE compressed payload the default behavior only = requiring the JWT header option for disabling compression. > =20 > I have tested it and found that: > With small payloads containing only keys and values having minimal = substring overlap it is possible for the DEFLATE compression to produce = equivalent or larger output. > But I have also found that: > Payloads including keys or values with any repeated name-space parts = easily achieve payload size reduction. > =20 > I believe that in common use cases compression will achieve payload = size reduction, since repeated name-space parts are likely to occur: > 1. A number of the =93reserved claim names=94 type keys expect = content of type =93StringOrURI=94 which are likely to have repeated = name-space parts. > 2. The specs support the =93public claim names=94 type key = extensions which will also most likely share common base URI name-space = parts. > =20 > Another benefit is that DEFLATE compression on the payload should = encourage the use of unique name-spaced identifiers, since DEFLATE = compression removes the payload size penalty otherwise incurred when = repeating a common name-space part over and over again. > =20 > Is this doable? > =20 > Desired? > =20 > What do you think of these ideas? > =20 > Thanks for your consideration, > -Steffen > =20 --Apple-Mail=_02091F8E-3980-454F-81B6-4B184DEEF0B8 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MDkyMTAzMDdaMCMGCSqGSIb3DQEJBDEWBBQvPRcBxwGh+P9mkLTj1Xfqy8hTbjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCGx9S0qBzWgd+1B/fqcZD7MaaW8JMy/FkoYdyW8xSS/2NaSRyJOl5JFaVOkwXrqN7ePMXqvp33 A5UpykvrPtNLi3zvQswzjwjKzddKJ6uxoFt2NKme1IIVmOKvOval0rSHAQDXx8Rt6Qh5BYGlcVBA a8KUuPwEjRdfdNZjA3UMUAPvjT8RbGANWfrUPKFOXGDe7hb6ZZlw1g9ZdDSJkcjLKx6gI49bJ/Wv BWhpCAXNDdDVP9pZ6z3SkBsmnM1gHaW6rGh3Y42Ct4lMNXi3tT2rBdOgEX8/PlHStUzz4+u/vwlM TlimpN5S/JTDaK/TctyS8QgJOgLw/SXkpGZvXOYaAAAAAAAA --Apple-Mail=_02091F8E-3980-454F-81B6-4B184DEEF0B8-- From Michael.Jones@microsoft.com Fri Feb 10 13:31:30 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44ABD21F8748 for ; Fri, 10 Feb 2012 13:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVezOaG451sg for ; Fri, 10 Feb 2012 13:31:22 -0800 (PST) Received: from AM1EHSOBE001.bigfish.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id D574621F875D for ; Fri, 10 Feb 2012 13:31:21 -0800 (PST) Received: from mail19-am1-R.bigfish.com (10.3.201.248) by AM1EHSOBE001.bigfish.com (10.3.204.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Feb 2012 21:31:20 +0000 Received: from mail19-am1 (localhost [127.0.0.1]) by mail19-am1-R.bigfish.com (Postfix) with ESMTP id 676D08062D for ; Fri, 10 Feb 2012 21:31:20 +0000 (UTC) X-SpamScore: -19 X-BigFish: VS-19(zzc85fhzz1202hzz1033IL8275eh8275bh8275dha1495iz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail19-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC106.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail19-am1 (localhost.localdomain [127.0.0.1]) by mail19-am1 (MessageSwitch) id 1328909478985608_4607; Fri, 10 Feb 2012 21:31:18 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.235]) by mail19-am1.bigfish.com (Postfix) with ESMTP id ECFDB4C0045 for ; Fri, 10 Feb 2012 21:31:18 +0000 (UTC) Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Feb 2012 21:31:18 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0247.005; Fri, 10 Feb 2012 13:31:11 -0800 From: Mike Jones To: "jose@ietf.org" Thread-Topic: Discussion of open issues in JOSE drafts Thread-Index: AczoO0YE4vGS3UblSUWSpCkmMaMKUA== Date: Fri, 10 Feb 2012 21:31:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436639FBD8@TK5EX14MBXC284.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436639FBD8TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [jose] Discussion of open issues in JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:31:30 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436639FBD8TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear JOSE members, As most of you have probably already seen, I put a section calling out open= issues in each of the JOSE documents. I'd like explicitly bring them to y= our attention to ensure they get discussed on by the working group before o= ur upcoming meeting in Paris. For those issues that we can close before th= en, I'd also like to include the resolutions to any resolved issues in upda= ted drafts to be published before the March 3rd Internet Draft submission c= ut-off date. I'll list the open issues in the drafts below and in some cases, propose re= solutions to get the discussions going. When proposing resolutions, to be = clear, I'm writing as an individual working group participant - not as the = editor. Hopefully we can close many of these open issues in the next few w= eeks. If you want to start discussion on a particular issue, it would prob= ably be good to create an e-mail thread with a descriptive subject line for= that issue to help people manage their participation in the discussion. Hopefully we can reach consensus on many/most of these in the next few week= s. Best wishes= , -- Mike >From http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00#secti= on-9: * Clarify the optional ability to provide type information in the J= WS header. Specifically, clarify the intended use of the typ Header Paramet= er, whether it conveys syntax or semantics, and indeed, whether this is the= right approach. Also clarify the relationship between these type values an= d MIME [RFC2045] types. I believe that the meaning of the typ parameter is going to be context-depe= ndent in the general case, similarly to how the meanings of the issuer, aud= ience, and principal claims are in in the JWT spec. Given that the typ parameter is the onl= y context-dependent parameter in the spec at present, one possible resoluti= on is to remove it from the signature spec entirely and leave the definitio= n of it up to usage profiles for particular contexts. In particular, there= 's no reason that it couldn't be defined in the JWT spec, rather than JWS. = Would people be happier with that resolution or would they prefer that typ= remain as-is? * Clarify the semantics of the kid (key ID) header parameter. Open = issues include: What happens if a kid header is received with an unrecogniz= ed value? Is that an error? Should it be treated as if it's empty? What hap= pens if the header has a recognized value but the value doesn't match the k= ey associated with that value, but it does match another key that is associ= ated with the issuer? Is that an error? I believe that the key ID should definitely not be ignored or treated as em= pty in this case, as that may introduce security issues. If provided, I be= lieve that a key matching the key ID MUST be used, and if not found, this i= s an error, just like any other reason for being unable to locate the corre= ct key would be. * Consider whether a key type parameter should also be introduced. I'm open to this possibility, but would like to understand a compelling sce= nario that requires this functionality first. If someone wants this, I'd a= sk that they point the WG to an existing crypto spec with this functionalit= y and let the WG know how the functionality you're requesting should be lik= e and/or different than that. If this isn't requested by participants with= a compelling motivating scenario, I propose to delete this open issue from= the next version of the spec. * Add Security Considerations text on timing attacks. Write text saying how the time taken for crypto operations should be invari= ant to whether they succeed or fail, to thwart timing attacks to guess keys= . If someone can provide with me a reference we should use about timing at= tacks in the spec, that would be great. * It would be good to have a confirmation method element so it coul= d be used with holder-of-key. I'd welcome a specific proposal for this functionality. Again, if it can b= e based on an existing successful method of achieving this, that would be b= est, as it would be good to invent as little as possible. * Consider whether to add parameters for directly including keys in= the header, either as JWK Key Objects, or X.509 cert values, or both. I suspect this will be required by some use cases. Any disagreement or dis= cussion? * Consider whether to add version numbers. I believe these should be added by a later version of the spec, if ever nee= ded. Hopefully any revisions will not change the meaning of existing param= eters but will only add new ones, effectively "versioning" the usage dynami= cally. If you understand all the parameters in the new version, you're goo= d. If you don't, a version number wouldn't have helped you anyway. Unless= the discussion goes differently, I propose to delete this open issue. * Think about how to best describe the concept currently described = as "the bytes of the UTF-8 representation of". Possible terms to use instea= d of "bytes of" include "byte sequence", "octet series", and "octet sequenc= e". Also consider whether we want to add an overall clarifying statement so= mewhere in each spec something like "every place we say 'the UTF-8 represen= tation of X', we mean 'the bytes of the UTF-8 representation of X'". That w= ould potentially allow us to omit the "the bytes of" part everywhere else. This one is purely editorial. Any preferences from the WG? * Finish the Security Considerations section. Volunteers welcome! :) Proposed text for specific issues would be apprecia= ted. * Add an example in which the payload is not a base64url encoded JS= ON object. Editorial. I plan to do this. >From http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#sect= ion-12: * Describe the relationship between the JWE, JWS, and JWT header pa= rameters. In particular, point out that the set of "alg" values defined by = each must be compatible and non-overlapping. Editorial. I plan to do this. This probably needs to be mentioned in both= the JWE and JWS specs, and certainly in the JWA spec. * Consider whether we want to define composite integrity/encryption= operations (as was the consensus to do at IIW, as documented at http://sel= f-issued.info/?p=3D378). This would provide both confidentiality and integr= ity. I believe there's consensus to add this capability to the JWE spec. * Consider whether reusing the JWS jku, kid, x5u, and x5t parameter= s is the right thing to do, particularly as it effectively precludes specif= ying composite operations. This question will need to be addressed when specifying the composite opera= tions. The choices seem to be to use different parameter names or to use t= he same parameter names but put them inside a separate JSON object within t= he header. Opinions? * Consider whether to add parameters for directly including keys in= the header, either as JWK Key Objects, or X.509 cert values, or both. As for JWS, I suspect this will be required by some use cases. Any disagre= ement or discussion? * Consider whether to add version numbers. As with JWS, I believe that this would not aid interoperability in practice= . Unless the WG disagrees, I propose to delete this open issue. * Consider which of the open issues from the JWS and JWT specs also= apply here. Having just reviewed them, the only one that seems that it may apply is a d= ecision on whether to create a JSON serialization whose final representatio= n is JSON (probably in separate specifications) in addition to the current = compact serializations, whose representation is base64url encoded data stru= ctures. One problem with the JSON serialization is the possible need for c= anonicalization algorithms. (Bear in mind that not needing canonicalizatio= n is one of the major advantages of the present specs over the correspondin= g XML ones.) I don't think, however that the outcome of this decision will= affect the current specs either way. * Think about how to best describe the concept currently described = as "the bytes of the UTF-8 representation of". Possible terms to use instea= d of "bytes of" include "byte sequence", "octet series", and "octet sequenc= e". Also consider whether we want to add an overall clarifying statement so= mewhere in each spec something like "every place we say 'the UTF-8 represen= tation of X', we mean 'the bytes of the UTF-8 representation of X'". That w= ould potentially allow us to omit the "the bytes of" part everywhere else. Same editorial question as for JWS. Suggestions? * Finish the Security Considerations section. Volunteers? Proposed text for specific issues would be appreciated. * Write a note in the Security Considerations section about how x5t= (x.509 certificate thumbprint) should be deprecated because of known probl= ems with SHA-1. This should be done, along with text describing that SHA-1 cert thumbprints= are existing practice. A related open issue is whether (and if so, how) t= o enable thumbprints using other algorithms. * Should StringOrURI use IRIs rather than RFC 3986 URIs? Opinions? Is this a standing IETF requirement now, or is this being handle= d on case-by-case basis as makes sense in context? * Provide a more robust description of the use of the IV. The curre= nt statement "For GCM, the random 64-bit IV is prepended to the ciphertext"= in the Symmetric Encryption section is almost certainly out of place. I'd welcome any of the experts who are WG members weighing in with proposed= text here. >From http://tools.ietf.org/html/draft-ietf-jose-json-web-key-00#section-8: * Write the Security Considerations section. Volunteers? Proposed text for specific issues would be appreciated. >From http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#sect= ion-7: * Since RFC 3447 Section 8 explicitly calls for people NOT to adopt RSA= SSA-PKCS1 for new applications and instead requests that people transition = to RSASSA-PSS, we probably need some Security Considerations text explainin= g why RSASSA-PKCS1 is being used (it's what's commonly implemented) and wha= t the potential consequences are. Volunteers? Specific proposed text would be appreciated. * Consider having an algorithm that is a MAC using SHA-256 that provide= s content integrity but for which there is no associated secret. This would= be like the JWT "alg":"none", in that no validation of the authenticity co= ntent is performed but a checksum is provided. I propose to delete this open issue unless a compelling scenario motivating= this functionality is described and endorsed by the working group. * Consider whether to define "alg":"none" here, rather than in the JWT = spec. This would seem to make sense, as other application contexts may also want = this capability. Any disagreement? * Should we define the use of RFC 5649 key wrapping functions, which al= low arbitrary key sizes, in addition to the current use of RFC 3394 key wra= pping functions, which require that keys be multiples of 64 bits? Is this n= eeded in practice? In the interest of simplify, I propose that we only do this if specific mot= ivating scenarios are described and endorsed by the WG. * Decide whether to move the JWK algorithm family definitions "EC" and = "RSA" here. This would likely result in all the family-specific parameter d= efinitions also moving here ("crv", "x", "y", "mod", "exp"), leaving very l= ittle normative text in the JWK spec itself. This seems like it would reduc= e spec readability and so was not done. After discussion, unless the WG disagrees, I propose to delete this open is= sue. * It would be good to say somewhere, in normative language, that eventu= ally the algorithms and/or key sizes currently specified will no longer be = considered sufficiently secure and will be removed. Therefore, implementers= MUST be prepared for this eventuality. Agreed. I'll plan on doing this. * Write the Security Considerations section. Volunteers? Proposed text for specific issues would be appreciated. --_000_4E1F6AAD24975D4BA5B16804296739436639FBD8TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear JOSE members,

 

As most of you have probably already seen, I put a s= ection calling out open issues in each of the JOSE documents.  I’= ;d like explicitly bring them to your attention to ensure they get discusse= d on by the working group before our upcoming meeting in Paris.  For those issues that we can close before then, I&= #8217;d also like to include the resolutions to any resolved issues in upda= ted drafts to be published before the March 3rd Internet Draft s= ubmission cut-off date.

 

I’ll list the open issues in the drafts below = and in some cases, propose resolutions to get the discussions going.  = When proposing resolutions, to be clear, I’m writing as an individual= working group participant – not as the editor.  Hopefully we can close many of these open issues in the next few weeks.  If you= want to start discussion on a particular issue, it would probably be good = to create an e-mail thread with a descriptive subject line for that issue t= o help people manage their participation in the discussion.

 

Hopefully we can reach consensus on many/most of the= se in the next few weeks.

 

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Best wishes,

        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     -- Mike

 

From http://tools.ietf.org/html/draft-ietf-jose-json-web-signature-00#section-9<= /a>:

 

·     &= nbsp;   Clarify= the optional ability to provide type information in the JWS header. Specif= ically, clarify the intended use of the typ Header Parameter, whether it conveys syntax or semantics, and indeed= , whether this is the right approach. Also clarify the relationship between these type values and MIME [RFC2045] types.

I believe th= at the meaning of the typ parameter is going to be context-dependent in the general case, s= imilarly to how the meanings of the issuer, audience, and principal claims are in in the JWT spec.  Given that the typ<= /tt> parameter is the only context-= dependent parameter in the spec at present, one possible resolution is to remove it from the signature spec entirely and leave the definition = of it up to usage profiles for particular contexts.  In particular, th= ere’s no reason that it couldn’t be defined in the JWT spec, ra= ther than JWS.  Would people be happier with that resolution or would they prefer that typ remain as-is?

 <= /o:p>

·     &= nbsp;   Clarify= the semantics of the kid (key ID) header parameter. Open issues include: What happens if a kid header is received with an unrecognized value? Is that an error? Sho= uld it be treated as if it's empty? What happens if the header has a recognized value but the value doesn't match the key associated with= that value, but it does match another key that is associated with the issu= er? Is that an error?

I believe th= at the key ID should definitely not be ignored or treated as empty in this = case, as that may introduce security issues.  If provided, I believe that a key matching the key ID MUST be used, and if not found, t= his is an error, just like any other reason for being unable to locate the = correct key would be.

 <= /o:p>

·     &= nbsp;   Conside= r whether a key type parameter should also be introduced.

I’m op= en to this possibility, but would like to understand a compelling scenario = that requires this functionality first.  If someone wants this, I’d ask that they point the WG to an existing crypto spec with this = functionality and let the WG know how the functionality you’re reques= ting should be like and/or different than that.  If this isn’t r= equested by participants with a compelling motivating scenario, I propose to delete this open issue from the next version of the spec.

 <= /o:p>

·     &= nbsp;   Add Sec= urity Considerations text on timing attacks.

Write text s= aying how the time taken for crypto operations should be invariant to wheth= er they succeed or fail, to thwart timing attacks to guess keys.  If someone can provide with me a reference we should use about= timing attacks in the spec, that would be great.

 <= /o:p>

·     &= nbsp;   It woul= d be good to have a confirmation method element so it could be used with ho= lder-of-key.

I’d we= lcome a specific proposal for this functionality.  Again, if it can be= based on an existing successful method of achieving this, that would be best, as it would be good to invent as little as possible.

 <= /o:p>

·     &= nbsp;   Conside= r whether to add parameters for directly including keys in the header, eith= er as JWK Key Objects, or X.509 cert values, or both.

I suspect th= is will be required by some use cases.  Any disagreement or discussion= ?

 <= /o:p>

·     &= nbsp;   Conside= r whether to add version numbers.

I believe th= ese should be added by a later version of the spec, if ever needed.  H= opefully any revisions will not change the meaning of existing parameters but will only add new ones, effectively “versioning”= ; the usage dynamically.  If you understand all the parameters in the = new version, you’re good.  If you don’t, a version number = wouldn’t have helped you anyway.  Unless the discussion goes dif= ferently, I propose to delete this open issue.

 <= /o:p>

·     &= nbsp;   Think a= bout how to best describe the concept currently described as "the byte= s of the UTF-8 representation of". Possible terms to use instead of "bytes of" include "byte sequence", "octet ser= ies", and "octet sequence". Also consider whether we want to= add an overall clarifying statement somewhere in each spec something like = "every place we say 'the UTF-8 representation of X', we mean 'the byte= s of the UTF-8 representation of X'". That would potentially allow us t= o omit the "the bytes of" part everywhere else.

This one is = purely editorial.  Any preferences from the WG?

 <= /o:p>

·     &= nbsp;   Finish = the Security Considerations section.

Volunteers w= elcome! J  Proposed = text for specific issues would be appreciated.

 <= /o:p>

·     &= nbsp;   Add an = example in which the payload is not a base64url encoded JSON object.

Editorial.&n= bsp; I plan to do this.

 

From http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#section-1= 2:

 

·     &= nbsp;   Describ= e the relationship between the JWE, JWS, and JWT header parameters. In part= icular, point out that the set of "alg" values defined by each must be compatible and non-overlapping.

Editorial.&n= bsp; I plan to do this.  This probably needs to be mentioned in both t= he JWE and JWS specs, and certainly in the JWA spec.

 <= /o:p>

·     &= nbsp;   Conside= r whether we want to define composite integrity/encryption operations (as w= as the consensus to do at IIW, as documented at http://self-issued.info/?p= =3D378). This would provide both confidentiality and integrity. <= /p>

I believe th= ere’s consensus to add this capability to the JWE spec.

 <= /o:p>

·     &= nbsp;   Conside= r whether reusing the JWS jku, kid, x5u, and x5t parameters is the right thing to do, particularly as it = effectively precludes specifying composite operations.

This questio= n will need to be addressed when specifying the composite operations. = The choices seem to be to use different parameter names or to use the same parameter names but put them inside a separate JSON object wi= thin the header.  Opinions?

 <= /o:p>

·     &= nbsp;   Conside= r whether to add parameters for directly including keys in the header, eith= er as JWK Key Objects, or X.509 cert values, or both.

As for JWS, = I suspect this will be required by some use cases.  Any disagreement o= r discussion?

 <= /o:p>

·     &= nbsp;   Conside= r whether to add version numbers.

As with JWS,= I believe that this would not aid interoperability in practice.  Unle= ss the WG disagrees, I propose to delete this open issue.=

 <= /o:p>

·     &= nbsp;   Conside= r which of the open issues from the JWS and JWT specs also apply here.

Having just = reviewed them, the only one that seems that it may apply is a decision on w= hether to create a JSON serialization whose final representation is JSON (probably in separate specifications) in addition to the current c= ompact serializations, whose representation is base64url encoded data struc= tures.  One problem with the JSON serialization is the possible need f= or canonicalization algorithms.  (Bear in mind that not needing canonicalization is one of the major advantages o= f the present specs over the corresponding XML ones.)  I don’t t= hink, however that the outcome of this decision will affect the current spe= cs either way.

 <= /o:p>

·     &= nbsp;   Think a= bout how to best describe the concept currently described as "the byte= s of the UTF-8 representation of". Possible terms to use instead of "bytes of" include "byte sequence", "octet ser= ies", and "octet sequence". Also consider whether we want to= add an overall clarifying statement somewhere in each spec something like = "every place we say 'the UTF-8 representation of X', we mean 'the byte= s of the UTF-8 representation of X'". That would potentially allow us t= o omit the "the bytes of" part everywhere else.

Same editori= al question as for JWS.  Suggestions?

 <= /o:p>

·     &= nbsp;   Finish = the Security Considerations section.

Volunteers?&= nbsp; Proposed text for specific issues would be appreciated.

 <= /o:p>

·     &= nbsp;   Write a= note in the Security Considerations section about how x5t (x.509 certificate thumbprint) should be deprecated beca= use of known problems with SHA-1.

This should = be done, along with text describing that SHA-1 cert thumbprints are existin= g practice.  A related open issue is whether (and if so, how) to enable thumbprints using other algorithms.

 <= /o:p>

·     &= nbsp;   Should = StringOrURI use IRIs rather than RFC 3986 URIs?

Opinions?&nb= sp; Is this a standing IETF requirement now, or is this being handled on ca= se-by-case basis as makes sense in context?

 <= /o:p>

·     &= nbsp;   Provide= a more robust description of the use of the IV. The current statement &quo= t;For GCM, the random 64-bit IV is prepended to the ciphertext" in the Symmetric Encryption section is almost certainly out of place.

I’d we= lcome any of the experts who are WG members weighing in with proposed text = here.

 <= /o:p>

From http://tools.ietf.org/html/draft-ietf-jose-json-web-key-00#section-8:

 

  • Write the Security Considerations section.

Volunteers?&= nbsp; Proposed text for specific issues would be appreciated.

 <= /o:p>

From http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#section-7= :

 

  • Since RFC 3447 Section 8 explicitly calls for people NO= T to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, we probably need some Security Consi= derations text explaining why RSASSA-PKCS1 is being used (it's what's commo= nly implemented) and what the potential consequences are.

Volunteers?&= nbsp; Specific proposed text would be appreciated.

 <= /o:p>

  • Consider having an algorithm that is a MAC using SHA-25= 6 that provides content integrity but for which there is no associated secret. This would be like the JWT "alg":"none&q= uot;, in that no validation of the authenticity content is performed but a = checksum is provided.

I propose to= delete this open issue unless a compelling scenario motivating this functi= onality is described and endorsed by the working group.

 <= /o:p>

  • Consider whether to define "alg":"none&q= uot; here, rather than in the JWT spec.

This would s= eem to make sense, as other application contexts may also want this capabil= ity.  Any disagreement?

 <= /o:p>

  • Should we define the use of RFC 5649 key wrapping funct= ions, which allow arbitrary key sizes, in addition to the current use of RFC 3394 key wrapping functions, which require that keys be multipl= es of 64 bits? Is this needed in practice?

In the inter= est of simplify, I propose that we only do this if specific motivating scen= arios are described and endorsed by the WG.

 <= /o:p>

  • Decide whether to move the JWK algorithm family definit= ions "EC" and "RSA" here. This would likely result in a= ll the family-specific parameter definitions also moving here ("crv", &= quot;x", "y", "mod", "exp"), leaving ver= y little normative text in the JWK spec itself. This seems like it would re= duce spec readability and so was not done.

After discus= sion, unless the WG disagrees, I propose to delete this open issue.

 <= /o:p>

  • It would be good to say somewhere, in normative languag= e, that eventually the algorithms and/or key sizes currently specified will no longer be considered sufficiently secure and will be rem= oved. Therefore, implementers MUST be prepared for this eventuality.

Agreed. = ; I’ll plan on doing this.

 <= /o:p>

  • Write the Security Considerations section.

Volunteers?&= nbsp; Proposed text for specific issues would be appreciated.

 <= /o:p>

--_000_4E1F6AAD24975D4BA5B16804296739436639FBD8TK5EX14MBXC284r_-- From ve7jtb@ve7jtb.com Fri Feb 10 13:45:52 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8DC21F85FD for ; Fri, 10 Feb 2012 13:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.54 X-Spam-Level: X-Spam-Status: No, score=-3.54 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjlrEAXuqPKj for ; Fri, 10 Feb 2012 13:45:50 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 20FD621F85FC for ; Fri, 10 Feb 2012 13:45:50 -0800 (PST) Received: by ghbg16 with SMTP id g16so2017426ghb.31 for ; Fri, 10 Feb 2012 13:45:49 -0800 (PST) Received: by 10.101.21.2 with SMTP id y2mr3537393ani.11.1328910349668; Fri, 10 Feb 2012 13:45:49 -0800 (PST) Received: from [192.168.1.213] ([190.22.43.148]) by mx.google.com with ESMTPS id n72sm11586905yhh.21.2012.02.10.13.45.42 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 10 Feb 2012 13:45:48 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_A0801C87-5DA6-4C05-A265-813FBC3C677A"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <397B382EC2E6D9479F9A5D6D050FB707033BFF@WO-SFOEXCH-02.wideorbit.com> Date: Fri, 10 Feb 2012 18:45:38 -0300 Message-Id: <2ED0B3DE-CB1C-4C2E-8A66-0FD6B359368D@ve7jtb.com> References: <397B382EC2E6D9479F9A5D6D050FB707033ABB@WO-SFOEXCH-02.wideorbit.com> <25CABF36-27D0-4DDB-8644-58EBFEDFC4EC@ve7jtb.com> <397B382EC2E6D9479F9A5D6D050FB707033BFF@WO-SFOEXCH-02.wideorbit.com> To: Steffen Yount X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQngIdhr1enKn1ukVc/DGLNOBYxb4fHL6NtVHpYdOR47ZntIlOmIYJedQyVT2QVqyqM3fv1e X-Mailman-Approved-At: Fri, 10 Feb 2012 13:55:30 -0800 Cc: Eric Rescorla , Dirk Balfanz , "jose@ietf.org" , John Panzer , Brian Campbell , "Yaron Y. Goland" , "Michael B. Jones" , Joe Hildebrand , Paul Tarjan , Nat Sakimura , Chuck Mortimore Subject: Re: [jose] Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 21:45:52 -0000 --Apple-Mail=_A0801C87-5DA6-4C05-A265-813FBC3C677A Content-Type: multipart/alternative; boundary="Apple-Mail=_35113224-9D41-4DF7-8DB3-14B4C402D75B" --Apple-Mail=_35113224-9D41-4DF7-8DB3-14B4C402D75B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The reason I had for originally proposing LZ77 with 32 bitCRC was to = provide an integrity check against tampering when using AES-CBC = encryption. If we make encryption with integrity the default I don't have any issue = with dropping the internal CRC. I can see your point about compressing signed tokens in the header being = easier if it is directly supported by the spec. I would not be opposed to that change if there is consensus in the WG to = make it. John B. On 2012-02-09, at 11:32 PM, Steffen Yount wrote: > Hi John, > =20 > Thanks for pointing that out, I've located that reserved header = parameter "zip" in the JWE spec. = (http://tools.ietf.org/html/draft-jones-json-web-encryption-02#section-4.1= ) > =20 > Yes, I think this "zip" header should be added for JWS signing as = well. > =20 > My use case: > I'm looking at using JWS as a Bearer token for HTTP Authorization and = encoding multiple "scope" grants into the token. The clients will be = treating the token as opaque data and it is not clear that they will = know if a server supports HTTP compression when their requests are made. = So, I'm expecting that the client's HTTP requests will be submitted = uncompressed. > =20 > Since I can't rely on HTTP level compression, I would like to compress = the payload before it is used in the request. Compression should reduce = my token size considerably, since the multiple scope grants will be = repeating name-space parts. > =20 > Would it be possible to specify a "zip"=3D"DEFLATE" option too for = both JWS and JWE? > =B7 This option should rely only on RFC1951 compression without = a ZLIB header or checksum field. (a.k.a: DEFLATE with the "nowrap" = option) > =B7 The difference is 18 bytes of GZIP wrapper data overhead. > =B7 When dealing with small payloads containing only few = repeating parts, these 18 bytes are likely to leave the compressed = output longer than the input. > =20 > Thanks again, > -Steffen > =20 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 > Sent: Thursday, February 09, 2012 1:03 PM > To: Steffen Yount > Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; = Yaron Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; = Joe Hildebrand; jose@ietf.org > Subject: Re: Would it be possible to add DEFLATE compression for the = JWT payload into the JWT/JWS/JWE specs? > =20 > We do currently have the option of RFC1952 compression of the plain = text before encryption. > Personally I think compression before encryption should be the = default. Others prefer it as a option. > =20 > We didn't add it to signing as there are existing ways to compress = content in http.=20 > =20 > If you think it needs to be added to signing then let us know. > =20 > Regards > John Bradley > =20 > =20 > =20 > On 2012-02-09, at 4:21 PM, Steffen Yount wrote: > =20 > > Hi, > >=20 > > I hope this email reaches someone who can respond. I=92ve included = authors from the various JWT specs. > >=20 > > I was thinking through JSON Web Token (JWT) Bearer Token Profiles = for OAuth 2.0 draft spec = (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-03 ) while = researching options for a REST based SSO implementation. > >=20 > > One of the stated motivators for the JWT/JWS/JWE formats is = compactness. And, I want compactness in my HTTP headers. > >=20 > > It has been pointed out that HTTP load times can be dramatically = effected by relatively small amounts of data in the HTTP headers. = (see:http://mike.bailey.net.au/2010/07/tcp-and-the-lower-bound-of-web-perf= ormance/ ) > >=20 > > Would it be possible to add DEFLATE compression for the JWT payload = into the JWT/JWS/JWE specs? > >=20 > > My suggestion here has 2 parts, each can be considered separately: > > 1. Add the option to apply DEFLATE compression (omitting the = ZLIB header and checksum fields) on the payload before = encryption/signing. (It is important to apply the compression before the = encryption, since an encrypted payload will contain a bunch of = pseudo-random noise that isn=92t easily compressed.) This feature should = be accompanied by a JWT header option to toggle compression on/off. = (Maybe something like =93dfl=94 : true/false) > > 2. Make the DEFLATE compressed payload the default behavior = only requiring the JWT header option for disabling compression. > >=20 > > I have tested it and found that: > > With small payloads containing only keys and values having minimal = substring overlap it is possible for the DEFLATE compression to produce = equivalent or larger output. > > But I have also found that: > > Payloads including keys or values with any repeated name-space parts = easily achieve payload size reduction. > >=20 > > I believe that in common use cases compression will achieve payload = size reduction, since repeated name-space parts are likely to occur: > > 1. A number of the =93reserved claim names=94 type keys expect = content of type =93StringOrURI=94 which are likely to have repeated = name-space parts. > > 2. The specs support the =93public claim names=94 type key = extensions which will also most likely share common base URI name-space = parts. > >=20 > > Another benefit is that DEFLATE compression on the payload should = encourage the use of unique name-spaced identifiers, since DEFLATE = compression removes the payload size penalty otherwise incurred when = repeating a common name-space part over and over again. > >=20 > > Is this doable? > >=20 > > Desired? > >=20 > > What do you think of these ideas? > >=20 > > Thanks for your consideration, > > -Steffen > >=20 --Apple-Mail=_35113224-9D41-4DF7-8DB3-14B4C402D75B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The reason I had for originally proposing LZ77 with = 32 bitCRC was to provide an integrity check against tampering when using = AES-CBC encryption.

If we make encryption with = integrity the default I don't have any issue with dropping the internal = CRC.

I can see your point about compressing = signed tokens in the header being easier if it is directly supported by = the spec.

I would not be opposed to that change = if there is consensus in the WG to make = it.

John = B.


On 2012-02-09, at 11:32 PM, = Steffen Yount wrote:

Hi John,
 
Thanks for pointing that out, = I've located that reserved header parameter "zip" in the JWE spec. ( )
 
We do currently have the option of RFC1952 compression of = the plain text before encryption.
Personally I think compression before encryption should be = the default.  Others prefer it as a option.
 
We didn't add it to signing as = there are existing ways to compress content in = http. 
 
If you think it needs to be added to signing then let us = know.
 
John Bradley
 
 
 
On 2012-02-09, at 4:21 PM, = Steffen Yount wrote:
 
> Hi,
> I hope this email reaches = someone who can respond. I=92ve included authors from the various JWT = specs.
> 
> I was thinking through JSON Web Token (JWT) Bearer = Token Profiles for OAuth 2.0 draft spec ( ) while researching = options for a REST based SSO implementation.

Thread-Topic: [jose] Comments on the -03 JSON Web Signature document Thread-Index: AcydAC1ZyMCYdH1nSHiQnx6fNbxIaRLO7MzA Date: Fri, 10 Feb 2012 22:28:13 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436639FDA8@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <017201cca118$5883ee30$098bca90$@augustcellars.com> In-Reply-To: <017201cca118$5883ee30$098bca90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436639FDA8TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "jose@ietf.org" Subject: Re: [jose] Comments on the -03 JSON Web Signature document X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 22:28:25 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436639FDA8TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This note replies the comments from your note where the resolutions to them= were incomplete or different than you proposed. Per our e-mail exchange, = I won't clutter the discussion by replying to comments whose resolutions ar= e already incorporated into the working group drafts. 1. I have a personal problem with the fact that the draft is still named "= JSON Web Signature" rather than something like "JSON Integrity Objects". I= doubt that I am the only person who has this issue given the number of peo= ple who gave opinions during the charter discussion and the resulting chart= er description "JSON-structured integrity protection to data". This become= s a major re-write of the document internally as well. Per discussion that occurred within the WG after the Taipei meeting on the = list, for the same reasons that the WG uses the term "signature", the spec = continues to use the vernacular term "signature" as the most readable of th= e choices in the title. For instance, see http://www.ietf.org/mail-archive= /web/jose/current/msg00315.html and http://www.ietf.org/mail-archive/web/jo= se/current/msg00309.html. That being said, the terminology within the spec= s has been changed to no longer call both digital signatures and HMACs "sig= natures", and so I believe is now correct throughout. 9. Is "member names" considered to be a normal method to refer to the elements in an object? If so then no objections, if not then I would rationalize the string. I normally see something like name/value pairs so = I don't know where "member" came from. Yes, this is JSON terminology. 13. Section 4.1 - I find the table version to be difficult to read given t= he amount of text in the semantics field. Having this many really short li= nes inhibits readability. I believe the correct solution is to restructure the text by making each ta= ble row its own

so that the identifier names are all indexed. Th= is is on my to-do list as editor. 16. The text states that the key must be associated with the signer of the content. The current document for json keys does not have any way of associating a key with the signer. What does this requirement really mean? It's intended to mean that there must be a way to verify that the content w= as signed by the correct party, using a key controlled by that party. I'd = welcome better language for this concept (possibly lifted from another cryp= to spec?). 18. It would be useful to know if there was going to be any registry for t= he "typ" header. If not, then it would be useful to state that the values = of the "typ" header are based on agreement between the parties. It would a= lso be useful to state the expected behavior in the case the the value of t= he typ field is either unknown, does not match the expected value or is mis= sing. Are values of the "typ" field supposed to have the same type of publ= ic/private values as does algorithm? If not what happens when a collision = exists between two different applications? Per my comments on the open issues listed in the drafts, an argument can be= made for deleting this parameter from the JWS spec entirely and leaving it= s definition up to profile specs like JWT. If this isn't done, then a regi= stry could be considered for names not residing in a collision-resistant na= mespace. 19. 'kid' parameter - I want to write a library to deal with this specific= ation I don't know what to do with the kid parameter. It would be more use= ful if you specified what would go in this value if the jku or x5u fields w= ere used. Why would I not use the kid field rather than the x5t parameter = using the same value? Why is this parameter even defined if one does not k= now how to use it. I agree that we should likely strengthen this description, at least by desc= ribing the relationship between this parameter and the JWK kid parameter. = In that case, the semantics should be well-defined. 20. 'x5u' parameter - I think you want to be able to allow for a bare x509 = certificate w/ no packaging. This is a very common method of having pointe= rs to certificates as well. This would not be pulling a certificate chain = (which would require a CMS degenerate signed data blob) but a single certif= icate. Agreed. If the WG agrees, we should add this. 21. 'x5t' parameter - there may be push back from the security ADs on the I= ESG about the fact that this is not an algorithm agnostic manner of doing t= his. What would the correct way be for using the SHA-256 hash rather than the SHA-1 hash as a thumbprint for the certificate? One way would be to d= o an : pair and saying that the "sha1:" can be omitted. What do people think of this proposal? 23. Having done a much more detailed read. The last para in section 4.2 c= an be expanded as follows: New header parameters should be introduced sparingly, an implementation whi= ch does not understand a newly introduced parameter will fail validate of t= he JWS. However, uses which use the JWS structure but define additional se= mantics, such as the JSON Web Token usage, are expected to define additiona= l public header parameters. The first concept (must-understand of header parameters) is already in the = second sentence of the description of header parameters (in Section 4). I = could however, add the sentence "However, it is expected that some addition= al header parameters will be defined by specific profiles and specification= s using this specification" to cover the second point, if that works for yo= u. 24. Why MUST I do the following steps (since to me this implies an order o= f operations). Is there a reason that I cannot do things in the order of 3= , 4, 5, 1, 2, 6, 7? Reordered and partially rewrote to be more logical. Please review. 28. It would be good at this point to say if the normal methods of looking= up an field name are going to work according to the text you have outlined= . i.e. should one expect that aobj.alg is going to return the right answer? This statement seems to me to be too implementation-specific (are you think= ing of JavaScript, Ruby, Perl, Python, ... syntax?). That being said, I be= lieve that the "standard" methods should work in most/all programming envir= onments with JSON support, but this certainly can't be a normative statemen= t. 31. Section 6.1 - is there a reason to compare the values as base64url enc= oded rather than in the native binary values? Either could be done. I'll put making this text more general in this manne= r on my to-do list for the next revision of the JWA spec. (This text now l= ives in 3.1 there.) 21, Section 6.1 - The last para states that there is a correspondingly long= er key and result. While the result is going to be longer, there is no req= uirement that the key be longer unless you are going to make a statement to= that effect. One could use a 512 bit key for all of the algorithms. I believe that this statement is true for the HS256, HS384, and HS512 algor= ithms, but I agree that it's not particularly enabling. I'll put describin= g the expected key sizes for all the algorithms on my to-do list. 24. Section 8.1 - can JSON names include strings outside of the Basic Multl= ingual plane? Yes. The text below is from the JSON spec (RFC 4627): To escape an extended character that is not in the Basic Multilingual Plane, the character is represented as a twelve-character sequence, encoding the UTF-16 surrogate pair. So, for example, a string containing only the G clef character (U+1D11E) may be represented as "\uD834\uDD1E". --_000_4E1F6AAD24975D4BA5B16804296739436639FDA8TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This note replies the = comments from your note where the resolutions to them were incomplete or di= fferent than you proposed.  Per our e-mail exchange, I won’t clu= tter the discussion by replying to comments whose resolutions are already incorporated into the working group drafts.

 

1.  I have a personal problem with the fact = that the draft is still named "JSON Web Signature" rather than so= mething like "JSON Integrity Objects".  I doubt that I am th= e only person who has this issue given the number of people who gave opinions during the charter discussion and the resulting charter desc= ription "JSON-structured integrity protection to data".  Thi= s becomes a major re-write of the document internally as well.

 

Per discussion that oc= curred within the WG after the Taipei meeting on the list, for the same rea= sons that the WG uses the term “signature”, the spec continues = to use the vernacular term “signature” as the most readable of the choices in the title.  For instance, see http://www.ietf.org/mail-archive/web/jose/current/msg00315.html and http://www.ietf.org/mail-archive/web/jose/current/msg00309.html.  = That being said, the terminology within the specs has been changed to no lo= nger call both digital signatures and HMACs "signatures", and so = I believe is now correct throughout.

 

9.  Is "member names" considered t= o be a normal method to refer to the

elements in an object?    If so th= en no objections, if not then I would

rationalize the string.  I normally see some= thing like name/value pairs so I don't know where "member" came f= rom.

 

Yes, this is JSON term= inology.

 

13.  Section 4.1 - I find the table version = to be difficult to read given the amount of text in the semantics field.&nb= sp; Having this many really short lines inhibits readability.

 

I believe the correct = solution is to restructure the text by making each table row its own <se= ction> so that the identifier names are all indexed.  This is on my= to-do list as editor.

 

16.  The text states that the key must be as= sociated with the signer of the

content.   The current document for jso= n keys does not have any way of

associating a key with the signer.  What doe= s this requirement really mean?

 

It’s intended to= mean that there must be a way to verify that the content was signed by the= correct party, using a key controlled by that party.  I’d welco= me better language for this concept (possibly lifted from another crypto spec?).

 

18.  It would be useful to know if there was= going to be any registry for the "typ" header.  If not, the= n it would be useful to state that the values of the "typ" header= are based on agreement between the parties.  It would also be useful to state the expected behavior in the case the the value of the typ field = is either unknown, does not match the expected value or is missing.  A= re values of the "typ" field supposed to have the same type of pu= blic/private values as does algorithm?  If not what happens when a collision exists between two different applications?

 

Per my comments on the= open issues listed in the drafts, an argument can be made for deleting thi= s parameter from the JWS spec entirely and leaving its definition up to pro= file specs like JWT.  If this isn’t done, then a registry could be considered for names not residing in a coll= ision-resistant namespace.

 

19.  'kid' parameter - I want to write a lib= rary to deal with this specification I don't know what to do with the kid p= arameter.  It would be more useful if you specified what would go in t= his value if the jku or x5u fields were used.  Why would I not use the kid field rather than the x5t parameter using the = same value?  Why is this parameter even defined if one does not know h= ow to use it.

 

I agree that we should= likely strengthen this description, at least by describing the relationshi= p between this parameter and the JWK kid parameter.  In that case, the= semantics should be well-defined.

 

20. 'x5u' parameter - I think you want to be able= to allow for a bare x509 certificate w/ no packaging.  This is a very= common method of having pointers to certificates as well.  This would= not be pulling a certificate chain (which would require a CMS degenerate signed data blob) but a single certificate.<= /o:p>

 

Agreed.  If the W= G agrees, we should add this.

 

21. 'x5t' parameter - there may be push back from= the security ADs on the IESG about the fact that this is not an algorithm = agnostic manner of doing this.  What would the correct way be for usin= g the SHA-256 hash rather than

the SHA-1 hash as a thumbprint for the certificat= e?   One way would be to do

an <algorithm>:<value> pair and sayin= g that the "sha1:" can be omitted.

 

What do people think o= f this proposal?

 

23.  Having done a much more detailed read.&= nbsp; The last para in section 4.2 can be expanded as follows:

 

New header parameters should be introduced sparin= gly, an implementation which does not understand a newly introduced paramet= er will fail validate of the JWS.  However, uses which use the JWS str= ucture but define additional semantics, such as the JSON Web Token usage, are expected to define additional public= header parameters.

 

The first concept (mus= t-understand of header parameters) is already in the second sentence of the= description of header parameters (in Section 4).  I could however, ad= d the sentence “However, it is expected that some additional header parameters will be defined by specific profiles and= specifications using this specification” to cover the second point, = if that works for you.

 

24.  Why MUST I do the following steps (sinc= e to me this implies an order of operations).  Is there a reason that = I cannot do things in the order of 3, 4, 5, 1, 2, 6, 7?

 

Reordered and partiall= y rewrote to be more logical.  Please review.

 

28.  It would be good at this point to say i= f the normal methods of looking up an field name are going to work accordin= g to the text you have outlined.

i.e. should one expect that aobj.alg is going to = return the right answer?

 

This statement seems t= o me to be too implementation-specific (are you thinking of JavaScript, Rub= y, Perl, Python, … syntax?).  That being said, I believe that th= e “standard” methods should work in most/all programming environments with JSON support, but this certainly can’t be a normat= ive statement.

 

31.  Section 6.1 - is there a reason to comp= are the values as base64url encoded rather than in the native binary values= ?

 

Either could be done.&= nbsp; I’ll put making this text more general in this manner on my to-= do list for the next revision of the JWA spec.  (This text now lives i= n 3.1 there.)

 

21, Section 6.1 - The last para states that there= is a correspondingly longer key and result.  While the result is goin= g to be longer, there is no requirement that the key be longer unless you a= re going to make a statement to that effect.  One could use a 512 bit key for all of the algorithms.

 

I believe that this st= atement is true for the HS256, HS384, and HS512 algorithms, but I agree that it= ’s not particularly enabling.  I’ll put describing the exp= ected key sizes for all the algorithms on my to-do list.<= /p>

 

24. Section 8.1 - can JSON names include strings = outside of the Basic Multlingual plane?

 

Yes.  The text be= low is from the JSON spec (RFC 4627):

 

   To escape an extended character that is not i= n the Basic Multilingual

   Plane, the character is represented as a twel= ve-character sequence,

   encoding the UTF-16 surrogate pair.  So,= for example, a string

   containing only the G clef character (U+1= D11E) may be represented as

   "\uD834\uDD1E".

 

--_000_4E1F6AAD24975D4BA5B16804296739436639FDA8TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Fri Feb 10 14:39:53 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A0C21F863F for ; Fri, 10 Feb 2012 14:39:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.232 X-Spam-Level: X-Spam-Status: No, score=-5.232 tagged_above=-999 required=5 tests=[AWL=1.366, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaqt3hA6GijL for ; Fri, 10 Feb 2012 14:39:52 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0544B21F862D for ; Fri, 10 Feb 2012 14:39:50 -0800 (PST) Received: from mail50-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Feb 2012 22:39:50 +0000 Received: from mail50-tx2 (localhost [127.0.0.1]) by mail50-tx2-R.bigfish.com (Postfix) with ESMTP id 8BDF0460649; Fri, 10 Feb 2012 22:39:50 +0000 (UTC) X-SpamScore: -5 X-BigFish: VS-5(zzc85fh1444Mzz1202hzz8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail50-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC107.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail50-tx2 (localhost.localdomain [127.0.0.1]) by mail50-tx2 (MessageSwitch) id 1328913588971118_11853; Fri, 10 Feb 2012 22:39:48 +0000 (UTC) Received: from TX2EHSMHS023.bigfish.com (unknown [10.9.14.243]) by mail50-tx2.bigfish.com (Postfix) with ESMTP id E8C2CA004C; Fri, 10 Feb 2012 22:39:48 +0000 (UTC) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS023.bigfish.com (10.9.99.123) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Feb 2012 22:39:47 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0247.005; Fri, 10 Feb 2012 14:39:46 -0800 From: Mike Jones To: Jim Schaad , "jose@ietf.org" , "draft-jones-json-web-encryption@ietf.org" Thread-Topic: [jose] Comments on the JSON Web Encryption document Thread-Index: Acyg0zPto4vE/gwcRJiEJOYEK7bXJBHcEZJA Date: Fri, 10 Feb 2012 22:39:46 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436639FDF1@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <017101cca118$5883ee30$098bca90$@augustcellars.com> In-Reply-To: <017101cca118$5883ee30$098bca90$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436639FDF1TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Comments on the JSON Web Encryption document X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 22:39:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436639FDF1TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Like my previous reply about the JWS spec, this note replies the comments f= rom your note where the resolutions to them were incomplete or different th= an you proposed. It also doesn't reply to comments whose resolutions are a= lready incorporated into the working group drafts. -- Mike 2. The example in section 3 makes me interested in the following question. When I do a ToString on a binary value in JSON, what is the output. Is thi= s going to be better than using the base64 encoding of binary values to get= text values followed by doing the base64 encoding again. The answer to the ToString question is obviously going to be language and e= nvironment specific. Do you mean in JavaScript? C#? Java? Ruby? ... Th= e reason for using base64url is that it has the right semantic properties a= nd is language/environment independent. 3. Given the amount of overlap. Is there a reason for having different IAN= A registries for the encryption and signature header parameter names? I agree that these should probably be combined, especially as the come from= an overlapping parameter space. I'll put this on my to-do list. Any dis= agreement? 4. Is there a reason for not supporting the "zip" header for signature? Interestingly, there's currently a discussion of this very topic on the JOS= E list. (See the thread "Would it be possible to add DEFLATE compression f= or the JWT payload into the JWT/JWS/JWE specs?") It wasn't there thus far = because every mandatory-to-implement feature makes implementations that muc= h harder to do and simplicity is a core goal. That being said, if the WG h= as a clear and compelling need for this that outweighs the complexity downs= ide, it could of course be added. Discussion? --_000_4E1F6AAD24975D4BA5B16804296739436639FDF1TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Like my previous reply= about the JWS spec, this note replies the comments from your note where th= e resolutions to them were incomplete or different than you proposed. = It also doesn’t reply to comments whose resolutions are already incorporated into the working group drafts.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

2. The example in section 3 makes me interested i= n the following question.

When I do a ToString on a binary value in JSON, w= hat is the output.  Is this going to be better than using the base64 e= ncoding of binary values to get text values followed by doing the base64 en= coding again.

 

The answer to the ToSt= ring question is obviously going to be language and environment specific.&n= bsp; Do you mean in JavaScript?  C#?  Java?  Ruby? …&n= bsp; The reason for using base64url is that it has the right semantic properties and is language/environment independent.

 =

3. Given the amount of overlap.  Is there a = reason for having different IANA registries for the encryption and signatur= e header parameter names?

 

I agree that these sho= uld probably be combined, especially as the come from an overlapping parame= ter space.  I’ll put this on my to-do list.   Any disa= greement?

 =

4.  Is there a reason for not supporting the= "zip" header for signature?

 

Interestingly, there&#= 8217;s currently a discussion of this very topic on the JOSE list.  (S= ee the thread “Would it be possible to add DEFLATE compression for th= e JWT payload into the JWT/JWS/JWE specs?”)  It wasn’t there thus far because every mandatory-to-implement feature makes implemen= tations that much harder to do and simplicity is a core goal.  That be= ing said, if the WG has a clear and compelling need for this that outweighs= the complexity downside, it could of course be added.  Discussion?

 

--_000_4E1F6AAD24975D4BA5B16804296739436639FDF1TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Fri Feb 10 14:45:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3436B21F8699 for ; Fri, 10 Feb 2012 14:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.769 X-Spam-Level: X-Spam-Status: No, score=-3.769 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn2nlzALaYba for ; Fri, 10 Feb 2012 14:45:19 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe006.messaging.microsoft.com [213.199.154.144]) by ietfa.amsl.com (Postfix) with ESMTP id BB86121F84EF for ; Fri, 10 Feb 2012 14:45:17 -0800 (PST) Received: from mail23-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 Feb 2012 22:45:16 +0000 Received: from mail23-db3 (localhost [127.0.0.1]) by mail23-db3-R.bigfish.com (Postfix) with ESMTP id 4CD0E600B1; Fri, 10 Feb 2012 22:45:16 +0000 (UTC) X-SpamScore: -56 X-BigFish: VS-56(zz9371I936eKc85fh148cM1444M542M1dbaL1432N98dK111aLzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail23-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail23-db3 (localhost.localdomain [127.0.0.1]) by mail23-db3 (MessageSwitch) id 1328913914748210_4646; Fri, 10 Feb 2012 22:45:14 +0000 (UTC) Received: from DB3EHSMHS015.bigfish.com (unknown [10.3.81.237]) by mail23-db3.bigfish.com (Postfix) with ESMTP id B0774C0045; Fri, 10 Feb 2012 22:45:14 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS015.bigfish.com (10.3.87.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 Feb 2012 22:45:14 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0247.005; Fri, 10 Feb 2012 14:45:06 -0800 From: Mike Jones To: John Bradley , Steffen Yount Thread-Topic: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? Thread-Index: AQHM525CysEwrlAIgUatL5gULAQISJY1770AgAFCKQD//4oZkA== Date: Fri, 10 Feb 2012 22:45:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436639FEB9@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <397B382EC2E6D9479F9A5D6D050FB707033ABB@WO-SFOEXCH-02.wideorbit.com> <25CABF36-27D0-4DDB-8644-58EBFEDFC4EC@ve7jtb.com> <397B382EC2E6D9479F9A5D6D050FB707033BFF@WO-SFOEXCH-02.wideorbit.com> <2ED0B3DE-CB1C-4C2E-8A66-0FD6B359368D@ve7jtb.com> In-Reply-To: <2ED0B3DE-CB1C-4C2E-8A66-0FD6B359368D@ve7jtb.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436639FEB9TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Fri, 10 Feb 2012 15:00:32 -0800 Cc: Eric Rescorla , Dirk Balfanz , "jose@ietf.org" , John Panzer , Brian Campbell , Yaron Goland , Joe Hildebrand , Paul Tarjan , Nat Sakimura , Chuck Mortimore Subject: Re: [jose] Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 22:45:23 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436639FEB9TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Compression isn't specified in JWS thus far because every mandatory-to-impl= ement feature makes implementations that much harder to do and simplicity i= s a core goal. That being said, if the WG has a clear and compelling need = for this that outweighs the complexity downside, it could of course be adde= d. Discussion? -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Friday, February 10, 2012 1:46 PM To: Steffen Yount Cc: Mike Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland= ; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jo= se@ietf.org Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? The reason I had for originally proposing LZ77 with 32 bitCRC was to provid= e an integrity check against tampering when using AES-CBC encryption. If we make encryption with integrity the default I don't have any issue wit= h dropping the internal CRC. I can see your point about compressing signed tokens in the header being ea= sier if it is directly supported by the spec. I would not be opposed to that change if there is consensus in the WG to ma= ke it. John B. On 2012-02-09, at 11:32 PM, Steffen Yount wrote: Hi John, Thanks for pointing that out, I've located that reserved header parameter "= zip" in the JWE spec. (http://tools.ietf.org/html/draft-jones-json-web-encr= yption-02#section-4.1 ) Yes, I think this "zip" header should be added for JWS signing as well. My use case: I'm looking at using JWS as a Bearer token for HTTP Authorization and encod= ing multiple "scope" grants into the token. The clients will be treating th= e token as opaque data and it is not clear that they will know if a server = supports HTTP compression when their requests are made. So, I'm expecting t= hat the client's HTTP requests will be submitted uncompressed. Since I can't rely on HTTP level compression, I would like to compress the = payload before it is used in the request. Compression should reduce my toke= n size considerably, since the multiple scope grants will be repeating name= -space parts. Would it be possible to specify a "zip"=3D"DEFLATE" option too for both JWS= and JWE? * This option should rely only on RFC1951 compression without a ZLIB= header or checksum field. (a.k.a: DEFLATE with the "nowrap" option) * The difference is 18 bytes of GZIP wrapper data overhead. * When dealing with small payloads containing only few repeating par= ts, these 18 bytes are likely to leave the compressed output longer than th= e input. Thanks again, -Steffen -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Thursday, February 09, 2012 1:03 PM To: Steffen Yount Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron = Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hilde= brand; jose@ietf.org Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? We do currently have the option of RFC1952 compression of the plain text be= fore encryption. Personally I think compression before encryption should be the default. Ot= hers prefer it as a option. We didn't add it to signing as there are existing ways to compress content = in http. If you think it needs to be added to signing then let us know. Regards John Bradley On 2012-02-09, at 4:21 PM, Steffen Yount wrote: > Hi, > > I hope this email reaches someone who can respond. I've included authors = from the various JWT specs. > > I was thinking through JSON Web Token (JWT) Bearer Token Profiles for OAu= th 2.0 draft spec (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 03 ) while researching options for a REST based SSO implementation. > > One of the stated motivators for the JWT/JWS/JWE formats is compactness. = And, I want compactness in my HTTP headers. > > It has been pointed out that HTTP load times can be dramatically effected= by relatively small amounts of data in the HTTP headers. (see:http://mike.= bailey.net.au/2010/07/tcp-and-the-lower-bound-of-web-performance/ ) > > Would it be possible to add DEFLATE compression for the JWT payload into = the JWT/JWS/JWE specs? > > My suggestion here has 2 parts, each can be considered separately: > 1. Add the option to apply DEFLATE compression (omitting the ZLIB he= ader and checksum fields) on the payload before encryption/signing. (It is = important to apply the compression before the encryption, since an encrypte= d payload will contain a bunch of pseudo-random noise that isn't easily com= pressed.) This feature should be accompanied by a JWT header option to togg= le compression on/off. (Maybe something like "dfl" : true/false) > 2. Make the DEFLATE compressed payload the default behavior only req= uiring the JWT header option for disabling compression. > > I have tested it and found that: > With small payloads containing only keys and values having minimal substr= ing overlap it is possible for the DEFLATE compression to produce equivalen= t or larger output. > But I have also found that: > Payloads including keys or values with any repeated name-space parts easi= ly achieve payload size reduction. > > I believe that in common use cases compression will achieve payload size = reduction, since repeated name-space parts are likely to occur: > 1. A number of the "reserved claim names" type keys expect content o= f type "StringOrURI" which are likely to have repeated name-space parts. > 2. The specs support the "public claim names" type key extensions wh= ich will also most likely share common base URI name-space parts. > > Another benefit is that DEFLATE compression on the payload should encoura= ge the use of unique name-spaced identifiers, since DEFLATE compression rem= oves the payload size penalty otherwise incurred when repeating a common na= me-space part over and over again. > > Is this doable? > > Desired? > > What do you think of these ideas? > > Thanks for your consideration, > -Steffen > --_000_4E1F6AAD24975D4BA5B16804296739436639FEB9TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Compression isn’t s= pecified in JWS thus far because every mandatory-to-implement feature makes= implementations that much harder to do and simplicity is a core goal.  That being said, if the WG has a clear and compelling need for= this that outweighs the complexity downside, it could of course be added.&= nbsp; Discussion?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Friday, February 10, 2012 1:46 PM
To: Steffen Yount
Cc: Mike Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron= Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebr= and; jose@ietf.org
Subject: Re: Would it be possible to add DEFLATE compression for the= JWT payload into the JWT/JWS/JWE specs?

 

The reason I had for originally proposing LZ77 with = 32 bitCRC was to provide an integrity check against tampering when using AE= S-CBC encryption.

 

If we make encryption with integrity the default I d= on't have any issue with dropping the internal CRC.

 

I can see your point about compressing signed tokens= in the header being easier if it is directly supported by the spec.

 

I would not be opposed to that change if there is co= nsensus in the WG to make it.

 

John B.

 

 

On 2012-02-09, at 11:32 PM, Steffen Yount wrote:



Hi John,

 

Thanks for pointing that out, I've loca= ted that reserved header parameter "zip" in the JWE spec. (http://tools.ietf.org/html/draft-jones-json-web-encryption-02#section-= 4.1 )

 

Yes, I think this "zip" heade= r should be added for JWS signing as well.

 

My use case:

I'm looking at using JWS as a Bearer to= ken for HTTP Authorization and encoding multiple "scope" grants i= nto the token. The clients will be treating the token as opaque data and it is not clear that they will know if a server supports HTTP compress= ion when their requests are made. So, I'm expecting that the client's HTTP = requests will be submitted uncompressed.

 

Since I can't rely on HTTP level compre= ssion, I would like to compress the payload before it is used in the reques= t. Compression should reduce my token size considerably, since the multiple scope grants will be repeating name-space parts.

 

Would it be possible to specify a "= ;zip"=3D"DEFLATE" option too for both JWS and JWE?

·        This option should rely only on RFC1951 compression without a ZLIB header or ch= ecksum field. (a.k.a: DEFLATE with the "nowrap" option)

·        The difference is 18 bytes of GZIP wrapper data overhead.

·        When dealing with small payloads containing only few repeating parts, these 18 = bytes are likely to leave the compressed output longer than the input.=

 

Thanks again,

-Steffen

 

-----Original Message-----
From: John Bradley [mailto:ve= 7jtb@ve7jtb.com] 
Sent: Thursday, February 09, 2012 1:03 PM
To: Steffen Yount
Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron = Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hilde= brand; jose@ietf.org
Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs?

 

We do currently have the option of RFC1= 952 compression of the plain text before encryption.

Personally I think compression before e= ncryption should be the default.  Others prefer it as a option.

 

We didn't add it to signing as there ar= e existing ways to compress content in http. 

 

If you think it needs to be added to si= gning then let us know.

 

Regards

John Bradley

 

 

 

On 2012-02-09, at 4:21 PM, Steffen Youn= t wrote:

 

> Hi,

> 

> I hope this email reaches someone = who can respond. I’ve included authors from the various JWT specs.

> 

> I was thinking through JSON Web To= ken (JWT) Bearer Token Profiles for OAuth 2.0 draft spec (http://tools.ietf.org/html/draft-jones-oau= th-jwt-bearer-03 ) while researching options for a REST based SSO implementation.<= /span>

> 

> One of the stated motivators for t= he JWT/JWS/JWE formats is compactness. And, I want compactness in my HTTP h= eaders.

> 

> It has been pointed out that HTTP = load times can be dramatically effected by relatively small amounts of data= in the HTTP headers. (see:http://mike.bailey.net.au/2010/07/tcp-and-the-lo= wer-bound-of-web-performance/ )

> 

> Would it be possible to add DEFLAT= E compression for the JWT payload into the JWT/JWS/JWE specs?

> 

> My suggestion here has 2 parts, ea= ch can be considered separately:

> 1.      A= dd the option to apply DEFLATE compression (omitting the ZLIB header and ch= ecksum fields) on the payload before encryption/signing. (It is important t= o apply the compression before the encryption, since an encrypted payload will contain= a bunch of pseudo-random noise that isn’t easily compressed.) This f= eature should be accompanied by a JWT header option to toggle compression o= n/off. (Maybe something like “dfl” : true/false)

> 2.      M= ake the DEFLATE compressed payload the default behavior only requiring the = JWT header option for disabling compression.

> 

> I have tested it and found that:

> With small payloads containing onl= y keys and values having minimal substring overlap it is possible for the D= EFLATE compression to produce equivalent or larger output.

> But I have also found that:

> Payloads including keys or values = with any repeated name-space parts easily achieve payload size reduction.

> 

> I believe that in common use cases= compression will achieve payload size reduction, since repeated name-space= parts are likely to occur:

> 1.      A= number of the “reserved claim names” type keys expect content = of type “StringOrURI” which are likely to have repeated name-sp= ace parts.

> 2.      T= he specs support the “public claim names” type key extensions w= hich will also most likely share common base URI name-space parts.

> 

> Another benefit is that DEFLATE co= mpression on the payload should encourage the use of unique name-spaced ide= ntifiers, since DEFLATE compression removes the payload size penalty otherwise incurred when repeating a common name-space part over an= d over again.

> 

> Is this doable?<= /p>

> 

> Desired?

> 

> What do you think of these ideas?<= o:p>

> 

> Thanks for your consideration,

> -Steffen

> 

 

--_000_4E1F6AAD24975D4BA5B16804296739436639FEB9TK5EX14MBXC284r_-- From Michael.Jones@microsoft.com Fri Feb 10 16:05:55 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F291D21F8699 for ; Fri, 10 Feb 2012 16:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.764 X-Spam-Level: X-Spam-Status: No, score=-3.764 tagged_above=-999 required=5 tests=[AWL=-0.166, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGs5aZztuTxK for ; Fri, 10 Feb 2012 16:05:49 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 8373821F8608 for ; Fri, 10 Feb 2012 16:05:49 -0800 (PST) Received: from mail103-ch1-R.bigfish.com (10.43.68.237) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Sat, 11 Feb 2012 00:05:48 +0000 Received: from mail103-ch1 (localhost [127.0.0.1]) by mail103-ch1-R.bigfish.com (Postfix) with ESMTP id 39E5F4C00F7; Sat, 11 Feb 2012 00:05:48 +0000 (UTC) X-SpamScore: -3 X-BigFish: VS-3(zzc85fh111aLzz1202hzz8275eh8275bh8275dha1495iz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail103-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail103-ch1 (localhost.localdomain [127.0.0.1]) by mail103-ch1 (MessageSwitch) id 1328918746936720_9810; Sat, 11 Feb 2012 00:05:46 +0000 (UTC) Received: from CH1EHSMHS020.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail103-ch1.bigfish.com (Postfix) with ESMTP id E0E27140046; Sat, 11 Feb 2012 00:05:46 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS020.bigfish.com (10.43.70.20) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 11 Feb 2012 00:05:46 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0247.005; Fri, 10 Feb 2012 16:05:45 -0800 From: Mike Jones To: Yaron Sheffer , "jose@ietf.org" Thread-Topic: [jose] Comments on the JOSE drafts Thread-Index: AQHM1bKNqrUc7ZcPqUO+Ach6FhljB5Y25GPQ Date: Sat, 11 Feb 2012 00:05:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663A01B0@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <4F167432.1030503@gmail.com> In-Reply-To: <4F167432.1030503@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663A01B0TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Comments on the JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 00:05:55 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663A01B0TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your detailed comments, Yaron. Responses inline below. draft-ietf-jose-json-web-key-00 * This is probably water under the bridge by now, but I think the applicabi= lity of bare public keys (as opposed to certificates and certificate chains= ) is very limited. And there is value in using the mechanisms defined here = for certificate (and not just public key) roll-over. There was an explicit working group decision to include JSON representation= of bare public keys in the working group charter. That being said, if the= re are specific changes you'd like to see, by all means, let's discuss them= . * In addition, integrity protection and encryption with symmetric keys is a= lso extremely useful. For example, this format could be used for Kerberos-l= ike authorization tickets. If you make a compelling case for a scenario that requires or would benefit= from this functionality, I'm sure the working group would consider it. * Why mention specifically RSA and Elliptic Curve, instead of building on (= a subset of) PKCS#8, which is more generic? For example, someone's bound to= require modular DSA at some point. The goal was to be able to encode public keys for algorithms in common usag= e on the Internet. The more minimal, the more likely the spec is to be act= ually implemented, provided it actually meets the needs of the implementer'= s scenarios. Thus, keys for RSA and Elliptic Curve algorithms were explici= tly selected. If you want to make the case for including other algorithm families based o= n a real scenario, I suspect the working group would be open to that. * "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed to E= CDH). This may be more than you want to know, but in the first version of the spe= c, this iden= tifier was, in fact, "ECDSA". This was changed in the -01 version with the= introduction of the JWE spec and the need to represent keys used with the = ECDH algorithm as well as those used with ECDSA. The "EC" identifier is ex= plicitly there to represent a family of algorithms sharing the same key rep= resentation - not a specific algorithm. * The way we propose to deal with additional, unknown members precludes ext= ensibility. One can easily think of meaningful optional members (e.g. key owner, key version) that do NOT need to be understood by most consumers= . For a core security feature, the decision was to err on the side of securit= y, rather than convenience of extensibility. The problem is - how would an= implementation know whether it's safe to ignore a parameter or not? Unles= s there's a way to tell outside of understanding the parameter itself, the = only safe thing to do is to require rejecting not-understood parameters. draft-ietf-jose-json-web-signature-00 * Again, why mention HMAC already in the introduction, vs. the more generic= "message authentication code". I'm open to this change. Comments from others in the WG? * Can the payload be binary? The Terminology should clarify it. Yes. The introduction already says "... independent of the type of content= being secured, allowing arbitrary content to be secured", but I suppose I = could this clarification to the JWS Payload definition as well. I'll add t= his to my to-do list. * The definition of JWS Header is self-referential and confusing. Agreed, I'll clarify this in the next version to be more along the lines of= the (hopefully clearer) JWE Header definition in the JWE spec. * "Computing the HMAC of the UTF-8 representation": this is a bit misleadin= g - the representation is actually good old ASCII. Yes it is ASCII. Would the language "Computing the HMAC of the bytes of th= e ASCII representation" be better? Comments from others? * In the same paragraph, computing HMAC-256 also requires a key, which shou= ld have been mentioned. Agreed. I'll add this to my to-do list. (The key is shown in the example = in Appendix A, but it should be mentioned in 3.1 as well.) * When defining the jku member: RFC 6125 is very new - do we really have to= make it mandatory here? Opinions from the working group? * No way is defined to name symmetric keys used for HMAC signatures. I suspect the right thing to do is to generalize the Key ID language to all= ow it to be used for symmetric keys as well as asymmetric. Any disagreemen= t? * I suggest to rename x5t to something that includes the algorithm, e.g. "x5t_sha1". We have already migrated from MD5 to SHA-1, there will be more = coming. But the idea of using key names instead of the full key is valuable= . Also see Jim Schaad's proposal on this x5t that I replied to earlier today= . Ideas welcome... * Again, step #3 of the JWS validation process precludes easy extensibility= . In many cases you do NOT want the signature consumer to understand all th= e fields. In particular when some parameters ("typ") are underspecified. See my comments on the typ header parameter in JWS in my note "Discussion o= f open issues in JOSE drafts" sent earlier today. I believe my comments on= must-understand above also apply here in the general case, however. * IANA considerations: why not define a way for implementations to have mem= ber names that are guaranteed *not* to become reserved? Something like "x-*= "? URIs are simply too long. I believe the sense among IETF participants at this point is that "x-" was = a well-intentioned idea that failed in practice for a number of real-world = reasons. But I would certainly be open to the WG discussing this possibili= ty. * Also, it is very important to allow for IANA extensibility of the set of = supported algorithms (probably in the forthcoming JWA document). Yes - a registry for this purpose is already specified. draft-ietf-jose-json-web-encryption-00 * Many people are still not using authenticated-encryption algorithms. Such people are very likely to abuse this specification, i.e. use just encr= yption with no integrity protection (yes, despite the SHOULD wording at the= bottom of the document). IMHO this spec must also support the more traditi= onal usage of encryption+MAC. Integrity protection should not be left as an= implementer's option. I believe the working group largely feels the same as you do on this point.= A proposal for enabling encryption+integrity is in the works. * 4.2: this paragraph talks about parameter names, but also sneaks in algor= ithm names, which probably require a separate IANA registry and possibly se= parate extensibility rules. I suggest to separate them out. You're right that this is unnecessarily confusing, as written. In practice= , separate registries for header parameters and algorithms are already spec= ified. All add clarifying this text to my to-do list. * 5: in steps #5 and #6, this is not a bitstring, it's a byte string (or a = "sequence of octets"). Agreed - I'll make this change. * 6: the decryption step (#6) also includes validation of the AES-GCM authe= ntication tag, and this may fail of course. Agreed - I'll make this clarification. * 7.2: OK, the algorithm can be specified, but how do we reference the key = being used, and its version number? Possibly with the Key ID, per my earlier comment? * As far as I know "randomness in browsers... is easy to screw up" is actua= lly an understatement. It is still impossible to do, at least not in a port= able way. That's what I thought. Do you have a reference handy that authoritatively = makes this point? =3D=3D=3D=3D Thanks again for the detailed read! -- Mike --_000_4E1F6AAD24975D4BA5B1680429673943663A01B0TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your detail= ed comments, Yaron.  Responses inline below.

 

draft-ietf-jose-json-web-key-00

 

* This is probably water under the bridge by now,= but I think the applicability of bare public keys (as opposed to certifica= tes and certificate chains) is very limited. And there is value in using th= e mechanisms defined here for certificate (and not just public key) roll-over.

 

There was an explicit = working group decision to include JSON representation of bare public keys i= n the working group charter.  That being said, if there are specific c= hanges you’d like to see, by all means, let’s discuss them.

 

* In addition, integrity protection and encryptio= n with symmetric keys is also extremely useful. For example, this format co= uld be used for Kerberos-like authorization tickets.

 

If you make a compelli= ng case for a scenario that requires or would benefit from this functionali= ty, I’m sure the working group would consider it.

 

* Why mention specifically RSA and Elliptic Curve= , instead of building on (a subset of) PKCS#8, which is more generic? For e= xample, someone's bound to require modular DSA at some point.

 

The goal was to be abl= e to encode public keys for algorithms in common usage on the Internet.&nbs= p; The more minimal, the more likely the spec is to be actually implemented= , provided it actually meets the needs of the implementer’s scenarios.  Thus, keys for RSA and Elliptic C= urve algorithms were explicitly selected.

 

If you want to make th= e case for including other algorithm families based on a real scenario, I s= uspect the working group would be open to that.

 

* "EC" is not an algorithm. You probabl= y mean "ECDSA" (e.g. as opposed to ECDH).

 

This may be more than = you want to know, but in t= he first version of the spec, this identifier was, in fact, “ECDS= A”.  This was changed in the -01 version with the introduction o= f the JWE spec and the need to represent keys used with the ECDH algorithm as well as those used with ECDSA.  The “= ;EC” identifier is explicitly there to represent a family of algorith= ms sharing the same key representation – not a specific algorithm.

 

* The way we propose to deal with additional, unk= nown members precludes extensibility. One can easily think of meaningful op= tional members (e.g.

key owner, key version) that do NOT need to be un= derstood by most consumers.

 

For a core security fe= ature, the decision was to err on the side of security, rather than conveni= ence of extensibility.  The problem is – how would an implementa= tion know whether it’s safe to ignore a parameter or not?  Unl= ess there’s a way to tell outside of understanding the parameter itse= lf, the only safe thing to do is to require rejecting not-understood parame= ters.

 

draft-ietf-jose-json-web-signature-00<= /p>

 

* Again, why mention HMAC already in the introduc= tion, vs. the more generic "message authentication code".

 

I’m open to this= change.  Comments from others in the WG?

 

* Can the payload be binary? The Terminology shou= ld clarify it.

 

Yes.  The introdu= ction already says “… independent of the type of content being secured= , allowing arbitrary content to be secured”, but I suppose I could this clarification to the JWS Payload definition as well.  I’ll add this to my to-do list.

 

* The definition of JWS Header is self-referentia= l and confusing.

 

Agreed, I’ll cla= rify this in the next version to be more along the lines of the (hopefully = clearer) JWE Header definition in the JWE spec.

 

* "Computing the HMAC of the UTF-8 represent= ation": this is a bit misleading - the representation is actually good= old ASCII.

 

Yes it is ASCII. = Would the language “Computing the HMAC of the bytes of the ASCII rep= resentation” be better?  Comments from others?=

 

* In the same paragraph, computing HMAC-256 also = requires a key, which should have been mentioned.

 

Agreed.  I’= ll add this to my to-do list.  (The key is shown in the example in Appendix A, but it should be mentioned in= 3.1 as well.)

 

* When defining the jku member: RFC 6125 is very = new - do we really have to make it mandatory here?

 

Opinions from the work= ing group?

 

* No way is defined to name symmetric keys used f= or HMAC signatures.

 

I suspect the right th= ing to do is to generalize the Key ID language to allow it to be used for s= ymmetric keys as well as asymmetric.  Any disagreement?

 

* I suggest to rename x5t to something that inclu= des the algorithm, e.g.

"x5t_sha1". We have already migrated fr= om MD5 to SHA-1, there will be more coming. But the idea of using key names= instead of the full key is valuable.

 

Also see Jim Schaad= 217;s proposal  on this x5t that I replied to earlier today.  Ide= as welcome…

 

* Again, step #3 of the JWS validation process pr= ecludes easy extensibility. In many cases you do NOT want the signature con= sumer to understand all the fields. In particular when some parameters (&qu= ot;typ") are underspecified.

 

See my comments on the= typ header parameter in JWS in my note “Discussion of open issues in= JOSE drafts” sent earlier today.  I believe my comments on must= -understand above also apply here in the general case, however.

 

* IANA considerations: why not define a way for i= mplementations to have member names that are guaranteed *not* to become res= erved? Something like "x-*"? URIs are simply too long.=

 

I believe the sense am= ong IETF participants at this point is that “x-” was a well-int= entioned idea that failed in practice for a number of real-world reasons.&n= bsp; But I would certainly be open to the WG discussing this possibility.

 

* Also, it is very important to allow for IANA ex= tensibility of the set of supported algorithms (probably in the forthcoming= JWA document).

 

Yes – a registry= for this purpose is already specified.

 

 

draft-ietf-jose-json-web-encryption-00=

 

* Many people are still not using authenticated-e= ncryption algorithms.

Such people are very likely to abuse this specifi= cation, i.e. use just encryption with no integrity protection (yes, despite= the SHOULD wording at the bottom of the document). IMHO this spec must als= o support the more traditional usage of encryption+MAC. Integrity protection should not be left as an imple= menter's option.

 

I believe the working = group largely feels the same as you do on this point.  A proposal for = enabling encryption+integrity is in the works.

 

* 4.2: this paragraph talks about parameter names= , but also sneaks in algorithm names, which probably require a separate IAN= A registry and possibly separate extensibility rules. I suggest to separate= them out.

 

You’re right tha= t this is unnecessarily confusing, as written.  In practice, separate = registries for header parameters and algorithms are already specified. = ; All add clarifying this text to my to-do list.

 

* 5: in steps #5 and #6, this is not a bitstring,= it's a byte string (or a "sequence of octets").

 

Agreed – I’= ;ll make this change.

 

* 6: the decryption step (#6) also includes valid= ation of the AES-GCM authentication tag, and this may fail of course.<= /o:p>

 

Agreed – I’= ;ll make this clarification.

 

* 7.2: OK, the algorithm can be specified, but ho= w do we reference the key being used, and its version number?

 

Possibly with the Key = ID, per my earlier comment?

 

* As far as I know "randomness in browsers..= . is easy to screw up" is actually an understatement. It is still impo= ssible to do, at least not in a portable way.

 

That’s what I th= ought.  Do you have a reference handy that authoritatively makes this = point?

 

=3D=3D=3D=3D

 

Thanks again for the d= etailed read!

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          -- Mike=

 

--_000_4E1F6AAD24975D4BA5B1680429673943663A01B0TK5EX14MBXC284r_-- From yaronf.ietf@gmail.com Sat Feb 11 06:12:42 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1370121F84CD for ; Sat, 11 Feb 2012 06:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.413 X-Spam-Level: X-Spam-Status: No, score=-103.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0ZOG-fex2+6 for ; Sat, 11 Feb 2012 06:12:40 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1109921F847F for ; Sat, 11 Feb 2012 06:12:39 -0800 (PST) Received: by eekc41 with SMTP id c41so1259487eek.31 for ; Sat, 11 Feb 2012 06:12:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=IITX3BFwUB3FOI/OE814wbqvM2zb1XElX+5sg/wv2yI=; b=Vvb5lyHH1cG2xaQ3OPn9g41Lv+aoSKQICPrufhdxHzg1GPAxlcREsxr9W/tKbtS7if LgZaViRwtOI9oE8aY48F8E+GSPmAalTY4zcqNxSeuUjWC91a49v+31L22X8P0OMX2vA6 ZeOp+l75YMnMXYM/Qw7Vrvz7pMgmdx9g9g6Uk= Received: by 10.14.22.76 with SMTP id s52mr3174812ees.32.1328969559206; Sat, 11 Feb 2012 06:12:39 -0800 (PST) Received: from [10.0.0.6] (bzq-79-177-151-176.red.bezeqint.net. [79.177.151.176]) by mx.google.com with ESMTPS id n56sm35739268eeh.6.2012.02.11.06.12.37 (version=SSLv3 cipher=OTHER); Sat, 11 Feb 2012 06:12:38 -0800 (PST) Message-ID: <4F367753.5070809@gmail.com> Date: Sat, 11 Feb 2012 16:12:35 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: Mike Jones References: <4F167432.1030503@gmail.com> <4E1F6AAD24975D4BA5B1680429673943663A01B0@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943663A01B0@TK5EX14MBXC284.redmond.corp.microsoft.com> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: "jose@ietf.org" Subject: Re: [jose] Comments on the JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 14:12:42 -0000 Hi Mike, please see my responses below. Apologies as this message is getting too long for humans to parse... On 02/11/2012 02:05 AM, Mike Jones wrote: > Thanks for your detailed comments, Yaron. Responses inline below. > > draft-ietf-jose-json-web-key-00 > > * This is probably water under the bridge by now, but I think the > applicability of bare public keys (as opposed to certificates and > certificate chains) is very limited. And there is value in using the > mechanisms defined here for certificate (and not just public key) roll-over. > > There was an explicit working group decision to include JSON > representation of bare public keys in the working group charter. That > being said, if there are specific changes you’d like to see, by all > means, let’s discuss them. I'm OK with the web-key spec being focused on bare public keys. What's important is what can be used in JWS, and that clearly allows certificates. However note that the "jku" parameter in JWS Sec. 4.1 mentions that it's used for "web keys" only, but then goes on to mention certificates. > > * In addition, integrity protection and encryption with symmetric keys > is also extremely useful. For example, this format could be used for > Kerberos-like authorization tickets. > > If you make a compelling case for a scenario that requires or would > benefit from this functionality, I’m sure the working group would > consider it. Recently I wrote some code that allows one server in a very dynamic cloud setup to issue time-limited authorization tickets to other servers, tickets that can only be validated by the issuing server. This is much easier to do with symmetric keys than with public keys. > > * Why mention specifically RSA and Elliptic Curve, instead of building > on (a subset of) PKCS#8, which is more generic? For example, someone's > bound to require modular DSA at some point. > > The goal was to be able to encode public keys for algorithms in common > usage on the Internet. The more minimal, the more likely the spec is to > be actually implemented, provided it actually meets the needs of the > implementer’s scenarios. Thus, keys for RSA and Elliptic Curve > algorithms were explicitly selected. > > If you want to make the case for including other algorithm families > based on a real scenario, I suspect the working group would be open to that. I don't... > > * "EC" is not an algorithm. You probably mean "ECDSA" (e.g. as opposed > to ECDH). > > This may be more than you want to know, but in the first version of the > spec , > this identifier was, in fact, “ECDSA”. This was changed in the -01 > version with the introduction of the JWE spec and the need to represent > keys used with the ECDH algorithm as well as those used with ECDSA. The > “EC” identifier is explicitly there to represent a family of algorithms > sharing the same key representation – not a specific algorithm. OK. > > * The way we propose to deal with additional, unknown members precludes > extensibility. One can easily think of meaningful optional members (e.g. > > key owner, key version) that do NOT need to be understood by most consumers. > > For a core security feature, the decision was to err on the side of > security, rather than convenience of extensibility. The problem is – how > would an implementation /know/ whether it’s safe to ignore a parameter > or not? Unless there’s a way to tell outside of understanding the > parameter itself, the only safe thing to do is to require rejecting > not-understood parameters. There are standard ways of dealing with this issue, the so-called "critical" flag. The semantics needs to be defined very well. But I think it's worth the effort if you expect this format to be widely deployed. See e.g. bottom of http://tools.ietf.org/html/rfc5996#section-2.5. > > draft-ietf-jose-json-web-signature-00 > > * Again, why mention HMAC already in the introduction, vs. the more > generic "message authentication code". > > I’m open to this change. Comments from others in the WG? > > * Can the payload be binary? The Terminology should clarify it. > > Yes. The introduction already says “… independent of the type of content > being secured, allowing arbitrary content to be secured”, but I supposebit > I could this clarification to the JWS Payload definition as well. I’ll > add this to my to-do list. > > * The definition of JWS Header is self-referential and confusing. > > Agreed, I’ll clarify this in the next version to be more along the lines > of the (hopefully clearer) JWE Header definition in the JWE spec. > > * "Computing the HMAC of the UTF-8 representation": this is a bit > misleading - the representation is actually good old ASCII. > > Yes it is ASCII. Would the language “Computing the HMAC of the bytes of > the ASCII representation” be better? Comments from others? Fine with me. > > * In the same paragraph, computing HMAC-256 also requires a key, which > should have been mentioned. > > Agreed. I’ll add this to my to-do list. (The key /is/ shown in the > example in Appendix A, but it should be mentioned in 3.1 as well.) > > * When defining the jku member: RFC 6125 is very new - do we really have > to make it mandatory here? > > Opinions from the working group? > > * No way is defined to name symmetric keys used for HMAC signatures. > > I suspect the right thing to do is to generalize the Key ID language to > allow it to be used for symmetric keys as well as asymmetric. Any > disagreement? Not from me. > > * I suggest to rename x5t to something that includes the algorithm, e.g. > > "x5t_sha1". We have already migrated from MD5 to SHA-1, there will be > more coming. But the idea of using key names instead of the full key is > valuable. > > Also see Jim Schaad’s proposal on this x5t that I replied to earlier > today. Ideas welcome… > > * Again, step #3 of the JWS validation process precludes easy > extensibility. In many cases you do NOT want the signature consumer to > understand all the fields. In particular when some parameters ("typ") > are underspecified. > > See my comments on the typ header parameter in JWS in my note > “Discussion of open issues in JOSE drafts” sent earlier today. I believe > my comments on must-understand above also apply here in the general > case, however. > > * IANA considerations: why not define a way for implementations to have > member names that are guaranteed *not* to become reserved? Something > like "x-*"? URIs are simply too long. > > I believe the sense among IETF participants at this point is that “x-” > was a well-intentioned idea that failed in practice for a number of > real-world reasons. But I would certainly be open to the WG discussing > this possibility. You're probably right (although I don't know why "x-" is considered to have failed). Anyway, you can always use a URI. > > * Also, it is very important to allow for IANA extensibility of the set > of supported algorithms (probably in the forthcoming JWA document). > > Yes – a registry for this purpose is already specified. > > draft-ietf-jose-json-web-encryption-00 > > * Many people are still not using authenticated-encryption algorithms. > > Such people are very likely to abuse this specification, i.e. use just > encryption with no integrity protection (yes, despite the SHOULD wording > at the bottom of the document). IMHO this spec must also support the > more traditional usage of encryption+MAC. Integrity protection should > not be left as an implementer's option. > > I believe the working group largely feels the same as you do on this > point. A proposal for enabling encryption+integrity is in the works. > > * 4.2: this paragraph talks about parameter names, but also sneaks in > algorithm names, which probably require a separate IANA registry and > possibly separate extensibility rules. I suggest to separate them out. > > You’re right that this is unnecessarily confusing, as written. In > practice, separate registries for header parameters and algorithms are > already specified. All add clarifying this text to my to-do list. > > * 5: in steps #5 and #6, this is not a bitstring, it's a byte string (or > a "sequence of octets"). > > Agreed – I’ll make this change. > > * 6: the decryption step (#6) also includes validation of the AES-GCM > authentication tag, and this may fail of course. > > Agreed – I’ll make this clarification. > > * 7.2: OK, the algorithm can be specified, but how do we reference the > key being used, and its version number? > > Possibly with the Key ID, per my earlier comment? OK. > > * As far as I know "randomness in browsers... is easy to screw up" is > actually an understatement. It is still impossible to do, at least not > in a portable way. > > That’s what I thought. Do you have a reference handy that > authoritatively makes this point? > Nothing better than "private communication"... > ==== > > Thanks again for the detailed read! My pleasure. Yaron > > -- Mike > From ietf@augustcellars.com Sat Feb 11 22:05:32 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB44D21F84AA for ; Sat, 11 Feb 2012 22:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjBqmYxh3uS7 for ; Sat, 11 Feb 2012 22:05:28 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id EF47021F84C3 for ; Sat, 11 Feb 2012 22:05:27 -0800 (PST) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3F2D02C9F5; Sat, 11 Feb 2012 22:05:27 -0800 (PST) From: "Jim Schaad" To: "'Mike Jones'" References: <017201cca118$5883ee30$098bca90$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436639FDA8@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436639FDA8@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Sat, 11 Feb 2012 22:04:43 -0800 Message-ID: <01a701cce94c$37355490$a59ffdb0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01CCE909.291AEE30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQKkhR3r5OPCJZ9px65ORENeD3ivmQFtZsNClH4SKDA= Cc: jose@ietf.org Subject: Re: [jose] Comments on the -03 JSON Web Signature document X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 06:05:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A8_01CCE909.291AEE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit None interesting things have been removed. Jim From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 10, 2012 2:28 PM To: Jim Schaad; draft-jones-json-web-signature@tools.ietf.org Cc: jose@ietf.org Subject: RE: [jose] Comments on the -03 JSON Web Signature document This note replies the comments from your note where the resolutions to them were incomplete or different than you proposed. Per our e-mail exchange, I won't clutter the discussion by replying to comments whose resolutions are already incorporated into the working group drafts. 1. I have a personal problem with the fact that the draft is still named "JSON Web Signature" rather than something like "JSON Integrity Objects". I doubt that I am the only person who has this issue given the number of people who gave opinions during the charter discussion and the resulting charter description "JSON-structured integrity protection to data". This becomes a major re-write of the document internally as well. Per discussion that occurred within the WG after the Taipei meeting on the list, for the same reasons that the WG uses the term "signature", the spec continues to use the vernacular term "signature" as the most readable of the choices in the title. For instance, see http://www.ietf.org/mail-archive/web/jose/current/msg00315.html and http://www.ietf.org/mail-archive/web/jose/current/msg00309.html. That being said, the terminology within the specs has been changed to no longer call both digital signatures and HMACs "signatures", and so I believe is now correct throughout. [JLS] I disagree with this, but am not going to fight this issue at this time. 16. The text states that the key must be associated with the signer of the content. The current document for json keys does not have any way of associating a key with the signer. What does this requirement really mean? It's intended to mean that there must be a way to verify that the content was signed by the correct party, using a key controlled by that party. I'd welcome better language for this concept (possibly lifted from another crypto spec?). [JLS] I have a problem with the statement both in the original text and above. If we are looking at a bare key for doing the validation, we have no idea who the correct party is in general. The fact that the key was found at https://example.com/Tom_Piperson does not tell me without other information who the key is associated with. Going back and re-reading the MUST statement I think that it could be removed entirely. I am not sure that I even understand what the test should be for an interop matrix. If the algorithm is understood by the sender and not the validator is the MUST violated? Is processing a sender or a validator function or both? If I were to successfully forge a message, would the MUST still be true? 18. It would be useful to know if there was going to be any registry for the "typ" header. If not, then it would be useful to state that the values of the "typ" header are based on agreement between the parties. It would also be useful to state the expected behavior in the case the the value of the typ field is either unknown, does not match the expected value or is missing. Are values of the "typ" field supposed to have the same type of public/private values as does algorithm? If not what happens when a collision exists between two different applications? Per my comments on the open issues listed in the drafts, an argument can be made for deleting this parameter from the JWS spec entirely and leaving its definition up to profile specs like JWT. If this isn't done, then a registry could be considered for names not residing in a collision-resistant namespace. [JLS] If it is believe that a parameter this list is going to be "commonly" used by many different profilers, then I believe that the core items needs to be done the in the base specification. I would therefore not be in favor of punting it out to somebody else. The only exception would be if we are going to have a very light core and a "real" core specs. In this case the very light core spec could punt to the "real" core spec. Having said that I think that a registry would be a good idea. 23. Having done a much more detailed read. The last para in section 4.2 can be expanded as follows: New header parameters should be introduced sparingly, an implementation which does not understand a newly introduced parameter will fail validate of the JWS. However, uses which use the JWS structure but define additional semantics, such as the JSON Web Token usage, are expected to define additional public header parameters. The first concept (must-understand of header parameters) is already in the second sentence of the description of header parameters (in Section 4). I could however, add the sentence "However, it is expected that some additional header parameters will be defined by specific profiles and specifications using this specification" to cover the second point, if that works for you. [JLS] I see no problems with re-iterating why it is a problem, but would not insist on it. Telling people that it breaks is usually insufficient, telling them why it breaks means they have a starting place to look for problems. 24. Why MUST I do the following steps (since to me this implies an order of operations). Is there a reason that I cannot do things in the order of 3, 4, 5, 1, 2, 6, 7? Reordered and partially rewrote to be more logical. Please review. [JLS] Sorry, my core problem was insufficiently defined in my message. My problem is that the order of the steps is NOT NORMATIVE. The result needs to be the same as the steps given, but the order that I do things can be anything that works for me. [JLS] In step 3 is there a reason that I cannot perform canonicalization? The current text explicitly forbids it. [JLS] Having followed and read RFC4627 - I note that a JSON object IS permitted to have the same member name listed twice. No restriction about if the values are required to be the same. [JLS] For decode - I think that step 5 should be folded into the text for step 1. [JLS] I would suggest that section 5 be sub-divided - one for creation and one for validation. [JLS] I think that I am having some problems with the fact that the validation process apparently is now totally based on the alg being used and does not have any reliance on this specification. At a minimum the text in validate step 6 needs to say that the input for processing is the concatenation of .. 21, Section 6.1 - The last para states that there is a correspondingly longer key and result. While the result is going to be longer, there is no requirement that the key be longer unless you are going to make a statement to that effect. One could use a 512 bit key for all of the algorithms. I believe that this statement is true for the HS256, HS384, and HS512 algorithms, but I agree that it's not particularly enabling. I'll put describing the expected key sizes for all the algorithms on my to-do list. [JLS] Where did this text wander off to? Some place in JWA? ------=_NextPart_000_01A8_01CCE909.291AEE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<NO HAT>

 

None interesting things = have been removed.

 

Jim

 

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Friday, = February 10, 2012 2:28 PM
To: Jim Schaad; = draft-jones-json-web-signature@tools.ietf.org
Cc: = jose@ietf.org
Subject: RE: [jose] Comments on the -03 JSON Web = Signature document

 

This note replies the comments from your note = where the resolutions to them were incomplete or different than you = proposed.  Per our e-mail exchange, I won’t clutter the = discussion by replying to comments whose resolutions are already = incorporated into the working group drafts.

 

1.  I have a personal problem with the fact = that the draft is still named "JSON Web Signature" rather than = something like "JSON Integrity Objects".  I doubt that I = am the only person who has this issue given the number of people who = gave opinions during the charter discussion and the resulting charter = description "JSON-structured integrity protection to = data".  This becomes a major re-write of the document = internally as well.

 

Per discussion that = occurred within the WG after the Taipei meeting on the list, for the = same reasons that the WG uses the term “signature”, the spec = continues to use the vernacular term “signature” as the most = readable of the choices in the title.  For instance, see = http://www.ietf.org/mail-archive/web/jose/current/msg00315.html and = = http://www.ietf.org/mail-archive/web/jose/current/msg00309.html. = ; That being said, the terminology within the specs has been changed to = no longer call both digital signatures and HMACs "signatures", = and so I believe is now correct throughout.

 

[JLS] I disagree with = this, but am not going to fight this issue at this = time.

 

16.  The text states that the key must be = associated with the signer of the

content.   The current document for json = keys does not have any way of

associating a key with the signer.  What does = this requirement really mean?

 

It’s intended to = mean that there must be a way to verify that the content was signed by = the correct party, using a key controlled by that party.  I’d = welcome better language for this concept (possibly lifted from another = crypto spec?).

 

[JLS]  I have a = problem with the statement both in the original text and above.  If = we are looking at a bare key for doing the validation, we have no idea = who the correct party is in general.   The fact that the key = was found at https://example.com/Tom_Piperso= n does not tell me without other information who the key is = associated with.  Going back and re-reading the MUST statement I = think that it could be removed entirely.  I am not sure that I even = understand what the test should be for an interop matrix.  If the = algorithm is understood by the sender and not the validator is the MUST = violated?  Is processing a sender or a validator function or = both?  If I were to successfully forge a message, would the MUST = still be true? 

 

18.  It would be useful to know if there was = going to be any registry for the "typ" header.  If not, = then it would be useful to state that the values of the "typ" = header are based on agreement between the parties.  It would also = be useful to state the expected behavior in the case the the value of = the typ field is either unknown, does not match the expected value or is = missing.  Are values of the "typ" field supposed to have = the same type of public/private values as does algorithm?  If not = what happens when a collision exists between two different = applications?

 

Per my comments on the = open issues listed in the drafts, an argument can be made for deleting = this parameter from the JWS spec entirely and leaving its definition up = to profile specs like JWT.  If this isn’t done, then a = registry could be considered for names not residing in a = collision-resistant namespace.

 

[JLS] If it is believe = that a parameter this list is going to be “commonly” used by = many different profilers, then I believe that the core items needs to be = done the in the base specification.  I would therefore not be in = favor of punting it out to somebody else.  The only exception would = be if we are going to have a very light core and a “real” = core specs.  In this case the very light core spec could punt to = the “real” core spec.  Having said that I think that a = registry would be a good idea.

 

23.  Having done a much more detailed = read.  The last para in section 4.2 can be expanded as = follows:

 

New header parameters should be introduced = sparingly, an implementation which does not understand a newly = introduced parameter will fail validate of the JWS.  However, uses = which use the JWS structure but define additional semantics, such as the = JSON Web Token usage, are expected to define additional public header = parameters.

 

The first concept = (must-understand of header parameters) is already in the second sentence = of the description of header parameters (in Section 4).  I could = however, add the sentence “However, it is expected that some = additional header parameters will be defined by specific profiles and = specifications using this specification” to cover the second = point, if that works for you.

 

[JLS]  I see no = problems with re-iterating why it is a problem, but would not insist on = it.  Telling people that it  breaks is usually insufficient, = telling them why it breaks means they have a starting place to look for = problems.

 

24.  Why MUST I do the following steps (since = to me this implies an order of operations).  Is there a reason that = I cannot do things in the order of 3, 4, 5, 1, 2, 6, 7?

 

Reordered and partially = rewrote to be more logical.  Please review.

 

[JLS] Sorry, my core = problem was insufficiently defined in my message.  My problem is = that the order of the steps is NOT NORMATIVE.  The result needs to = be the same as the steps given, but the order that I do things can be = anything that works for me.

 

[JLS] In step 3 is there = a reason that I cannot perform canonicalization?  The current text = explicitly forbids it.

 

[JLS] Having followed = and read RFC4627 – I note that a JSON  object IS permitted to = have the same member name listed twice.  No restriction about if = the values are required to be the same.

 

[JLS] For decode – = I think that step 5 should be folded into the text for step = 1.

 

[JLS] I would suggest = that section 5 be sub-divided – one for creation and one for = validation.

 

[JLS] I think that I am = having some problems with the fact that the validation process = apparently is now totally based on the alg being used and does not have = any reliance on this specification.   At a minimum the text in = validate step 6 needs to say that the input for processing is the = concatenation of ….

 

21, Section 6.1 - The last para states that there = is a correspondingly longer key and result.  While the result is = going to be longer, there is no requirement that the key be longer = unless you are going to make a statement to that effect.  One could = use a 512 bit key for all of the algorithms.

 

I believe that this = statement is true for the HS256, HS384, and HS512 algorithms, but = I agree that it’s not particularly enabling.  I’ll put = describing the expected key sizes for all the algorithms on my to-do = list.

 

[JLS] Where did this = text wander off to?  Some place in JWA?

 

 

------=_NextPart_000_01A8_01CCE909.291AEE30-- From matthewdgreen@gmail.com Sun Feb 12 11:23:29 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DDDC21F853E for ; Sun, 12 Feb 2012 11:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIopryKyBiLN for ; Sun, 12 Feb 2012 11:23:28 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7168D21F8537 for ; Sun, 12 Feb 2012 11:23:28 -0800 (PST) Received: by qafi29 with SMTP id i29so1210819qaf.10 for ; Sun, 12 Feb 2012 11:23:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; bh=ihIr3+WjnSw3MpA1tcruIRzyXMScQ1fuvBqlh3AGO8I=; b=yHb8WS4dqke2UZd7P1O+uzElsl59OEgvJ6p+S9sJO+LOykCnyYccXpYV1pxRgoicwt QPxL80Pa5n8pvKPa+GDmmNanK4LLiAi1SitYiwAc6pl1e8a7GssH/wV6EiFkWxmNEf8j mMhMHP8FL8pRvWOS8DIYVNnRvcKOcD8y61XTA= Received: by 10.229.137.142 with SMTP id w14mr386879qct.84.1329074608001; Sun, 12 Feb 2012 11:23:28 -0800 (PST) Received: from [192.168.1.11] (c-76-21-153-251.hsd1.md.comcast.net. [76.21.153.251]) by mx.google.com with ESMTPS id r10sm28705189qaz.7.2012.02.12.11.23.25 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 11:23:27 -0800 (PST) From: Matthew Green Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Feb 2012 14:23:29 -0500 Message-Id: <193BB50D-89DF-43DD-93A1-9483217BC5A1@gmail.com> To: jose@ietf.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 19:23:29 -0000 I'm apologize for stepping into this conversation so late. I recently = came across the draft-jones-json-web-encryption spec, and I was = surprised to see that it doesn't explicitly mandate the use of = authenticated encryption. This seems extremely dangerous to me, and I = was hoping I could convince this group to reconsider. Many of my concerns were already raised by David McGrew in a post he = wrote back in November.* David cites most of the academic literature on = padding oracle attacks, which are an efficient class of attacks that can = be leveraged against unauthenticated encryption modes used in online = systems. I wanted to add that this problem is hardly academic. Padding = oracle attacks are easy to implement (I've had undergrads code them as = an assignment), and there are toolkits available to help people run them = on most systems. Moreover, they're almost impossible to defend on = without some sort of authentication. This authentication would be = provided via an AEAD mode like GCM, or through use of a MAC. Probably the most relevant example is Jager and Somorovsky's recent = attack against the 2002 W3C XML Encryption standard (as implemented in = JBoss and Axis2), which serves almost the same purpose as = json-web-encryption. Given all the press that attack received, I think = would be particularly unfortunate to have this brand new standard fall = to same sort of attack. I understand that the standard gives the /option/ to use authenticated = encryption (GCM mode) or unauthenticated CBC-mode. What's missing, I = think is the appropriate warning to non-expert implementers. I would = phrase it along these lines: * If you choose to implement this specification using unauthenticated = encryption (CBC mode), your ciphertexts will be vulnerable to simple = attacks that lead to complete plaintext recovery. Therefore, we do not = recommend the use of CBC mode in any application where message = confidentiality is critical to system security. On the other hand, why should you ever have to write something like that = into an encryption standard? It seems like the proper solution would be = to simply remove the CBC option altogether. Regards, Matt Green * http://www.ietf.org/mail-archive/web/jose/current/msg00304.html From ve7jtb@ve7jtb.com Sun Feb 12 11:58:39 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B39521F8636 for ; Sun, 12 Feb 2012 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1ql9XbfNXdF for ; Sun, 12 Feb 2012 11:58:38 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3152721F8617 for ; Sun, 12 Feb 2012 11:58:38 -0800 (PST) Received: by ggnq2 with SMTP id q2so2419275ggn.31 for ; Sun, 12 Feb 2012 11:58:37 -0800 (PST) Received: by 10.236.124.2 with SMTP id w2mr16856170yhh.83.1329076717728; Sun, 12 Feb 2012 11:58:37 -0800 (PST) Received: from [192.168.1.213] (186-107-148-253.baf.movistar.cl. [186.107.148.253]) by mx.google.com with ESMTPS id a38sm16613848ana.17.2012.02.12.11.58.34 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 11:58:35 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_3596B670-D134-432A-A8B7-B30C473FFF56"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <193BB50D-89DF-43DD-93A1-9483217BC5A1@gmail.com> Date: Sun, 12 Feb 2012 16:58:28 -0300 Message-Id: <0BBBE883-7C70-4A7D-979C-A11418ED91F5@ve7jtb.com> References: <193BB50D-89DF-43DD-93A1-9483217BC5A1@gmail.com> To: Matthew Green X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkDuvPx2dShAk8zbmHZ9M2HvcYRMqyZYwNdbBUyuUIegqzO6rwa/MznTqxlatXX8MS/+I0N Cc: jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 19:58:39 -0000 --Apple-Mail=_3596B670-D134-432A-A8B7-B30C473FFF56 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii While it would be nice to have GWC on all platforms it is not currently. = openssl is a prime culprit at the moment. =20 So totally removing AES-CBC is not practical. =20 We have discussed adding MAC integrity to CBC in the next draft. =20 The question is should CBC be allowed without integrity. Personally I = would be on the no side of that question. I don't yet have a sense of the WG on that question. I do think there = is consensus on adding a integrity check to CBC as a preferred option. John B. On 2012-02-12, at 4:23 PM, Matthew Green wrote: > I'm apologize for stepping into this conversation so late. I recently = came across the draft-jones-json-web-encryption spec, and I was = surprised to see that it doesn't explicitly mandate the use of = authenticated encryption. This seems extremely dangerous to me, and I = was hoping I could convince this group to reconsider. >=20 > Many of my concerns were already raised by David McGrew in a post he = wrote back in November.* David cites most of the academic literature on = padding oracle attacks, which are an efficient class of attacks that can = be leveraged against unauthenticated encryption modes used in online = systems. I wanted to add that this problem is hardly academic. Padding = oracle attacks are easy to implement (I've had undergrads code them as = an assignment), and there are toolkits available to help people run them = on most systems. Moreover, they're almost impossible to defend on = without some sort of authentication. This authentication would be = provided via an AEAD mode like GCM, or through use of a MAC. >=20 > Probably the most relevant example is Jager and Somorovsky's recent = attack against the 2002 W3C XML Encryption standard (as implemented in = JBoss and Axis2), which serves almost the same purpose as = json-web-encryption. Given all the press that attack received, I think = would be particularly unfortunate to have this brand new standard fall = to same sort of attack. >=20 > I understand that the standard gives the /option/ to use authenticated = encryption (GCM mode) or unauthenticated CBC-mode. What's missing, I = think is the appropriate warning to non-expert implementers. I would = phrase it along these lines: >=20 > * If you choose to implement this specification using unauthenticated = encryption (CBC mode), your ciphertexts will be vulnerable to simple = attacks that lead to complete plaintext recovery. Therefore, we do not = recommend the use of CBC mode in any application where message = confidentiality is critical to system security. >=20 > On the other hand, why should you ever have to write something like = that into an encryption standard? It seems like the proper solution = would be to simply remove the CBC option altogether. >=20 > Regards, >=20 > Matt Green >=20 > * http://www.ietf.org/mail-archive/web/jose/current/msg00304.html >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_3596B670-D134-432A-A8B7-B30C473FFF56 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTIxOTU4MjlaMCMGCSqGSIb3DQEJBDEWBBSktN8cZtd3STRAH/WygqTWQjENDDCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAfFFhOvAoGAiLkTV1jlBj/eCdMXIZVU7TijIGv+Rae/xqMXxF/EYuVtoFXT01hGMWmjKBiyxqj Fhc1mJkev4FaBDG84RuRe7YoptrLzG5J8lJY6nAHS/VOm/p15GmV0s4V6cMhOROg67yTRjcw/+vQ PbTGccmhNtUcAQYgaqjJyHN4vyNP6PvsNfRcU9wNhg8ZXeBb1N9zDgExeqchlselZodlVyerIPeW C2ayGdveLvCh0lyiHORSzJKpsHBsv70W36+OY5cSlrVGHt6ozDUEVv8aEa14j2+RUQdctMFDyT2y 9lL+A+QCK6IjU6IwagGVxScPdQNscZpfrcicj52dAAAAAAAA --Apple-Mail=_3596B670-D134-432A-A8B7-B30C473FFF56-- From ve7jtb@ve7jtb.com Sun Feb 12 13:40:49 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1B921F86AD for ; Sun, 12 Feb 2012 13:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu+1Jcn9SOhL for ; Sun, 12 Feb 2012 13:40:48 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C61721F8642 for ; Sun, 12 Feb 2012 13:40:48 -0800 (PST) Received: by yenm3 with SMTP id m3so2444229yen.31 for ; Sun, 12 Feb 2012 13:40:47 -0800 (PST) Received: by 10.101.81.12 with SMTP id i12mr5365622anl.88.1329082847754; Sun, 12 Feb 2012 13:40:47 -0800 (PST) Received: from [192.168.1.213] (186-107-148-253.baf.movistar.cl. [186.107.148.253]) by mx.google.com with ESMTPS id o50sm20970844yhl.9.2012.02.12.13.40.42 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 13:40:46 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_19404F43-28E8-47DF-BA1A-DDA32BFA9E95"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <045101cca4c3$87a77b60$96f67220$@augustcellars.com> Date: Sun, 12 Feb 2012 18:40:38 -0300 Message-Id: <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQl9PFXB99dGoVwAbUPgIpbrQOQZhzm3Bbbwd228nskm5C3GDLwtyHi/9sLDBxyyHt7q5nGN Cc: 'Mike Jones' , 'David McGrew' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 21:40:49 -0000 --Apple-Mail=_19404F43-28E8-47DF-BA1A-DDA32BFA9E95 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jim, I may be missing something. The scenario below is using RFC6278 and pre shared EC keys to crate a = master symmetric key to wrap a per message symmetric key used for = generating a HMAC, or to use the master symmetric key to wrap a MAC of = the message? For EC we only included ECDSA. =20 The main difference is that with EC-DH-SS only the intended recipient = can verify the message. Slightly different from the ECDSA case. =20 Is the reason for this performance in a embedded environment? I think there is a general question about key wrapping vs using the = pre-shared or key agreement value directly. =20 The current specs lean towards using the values directly rather than for = key wrapping. I tend to prefer key wrapping for security, but that depends on people = actually rotating keys, and it makes the minimum message size larger. Is key agreement for integrity (signing) common? John B. On 2011-11-16, at 9:54 PM, Jim Schaad wrote: > Mike, >=20 > I think that while the structures for JWS might need to undergo some = changes that will mean that while the MAC and Digital Signature = structures. As I mentioned at the F2F meeting, I know of someone is = doing some small device work where they are sending messages from the = devices to more central locations. In this case there is not a = pre-existing shared secret generally between the two entities and they = are not using TLS so they could not derive one from the session key. = Mapping what they do into the current JWS work would require some = changes. Specifically >=20 > Header Object > - contains a MAC algorithm to be used - generally AES-GMAC > - contains a key wrapping algorithm - generally AES key wrap > - contains a key agreement algorithm - generally EC-DH > Key Exchange Value - the CEK wrapped by the KEK where the KEK came = from the static-static EC-DH algorithm > Body > MAC value >=20 > In this case we have four not three items that need to be placed in = the sequence of items to be sent between the originator and the = verifier. I would still compute the MAC value in much the same way, = only I would compute the MAC over the first three elements instead of = the two elements. >=20 > This is the sort of thing that is used in a more store and forward = environment or one where the answer is going to be pre-computed or where = it needs to last longer than just the current session (i.e. later = validation). >=20 > The same type of thing can be used for a long term shared KEK value on = both the sender and recipient, where a unique CEK is generated for each = message and wrapped. David would be a better person than I am to = address the question of security. -"Do you have more security by doing = an indirection and have a fresh key for doing the MAC on each operation = rather than using the long term key for doing the MAC." =20 >=20 > If we did the above change, then I would say that the "Key Exchange = Value" would become and empty string if you have a key derivied from the = TLS session that you are using - but this would still lead to having = four not three elements in the MAC case. >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_19404F43-28E8-47DF-BA1A-DDA32BFA9E95 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTIyMTQwMzlaMCMGCSqGSIb3DQEJBDEWBBTfxUIJm2Vxihlz+YJZpbDDgAlzOTCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQAaJFecR4pao3khxJOmM62wxY8nH6D1z9K7XXbRe6L46NurGLAQrXD6+LkBWmlGwJ8jpmqSsYpJ rfE5jssolrCgoR7+ih7DAaeHBVVDOSPhqPlgiMeAvVHO0l1R1fRjvj06ckiYhhq1AZT9TOoLUQMa 2Lni4Iui8osX2Pi2JRJ/Z9apnY6mcEXmc7Ij9CeaZuW7+eCHYKZOy/wjCdMH2qNVXa8h39Vf1YJy pfgraWb2xt8RgCXTDodW9bB63IVtPlcYGAyUPWXn0LAnbsYymgpUBHNJZbEcaK15YTaOCzyovn7K VdmWhrxfD116kZb8CGxN1z5N7Im8palHXNoPQU8fAAAAAAAA --Apple-Mail=_19404F43-28E8-47DF-BA1A-DDA32BFA9E95-- From ietf@augustcellars.com Sun Feb 12 15:37:05 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A5C221F86D0 for ; Sun, 12 Feb 2012 15:37:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.834 X-Spam-Level: X-Spam-Status: No, score=-2.834 tagged_above=-999 required=5 tests=[AWL=-0.475, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqiQW9YYauNS for ; Sun, 12 Feb 2012 15:37:04 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id C77A521F8671 for ; Sun, 12 Feb 2012 15:37:01 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 3DD4B38F06; Sun, 12 Feb 2012 15:36:58 -0800 (PST) From: "Jim Schaad" To: "'John Bradley'" References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> In-Reply-To: <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> Date: Sun, 12 Feb 2012 15:36:10 -0800 Message-ID: <01c401cce9df$1d6db690$584923b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQIfXWiGz+BYDGrCkc9B4MZ2d8XmRgGqxNXOAcOgPqsBrEMyFgIUxGhfAb7pkuaVTYq8QA== Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 23:37:05 -0000 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Sunday, February 12, 2012 1:41 PM > To: Jim Schaad > Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] comments on draft-jones-json-web-signature and draft- > jones-json-web-encryption > > Jim, > > I may be missing something. > > The scenario below is using RFC6278 and pre shared EC keys to crate a master > symmetric key to wrap a per message symmetric key used for generating a > HMAC, or to use the master symmetric key to wrap a MAC of the message? It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric key which uses A128KW to wrap a symmetric key which is used to MAC the message. > > For EC we only included ECDSA. > > The main difference is that with EC-DH-SS only the intended recipient can > verify the message. Slightly different from the ECDSA case. But not any different from the case of using a pre-shared secret key and a MAC algorithm. This is the current MUST implement. ECDSA is only a SHOULD implement. > > Is the reason for this performance in a embedded environment? In the case I outlined below, yes this is an embedded system. The goal was, in part, to use the fewest possible cryptographic primitives necessary. Since encryption was a requirement, there was already AES and EC shared-secret computation. Using an AES based KDF meant that there are no hash functions. Adding integrity protection as well without adding new primitives was desired. It could use EC + the AES KDF to get a key and AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. > > I think there is a general question about key wrapping vs using the pre- > shared or key agreement value directly. > The current specs lean towards using the values directly rather than for key > wrapping. > > I tend to prefer key wrapping for security, but that depends on people > actually rotating keys, and it makes the minimum message size larger. Actually it is the other way around. Not using key wrapping is more dependent on people actually rotating keys. If one uses a key agreement or key transport to carry the key, then a fresh key is being used for the MAC every time and there is no problems with either forward security or gathering a large number of messages with the same MAC value and being able to do things based on that. So you most likely trading off message size for security depending on the source of the key you are using for the MAC operation. For example if it came from the TLS session then the answer would be different. > > Is key agreement for integrity (signing) common? How common is it to use MACs? In those cases how many people are complaining because the shared keys never get rolled over? No it is not common, what is common is to have no security at all. The next is to have very long term shared keys for doing MACs. One could possibly argue that the entire project is a waste of time since all of these items are sent over a TLS session (or should be) and therefore the integrity of the transfer is already protected. This would mean that you are making for bigger messages by adding a second level of integrity protection. The question is what is the second level of integrity protection trying to protect? Is it trying to be long term or short term? Without knowing what the goals are, it is not possible to say that the answer is actually working correctly. > > John B. > On 2011-11-16, at 9:54 PM, Jim Schaad wrote: > > > Mike, > > > > I think that while the structures for JWS might need to undergo some > changes that will mean that while the MAC and Digital Signature structures. > As I mentioned at the F2F meeting, I know of someone is doing some small > device work where they are sending messages from the devices to more > central locations. In this case there is not a pre-existing shared secret > generally between the two entities and they are not using TLS so they could > not derive one from the session key. Mapping what they do into the current > JWS work would require some changes. Specifically > > > > Header Object > > - contains a MAC algorithm to be used - generally AES-GMAC > > - contains a key wrapping algorithm - generally AES key wrap > > - contains a key agreement algorithm - generally EC-DH > > Key Exchange Value - the CEK wrapped by the KEK where the KEK came > from the static-static EC-DH algorithm > > Body > > MAC value > > > > In this case we have four not three items that need to be placed in the > sequence of items to be sent between the originator and the verifier. I > would still compute the MAC value in much the same way, only I would > compute the MAC over the first three elements instead of the two > elements. > > > > This is the sort of thing that is used in a more store and forward > environment or one where the answer is going to be pre-computed or > where it needs to last longer than just the current session (i.e. later > validation). > > > > The same type of thing can be used for a long term shared KEK value on > both the sender and recipient, where a unique CEK is generated for each > message and wrapped. David would be a better person than I am to address > the question of security. -"Do you have more security by doing an indirection > and have a fresh key for doing the MAC on each operation rather than using > the long term key for doing the MAC." > > > > If we did the above change, then I would say that the "Key Exchange > Value" would become and empty string if you have a key derivied from the > TLS session that you are using - but this would still lead to having four not > three elements in the MAC case. > > > > Jim > > > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose From ve7jtb@ve7jtb.com Sun Feb 12 16:05:22 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A91821F8709 for ; Sun, 12 Feb 2012 16:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBD1zGUquhGP for ; Sun, 12 Feb 2012 16:05:21 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3621F8703 for ; Sun, 12 Feb 2012 16:05:21 -0800 (PST) Received: by yhkk25 with SMTP id k25so2463847yhk.31 for ; Sun, 12 Feb 2012 16:05:18 -0800 (PST) Received: by 10.236.177.6 with SMTP id c6mr17423044yhm.42.1329091518138; Sun, 12 Feb 2012 16:05:18 -0800 (PST) Received: from [192.168.1.213] (186-107-148-253.baf.movistar.cl. [186.107.148.253]) by mx.google.com with ESMTPS id v7sm21506517yhi.1.2012.02.12.16.05.14 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 16:05:17 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_EAC75D68-C35D-480B-8F20-DBD6A1EC1511"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <01c401cce9df$1d6db690$584923b0$@augustcellars.com> Date: Sun, 12 Feb 2012 21:05:10 -0300 Message-Id: <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> <01c401cce9df$1d6db690$584923b0$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkttqxup4tdpRZX00J8ojDtR42beQxH4pfTmPtFlvj/3EvA/2DJC1O9eqjclQRwn1lcylu0 Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:05:22 -0000 --Apple-Mail=_EAC75D68-C35D-480B-8F20-DBD6A1EC1511 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2012-02-12, at 8:36 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Sunday, February 12, 2012 1:41 PM >> To: Jim Schaad >> Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org >> Subject: Re: [jose] comments on draft-jones-json-web-signature and = draft- >> jones-json-web-encryption >>=20 >> Jim, >>=20 >> I may be missing something. >>=20 >> The scenario below is using RFC6278 and pre shared EC keys to crate a > master >> symmetric key to wrap a per message symmetric key used for generating = a >> HMAC, or to use the master symmetric key to wrap a MAC of the = message? >=20 > It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric = key > which uses A128KW to wrap a symmetric key which is used to MAC the = message. Ah OK you had static static that confused me. We do have ECDSA-ES for = encryption, but hadn't thought about it for signing, because it is more = integrity, without knowing the identity of the originator. >=20 >>=20 >> For EC we only included ECDSA. >>=20 >> The main difference is that with EC-DH-SS only the intended recipient = can >> verify the message. Slightly different from the ECDSA case. >=20 > But not any different from the case of using a pre-shared secret key = and a > MAC algorithm. This is the current MUST implement. ECDSA is only a = SHOULD > implement. I don't know that we are going to get more agreement on ECDH-ES being a = MUST than ECDSA. >=20 >>=20 >> Is the reason for this performance in a embedded environment? >=20 > In the case I outlined below, yes this is an embedded system. The = goal was, > in part, to use the fewest possible cryptographic primitives = necessary. > Since encryption was a requirement, there was already AES and EC > shared-secret computation. Using an AES based KDF meant that there = are no > hash functions. Adding integrity protection as well without adding = new > primitives was desired. It could use EC + the AES KDF to get a key = and > AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. In your original post I missed that the body was encrypted, I thought = you were only encrypting the key. Generating a unauthenticated integrity check. If we are talking about Encryption then ECDH-ES with AES-GWC in the = existing spec works. We do need to add the MAC integrity check to support CBC. Again in ECDH-ES only the recipient is authenticated. >=20 >>=20 >> I think there is a general question about key wrapping vs using the = pre- >> shared or key agreement value directly. >> The current specs lean towards using the values directly rather than = for > key >> wrapping. >>=20 >> I tend to prefer key wrapping for security, but that depends on = people >> actually rotating keys, and it makes the minimum message size larger. >=20 > Actually it is the other way around. Not using key wrapping is more > dependent on people actually rotating keys. If one uses a key = agreement or > key transport to carry the key, then a fresh key is being used for the = MAC > every time and there is no problems with either forward security or > gathering a large number of messages with the same MAC value and being = able > to do things based on that. So you most likely trading off message = size for > security depending on the source of the key you are using for the MAC > operation. For example if it came from the TLS session then the = answer > would be different.=20 My confidence in people using a fresh key for the MAC each time in = wrapping is less than yours. =20 I admit encouraging them to do the right thing is probably the best, = rather than optimizing for there potential mistakes. >=20 >>=20 >> Is key agreement for integrity (signing) common? >=20 > How common is it to use MACs? In those cases how many people are > complaining because the shared keys never get rolled over? No it is = not > common, what is common is to have no security at all. The next is to = have > very long term shared keys for doing MACs.=20 >=20 > One could possibly argue that the entire project is a waste of time = since > all of these items are sent over a TLS session (or should be) and = therefore > the integrity of the transfer is already protected. This would mean = that > you are making for bigger messages by adding a second level of = integrity > protection. The question is what is the second level of integrity > protection trying to protect? Is it trying to be long term or short = term? > Without knowing what the goals are, it is not possible to say that the > answer is actually working correctly. >=20 In general with HMAC type integrity checks people infer the identity of = the originator through the possession of the long term secret. =20 The scenario you present seems to not care about the identity of the = originator. =20 Sorry if the questions are simple. I am just trying to understand the use case. John B. >>=20 >> John B. >> On 2011-11-16, at 9:54 PM, Jim Schaad wrote: >>=20 >>> Mike, >>>=20 >>> I think that while the structures for JWS might need to undergo some >> changes that will mean that while the MAC and Digital Signature > structures. >> As I mentioned at the F2F meeting, I know of someone is doing some = small >> device work where they are sending messages from the devices to more >> central locations. In this case there is not a pre-existing shared = secret >> generally between the two entities and they are not using TLS so they > could >> not derive one from the session key. Mapping what they do into the > current >> JWS work would require some changes. Specifically >>>=20 >>> Header Object >>> - contains a MAC algorithm to be used - generally AES-GMAC >>> - contains a key wrapping algorithm - generally AES key wrap >>> - contains a key agreement algorithm - generally EC-DH >>> Key Exchange Value - the CEK wrapped by the KEK where the KEK came >> from the static-static EC-DH algorithm >>> Body >>> MAC value >>>=20 >>> In this case we have four not three items that need to be placed in = the >> sequence of items to be sent between the originator and the verifier. = I >> would still compute the MAC value in much the same way, only I would >> compute the MAC over the first three elements instead of the two >> elements. >>>=20 >>> This is the sort of thing that is used in a more store and forward >> environment or one where the answer is going to be pre-computed or >> where it needs to last longer than just the current session (i.e. = later >> validation). >>>=20 >>> The same type of thing can be used for a long term shared KEK value = on >> both the sender and recipient, where a unique CEK is generated for = each >> message and wrapped. David would be a better person than I am to = address >> the question of security. -"Do you have more security by doing an > indirection >> and have a fresh key for doing the MAC on each operation rather than = using >> the long term key for doing the MAC." >>>=20 >>> If we did the above change, then I would say that the "Key Exchange >> Value" would become and empty string if you have a key derivied from = the >> TLS session that you are using - but this would still lead to having = four > not >> three elements in the MAC case. >>>=20 >>> Jim >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >=20 >=20 --Apple-Mail=_EAC75D68-C35D-480B-8F20-DBD6A1EC1511 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTMwMDA1MTFaMCMGCSqGSIb3DQEJBDEWBBT3N2yrt3JRcu97hdcb/bQQdPOrhjCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCtVIig2/i0Jf2h9jeqn6cxEwV6sJyw8OU6DUDFQPNBsBNoh9Ut8HrsB3/bdd+KTBCdnH2zskDF 9/JRlD4Xuyyl6UpxkqjjlN+nn/8xhwdwPAE9H5aAjSNKrnfIULc+xZqHljzL0vZWz7kHf/35RxNO soIclqaNSKK2IPc0HzhTCPbXYCt5kswDjNmVyfc0Fku9fx3EBY5aC9XiZKQvhfDP9vTN2y5VVO5J fID5qkmQJgXzG+UsUu3OwO2j67y2m/AzQ3qpzyCUBOKNuKA0yiL8hwkBnwHUFgUBGDfygbOqTUHj o12BWfeEZh0D6ccPUKlR6m6ofemYI0DxalJ1OPAaAAAAAAAA --Apple-Mail=_EAC75D68-C35D-480B-8F20-DBD6A1EC1511-- From ietf@augustcellars.com Sun Feb 12 16:16:18 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01D121F8709 for ; Sun, 12 Feb 2012 16:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.794 X-Spam-Level: X-Spam-Status: No, score=-2.794 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C63B1z3348nq for ; Sun, 12 Feb 2012 16:16:18 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E91E921F8703 for ; Sun, 12 Feb 2012 16:16:17 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4B3A82C9E7; Sun, 12 Feb 2012 16:16:15 -0800 (PST) From: "Jim Schaad" To: "'John Bradley'" References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> <01c401cce9df$1d6db690$584923b0$@augustcellars.com> <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> In-Reply-To: <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> Date: Sun, 12 Feb 2012 16:15:29 -0800 Message-ID: <01cd01cce9e4$9961f1d0$cc25d570$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQIfXWiGz+BYDGrCkc9B4MZ2d8XmRgGqxNXOAcOgPqsBrEMyFgIUxGhfAb7pkuYCUqYwMgGl5Y1wlS3V4/A= Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:16:18 -0000 > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Sunday, February 12, 2012 4:05 PM > To: Jim Schaad > Cc: 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] comments on draft-jones-json-web-signature and draft- > jones-json-web-encryption > > > On 2012-02-12, at 8:36 PM, Jim Schaad wrote: > > > > > > >> -----Original Message----- > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> Sent: Sunday, February 12, 2012 1:41 PM > >> To: Jim Schaad > >> Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org > >> Subject: Re: [jose] comments on draft-jones-json-web-signature and > draft- > >> jones-json-web-encryption > >> > >> Jim, > >> > >> I may be missing something. > >> > >> The scenario below is using RFC6278 and pre shared EC keys to crate a > > master > >> symmetric key to wrap a per message symmetric key used for generating > a > >> HMAC, or to use the master symmetric key to wrap a MAC of the > message? > > > > It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric key > > which uses A128KW to wrap a symmetric key which is used to MAC the > message. > > Ah OK you had static static that confused me. We do have ECDSA-ES for > encryption, but hadn't thought about it for signing, because it is more > integrity, without knowing the identity of the originator. Yeah - I forgot - it depends on if you want to know who sent it. If you want to know who sent it then you need to use static-static. But that is completely orthogonal to the rest of the argument. > > > > >> > >> For EC we only included ECDSA. > >> > >> The main difference is that with EC-DH-SS only the intended recipient can > >> verify the message. Slightly different from the ECDSA case. > > > > But not any different from the case of using a pre-shared secret key and a > > MAC algorithm. This is the current MUST implement. ECDSA is only a > SHOULD > > implement. > > I don't know that we are going to get more agreement on ECDH-ES being a > MUST than ECDSA. I am not saying that it needs to be a MUST - but the current structure does not support it in any fashion. > > > > >> > >> Is the reason for this performance in a embedded environment? > > > > In the case I outlined below, yes this is an embedded system. The goal > was, > > in part, to use the fewest possible cryptographic primitives necessary. > > Since encryption was a requirement, there was already AES and EC > > shared-secret computation. Using an AES based KDF meant that there are > no > > hash functions. Adding integrity protection as well without adding new > > primitives was desired. It could use EC + the AES KDF to get a key and > > AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. > > In your original post I missed that the body was encrypted, I thought you > were only encrypting the key. In this case I am not encrypting the body. I am only doing an authentication operation. What I am looking at is the number of primitives that are required for the sender to be able to do both operations. > > Generating a unauthenticated integrity check. > > If we are talking about Encryption then ECDH-ES with AES-GWC in the > existing spec works. > We do need to add the MAC integrity check to support CBC. > > Again in ECDH-ES only the recipient is authenticated. > > > > >> > >> I think there is a general question about key wrapping vs using the pre- > >> shared or key agreement value directly. > >> The current specs lean towards using the values directly rather than for > > key > >> wrapping. > >> > >> I tend to prefer key wrapping for security, but that depends on people > >> actually rotating keys, and it makes the minimum message size larger. > > > > Actually it is the other way around. Not using key wrapping is more > > dependent on people actually rotating keys. If one uses a key agreement > or > > key transport to carry the key, then a fresh key is being used for the MAC > > every time and there is no problems with either forward security or > > gathering a large number of messages with the same MAC value and being > able > > to do things based on that. So you most likely trading off message size for > > security depending on the source of the key you are using for the MAC > > operation. For example if it came from the TLS session then the answer > > would be different. > > My confidence in people using a fresh key for the MAC each time in > wrapping is less than yours. > I admit encouraging them to do the right thing is probably the best, rather > than optimizing for there potential mistakes. > There are a lot of things people can do that is bad. That does not mean we should discourage those that want to do it correctly. > > > > >> > >> Is key agreement for integrity (signing) common? > > > > How common is it to use MACs? In those cases how many people are > > complaining because the shared keys never get rolled over? No it is not > > common, what is common is to have no security at all. The next is to have > > very long term shared keys for doing MACs. > > > > One could possibly argue that the entire project is a waste of time since > > all of these items are sent over a TLS session (or should be) and therefore > > the integrity of the transfer is already protected. This would mean that > > you are making for bigger messages by adding a second level of integrity > > protection. The question is what is the second level of integrity > > protection trying to protect? Is it trying to be long term or short term? > > Without knowing what the goals are, it is not possible to say that the > > answer is actually working correctly. > > > In general with HMAC type integrity checks people infer the identity of the > originator through the possession of the long term secret. > > The scenario you present seems to not care about the identity of the > originator. See above note - It actually does use a static-static. But as I can easily add to that to the list of "private" algorithms this is not a stumbling block. Note that if you look at the above I needed to add a new ECDH algorithm in any event since I am not using the standard KDF function. Jim > > Sorry if the questions are simple. > I am just trying to understand the use case. > > John B. > > >> > >> John B. > >> On 2011-11-16, at 9:54 PM, Jim Schaad wrote: > >> > >>> Mike, > >>> > >>> I think that while the structures for JWS might need to undergo some > >> changes that will mean that while the MAC and Digital Signature > > structures. > >> As I mentioned at the F2F meeting, I know of someone is doing some > small > >> device work where they are sending messages from the devices to more > >> central locations. In this case there is not a pre-existing shared secret > >> generally between the two entities and they are not using TLS so they > > could > >> not derive one from the session key. Mapping what they do into the > > current > >> JWS work would require some changes. Specifically > >>> > >>> Header Object > >>> - contains a MAC algorithm to be used - generally AES-GMAC > >>> - contains a key wrapping algorithm - generally AES key wrap > >>> - contains a key agreement algorithm - generally EC-DH > >>> Key Exchange Value - the CEK wrapped by the KEK where the KEK came > >> from the static-static EC-DH algorithm > >>> Body > >>> MAC value > >>> > >>> In this case we have four not three items that need to be placed in the > >> sequence of items to be sent between the originator and the verifier. I > >> would still compute the MAC value in much the same way, only I would > >> compute the MAC over the first three elements instead of the two > >> elements. > >>> > >>> This is the sort of thing that is used in a more store and forward > >> environment or one where the answer is going to be pre-computed or > >> where it needs to last longer than just the current session (i.e. later > >> validation). > >>> > >>> The same type of thing can be used for a long term shared KEK value on > >> both the sender and recipient, where a unique CEK is generated for each > >> message and wrapped. David would be a better person than I am to > address > >> the question of security. -"Do you have more security by doing an > > indirection > >> and have a fresh key for doing the MAC on each operation rather than > using > >> the long term key for doing the MAC." > >>> > >>> If we did the above change, then I would say that the "Key Exchange > >> Value" would become and empty string if you have a key derivied from > the > >> TLS session that you are using - but this would still lead to having four > > not > >> three elements in the MAC case. > >>> > >>> Jim > >>> > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > > > > From ve7jtb@ve7jtb.com Sun Feb 12 16:26:25 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC9F21F871E for ; Sun, 12 Feb 2012 16:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.392 X-Spam-Level: X-Spam-Status: No, score=-3.392 tagged_above=-999 required=5 tests=[AWL=0.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXhe5a56qHl5 for ; Sun, 12 Feb 2012 16:26:24 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5E021F8721 for ; Sun, 12 Feb 2012 16:26:24 -0800 (PST) Received: by yenm3 with SMTP id m3so2468848yen.31 for ; Sun, 12 Feb 2012 16:26:23 -0800 (PST) Received: by 10.236.136.99 with SMTP id v63mr17228393yhi.46.1329092783711; Sun, 12 Feb 2012 16:26:23 -0800 (PST) Received: from [192.168.1.213] (186-107-148-253.baf.movistar.cl. [186.107.148.253]) by mx.google.com with ESMTPS id a14sm32237107ana.20.2012.02.12.16.26.21 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 12 Feb 2012 16:26:22 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_E7810CD4-77F1-457C-A105-F4FCE765E90B"; protocol="application/pkcs7-signature"; micalg=sha1 From: John Bradley In-Reply-To: <01cd01cce9e4$9961f1d0$cc25d570$@augustcellars.com> Date: Sun, 12 Feb 2012 21:26:18 -0300 Message-Id: References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> <01c401cce9df$1d6db690$584923b0$@augustcellars.com> <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> <01cd01cce9e4$9961f1d0$cc25d570$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1257) X-Gm-Message-State: ALoCoQkuxowuXe+P6A5ytlv0Zu+OJGukGJTWjeTjIbWd9LkHu5WH/NikUAmchJfza7wFgkDLpFyM Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:26:25 -0000 --Apple-Mail=_E7810CD4-77F1-457C-A105-F4FCE765E90B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I can see adding ECDH-SS for both signing and encryption. It gets you = both at the same time sort of. Is there a problem with reusing the KDF from ECDH-ES? I think I see what you are after now. John B. On 2012-02-12, at 9:15 PM, Jim Schaad wrote: >=20 >=20 >> -----Original Message----- >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >> Sent: Sunday, February 12, 2012 4:05 PM >> To: Jim Schaad >> Cc: 'Mike Jones'; jose@ietf.org >> Subject: Re: [jose] comments on draft-jones-json-web-signature and = draft- >> jones-json-web-encryption >>=20 >>=20 >> On 2012-02-12, at 8:36 PM, Jim Schaad wrote: >>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] >>>> Sent: Sunday, February 12, 2012 1:41 PM >>>> To: Jim Schaad >>>> Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org >>>> Subject: Re: [jose] comments on draft-jones-json-web-signature and >> draft- >>>> jones-json-web-encryption >>>>=20 >>>> Jim, >>>>=20 >>>> I may be missing something. >>>>=20 >>>> The scenario below is using RFC6278 and pre shared EC keys to crate = a >>> master >>>> symmetric key to wrap a per message symmetric key used for = generating >> a >>>> HMAC, or to use the master symmetric key to wrap a MAC of the >> message? >>>=20 >>> It is using static-ephemeral ECDH (or ECDH-ES) to generate a = symmetric > key >>> which uses A128KW to wrap a symmetric key which is used to MAC the >> message. >>=20 >> Ah OK you had static static that confused me. We do have ECDSA-ES = for >> encryption, but hadn't thought about it for signing, because it is = more >> integrity, without knowing the identity of the originator. >=20 > Yeah - I forgot - it depends on if you want to know who sent it. If = you > want to know who sent it then you need to use static-static. But that = is > completely orthogonal to the rest of the argument. >=20 >>=20 >>>=20 >>>>=20 >>>> For EC we only included ECDSA. >>>>=20 >>>> The main difference is that with EC-DH-SS only the intended = recipient > can >>>> verify the message. Slightly different from the ECDSA case. >>>=20 >>> But not any different from the case of using a pre-shared secret key = and > a >>> MAC algorithm. This is the current MUST implement. ECDSA is only a >> SHOULD >>> implement. >>=20 >> I don't know that we are going to get more agreement on ECDH-ES being = a >> MUST than ECDSA. >=20 > I am not saying that it needs to be a MUST - but the current structure = does > not support it in any fashion. >=20 >>=20 >>>=20 >>>>=20 >>>> Is the reason for this performance in a embedded environment? >>>=20 >>> In the case I outlined below, yes this is an embedded system. The = goal >> was, >>> in part, to use the fewest possible cryptographic primitives = necessary. >>> Since encryption was a requirement, there was already AES and EC >>> shared-secret computation. Using an AES based KDF meant that there = are >> no >>> hash functions. Adding integrity protection as well without adding = new >>> primitives was desired. It could use EC + the AES KDF to get a key = and >>> AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. >>=20 >> In your original post I missed that the body was encrypted, I thought = you >> were only encrypting the key. >=20 > In this case I am not encrypting the body. I am only doing an > authentication operation. What I am looking at is the number of = primitives > that are required for the sender to be able to do both operations. >=20 >>=20 >> Generating a unauthenticated integrity check. >>=20 >> If we are talking about Encryption then ECDH-ES with AES-GWC in the >> existing spec works. >> We do need to add the MAC integrity check to support CBC. >>=20 >> Again in ECDH-ES only the recipient is authenticated. >>=20 >>>=20 >>>>=20 >>>> I think there is a general question about key wrapping vs using the > pre- >>>> shared or key agreement value directly. >>>> The current specs lean towards using the values directly rather = than > for >>> key >>>> wrapping. >>>>=20 >>>> I tend to prefer key wrapping for security, but that depends on = people >>>> actually rotating keys, and it makes the minimum message size = larger. >>>=20 >>> Actually it is the other way around. Not using key wrapping is more >>> dependent on people actually rotating keys. If one uses a key = agreement >> or >>> key transport to carry the key, then a fresh key is being used for = the > MAC >>> every time and there is no problems with either forward security or >>> gathering a large number of messages with the same MAC value and = being >> able >>> to do things based on that. So you most likely trading off message = size > for >>> security depending on the source of the key you are using for the = MAC >>> operation. For example if it came from the TLS session then the = answer >>> would be different. >>=20 >> My confidence in people using a fresh key for the MAC each time in >> wrapping is less than yours. >> I admit encouraging them to do the right thing is probably the best, > rather >> than optimizing for there potential mistakes. >>=20 >=20 > There are a lot of things people can do that is bad. That does not = mean we > should discourage those that want to do it correctly. >=20 >>=20 >>>=20 >>>>=20 >>>> Is key agreement for integrity (signing) common? >>>=20 >>> How common is it to use MACs? In those cases how many people are >>> complaining because the shared keys never get rolled over? No it is = not >>> common, what is common is to have no security at all. The next is = to > have >>> very long term shared keys for doing MACs. >>>=20 >>> One could possibly argue that the entire project is a waste of time > since >>> all of these items are sent over a TLS session (or should be) and > therefore >>> the integrity of the transfer is already protected. This would mean > that >>> you are making for bigger messages by adding a second level of = integrity >>> protection. The question is what is the second level of integrity >>> protection trying to protect? Is it trying to be long term or short > term? >>> Without knowing what the goals are, it is not possible to say that = the >>> answer is actually working correctly. >>>=20 >> In general with HMAC type integrity checks people infer the identity = of > the >> originator through the possession of the long term secret. >>=20 >> The scenario you present seems to not care about the identity of the >> originator. >=20 > See above note - It actually does use a static-static. But as I can = easily > add to that to the list of "private" algorithms this is not a = stumbling > block. Note that if you look at the above I needed to add a new ECDH > algorithm in any event since I am not using the standard KDF function. >=20 > Jim >=20 >>=20 >> Sorry if the questions are simple. >> I am just trying to understand the use case. >>=20 >> John B. >>=20 >>>>=20 >>>> John B. >>>> On 2011-11-16, at 9:54 PM, Jim Schaad wrote: >>>>=20 >>>>> Mike, >>>>>=20 >>>>> I think that while the structures for JWS might need to undergo = some >>>> changes that will mean that while the MAC and Digital Signature >>> structures. >>>> As I mentioned at the F2F meeting, I know of someone is doing some >> small >>>> device work where they are sending messages from the devices to = more >>>> central locations. In this case there is not a pre-existing shared > secret >>>> generally between the two entities and they are not using TLS so = they >>> could >>>> not derive one from the session key. Mapping what they do into the >>> current >>>> JWS work would require some changes. Specifically >>>>>=20 >>>>> Header Object >>>>> - contains a MAC algorithm to be used - generally AES-GMAC >>>>> - contains a key wrapping algorithm - generally AES key wrap >>>>> - contains a key agreement algorithm - generally EC-DH >>>>> Key Exchange Value - the CEK wrapped by the KEK where the KEK came >>>> from the static-static EC-DH algorithm >>>>> Body >>>>> MAC value >>>>>=20 >>>>> In this case we have four not three items that need to be placed = in > the >>>> sequence of items to be sent between the originator and the = verifier. > I >>>> would still compute the MAC value in much the same way, only I = would >>>> compute the MAC over the first three elements instead of the two >>>> elements. >>>>>=20 >>>>> This is the sort of thing that is used in a more store and forward >>>> environment or one where the answer is going to be pre-computed or >>>> where it needs to last longer than just the current session (i.e. = later >>>> validation). >>>>>=20 >>>>> The same type of thing can be used for a long term shared KEK = value on >>>> both the sender and recipient, where a unique CEK is generated for = each >>>> message and wrapped. David would be a better person than I am to >> address >>>> the question of security. -"Do you have more security by doing an >>> indirection >>>> and have a fresh key for doing the MAC on each operation rather = than >> using >>>> the long term key for doing the MAC." >>>>>=20 >>>>> If we did the above change, then I would say that the "Key = Exchange >>>> Value" would become and empty string if you have a key derivied = from >> the >>>> TLS session that you are using - but this would still lead to = having > four >>> not >>>> three elements in the MAC case. >>>>>=20 >>>>> Jim >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >=20 >=20 --Apple-Mail=_E7810CD4-77F1-457C-A105-F4FCE765E90B Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIO9TCCBwsw ggXzoAMCAQICAgZDMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTAwMzE3MTM0NDQ1WhcNMTIwMzE4MTE1NTExWjCBzTEgMB4GA1UEDRMXMTY1NTU1LTJHU3FU T1ZUbkk4OHhOSW4xCzAJBgNVBAYTAkNMMSIwIAYDVQQIExlNZXRyb3BvbGl0YW5hIGRlIFNhbnRp YWdvMREwDwYDVQQHEwhWaXRhY3VyYTEtMCsGA1UECxMkU3RhcnRDb20gVmVyaWZpZWQgQ2VydGlm aWNhdGUgTWVtYmVyMRUwEwYDVQQDEwxKb2huIEJyYWRsZXkxHzAdBgkqhkiG9w0BCQEWEGpicmFk bGV5QG1hYy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDB7DXf6x80dsJiB9B9 Ds4cBQdA+9bNuZMBeXkUAHrvYH2taw6y8fcadbhgk92FyPiCbsHtB1VTaJThaMqtXuTkS4r5Sfb8 k5kboz3OQVPMmrOJIUpaoDP2heKEhMUSL6ev9CvsuYs+XXe7f9vY3w/A8cVg/NoOXbdqKXbWOMMd NSdg7uJWSsmpqILFzQsumwqVH24tYX0sqvpJy/r+pc84j6QM+Ew0B9bz3OkEMafjcCeGRfdsQnLB +rIR8BPDeeKRP6a5e8Lf6slUQ3s/rh33otnkNaz6DMLTJrj0qoAD7FxB7LlLalIjrg08BNZDJUQK 7zTlNxkPqVHVTg3H0OG/AgMBAAGjggMyMIIDLjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFMjJGKHWsNb6VU54Wkktqcu2on3B MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MFQGA1UdEQRNMEuBEGpicmFkbGV5QG1h Yy5jb22BEXZlN2p0YkB2ZTdqdGIuY29tgRNqYnJhZGxleUB3aW5nYWEuY29tgQ9qYnJhZGxleUBt ZS5jb20wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQIBMIIBIDAuBggrBgEFBQcCARYi aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYBBQUHAgIwgaowFBYNU3RhcnRD b20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNlZSBzZWN0aW9uICpMZWdhbCBMaW1p dGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBh dmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBa MCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMCugKaAnhiVodHRw Oi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1Mi1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsG AQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMi9jbGllbnQvY2EwQgYI KwYBBQUHMAKGNmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczIuY2xpZW50 LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEF BQADggEBAHu8WZHdSu+I5GMzGDrkxFVUzZ2JAcwzgSscYNFX2CFJlU8ncC+/E5Y18oiGcIR9o7J3 Hh4fGrjJmxTsq2O3E9/qg0yWSEzlCBhAXl/D+GTyUJA/KfIuCbdsuS5opprSrBZztqMYcGSCQJFz lE+esdbCXazdyEww5XfiGVgKiRyV2ycXyxNjekowbcDffSsOYplGBjJwPRYpESgfCYDXm+yyDQhy Xk0pxNEA7ob5fAMellN8FcgLfQtwSRcg8cYl/m8/BeVl6+eZuzCb061PdUN+mDf6erS55tXqgWJ3 toTp3GGaaOwwGs/bA1UnLqYm93RfTyL3kU1OWG8syPFMLoIwggfiMIIFyqADAgECAgEOMA0GCSqG SIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQL EyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAyNTRaFw0xMjEwMjIyMTAyNTRaMIGM MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERp Z2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmlt YXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDLKIVFnAEs+xnyq6UzjCqgDcvQVe1dIoFnRsQPCFO+y92k8RK0Pn3MbQ2Gd+mehh9GBZ+36uUQ A7Xj9AGM6wgPhEE34vKtfpAN5tJ8LcFxveDObCKrL7O5UT9WsnAZHv7OYPYSR68mdmnEnJ83M4wQ gKO19b+Rt8sPDAz9ptkQsntCn4GeJzg3q2SVc4QJTg/WHo7wF2ah5LMOeh8xJVSKGEmd6uPkSbj1 13yKMm8vmNptRPmM1+YgmVwcdOYJOjCgFtb2sOP79jji8uhWR91xx7TpM1K3hv/wrBZwffrmmEpU euXHRs07JqCCvFh9coKF4UQZvfEg+x3/69xRCzb1AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/ MAsGA1UdDwQEAwIBpjAdBgNVHQ4EFgQUrlWDb+wxyrn3HfqvazHzyB3jrLswgagGA1UdIwSBoDCB nYAUTgvvGqRAW6UXaYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEp MCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9 BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYDVR0gBIIB VDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9jZXJ0LnN0YXJ0 Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5zdGFydGNvbS5vcmcv aW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQgQ29tbWVyY2lhbCAoU3Rh cnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCByZWFkIHRoZSBzZWN0aW9uICpM ZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5 IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYw EQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIBDQRDFkFTdGFydENvbSBDbGFzcyAyIFByaW1h cnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVtYWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUF AAOCAgEAHvcQF/726YR5L5A3Ta7JV1nTu3w9yWqp00945pg7uea+1KVtR/7/yeNFAV7MPQylPE8p ROEcGU+RwwDFuNn9cePfAMzOBTpy/6VE076+gYkZa4n8uWaL5A2FVo8tRmEyfoT4gRL9B5h5w8Y4 ZySCJBLyfp4jByyxHaTTIWZ8TIkxUQLSBeFnmHKYFwYwMbBA0Sgb8ONCvq9zeJcpMkkDadhJSCfB 9c9gZocbaaVHVqTlSeENRr5/Y31dapzIRQg2Pl9V/A65Cq03KQxMXBpXn8HkLO/g2FCt7KYkJCaT e6qT2JX8thmB3nb+5RmtWQIITCP+PPNkFQCts6ujOtJx6TlDLWA+tV7QLN2Q+S98p/SwnXito+GW 0N7kXcL8QDBVsF8lCvwCz+JQrvUIcW5xEzpAVk9xSbpePxVIMzNEUQhBobkFojhUqGt+VyU3GH/+ BP2brzl4StOJ1KXuw2EzFs0ai9OMsqCUFRyhykm6MrbnsnSrqhWSnSQPYIu+zpzwWC/8sZFxoJCw vbbIu+6E+AIGa8tP+pYF+empPn/7pkIoTT4LSkkEIxGKvUvDJTh86VDNL8bIIQE2LHVDwcOq+mcQ x416FAA9Nw1DBGyrFr6hQe5yTVXrJ4G7vJosNRGCwPnx302gonaFdwi++YyqjPyhPO6q4fRarYvW yqp5L6UxggNsMIIDaAIBATCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0 ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT L1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzAJBgUr DgMCGgUAoIIBrTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMjAy MTMwMDI2MTlaMCMGCSqGSIb3DQEJBDEWBBRBt9Q2MCKmJ387OZWjbBCBMqU2OzCBpAYJKwYBBAGC NxAEMYGWMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20g Q2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgZDMIGmBgsqhkiG9w0BCRAC CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIGQzANBgkqhkiG9w0BAQEFAASC AQCnW1Zo/6ChJvQ1+iqmH1IB5JInlmtdeoSvbAB4W4nMQsuj7FVJ4dgVB7pO2umXWfbiY4BZK/+6 yuYCp8nwXA8hRv9FoATXZHYvYkGyY5lYImuwO8zCwRvaMEMXYvC5/7W3W28+ESTjafrb2Z0tlD0j s7nnkLpLSbAsiWLewSdDyCiigQTSD/5oDGn0j8Ne0twBwdXk/1YbK1FQapEX4Ns9Ue0+vkZhCJPY ysiI6w2sraTWMVXN0ZmOvMdi7ZCYC6e+LbNL0m2RPBTv9Rte4N7aGUM5722ePLJDtPnQqxwEU5Zc YCvPSHA9Fs6GPIBD6hhc+sRAVkIPogyt1sNzRabZAAAAAAAA --Apple-Mail=_E7810CD4-77F1-457C-A105-F4FCE765E90B-- From ietf@augustcellars.com Sun Feb 12 16:51:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EF4421F86B0 for ; Sun, 12 Feb 2012 16:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.381 X-Spam-Level: X-Spam-Status: No, score=-3.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAY5KvwM8hbl for ; Sun, 12 Feb 2012 16:51:33 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id D6E2221F86AA for ; Sun, 12 Feb 2012 16:51:33 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id BC6EA38EA6; Sun, 12 Feb 2012 16:51:32 -0800 (PST) From: "Jim Schaad" To: "'John Bradley'" References: <9509AB72-10CC-4BA6-A61C-AD9C4AC7944A@cisco.com> <4E1F6AAD24975D4BA5B16804296739435F7113A8@TK5EX14MBXC285.redmond.corp.microsoft.com> <109CDA9B-7427-4FB5-ADFD-4A72E82E4CAA@cisco.com> <045101cca4c3$87a77b60$96f67220$@augustcellars.com> <32DB7054-1E9F-4BFB-80EC-D5F863C1BB03@ve7jtb.com> <01c401cce9df$1d6db690$584923b0$@augustcellars.com> <2C03AE7C-C9E0-4373-AC95-B265C2F16646@ve7jtb.com> <01cd01cce9e4$9961f1d0$cc25d570$@augustcellars.com> In-Reply-To: Date: Sun, 12 Feb 2012 16:50:47 -0800 Message-ID: <01e101cce9e9$87236f80$956a4e80$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-index: AQIfXWiGz+BYDGrCkc9B4MZ2d8XmRgGqxNXOAcOgPqsBrEMyFgIUxGhfAb7pkuYCUqYwMgGl5Y1wAg9WY+cCpC1lXZUIREBQ Cc: 'Mike Jones' , jose@ietf.org Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 00:51:35 -0000 In this case there was, but normally there is not. The KDF function from ECDH-ES uses SHA-256 as it's primitive. Since the system that I was looking at had no hash functions that did not work in that context. Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Sunday, February 12, 2012 4:26 PM > To: Jim Schaad > Cc: 'Mike Jones'; jose@ietf.org > Subject: Re: [jose] comments on draft-jones-json-web-signature and draft- > jones-json-web-encryption > > I can see adding ECDH-SS for both signing and encryption. It gets you both at > the same time sort of. > > Is there a problem with reusing the KDF from ECDH-ES? > > I think I see what you are after now. > > John B. > On 2012-02-12, at 9:15 PM, Jim Schaad wrote: > > > > > > >> -----Original Message----- > >> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >> Sent: Sunday, February 12, 2012 4:05 PM > >> To: Jim Schaad > >> Cc: 'Mike Jones'; jose@ietf.org > >> Subject: Re: [jose] comments on draft-jones-json-web-signature and > draft- > >> jones-json-web-encryption > >> > >> > >> On 2012-02-12, at 8:36 PM, Jim Schaad wrote: > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: John Bradley [mailto:ve7jtb@ve7jtb.com] > >>>> Sent: Sunday, February 12, 2012 1:41 PM > >>>> To: Jim Schaad > >>>> Cc: 'David McGrew'; 'Mike Jones'; jose@ietf.org > >>>> Subject: Re: [jose] comments on draft-jones-json-web-signature and > >> draft- > >>>> jones-json-web-encryption > >>>> > >>>> Jim, > >>>> > >>>> I may be missing something. > >>>> > >>>> The scenario below is using RFC6278 and pre shared EC keys to crate a > >>> master > >>>> symmetric key to wrap a per message symmetric key used for > generating > >> a > >>>> HMAC, or to use the master symmetric key to wrap a MAC of the > >> message? > >>> > >>> It is using static-ephemeral ECDH (or ECDH-ES) to generate a symmetric > > key > >>> which uses A128KW to wrap a symmetric key which is used to MAC the > >> message. > >> > >> Ah OK you had static static that confused me. We do have ECDSA-ES for > >> encryption, but hadn't thought about it for signing, because it is more > >> integrity, without knowing the identity of the originator. > > > > Yeah - I forgot - it depends on if you want to know who sent it. If you > > want to know who sent it then you need to use static-static. But that is > > completely orthogonal to the rest of the argument. > > > >> > >>> > >>>> > >>>> For EC we only included ECDSA. > >>>> > >>>> The main difference is that with EC-DH-SS only the intended recipient > > can > >>>> verify the message. Slightly different from the ECDSA case. > >>> > >>> But not any different from the case of using a pre-shared secret key and > > a > >>> MAC algorithm. This is the current MUST implement. ECDSA is only a > >> SHOULD > >>> implement. > >> > >> I don't know that we are going to get more agreement on ECDH-ES being > a > >> MUST than ECDSA. > > > > I am not saying that it needs to be a MUST - but the current structure does > > not support it in any fashion. > > > >> > >>> > >>>> > >>>> Is the reason for this performance in a embedded environment? > >>> > >>> In the case I outlined below, yes this is an embedded system. The goal > >> was, > >>> in part, to use the fewest possible cryptographic primitives necessary. > >>> Since encryption was a requirement, there was already AES and EC > >>> shared-secret computation. Using an AES based KDF meant that there > are > >> no > >>> hash functions. Adding integrity protection as well without adding new > >>> primitives was desired. It could use EC + the AES KDF to get a key and > >>> AES-CBC (or AES-GMAC) to compute a MAC by adding only modes. > >> > >> In your original post I missed that the body was encrypted, I thought you > >> were only encrypting the key. > > > > In this case I am not encrypting the body. I am only doing an > > authentication operation. What I am looking at is the number of primitives > > that are required for the sender to be able to do both operations. > > > >> > >> Generating a unauthenticated integrity check. > >> > >> If we are talking about Encryption then ECDH-ES with AES-GWC in the > >> existing spec works. > >> We do need to add the MAC integrity check to support CBC. > >> > >> Again in ECDH-ES only the recipient is authenticated. > >> > >>> > >>>> > >>>> I think there is a general question about key wrapping vs using the > > pre- > >>>> shared or key agreement value directly. > >>>> The current specs lean towards using the values directly rather than > > for > >>> key > >>>> wrapping. > >>>> > >>>> I tend to prefer key wrapping for security, but that depends on people > >>>> actually rotating keys, and it makes the minimum message size larger. > >>> > >>> Actually it is the other way around. Not using key wrapping is more > >>> dependent on people actually rotating keys. If one uses a key > agreement > >> or > >>> key transport to carry the key, then a fresh key is being used for the > > MAC > >>> every time and there is no problems with either forward security or > >>> gathering a large number of messages with the same MAC value and > being > >> able > >>> to do things based on that. So you most likely trading off message size > > for > >>> security depending on the source of the key you are using for the MAC > >>> operation. For example if it came from the TLS session then the answer > >>> would be different. > >> > >> My confidence in people using a fresh key for the MAC each time in > >> wrapping is less than yours. > >> I admit encouraging them to do the right thing is probably the best, > > rather > >> than optimizing for there potential mistakes. > >> > > > > There are a lot of things people can do that is bad. That does not mean we > > should discourage those that want to do it correctly. > > > >> > >>> > >>>> > >>>> Is key agreement for integrity (signing) common? > >>> > >>> How common is it to use MACs? In those cases how many people are > >>> complaining because the shared keys never get rolled over? No it is not > >>> common, what is common is to have no security at all. The next is to > > have > >>> very long term shared keys for doing MACs. > >>> > >>> One could possibly argue that the entire project is a waste of time > > since > >>> all of these items are sent over a TLS session (or should be) and > > therefore > >>> the integrity of the transfer is already protected. This would mean > > that > >>> you are making for bigger messages by adding a second level of integrity > >>> protection. The question is what is the second level of integrity > >>> protection trying to protect? Is it trying to be long term or short > > term? > >>> Without knowing what the goals are, it is not possible to say that the > >>> answer is actually working correctly. > >>> > >> In general with HMAC type integrity checks people infer the identity of > > the > >> originator through the possession of the long term secret. > >> > >> The scenario you present seems to not care about the identity of the > >> originator. > > > > See above note - It actually does use a static-static. But as I can easily > > add to that to the list of "private" algorithms this is not a stumbling > > block. Note that if you look at the above I needed to add a new ECDH > > algorithm in any event since I am not using the standard KDF function. > > > > Jim > > > >> > >> Sorry if the questions are simple. > >> I am just trying to understand the use case. > >> > >> John B. > >> > >>>> > >>>> John B. > >>>> On 2011-11-16, at 9:54 PM, Jim Schaad wrote: > >>>> > >>>>> Mike, > >>>>> > >>>>> I think that while the structures for JWS might need to undergo some > >>>> changes that will mean that while the MAC and Digital Signature > >>> structures. > >>>> As I mentioned at the F2F meeting, I know of someone is doing some > >> small > >>>> device work where they are sending messages from the devices to > more > >>>> central locations. In this case there is not a pre-existing shared > > secret > >>>> generally between the two entities and they are not using TLS so they > >>> could > >>>> not derive one from the session key. Mapping what they do into the > >>> current > >>>> JWS work would require some changes. Specifically > >>>>> > >>>>> Header Object > >>>>> - contains a MAC algorithm to be used - generally AES-GMAC > >>>>> - contains a key wrapping algorithm - generally AES key wrap > >>>>> - contains a key agreement algorithm - generally EC-DH > >>>>> Key Exchange Value - the CEK wrapped by the KEK where the KEK > came > >>>> from the static-static EC-DH algorithm > >>>>> Body > >>>>> MAC value > >>>>> > >>>>> In this case we have four not three items that need to be placed in > > the > >>>> sequence of items to be sent between the originator and the verifier. > > I > >>>> would still compute the MAC value in much the same way, only I would > >>>> compute the MAC over the first three elements instead of the two > >>>> elements. > >>>>> > >>>>> This is the sort of thing that is used in a more store and forward > >>>> environment or one where the answer is going to be pre-computed or > >>>> where it needs to last longer than just the current session (i.e. later > >>>> validation). > >>>>> > >>>>> The same type of thing can be used for a long term shared KEK value > on > >>>> both the sender and recipient, where a unique CEK is generated for > each > >>>> message and wrapped. David would be a better person than I am to > >> address > >>>> the question of security. -"Do you have more security by doing an > >>> indirection > >>>> and have a fresh key for doing the MAC on each operation rather than > >> using > >>>> the long term key for doing the MAC." > >>>>> > >>>>> If we did the above change, then I would say that the "Key Exchange > >>>> Value" would become and empty string if you have a key derivied from > >> the > >>>> TLS session that you are using - but this would still lead to having > > four > >>> not > >>>> three elements in the MAC case. > >>>>> > >>>>> Jim > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >>> > > > > From matthewdgreen@gmail.com Mon Feb 13 05:46:12 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1131D21F8594 for ; Mon, 13 Feb 2012 05:46:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8W60fret-9V for ; Mon, 13 Feb 2012 05:46:11 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC5B21F8591 for ; Mon, 13 Feb 2012 05:46:11 -0800 (PST) Received: by qafi29 with SMTP id i29so1567318qaf.10 for ; Mon, 13 Feb 2012 05:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=HXN6tqA9bOn4Q7bG0fHc/0LHQTQLOvQBcAPWII0KuLw=; b=KTNQ44TpVXYOE+n4Z4RNYZUo00y1UGGUtztBpgZtaYwKYy61IFr9ChvyxgkADnJoeg 74+YeEe2ItaC/EzKNL9OAOqd3+Yx2YjPA6z9K1CA9xeysxR5ZvFT+4ga7ZwinrYKS7b+ PtHt0rJvJ3qzwP9UsMg50OYtmoFMo43WHpHWQ= Received: by 10.229.111.228 with SMTP id t36mr9576313qcp.73.1329140770081; Mon, 13 Feb 2012 05:46:10 -0800 (PST) Received: from [192.168.1.11] (c-76-21-153-251.hsd1.md.comcast.net. [76.21.153.251]) by mx.google.com with ESMTPS id fi8sm34146559qab.21.2012.02.13.05.46.08 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Feb 2012 05:46:09 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1251.1) From: Matthew Green In-Reply-To: <0BBBE883-7C70-4A7D-979C-A11418ED91F5@ve7jtb.com> Date: Mon, 13 Feb 2012 08:46:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <193BB50D-89DF-43DD-93A1-9483217BC5A1@gmail.com> <0BBBE883-7C70-4A7D-979C-A11418ED91F5@ve7jtb.com> To: jose@ietf.org X-Mailer: Apple Mail (2.1251.1) Subject: Re: [jose] comments on draft-jones-json-web-signature and draft-jones-json-web-encryption X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 13:46:12 -0000 Thanks John and Nat, I'm glad to see that the WG is considering the = issue. Please count me as strongly in favor of this protection. John, I agree with your concerns re: GCM and platform dependence. CBC = with a MAC on the ciphertext would be a perfectly good alternative. I = understand that this requires key derivation for the MAC key, but this = shouldn't be too bad. Finally -- if a first version of the spec does ship without = authentication I would advocate putting a strongly-worded warning in the = "Security Considerations" section and elsewhere throughout the document! Regards, Matt On Feb 12, 2012, at 2:58 PM, John Bradley wrote: > While it would be nice to have GWC on all platforms it is not = currently. openssl is a prime culprit at the moment.=20 From mamille2@cisco.com Mon Feb 13 10:33:45 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0F621F87B9 for ; Mon, 13 Feb 2012 10:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.688 X-Spam-Level: X-Spam-Status: No, score=-8.688 tagged_above=-999 required=5 tests=[AWL=1.911, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KWT6JdajAzSJ for ; Mon, 13 Feb 2012 10:33:44 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id BF29D21F8588 for ; Mon, 13 Feb 2012 10:33:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=mamille2@cisco.com; l=6379; q=dns/txt; s=iport; t=1329158024; x=1330367624; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=tTTKDx6J6zhb64albPP3i2IV8uJT8wMie6BVM4aCs2I=; b=Eysk2HzP55hvP9YjIiAtJDNKrQ5BqUH26AzGysnxR4jwYi8OBDsC23An RV15jaqmZkJiomFkW9pq5jsGoMB6c5yXsQ6VABh+VAUyiDCQXXPaaiTt7 d5+Qa2/TEn5xKHYz4yTvCKB0M+VmgMs7KHOy/IB72Z5sG/EtjlfnCAJXU c=; X-Files: smime.p7s : 2214 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAL1WOU+rRDoJ/2dsb2JhbABDsBSBB4FyAQEBAwESAWYFCwsOOAJVBhMih1oJnSEBlnaLPQIJBg8UAQIFBQUDCgQmBhQBBIMsBQZBBRcCBAwCB4J+YwSISoV/hmmTBA X-IronPort-AV: E=Sophos;i="4.73,412,1325462400"; d="p7s'?scan'208";a="30108801" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 13 Feb 2012 18:33:44 +0000 Received: from dhcp-64-101-72-197.cisco.com (dhcp-64-101-72-197.cisco.com [64.101.72.197]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1DIXibD021184; Mon, 13 Feb 2012 18:33:44 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/signed; boundary=Apple-Mail-4-811002771; protocol="application/pkcs7-signature"; micalg=sha1 From: Matt Miller In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436639FBD8@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Mon, 13 Feb 2012 11:33:57 -0700 Message-Id: <666D4F23-662F-4AD7-B427-1BF91EACBB1B@cisco.com> References: <4E1F6AAD24975D4BA5B16804296739436639FBD8@TK5EX14MBXC284.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1084) Cc: "jose@ietf.org" Subject: Re: [jose] Discussion of open issues in JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 18:33:45 -0000 --Apple-Mail-4-811002771 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Trimming non-considered concerns... Also, another JWE concern that was stated in Taipei and on list: * Accommodating multiple recipients On Feb 10, 2012, at 14:31, Mike Jones wrote: >=20 > =46rom = http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-00#section-= 12: >=20 > * Consider whether to add parameters for directly including = keys in the header, either as JWK Key Objects, or X.509 cert values, or = both. > As for JWS, I suspect this will be required by some use cases. Any = disagreement or discussion? >=20 I need this for my use-cases. > * Consider which of the open issues from the JWS and JWT specs = also apply here. > Having just reviewed them, the only one that seems that it may apply = is a decision on whether to create a JSON serialization whose final = representation is JSON (probably in separate specifications) in addition = to the current compact serializations, whose representation is base64url = encoded data structures. One problem with the JSON serialization is the = possible need for canonicalization algorithms. (Bear in mind that not = needing canonicalization is one of the major advantages of the present = specs over the corresponding XML ones.) I don't think, however that the = outcome of this decision will affect the current specs either way. >=20 I would concur on efforts to avoid canonicalization. I can see the = appeal to having a "JSON-Stringified" representation (e.g. value =3D = JSON.parse(JSON.parse(input).field) ), but I personally have no problem = sticking with base64 or base64url. > * Should StringOrURI use IRIs rather than RFC 3986 URIs? > Opinions? Is this a standing IETF requirement now, or is this being = handled on case-by-case basis as makes sense in context? >=20 If humans are involved, then i18n is a concern. I suspect, at the = least, "jku" and "x5u" will require support for internationalized = values. > =46rom = http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-00#section-= 7: >=20 >=20 > * Consider whether to define "alg":"none" here, rather than in the = JWT spec. > This would seem to make sense, as other application contexts may also = want this capability. Any disagreement? >=20 I would find this very useful for some of my use-cases. >=20 > * Decide whether to move the JWK algorithm family definitions "EC" = and "RSA" here. This would likely result in all the family-specific = parameter definitions also moving here ("crv", "x", "y", "mod", "exp"), = leaving very little normative text in the JWK spec itself. This seems = like it would reduce spec readability and so was not done. > After discussion, unless the WG disagrees, I propose to delete this = open issue. >=20 I personally don't see a problem with moving them, as long as there's = plenty of (expanded) examples in the affected specs. - m&m Matt Miller - Cisco Systems, Inc. --Apple-Mail-4-811002771 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFNTCCBTEw ggMZoAMCAQICAwmYMjANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEyMTQxNzQ3MTlaFw0x MjEyMTMxNzQ3MTlaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjgf4wgfswDAYDVR0TAQH/BAIwADBWBglghkgBhvhC AQ0ESRZHVG8gZ2V0IHlvdXIgb3duIGNlcnRpZmljYXRlIGZvciBGUkVFIGhlYWQgb3ZlciB0byBo dHRwOi8vd3d3LkNBY2VydC5vcmcwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMCBgorBgEE AYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIGCCsGAQUFBzAB hhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMB0GA1UdEQQWMBSBEm1hbWlsbGUyQGNpc2NvLmNvbTAN BgkqhkiG9w0BAQUFAAOCAgEAoa/WVlTWG/rbVIFlG1tCdJrbVvIWNfUNSgojunKsoaVGCoIh7T1+ SgWe8sV+r7s5bVlq66iGxTm/qoKMHM9i4aNGlwWDkXqLHoCKbY4qKPGKnn7PaoA6DWQ5u7ZKBkn9 N2fY8iLxiAy/hLnjtRLlbSr2yBX0DbO1K0ORLDwfO2MUf1j2Cou+qVvEmyEe7cUq37iOOsNbtghT xjn+RE7WJiHcR9deAkfI1xXi7UZcFME+k6nhdnX/qWFFLox0fJJCzX1H8DTzRIjA+ciNLWSG+TRx s7fAn+YZisJdkGxMcWlHZxSu+ybPjc9T7zCyf4+yFHigdOMNxiQ2k/E9WTJ84xIis2TG3E9Nba9B PMb6cgjiqGxiFpKKHj9/5A3wDIHZ8dof+M7YFGnHzwF9i72ZEoaO3hMEhAg9LhqGtQtEZohbTZL2 FOeT+8VjUHSOKhEYurQjWrHDj+ZyDjzhOE/KMwqSWokZhoy0s+VQ05BrVlbXd5DJaB/Hem0MdDUc /6IjqtI6f8O/HLQFAVUQgtW50bfCjDOAB/SaEKzygblcAHxSKDbduRQaRst6cIHEy4eQxvxrHIhg b2KWZ00jS+7NUnAMOyzIJTcZfV5mkCb8UjMHq9NSChwpBFuDzpXxjU20xJGDvbVWNDwfbITCczph p4uuhLITzvhHKaUNwxoqx0oxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYD VQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRo b3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDCZgyMAkGBSsOAwIaBQCg ggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxMzE4MzM1 N1owIwYJKoZIhvcNAQkEMRYEFPv22fOxMwXB34ERpJgG3WsG9BmiMIGRBgkrBgEEAYI3EAQxgYMw gYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIw IAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0 QGNhY2VydC5vcmcCAwmYMjCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4GA1UEChMHUm9vdCBD QTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25p bmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwmYMjANBgkq hkiG9w0BAQEFAASCAQCzXM5Lz1lxIqgeRU2lsDGQbIAuGX2j1NIZQaLqpHCousBVkjZdSdUJLaDe /0QT3qc1S1cCtpsFlOK4dtFBGRnqiplqA64Od7jzaqTgAEd/2Vj4WaYyJ387tGS4j5KozXKP57TS NN/n3AeuWq3FbDqD+6iklOrynltswq7LgTIlMy0pMXkyUNEzezmrz/FTMqhflqjRQX/wjqCcMtJ8 sfogTvFXhs3l9QaRYyJdWrLRV255Lt1jsU2i2K2Gb73aDqsnbQ1Tkv3yvSiY2HSRNrw478OP+4e+ jLRjoSorUAYOOK9TbWenSrq3Jc1TJwlQQtvGjLV5vsQIIr3FJXWEl3Z9AAAAAAAA --Apple-Mail-4-811002771-- From stpeter@stpeter.im Mon Feb 13 19:22:07 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 919D221E804A for ; Mon, 13 Feb 2012 19:22:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gr65+gPq0o5l for ; Mon, 13 Feb 2012 19:22:06 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BB39121E8043 for ; Mon, 13 Feb 2012 19:22:06 -0800 (PST) Received: from squire.local (unknown [216.17.251.49]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9E65040058; Mon, 13 Feb 2012 20:32:53 -0700 (MST) Message-ID: <4F39D35C.5060308@stpeter.im> Date: Mon, 13 Feb 2012 20:22:04 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Matt Miller References: <4E1F6AAD24975D4BA5B16804296739436639FBD8@TK5EX14MBXC284.redmond.corp.microsoft.com> <666D4F23-662F-4AD7-B427-1BF91EACBB1B@cisco.com> In-Reply-To: <666D4F23-662F-4AD7-B427-1BF91EACBB1B@cisco.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Mike Jones , "jose@ietf.org" Subject: Re: [jose] Discussion of open issues in JOSE drafts X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 03:22:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2/13/12 11:33 AM, Matt Miller wrote: > On Feb 10, 2012, at 14:31, Mike Jones wrote: > >> * Should StringOrURI use IRIs rather than RFC 3986 URIs? >> Opinions? Is this a standing IETF requirement now, or is this >> being handled on case-by-case basis as makes sense in context? >> > > If humans are involved, then i18n is a concern. I suspect, at the > least, "jku" and "x5u" will require support for internationalized > values. UTF-8-encoded Unicode codepoints can be represented in URIs using pct-encoding, so I don't necessarily see a need to directly support IRIs. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8501wACgkQNL8k5A2w/vzkLACfUem3ihTSHBkReWD1kWVzTdya tBwAoI05q1MD7bMtzOK7sVcP+X2RY1q5 =fXWp -----END PGP SIGNATURE----- From Michael.Jones@microsoft.com Thu Feb 16 12:25:37 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB35D21F8633 for ; Thu, 16 Feb 2012 12:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.788 X-Spam-Level: X-Spam-Status: No, score=-3.788 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2OT+Glnt0YDo for ; Thu, 16 Feb 2012 12:25:32 -0800 (PST) Received: from VA3EHSOBE002.bigfish.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2C7A521F8628 for ; Thu, 16 Feb 2012 12:25:32 -0800 (PST) Received: from mail14-va3-R.bigfish.com (10.7.14.236) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 Feb 2012 20:25:30 +0000 Received: from mail14-va3 (localhost [127.0.0.1]) by mail14-va3-R.bigfish.com (Postfix) with ESMTP id 633CA3003B5; Thu, 16 Feb 2012 20:25:30 +0000 (UTC) X-SpamScore: -56 X-BigFish: VS-56(zz9371I936eKc85fh148cM1444M542M1dbaL1432N98dK111aLzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail14-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail14-va3 (localhost.localdomain [127.0.0.1]) by mail14-va3 (MessageSwitch) id 1329423928401888_21896; Thu, 16 Feb 2012 20:25:28 +0000 (UTC) Received: from VA3EHSMHS033.bigfish.com (unknown [10.7.14.249]) by mail14-va3.bigfish.com (Postfix) with ESMTP id 5A811360045; Thu, 16 Feb 2012 20:25:28 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS033.bigfish.com (10.7.99.43) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 Feb 2012 20:25:26 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.12]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0247.005; Thu, 16 Feb 2012 12:25:11 -0800 From: Mike Jones To: Steffen Yount , John Bradley Thread-Topic: Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? Thread-Index: AQHM525CysEwrlAIgUatL5gULAQISJY1770AgAFCKQD//4oZkIAJQwQAgAADZCA= Date: Thu, 16 Feb 2012 20:25:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663A85D4@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <397B382EC2E6D9479F9A5D6D050FB707033ABB@WO-SFOEXCH-02.wideorbit.com> <25CABF36-27D0-4DDB-8644-58EBFEDFC4EC@ve7jtb.com> <397B382EC2E6D9479F9A5D6D050FB707033BFF@WO-SFOEXCH-02.wideorbit.com> <2ED0B3DE-CB1C-4C2E-8A66-0FD6B359368D@ve7jtb.com> <4E1F6AAD24975D4BA5B16804296739436639FEB9@TK5EX14MBXC284.redmond.corp.microsoft.com> <397B382EC2E6D9479F9A5D6D050FB7071BECF279@WO-SFOEXCH-02.wideorbit.com> In-Reply-To: <397B382EC2E6D9479F9A5D6D050FB7071BECF279@WO-SFOEXCH-02.wideorbit.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.71] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943663A85D4TK5EX14MBXC284r_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-Mailman-Approved-At: Thu, 16 Feb 2012 13:00:23 -0800 Cc: Eric Rescorla , Dirk Balfanz , "jose@ietf.org" , John Panzer , Brian Campbell , Yaron Goland , Joe Hildebrand , Paul Tarjan , Nat Sakimura , Chuck Mortimore Subject: Re: [jose] Would it be possible to add DEFLATE compression for the JWT payload into the JWT/JWS/JWE specs? X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 20:25:38 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943663A85D4TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. If you're not already a member, you should join the IETF JOSE working= group mailing list at https://www.ietf.org/mailman/listinfo/jose and discu= ss this feature request there. Ideally, you should propose specific syntax= and semantics for the proposed addition so it's concrete and can be unambi= guously understood by the working group participants. Cheers, -- Mike From: Steffen Yount [mailto:syount@wideorbit.com] Sent: Thursday, February 16, 2012 12:10 PM To: Mike Jones; John Bradley Cc: Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland; John Panze= r; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jose@ietf.org Subject: RE: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? I believe this "zip" option can be added to the spec without implying yet a= nother mandatory-to-implement feature. We have the example of only supporti= ng a subset of the encryption and signature algorithms and then providing a= discovery process for determining which of them are supported. Compression= algorithms could be optionally supported in this same way. My use-case is really about re-using JWT/JWS/JWE as simple and well defined= assertion format. I realize that this use-case is beyond the targeted usag= e of JWT/JWS/JWE as the format for OpenID Connect id_tokens. So, I will und= erstand if my use case isn't deemed important enough to warrant changes to = the specs. That said: I do believe that it does make sense to compress the content of = the JWS payload part for my implementation. (I have this implemented) Rather than implementing my own proprietary extension to JWS for this purpo= se, I would prefer to do it using a standard option. Is there anything I can do to encourage consensus and get the WG to add thi= s "zip" option to the spec for JWT/JWS headers? Thank again, -Steffen From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Friday, February 10, 2012 2:45 PM To: John Bradley; Steffen Yount Cc: Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland; John Panze= r; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jose@ietf.org<= mailto:jose@ietf.org> Subject: RE: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? Compression isn't specified in JWS thus far because every mandatory-to-impl= ement feature makes implementations that much harder to do and simplicity i= s a core goal. That being said, if the WG has a clear and compelling need = for this that outweighs the complexity downside, it could of course be adde= d. Discussion? -- Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Friday, February 10, 2012 1:46 PM To: Steffen Yount Cc: Mike Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland= ; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jo= se@ietf.org Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? The reason I had for originally proposing LZ77 with 32 bitCRC was to provid= e an integrity check against tampering when using AES-CBC encryption. If we make encryption with integrity the default I don't have any issue wit= h dropping the internal CRC. I can see your point about compressing signed tokens in the header being ea= sier if it is directly supported by the spec. I would not be opposed to that change if there is consensus in the WG to ma= ke it. John B. On 2012-02-09, at 11:32 PM, Steffen Yount wrote: Hi John, Thanks for pointing that out, I've located that reserved header parameter "= zip" in the JWE spec. (http://tools.ietf.org/html/draft-jones-json-web-encr= yption-02#section-4.1 ) Yes, I think this "zip" header should be added for JWS signing as well. My use case: I'm looking at using JWS as a Bearer token for HTTP Authorization and encod= ing multiple "scope" grants into the token. The clients will be treating th= e token as opaque data and it is not clear that they will know if a server = supports HTTP compression when their requests are made. So, I'm expecting t= hat the client's HTTP requests will be submitted uncompressed. Since I can't rely on HTTP level compression, I would like to compress the = payload before it is used in the request. Compression should reduce my toke= n size considerably, since the multiple scope grants will be repeating name= -space parts. Would it be possible to specify a "zip"=3D"DEFLATE" option too for both JWS= and JWE? * This option should rely only on RFC1951 compression without a ZLIB= header or checksum field. (a.k.a: DEFLATE with the "nowrap" option) * The difference is 18 bytes of GZIP wrapper data overhead. * When dealing with small payloads containing only few repeating par= ts, these 18 bytes are likely to leave the compressed output longer than th= e input. Thanks again, -Steffen -----Original Message----- From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Thursday, February 09, 2012 1:03 PM To: Steffen Yount Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron = Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hilde= brand; jose@ietf.org Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs? We do currently have the option of RFC1952 compression of the plain text be= fore encryption. Personally I think compression before encryption should be the default. Ot= hers prefer it as a option. We didn't add it to signing as there are existing ways to compress content = in http. If you think it needs to be added to signing then let us know. Regards John Bradley On 2012-02-09, at 4:21 PM, Steffen Yount wrote: > Hi, > > I hope this email reaches someone who can respond. I've included authors = from the various JWT specs. > > I was thinking through JSON Web Token (JWT) Bearer Token Profiles for OAu= th 2.0 draft spec (http://tools.ietf.org/html/draft-jones-oauth-jwt-bearer-= 03 ) while researching options for a REST based SSO implementation. > > One of the stated motivators for the JWT/JWS/JWE formats is compactness. = And, I want compactness in my HTTP headers. > > It has been pointed out that HTTP load times can be dramatically effected= by relatively small amounts of data in the HTTP headers. (see:http://mike.= bailey.net.au/2010/07/tcp-and-the-lower-bound-of-web-performance/ ) > > Would it be possible to add DEFLATE compression for the JWT payload into = the JWT/JWS/JWE specs? > > My suggestion here has 2 parts, each can be considered separately: > 1. Add the option to apply DEFLATE compression (omitting the ZLIB he= ader and checksum fields) on the payload before encryption/signing. (It is = important to apply the compression before the encryption, since an encrypte= d payload will contain a bunch of pseudo-random noise that isn't easily com= pressed.) This feature should be accompanied by a JWT header option to togg= le compression on/off. (Maybe something like "dfl" : true/false) > 2. Make the DEFLATE compressed payload the default behavior only req= uiring the JWT header option for disabling compression. > > I have tested it and found that: > With small payloads containing only keys and values having minimal substr= ing overlap it is possible for the DEFLATE compression to produce equivalen= t or larger output. > But I have also found that: > Payloads including keys or values with any repeated name-space parts easi= ly achieve payload size reduction. > > I believe that in common use cases compression will achieve payload size = reduction, since repeated name-space parts are likely to occur: > 1. A number of the "reserved claim names" type keys expect content o= f type "StringOrURI" which are likely to have repeated name-space parts. > 2. The specs support the "public claim names" type key extensions wh= ich will also most likely share common base URI name-space parts. > > Another benefit is that DEFLATE compression on the payload should encoura= ge the use of unique name-spaced identifiers, since DEFLATE compression rem= oves the payload size penalty otherwise incurred when repeating a common na= me-space part over and over again. > > Is this doable? > > Desired? > > What do you think of these ideas? > > Thanks for your consideration, > -Steffen > --_000_4E1F6AAD24975D4BA5B1680429673943663A85D4TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes.  If you’r= e not already a member, you should join the IETF JOSE working group mailing= list at https://www.ietf.org= /mailman/listinfo/jose and discuss this feature request there.  Id= eally, you should propose specific syntax and semantics for the proposed ad= dition so it’s concrete and can be unambiguously understood by the working group participants.

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Cheers,

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     -- Mike

 <= /p>

From: Steffen = Yount [mailto:syount@wideorbit.com]
Sent: Thursday, February 16, 2012 12:10 PM
To: Mike Jones; John Bradley
Cc: Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland; Joh= n Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jose@ie= tf.org
Subject: RE: Would it be possible to add DEFLATE compression for the= JWT payload into the JWT/JWS/JWE specs?

 

I believe this "zip&= quot; option can be added to the spec without implying yet another mandator= y-to-implement feature. We have the example of only supporting a subset of the encryption and signature algorithms and then providing a discovery = process for determining which of them are supported. Compression algorithms= could be optionally supported in this same way.

 <= /p>

My use-case is really abo= ut re-using JWT/JWS/JWE as simple and well defined assertion format. I real= ize that this use-case is beyond the targeted usage of JWT/JWS/JWE as the format for OpenID Connect id_tokens. So, I will understand if my us= e case isn’t deemed important enough to warrant changes to the specs.=

 <= /p>

That said: I do believe t= hat it does make sense to compress the content of the JWS payload part for = my implementation. (I have this implemented)

 <= /p>

Rather than implementing = my own proprietary extension to JWS for this purpose, I would prefer to do = it using a standard option.

 <= /p>

Is there anything I can d= o to encourage consensus and get the WG to add this "zip" option = to the spec for JWT/JWS headers?

 <= /p>

Thank again,

-Steffen

 <= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: Mike Jon= es [mailto:Michael.Jon= es@microsoft.com]
Sent: Friday, February 10, 2012 2:45 PM
To: John Bradley; Steffen Yount
Cc: Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron Goland; Joh= n Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hildebrand; jose@ietf.org
Subject: RE: Would it be possible to add DEFLATE compression for the= JWT payload into the JWT/JWS/JWE specs?

 

Compression isn’t s= pecified in JWS thus far because every mandatory-to-implement feature makes= implementations that much harder to do and simplicity is a core goal.  That being said, if the WG has a clear and compelling need for= this that outweighs the complexity downside, it could of course be added.&= nbsp; Discussion?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         -- Mike

 <= /p>

 

The reason I had for originally proposing LZ77 with = 32 bitCRC was to provide an integrity check against tampering when using AE= S-CBC encryption.

 

If we make encryption with integrity the default I d= on't have any issue with dropping the internal CRC.

 

I can see your point about compressing signed tokens= in the header being easier if it is directly supported by the spec.

 

I would not be opposed to that change if there is co= nsensus in the WG to make it.

 

John B.

 

 

On 2012-02-09, at 11:32 PM, Steffen Yount wrote:

 

Hi John,

 

Thanks for pointing that out, I've loca= ted that reserved header parameter "zip" in the JWE spec. (http://tools.ietf.org/html/draft-jones-json-web-encryption-02#section-= 4.1 )

 

Yes, I think this "zip" heade= r should be added for JWS signing as well.

 

My use case:

I'm looking at using JWS as a Bearer to= ken for HTTP Authorization and encoding multiple "scope" grants i= nto the token. The clients will be treating the token as opaque data and it is not clear that they will know if a server supports HTTP compress= ion when their requests are made. So, I'm expecting that the client's HTTP = requests will be submitted uncompressed.

 

Since I can't rely on HTTP level compre= ssion, I would like to compress the payload before it is used in the reques= t. Compression should reduce my token size considerably, since the multiple scope grants will be repeating name-space parts.

 

Would it be possible to specify a "= ;zip"=3D"DEFLATE" option too for both JWS and JWE?

·        This option should rely only on RFC1951 compression without a ZLIB header or ch= ecksum field. (a.k.a: DEFLATE with the "nowrap" option)

·        The difference is 18 bytes of GZIP wrapper data overhead.

·        When dealing with small payloads containing only few repeating parts, these 18 = bytes are likely to leave the compressed output longer than the input.=

 

Thanks again,

-Steffen

 

-----Original Message-----
From: John Bradley [mailto:ve= 7jtb@ve7jtb.com] 
Sent: Thursday, February 09, 2012 1:03 PM
To: Steffen Yount
Cc: Michael B. Jones; Brian Campbell; Chuck Mortimore; Dirk Balfanz; Yaron = Y. Goland; John Panzer; Nat Sakimura; Paul Tarjan; Eric Rescorla; Joe Hilde= brand; jose@ietf.org
Subject: Re: Would it be possible to add DEFLATE compression for the JWT pa= yload into the JWT/JWS/JWE specs?

 

We do currently have the option of RFC1= 952 compression of the plain text before encryption.

Personally I think compression before e= ncryption should be the default.  Others prefer it as a option.

 

We didn't add it to signing as there ar= e existing ways to compress content in http. 

 

If you think it needs to be added to si= gning then let us know.

 

Regards

John Bradley

 

 

 

On 2012-02-09, at 4:21 PM, Steffen Youn= t wrote:

 

> Hi,

> 

> I hope this email reaches someone = who can respond. I’ve included authors from the various JWT specs.

> 

> I was thinking through JSON Web To= ken (JWT) Bearer Token Profiles for OAuth 2.0 draft spec (http://tools.ietf.org/html/draft-jones-oau= th-jwt-bearer-03 ) while researching options for a REST based SSO implementation.<= /span>

> 

> One of the stated motivators for t= he JWT/JWS/JWE formats is compactness. And, I want compactness in my HTTP h= eaders.

> 

> It has been pointed out that HTTP = load times can be dramatically effected by relatively small amounts of data= in the HTTP headers. (see:http://mike.bailey.net.au/2010/07/tcp-and-the-lo= wer-bound-of-web-performance/ )

> 

> Would it be possible to add DEFLAT= E compression for the JWT payload into the JWT/JWS/JWE specs?

> 

> My suggestion here has 2 parts, ea= ch can be considered separately:

> 1.      A= dd the option to apply DEFLATE compression (omitting the ZLIB header and ch= ecksum fields) on the payload before encryption/signing. (It is important t= o apply the compression before the encryption, since an encrypted payload will contain= a bunch of pseudo-random noise that isn’t easily compressed.) This f= eature should be accompanied by a JWT header option to toggle compression o= n/off. (Maybe something like “dfl” : true/false)

> 2.      M= ake the DEFLATE compressed payload the default behavior only requiring the = JWT header option for disabling compression.

> 

> I have tested it and found that:

> With small payloads containing onl= y keys and values having minimal substring overlap it is possible for the D= EFLATE compression to produce equivalent or larger output.

> But I have also found that:

> Payloads including keys or values = with any repeated name-space parts easily achieve payload size reduction.

> 

> I believe that in common use cases= compression will achieve payload size reduction, since repeated name-space= parts are likely to occur:

> 1.      A= number of the “reserved claim names” type keys expect content = of type “StringOrURI” which are likely to have repeated name-sp= ace parts.

> 2.      T= he specs support the “public claim names” type key extensions w= hich will also most likely share common base URI name-space parts.

> 

> Another benefit is that DEFLATE co= mpression on the payload should encourage the use of unique name-spaced ide= ntifiers, since DEFLATE compression removes the payload size penalty otherwise incurred when repeating a common name-space part over an= d over again.

> 

> Is this doable?<= /p>

> 

> Desired?

> 

> What do you think of these ideas?<= o:p>

> 

> Thanks for your consideration,

> -Steffen

> 

 

--_000_4E1F6AAD24975D4BA5B1680429673943663A85D4TK5EX14MBXC284r_-- From tony@att.com Thu Feb 23 16:01:35 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AB821F8674 for ; Thu, 23 Feb 2012 16:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.201 X-Spam-Level: X-Spam-Status: No, score=-106.201 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URSob-UmeO5p for ; Thu, 23 Feb 2012 16:01:35 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id B6E0D21F8668 for ; Thu, 23 Feb 2012 16:01:34 -0800 (PST) X-Env-Sender: tony@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1330041690!17097332!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.5.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 17076 invoked from network); 24 Feb 2012 00:01:31 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Feb 2012 00:01:31 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1O0215h014881 for ; Thu, 23 Feb 2012 19:02:01 -0500 Received: from sflint01.pst.cso.att.com (sflint01.pst.cso.att.com [144.154.234.228]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id q1O01rFP014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2012 19:01:55 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint01.pst.cso.att.com (RSA Interceptor) for ; Thu, 23 Feb 2012 19:01:09 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q1O019gJ005020 for ; Thu, 23 Feb 2012 19:01:09 -0500 Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id q1O00qWu003521 for ; Thu, 23 Feb 2012 19:01:03 -0500 Received: from [135.70.250.213] (vpn-135-70-250-213.vpn.east.att.com[135.70.250.213]) by maillennium.att.com (mailgw1) with ESMTP id <20120223235831gw100e4lnbe> (Authid: tony); Thu, 23 Feb 2012 23:58:31 +0000 X-Originating-IP: [135.70.250.213] Message-ID: <4F46D333.1020604@att.com> Date: Thu, 23 Feb 2012 19:00:51 -0500 From: Tony Hansen User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: jose@ietf.org References: <20120223202034.5246.66376.idtracker@ietfa.amsl.com> In-Reply-To: <20120223202034.5246.66376.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223202034.5246.66376.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------000507000307020507020909" X-RSA-Inspected: yes X-RSA-Classifications: public X-RSA-Action: allow Subject: [jose] Fwd: jose - Requested session has been scheduled for IETF 83 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:01:35 -0000 This is a multi-part message in MIME format. --------------000507000307020507020909 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Folks, we have a JOSE slot assigned to us for IETF 83. At the moment, that puts us opposite the following: APP weirds Worthwhile Extensible Internet Registration Data Service BOF INT ancp Access Node Control Protocol WG INT lisp Locator/ID Separation Protocol WG IRTF iccrg Internet Congestion Control Research Group OPS 6renum IPv6 Site Renumbering WG RAI avtext Audio/Video Transport Extensions WG RAI vipr Verification Involving PSTN Reachability WG As always, changes to the schedule can and will occur until the schedule is "frozen". Tony Hansen JOSE co-chair -------- Original Message -------- Subject: jose - Requested session has been scheduled for IETF 83 Date: Thu, 23 Feb 2012 12:20:34 -0800 From: "IETF Secretariat" The sessions that you have requested have been scheduled. Below is the scheduled session information followed by the original request. jose Session 1 (1.5 hours) Tuesday, Afternoon Session II 1520-1700 Room Name: 241 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Javascript Object Signing and Encryption Area Name: Security Area Session Requester: Wanda Lo Number of Sessions: 1 Length of Session(s): 1.5 hours Number of Attendees: 90 --------------------------------------------------------- --------------000507000307020507020909 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Folks, we have a JOSE slot assigned to us for IETF 83. At the moment, that puts us opposite the following:

APP weirds Worthwhile Extensible Internet Registration Data Service=C2= =A0 BOF
INT ancp Access Node Control Protocol WG
INT lisp Locator/ID Separation Protocol WG
IRTF iccrg Internet Congestion Control Research Group
OPS 6renum IPv6 Site Renumbering WG
RAI avtext Audio/Video Transport Extensions WG
RAI vipr Verification Involving PSTN Reachability WG

As always, changes to the schedule can and will occur until the schedule is "frozen".

=C2=A0=C2=A0=C2=A0 Tony Hansen
=C2=A0=C2=A0=C2=A0 JOSE co-chair

-------- Original Message --------
Subje= ct: jose - Requested session has been scheduled for IETF 83
Date:= Thu, 23 Feb 2012 12:20:34 -0800
From:= "IETF Secretariat" <agenda@ietf.org> 


The sessions that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.=20

jose Session 1 (1.5 hours)
    Tuesday, Afternoon Session II 1520-1700
    Room Name: 241
    ---------------------------------------------
   =20


Request Information:

---------------------------------------------------------
Working Group Name: Javascript Object Signing and Encryption
Area Name: Security Area
Session Requester: Wanda Lo

Number of Sessions: 1
Length of Session(s):  1.5 hours
Number of Attendees: 90

---------------------------------------------------------
--------------000507000307020507020909-- From ietf@augustcellars.com Wed Feb 29 09:30:23 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20F921F8681 for ; Wed, 29 Feb 2012 09:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.402 X-Spam-Level: X-Spam-Status: No, score=-0.402 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_50=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gYhMCM-smQf for ; Wed, 29 Feb 2012 09:30:19 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id ADF8021F864F for ; Wed, 29 Feb 2012 09:30:19 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 5E99F38F0E for ; Wed, 29 Feb 2012 09:30:19 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 29 Feb 2012 09:29:31 -0800 Message-ID: <008b01ccf707$b2ed0010$18c70030$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Acz3B4G8TRdHIl/bReyPa8I2OTRwqA== Content-Language: en-us Subject: [jose] Agenda Items X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 17:30:23 -0000 As we approach the meeting it is time for us to create the agenda for = the meeting. Please let the chairs know if you have any presentations = that you want to make, what documents they relate to and about how long = you expect the presentation to take. As always the sooner you get us slides the better, I strongly urge that = they be received by the chairs before the meeting starts. Jim From Michael.Jones@microsoft.com Wed Feb 29 10:30:47 2012 Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB6D21F86BB for ; Wed, 29 Feb 2012 10:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.78 X-Spam-Level: X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZ8e1AGsHPH4 for ; Wed, 29 Feb 2012 10:30:43 -0800 (PST) Received: from DB3EHSOBE005.bigfish.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 8D86521F86A7 for ; Wed, 29 Feb 2012 10:30:39 -0800 (PST) Received: from mail44-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 Feb 2012 18:30:38 +0000 Received: from mail44-db3 (localhost [127.0.0.1]) by mail44-db3-R.bigfish.com (Postfix) with ESMTP id 93A11460328; Wed, 29 Feb 2012 18:30:38 +0000 (UTC) X-SpamScore: -26 X-BigFish: VS-26(zz9371I542Mzz1202hzz1033IL8275dhz2fh2a8h668h839h944h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail44-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Michael.Jones@microsoft.com; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail44-db3 (localhost.localdomain [127.0.0.1]) by mail44-db3 (MessageSwitch) id 1330540236640626_25723; Wed, 29 Feb 2012 18:30:36 +0000 (UTC) Received: from DB3EHSMHS001.bigfish.com (unknown [10.3.81.227]) by mail44-db3.bigfish.com (Postfix) with ESMTP id 96697420048; Wed, 29 Feb 2012 18:30:36 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS001.bigfish.com (10.3.87.101) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 Feb 2012 18:30:34 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.124]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0283.004; Wed, 29 Feb 2012 18:30:31 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Agenda Items Thread-Index: Acz3B4G8TRdHIl/bReyPa8I2OTRwqAAB8zmg Date: Wed, 29 Feb 2012 18:30:30 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943663D452A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <008b01ccf707$b2ed0010$18c70030$@augustcellars.com> In-Reply-To: <008b01ccf707$b2ed0010$18c70030$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [jose] Agenda Items X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:30:47 -0000 I and my co-authors would be glad to give presentations overviewing the pro= gress in the specs since Taipei, describing the working group feedback that= has been incorporated, and going over the remaining open issues and propos= als for moving forward with them. We'll get back to you with specific presentation proposals and durations in= the next few days. -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, February 29, 2012 9:30 AM To: jose@ietf.org Subject: [jose] Agenda Items As we approach the meeting it is time for us to create the agenda for the m= eeting. Please let the chairs know if you have any presentations that you = want to make, what documents they relate to and about how long you expect t= he presentation to take. As always the sooner you get us slides the better, I strongly urge that the= y be received by the chairs before the meeting starts. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose