From ve7jtb@ve7jtb.com Sat Mar 2 09:13:27 2013 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 5CD5421F855A for ; Sat, 2 Mar 2013 09:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qjur6Cjgfvb for ; Sat, 2 Mar 2013 09:13:26 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7421F8555 for ; Sat, 2 Mar 2013 09:13:25 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp2so2322396pbb.34 for ; Sat, 02 Mar 2013 09:13:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:content-type:subject:message-id:date:to :mime-version:x-mailer:x-gm-message-state; bh=ZJYDDnqQFusDxFPkRKgelqWBV5a2i9IXF78wLiyLmLM=; b=oSVk9d2raQ1fsjIuv+r3MUR5Z2qhEOrr7V4dVmRh+YMqbeircgl3Gty5nQDiJODvHx qc4zUEf7HXI7+850JTvjPLe97pQ3H8fs8Hqmpi8hGK7EI4XgQHcgkWwDFV5f0Dgir9nP dBoNNjJBNzDGIIdm3DaDxJ5cLSuhA+jcUz8QPlkLb6zVSrV9C0uAVXP0k+sExJCAKpTs JZuMCKvLm7leCvBwop51ZxauF++rJTxquo3t1IJVLAKUyBJtUOZ3bUCkK3xBMTTx8VgK AJIkCiWsIayfWugRT54TMA29gy81/pYAC2UsLWUkh0U775sB+b78H1xMMOn6Di6JwHrB zT3A== X-Received: by 10.68.197.106 with SMTP id it10mr7411950pbc.22.1362244404926; Sat, 02 Mar 2013 09:13:24 -0800 (PST) Received: from [192.168.10.62] (ip-64-134-234-74.public.wayport.net. [64.134.234.74]) by mx.google.com with ESMTPS id ax3sm16067265pbd.42.2013.03.02.09.13.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Mar 2013 09:13:22 -0800 (PST) From: John Bradley Content-Type: multipart/signed; boundary="Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 09:13:20 -0800 To: Group Group , "openid-connect-interop@googlegroups.com" , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQlW+ZJSpukW0AB0EUoKnNFzhf+HNBD7sktTpTf50ly4qvt9XKBUCUDS2wkeUeud1mw0KzlU Subject: [jose] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 02 Mar 2013 17:13:27 -0000 --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 Content-Type: multipart/alternative; boundary="Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E" --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect = session prior to IETF86 is now available at: http://openid-ietf-86.eventbrite.com/ Please register if you are planning on coming. We will add the room = once we know it. Regards John Bradley= --Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii The eventbrite page for people wanting to attend the openID Connect session prior to IETF86 is now available at:

Please register if you are planning on coming.  We will add the room once we know it.

Regards
John Bradley
--Apple-Mail=_8920E6B0-A5E9-4B2B-99C8-5E528DBD184E-- --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzAyMTcxMzIxWjAjBgkqhkiG9w0BCQQxFgQUNoGZ2ZF5 43lTgpmapQmFYpwMg2EwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAIW2CiOGThcHh69152zdqtxx1RKIZBrWHR86vbKhN xXpJREwnOvnCatyLPsX/HR/4TqWhkzYcPe7Hx42+FhSh1PHpXFUU4oO4dwIYum2p5CgEH4xXellC atLaKwzMuoDwS6AN15dZuUljT6Tmg+0vZdHZJ6vvxjSBkdWqlJeLWXZ/PWiyUBjFQW+xw/SunlYR QwqsDSLgdNIaAx06hwVQ8StZj9zWjQdR0HV7AESKnM/KNcaEPOcdEiA1GYvhPVMvwwz2Chp6Cemd CkBs4AtDi3WG6vSqV/1K3+yEe2w6nSzBd+dyvkDawafNG3nNUvGIKYuLu5qa4guKioLalZCzuwAA AAAAAA== --Apple-Mail=_FD8933B5-7B61-49D4-8909-3E97D5F94CB4-- From barryleiba.mailing.lists@gmail.com Sat Mar 2 11:57:41 2013 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 91A3121F85A2; Sat, 2 Mar 2013 11:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.992 X-Spam-Level: X-Spam-Status: No, score=-102.992 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 464b7KErV3PC; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id 7535821F849A; Sat, 2 Mar 2013 11:57:40 -0800 (PST) Received: by mail-ve0-f177.google.com with SMTP id m1so3764575ves.8 for ; Sat, 02 Mar 2013 11:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Lr0I1q4lLE88WKKSdKsegfB0+tVEdC0TJlVnrmC/d9c=; b=014WEoi13u7+0jvm0BE4CUhUM8jBidcDWCIl6d+SL3bqTneJb/BRp5Ba/+Y9Qbbga/ x6180K5SjH9TLsV8X9sXzVjNkht2L5/WteHE/S5RM2JlSBcPhaHYpDPs5FfxgpyC5XlF PvOrnT/iCX32i8pWHChE5kcECdbJwQpz7ERJpc1sUrLsfMZ7z4x/792QX5RERmH/yZWY SI9r1B1nw7pqCU38fWDWPTOYVP2okJyWLOC/VryVUaMdYW+zYoFuA5iRJRe7yBQmJg7F Y5XvhDmLINllqxNSTCSCw4L0HcOmpNgpdtJ92uezXSwevUC5+cjqKisPNiWTRtBuAu4c RWCQ== MIME-Version: 1.0 X-Received: by 10.220.151.5 with SMTP id a5mr5713630vcw.22.1362254259904; Sat, 02 Mar 2013 11:57:39 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.59.3.41 with HTTP; Sat, 2 Mar 2013 11:57:39 -0800 (PST) In-Reply-To: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> Date: Sat, 2 Mar 2013 14:57:39 -0500 X-Google-Sender-Auth: pIhd1ejxGyjlivjoBjTUS8778as Message-ID: From: Barry Leiba To: John Bradley Content-Type: text/plain; charset=ISO-8859-1 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 02 Mar 2013 19:57:41 -0000 > The eventbrite page for people wanting to attend the openID Connect session > prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry From tonynad@microsoft.com Sat Mar 2 16:13:00 2013 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 15AD521F85BF; Sat, 2 Mar 2013 16:13:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnaaFHd1K8gw; Sat, 2 Mar 2013 16:12:59 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 368F521F84B9; Sat, 2 Mar 2013 16:12:59 -0800 (PST) Received: from BL2FFO11FD008.protection.gbl (10.173.161.203) by BL2FFO11HUB010.protection.gbl (10.173.161.112) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 3 Mar 2013 00:12:57 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD008.mail.protection.outlook.com (10.173.161.4) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 3 Mar 2013 00:12:57 +0000 Received: from am1outboundpool.messaging.microsoft.com (157.54.51.112) by mail.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.2.318.3; Sun, 3 Mar 2013 00:12:55 +0000 Received: from mail16-am1-R.bigfish.com (10.3.201.228) by AM1EHSOBE022.bigfish.com (10.3.207.144) with Microsoft SMTP Server id 14.1.225.23; Sun, 3 Mar 2013 00:12:50 +0000 Received: from mail16-am1 (localhost [127.0.0.1]) by mail16-am1-R.bigfish.com (Postfix) with ESMTP id 055AF4402C4; Sun, 3 Mar 2013 00:12:50 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT003.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -17 X-BigFish: PS-17(zz9371I542Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275bh8275dhz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h9a9j1155h) Received-SPF: softfail (mail16-am1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT003.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1 (MessageSwitch) id 1362269563418841_14662; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from AM1EHSMHS010.bigfish.com (unknown [10.3.201.238]) by mail16-am1.bigfish.com (Postfix) with ESMTP id 625233600E5; Sun, 3 Mar 2013 00:12:43 +0000 (UTC) Received: from BL2PRD0310HT003.namprd03.prod.outlook.com (157.56.240.21) by AM1EHSMHS010.bigfish.com (10.3.207.110) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sun, 3 Mar 2013 00:12:43 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT003.namprd03.prod.outlook.com (10.255.97.38) with Microsoft SMTP Server (TLS) id 14.16.275.5; Sun, 3 Mar 2013 00:12:42 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.620.20; Sun, 3 Mar 2013 00:12:40 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.143]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.231]) with mapi id 15.00.0620.020; Sun, 3 Mar 2013 00:12:40 +0000 From: Anthony Nadalin To: Barry Leiba , John Bradley Thread-Topic: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 Thread-Index: AQHOF4A8v0OPDTa670Gnsm2UmNnS0piTGJXA Date: Sun, 3 Mar 2013 00:12:39 +0000 Message-ID: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.46.126.7] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LISTS.OPENID.NET$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%COMPUTER.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLEGROUPS.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC107.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC107.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(13464002)(23726001)(16676001)(46406002)(5343635001)(6806001)(76482001)(5343655001)(53806001)(63696002)(74662001)(44976002)(77982001)(50986001)(47976001)(56776001)(66066001)(20776003)(59766001)(15202345001)(46102001)(74502001)(47446002)(47776003)(54316002)(31966008)(51856001)(4396001)(47736001)(56816002)(80022001)(79102001)(65816001)(49866001)(50466001)(33646001)(54356001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB010; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07749F8C42 Cc: "openid-connect-interop@googlegroups.com" , Group Group , "oauth@ietf.org WG" , "" , "webfinger@ietf.org" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 03 Mar 2013 00:13:00 -0000 I thought it was Sunday -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Bar= ry Leiba Sent: Saturday, March 2, 2013 11:58 AM To: John Bradley Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG= ; ; webfinger@ietf.org Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Conn= ect at IETF#86 in Sun Mar 10 > The eventbrite page for people wanting to attend the openID Connect=20 > session prior to IETF86 is now available at: > http://openid-ietf-86.eventbrite.com/ That page says this: OpenID Meeting at IETF 86 The OpenID Foundation Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) Orlando, FL I do hope it means Thursday, 7 March. 11 April is about a month *after* the IETF meeting. Barry _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From phil.hunt@oracle.com Sat Mar 2 16:20:04 2013 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 DFF1721F84D6; Sat, 2 Mar 2013 16:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGQS7N-7Fl+9; Sat, 2 Mar 2013 16:20:04 -0800 (PST) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3C821F84D1; Sat, 2 Mar 2013 16:20:03 -0800 (PST) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r230JwkD021597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Mar 2013 00:19:59 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r230Jwxt010425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Mar 2013 00:19:58 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r230JvdO030315; Sat, 2 Mar 2013 18:19:57 -0600 Received: from [25.73.5.188] (/74.198.150.188) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 02 Mar 2013 16:19:57 -0800 References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> X-Mailer: iPhone Mail (10B146) From: Phil Hunt Date: Sat, 2 Mar 2013 16:19:51 -0800 To: Anthony Nadalin X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , John Bradley , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 03 Mar 2013 00:20:05 -0000 I should be in orlando at 7:30ish if anything is happening in the evening.=20= Phil Sent from my phone. On 2013-03-02, at 16:12, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth From leifj@mnt.se Sun Mar 3 14:41:55 2013 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 ABB5121F886D for ; Sun, 3 Mar 2013 14:41:55 -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 WzSki5d-sEHr for ; Sun, 3 Mar 2013 14:41:55 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id D8DDA21F886A for ; Sun, 3 Mar 2013 14:41:51 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id um15so2716657pbc.0 for ; Sun, 03 Mar 2013 14:41:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=iX2ck7WRzOa6BlwcaXO4+MSn6kvfYeuhrbeVgTKWtJU=; b=QLxtGR1CBDpM50IxOhCk614uqrvLj/7oVqdv1J5v8kCYF6rzicBwikSb7FrMhNy1uT z4HMYLmeU964HkKuTlWXraDEzSeuuHN6gHswv07MmVvLwBlqc+iHECblno7nvrx7fFXq +6bho2ZT4ewaMwxkBb3rSIbTsGaZpLMzAO07xOroA7EucVcC0iQhowD4sVkp01Dbd3wL XOK1568G5MDfColmfR/IAR+hyWl2xqovuU4oo/FcNa3oZwjrgy+R3hb5VfgSSrYvrJ1w cRR71ME6TlyiVTDIljkzHah5uwUJppeQcD9hYkIlJ3Y/HrOuBh968SSqZihfbRBcJB+A ZdDw== X-Received: by 10.66.145.101 with SMTP id st5mr28649756pab.162.1362350511594; Sun, 03 Mar 2013 14:41:51 -0800 (PST) Received: from [172.21.3.5] ([61.115.201.105]) by mx.google.com with ESMTPS id xr3sm19917787pbc.46.2013.03.03.14.41.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 14:41:50 -0800 (PST) Message-ID: <5133D1AB.4040401@mnt.se> Date: Sun, 03 Mar 2013 23:41:47 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmjGN0vFl4w2fHeYhmkQpPPTfr+u4NC6bmsJ20ycUYyUsPX4ULhj8KHlq/CgAEmEPpip577 Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 03 Mar 2013 22:41:55 -0000 On 03/03/2013 01:12 AM, Anthony Nadalin wrote: > I thought it was Sunday > Could somebody update the eventbrite? From ve7jtb@ve7jtb.com Sun Mar 3 14:58:54 2013 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 DADF621F88C7 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 6JbepAvU19wW for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) Received: from mail-da0-f44.google.com (mail-da0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3871F21F88C1 for ; Sun, 3 Mar 2013 14:58:54 -0800 (PST) Received: by mail-da0-f44.google.com with SMTP id z20so2223909dae.31 for ; Sun, 03 Mar 2013 14:58:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=T8Kr+HzmtrVVdvBY4TuFNjgiCxYAhUg3qffVr0bw1yk=; b=dWqAw8hVsywyXcvafmRDzlY0Ni121xxUZQkygu6rl/HG+KYDkQWTpcuH/Sgk7u65OC TjvEcBiHBaYCAH5JUcd6mbUb/Wiaalp0kQfM1p/ZLaprR9WUMEnuhJKkFH6Qb0No0tAT Fgfpg1OQYHXqgPc1+GQCvOm6p4mNH9Z/mTyHA4PBN877NoyjeWc7GI7Xj0jZV4mjeNmd cRFwF/P79cmAbQ08H0GNtw+7m+o5zkOHIy8PpU9JjtjI5VS8SJNsJYVIm2jS9wFvLSEX 7yNa1XMO+xqToFl5uPLoFu4VDxhL7FP47JK8PHTCJBXodpj1DyBtP6BfuXwaajxlICZX MN2Q== X-Received: by 10.66.87.8 with SMTP id t8mr29074421paz.28.1362351533904; Sun, 03 Mar 2013 14:58:53 -0800 (PST) Received: from [10.186.239.43] ([61.213.4.2]) by mx.google.com with ESMTPS id hu2sm19966287pbc.38.2013.03.03.14.58.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 14:58:52 -0800 (PST) References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Mime-Version: 1.0 (1.0) In-Reply-To: <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <8FCA9E2B-78C5-4C60-BEC2-0DF10600A7BE@ve7jtb.com> X-Mailer: iPhone Mail (10B146) From: John Bradley Date: Mon, 4 Mar 2013 07:58:50 +0900 To: Anthony Nadalin X-Gm-Message-State: ALoCoQkTY25LNPWwi8HkFNI8G7cxomXeuMPIk8U42Mo92YNTNjZQJF3RJgMwpGlBJO4yqE5UTEsp Cc: Barry Leiba , "openid-connect-interop@googlegroups.com" , "" , "webfinger@ietf.org" , Group Group , "oauth@ietf.org WG" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 03 Mar 2013 22:58:55 -0000 --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable The title Sunday Mar 10 is the correct date. I will update the event.=20 Sorry don't know why the date is wrong.=20 Sent from my iPhone On 2013-03-03, at 9:12 AM, Anthony Nadalin wrote: > I thought it was Sunday >=20 > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ba= rry Leiba > Sent: Saturday, March 2, 2013 11:58 AM > To: John Bradley > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.org W= G; ; webfinger@ietf.org > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Con= nect at IETF#86 in Sun Mar 10 >=20 >> The eventbrite page for people wanting to attend the openID Connect=20 >> session prior to IETF86 is now available at: >> http://openid-ietf-86.eventbrite.com/ >=20 > That page says this: > OpenID Meeting at IETF 86 > The OpenID Foundation > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > Orlando, FL >=20 > I do hope it means Thursday, 7 March. 11 April is about a month > *after* the IETF meeting. >=20 > Barry > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwMzIyNTg1MlowIwYJKoZIhvcNAQkEMRYEFHoU Un2mvlAgj6PGvrOK7kAGVdeUMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBACPvAuSNf7VayrPjy8fhaGuQMESoT/GIvHsu 9XyHXwNcfPPxdWWIABHujKei0X/i6dG+VHkKs+P2nZPYB6f9m3QqdxUzUd180SWMXLvxzLMoFPQO X9lh50LmyVNeVOlrBZEQiAiN/c7c9ew5NNJRyk/pGEj53secKFMsW/vMvg10GBhuVuKuS3xlsyE1 Wu0MYrb7RkqqhRvrXxTxP3nwH0KKreUrh0v0LmyEOd8Y7ZTNqP/mtnGGLo6o0Jkm+y+p/UZaqIRs RtJYp3ukn24bPyxFXodrZR+MWoqrKL0L79SCtsPB4o17OK3vr6D3FFUv6zxQdXxklL35aTRHXvc2 ZyYAAAAAAAA= --Apple-Mail-53EDFDD5-BA90-4CA7-AA11-847A3F4AA553-- From ve7jtb@ve7jtb.com Sun Mar 3 15:05:39 2013 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 B846921F8899 for ; Sun, 3 Mar 2013 15:05:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 DldKWszgmbsm for ; Sun, 3 Mar 2013 15:05:39 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 0825521F8569 for ; Sun, 3 Mar 2013 15:05:38 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id bh2so2802984pad.30 for ; Sun, 03 Mar 2013 15:05:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=0sVZW7XCWdOLS37WtFKotCBFEg7xY0jwlGe02AJX8Ck=; b=L3KpocTaQ07aK+IacLIYcgslK48o/8rH9T5VjbG/0Cqb/4w+Y1ukkwwNpd2yAjBwSz 8yC88rF4/EiLHCTfnkUAxb/t3MpGZCHPeMqdefoghDqLO7rJtZ7p/2GoHTg+Us2aCptE OXBTUkYqNalLEkTgPxKgtR27ObX0ZoKH5k6qeIrg8gcO9rPpriZiIqBfAXQP2eflQtZk 6lAv4rV4+EA8zOG5lNih06WE99gnOHL3vniVDdZX89+jTGaOppdA/t39N/vkzuY/cDrm VBnfHydC0biNtrNZi5o+5rTZuGQW0jdrrXzCwxG1bI+U8PYwZO9u33OFLS2mhXNVfRbz ffiA== X-Received: by 10.66.74.197 with SMTP id w5mr29093091pav.60.1362351938673; Sun, 03 Mar 2013 15:05:38 -0800 (PST) Received: from [10.186.231.30] ([61.213.4.2]) by mx.google.com with ESMTPS id z6sm21485167pav.3.2013.03.03.15.05.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 03 Mar 2013 15:05:37 -0800 (PST) References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> <5133D1AB.4040401@mnt.se> Mime-Version: 1.0 (1.0) In-Reply-To: <5133D1AB.4040401@mnt.se> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-A80B0381-1C73-472B-B34A-F611DE84A050; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPad Mail (10B146) From: John Bradley Date: Mon, 4 Mar 2013 08:05:24 +0900 To: Leif Johansson X-Gm-Message-State: ALoCoQkhQ+pinpEhF3fYrJ6jRln03mGZE9FwmI/YV1/m26KeUrJo2iyMOs4TU8oS8tfzQWLXWpWr Cc: "jose@ietf.org" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 03 Mar 2013 23:05:39 -0000 --Apple-Mail-A80B0381-1C73-472B-B34A-F611DE84A050 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fixed Sent from my iPad On 2013-03-04, at 7:41 AM, Leif Johansson wrote: > On 03/03/2013 01:12 AM, Anthony Nadalin wrote: >> I thought it was Sunday > Could somebody update the eventbrite? > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail-A80B0381-1C73-472B-B34A-F611DE84A050 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHuTCCB7Uw ggadoAMCAQICAh5cMA0GCSqGSIb3DQEBBQUAMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3Rh cnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0Ew HhcNMTIwMzE4MDQzMjQ4WhcNMTQwMzE5MTEwNzMyWjCBmzEZMBcGA1UEDRMQR3JUTTZMUzdYMzU3 NzhzOTELMAkGA1UEBhMCQ0wxIjAgBgNVBAgTGU1ldHJvcG9saXRhbmEgZGUgU2FudGlhZ28xFjAU BgNVBAcTDUlzbGEgZGUgTWFpcG8xFTATBgNVBAMTDEpvaG4gQnJhZGxleTEeMBwGCSqGSIb3DQEJ ARYPamJyYWRsZXlAbWUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAskrlBI93 rBTLOQGSwIT6co6dAw/rwDPrRXl6/F2oc4KDn+QN6CdFeHo08H846VJS9CDjLKvnK9jbxxs4wYqe nKdPb3jgzt8oc7b9ZXtWkOgsxgMf6dBZ/IPm4lWBpCbSr3seDGDXEpiE2lTZXno7c25OguR4E6Qa hcpHABZjeEWK65mMH25gmoRf5MY1k3quu5y+FCYCHE2iwU5jzq+mI3HmG59+UMFLx1fjV+zTslRw 26cQDC/uepwjeYSp8S26hfWipVWwQj4js/C7RoPtvt2iyeU+LSH81jG4wlAWntiOG1WtoXUuXWSc ExhciKeKWCnemy9qqmxRfJqBROeGlQIDAQABo4IEDjCCBAowCQYDVR0TBAIwADALBgNVHQ8EBAMC BLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBQ/A7/CxKEnzpqmZlLz 9iaQMy24eTAfBgNVHSMEGDAWgBSuVYNv7DHKufcd+q9rMfPIHeOsuzB+BgNVHREEdzB1gQ9qYnJh ZGxleUBtZS5jb22BD2picmFkbGV5QG1lLmNvbYEQamJyYWRsZXlAbWFjLmNvbYERdmU3anRiQHZl N2p0Yi5jb22BE2picmFkbGV5QHdpbmdhYS5jb22BF2pvaG4uYnJhZGxleUB3aW5nYWEuY29tMIIC IQYDVR0gBIICGDCCAhQwggIQBgsrBgEEAYG1NwECAjCCAf8wLgYIKwYBBQUHAgEWImh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cuc3RhcnRz c2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgfcGCCsGAQUFBwICMIHqMCcWIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MAMCAQEagb5UaGlzIGNlcnRpZmljYXRlIHdhcyBpc3N1ZWQgYWNj b3JkaW5nIHRvIHRoZSBDbGFzcyAyIFZhbGlkYXRpb24gcmVxdWlyZW1lbnRzIG9mIHRoZSBTdGFy dENvbSBDQSBwb2xpY3ksIHJlbGlhbmNlIG9ubHkgZm9yIHRoZSBpbnRlbmRlZCBwdXJwb3NlIGlu IGNvbXBsaWFuY2Ugb2YgdGhlIHJlbHlpbmcgcGFydHkgb2JsaWdhdGlvbnMuMIGcBggrBgEFBQcC AjCBjzAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTADAgECGmRMaWFiaWxpdHkg YW5kIHdhcnJhbnRpZXMgYXJlIGxpbWl0ZWQhIFNlZSBzZWN0aW9uICJMZWdhbCBhbmQgTGltaXRh dGlvbnMiIG9mIHRoZSBTdGFydENvbSBDQSBwb2xpY3kuMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUyLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MyL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMi5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAEcfD4PmHrX+W3zaP/KsR4gwLAL0UTaMz14SIng6a9F3kb8ZDbTUneS9ubgpqeJQP2IFc 0U5gQnJ3XeCH6p9I88mvm1NqKQw8WvfglS0aIS19vfpTgXJSPdIO2JJPRqaBtXf3zkdXJwckX9/d NMrLGeGvaFT9fUNdQdHU4BI1pVUpgKr796T7LTc/ERfH8iFp1+CmdVkJ6Y2iJdWUp4h17XmbxbIT 0CdS4SSk/VW8LFsn/mVz6hB73VthwjGsIku54Wp4pRuq1KX+pATnRk3pHRa1z3mxJMmq7OEXENcC Vm+bAnyUrYbUilNS9UVTYS8/3dVsKiNupBaOZO+vOgJqVDGCA2wwggNoAgEBMIGTMIGMMQswCQYD VQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwg Q2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IElu dGVybWVkaWF0ZSBDbGllbnQgQ0ECAh5cMAkGBSsOAwIaBQCgggGtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMDMwMzIzMDUzNVowIwYJKoZIhvcNAQkEMRYEFAAk SX+UMLllLC9eT2Vh/y8FzhMwMIGkBgkrBgEEAYI3EAQxgZYwgZMwgYwxCzAJBgNVBAYTAklMMRYw FAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQQICHlwwgaYGCyqGSIb3DQEJEAILMYGWoIGTMIGMMQswCQYDVQQGEwJJTDEWMBQG A1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMiBQcmltYXJ5IEludGVybWVkaWF0ZSBD bGllbnQgQ0ECAh5cMA0GCSqGSIb3DQEBAQUABIIBAEas9IrPFxNr7/ylSbhtIF7cniGDl1NAct48 oeh/SAAkckObWap8EONjtB21GEAWUAyPg2I6iRzu3Mft3hGucOYspq/WRdCpBm1t9JQXsRXzwcI2 4zaUv9dZKmJVhG8vRKTP353JxHiFD9Z1HXBgdTP9L/wNCLXtVAfPHvc2fiuOO/83Xx4CG2JpKNq3 BEj0PlV6FBe01fJQ28jevbT1yxdht87rBLQIKsfOnae+ZWHFqboIwvXJpYWYFmypZOamJDC8Z+Sk jh5lhSThS9R9BcZl8SkN81XoZ4WL6aRPyloyMDDWl7IOXUdlCJz6/1+kiXHuiYejSa3mhl+mBmcC jmMAAAAAAAA= --Apple-Mail-A80B0381-1C73-472B-B34A-F611DE84A050-- From mpeck@mitre.org Sun Mar 3 20:00:08 2013 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 3934621F87E4 for ; Sun, 3 Mar 2013 20:00:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[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 ynBfDzyfqD1v for ; Sun, 3 Mar 2013 20:00:06 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 427AF21F8771 for ; Sun, 3 Mar 2013 20:00:03 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9A48D5310524 for ; Sun, 3 Mar 2013 23:00:02 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8AE765310525 for ; Sun, 3 Mar 2013 23:00:02 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.200]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Sun, 3 Mar 2013 23:00:02 -0500 From: "Peck, Michael A" To: "jose@ietf.org" Thread-Topic: Comments on json-web-algorithms-08 encryption Thread-Index: Ac4YjL7i8+BHLB75RcuBC+JqdGVjOQ== Date: Mon, 4 Mar 2013 04:00:02 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321E791714@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321E791714IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [jose] Comments on json-web-algorithms-08 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, 04 Mar 2013 04:00:08 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321E791714IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have comments on how encryption is performed as defined in draft-ietf-jos= e-json-web-algorithms-08 . Section 4.2: The content encryption algorithms defined in Section 4.2 are all AEAD algor= ithms. I would suggest using the RFC 5116 authenticated encryption interfa= ce for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as defined in th= at RFC, and the AES-CBC+HMAC algorithms defined in draft-mcgrew-aead-aes-cb= c-hmac-sha2). This would provide an opportunity for consistency across IET= F protocols and the potential for easier re-use of crypto library code that= properly handles the details of authenticated encryption. I see there was= discussion along these lines on the mailing list last November but did not= see any outcome. Section 4.6: The "Direct Encryption with a Shared Symmetric Key" option seems to not be = safe to use with AES-GCM because of the risk of re-using the same key and I= V pair. One potential way to resolve this may be for the sender to provide= a nonce (equal to the size of the shared symmetric key), and the sender an= d recipient combine the nonce with their shared symmetric key to form the C= MK. For example, based on RFC 5869 Section 2.2, CMK =3D HMAC-SHA-256(HMAC = key =3D nonce, HMAC message input =3D shared symmetric key). Section 4.8 - A128CBC+HS256 and A256CBC+HS512: I don't understand why AES-128 is combined with HMAC-SHA-256 with a full 25= 6-bit authentication tag, and similarly why AES-256 is combined with HMAC-S= HA-512 with a full 512-bit authentication tag. Section 4.8 states that the= integrity check provides "matching strength" but in these cases the integr= ity check provides twice the strength of the encryption. Instead, how about truncating the HMAC output in half? Then the HMAC key c= an also be truncated in half, and the CMK will only need to be the length o= f the encryption key leading to additional compactness (and less chance of = confusion about the provided security level). draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates the authentication ta= g. draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to be provided a key that i= s of the form ENC_KEY || MAC_KEY, but the JWE CMK could still be used in a = way that is compatible: just have JWE take its CMK and derive ENC_KEY || MA= C_KEY before calling the aead-aes-cbc-hmac-sha2 interface. Thanks, Mike --_000_8B4C063947CD794BB6FF90C78BAE9B321E791714IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have comments on how encryption is performed as de= fined in draft-ietf-jose-json-web-algorithms-08 .

 

Section 4.2:

The content encryption algorithms defined in Section= 4.2 are all AEAD algorithms.  I would suggest using the RFC 5116 auth= enticated encryption interface for all of these (AEAD_AES_128_GCM and AEAD_= AES_256_GCM as defined in that RFC, and the AES-CBC+HMAC algorithms defined in draft-mcgrew-aead-aes-cbc-hmac-= sha2).  This would provide an opportunity for consistency across IETF = protocols and the potential for easier re-use of crypto library code that p= roperly handles the details of authenticated encryption.  I see there was discussion along these lines on the mail= ing list last November but did not see any outcome.

 

Section 4.6:

The “Direct Encryption with a Shared Symmetric= Key” option seems to not be safe to use with AES-GCM because of the = risk of re-using the same key and IV pair.  One potential way to resol= ve this may be for the sender to provide a nonce (equal to the size of the shared symmetric key), and the sender and recipient com= bine the nonce with their shared symmetric key to form the CMK.  For e= xample, based on RFC 5869 Section 2.2, CMK =3D HMAC-SHA-256(HMAC key =3D no= nce, HMAC message input =3D shared symmetric key).

 

Section 4.8 - A128CBC+HS256 and A256CBC+HS51= 2:

I don’t understand why AES-128 is combined wit= h HMAC-SHA-256 with a full 256-bit authentication tag, and similarly why AE= S-256 is combined with HMAC-SHA-512 with a full 512-bit authentication tag.=   Section 4.8 states that the integrity check provides “matching strength” but in these cases the inte= grity check provides twice the strength of the encryption. 

Instead, how about truncating the HMAC output in hal= f?  Then the HMAC key can also be truncated in half, and the CMK will = only need to be the length of the encryption key leading to additional comp= actness (and less chance of confusion about the provided security level). 

draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncate= s the authentication tag.  draft-mcgrew-aead-aes-cbc-hmac-sha2 expects= to be provided a key that is of the form ENC_KEY || MAC_KEY, but the JWE C= MK could still be used in a way that is compatible: just have JWE take its CMK and derive ENC_KEY || MAC_KEY befor= e calling the aead-aes-cbc-hmac-sha2 interface.

 

 

Thanks,

Mike

 

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321E791714IMCMBX04MITREOR_-- From rlb@ipv.sx Mon Mar 4 13:29:02 2013 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 15EE621F8A98 for ; Mon, 4 Mar 2013 13:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QRzUC68ZL2W5 for ; Mon, 4 Mar 2013 13:29:01 -0800 (PST) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3844821F85D9 for ; Mon, 4 Mar 2013 13:29:01 -0800 (PST) Received: by mail-oa0-f52.google.com with SMTP id k14so9661598oag.39 for ; Mon, 04 Mar 2013 13:29:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/qgdvmvXCjOWXxLSnlDh6OTn4Up5Qofh6fQYFugRk+I=; b=VS/jZ1V8157HDgwuJYdU9rHOV+5Z6HnTSmoXCU32HOclec5W2yKGjjr5q/AOiwHsF1 PfSRHnAhNoslcWxNN5ETi33nzXJHvYDWHuiJ62Crs8G/u96w/yjBH/7S6CI2Mzh5MpCb amHCaiEhMv9yrtJvLKoVJ+yNLQzQlLjFs0syAbxTPWk/+uH3l9mi433gJ5WHnUkyfVo0 9bi6OGytBqFpZLU19ya/dnJw6OWw9MktoQ46LatWT/KT8TzfIeAaQgq/VA2CDa6xkks0 o+tknmT6GnmxHSqRKPPnf7AqKAPmf//1b9LMebgEbO8DNA8swsNgSGKAwKIKw22q/oTQ 469w== MIME-Version: 1.0 X-Received: by 10.182.144.40 with SMTP id sj8mr16735561obb.82.1362432540711; Mon, 04 Mar 2013 13:29:00 -0800 (PST) Received: by 10.60.10.101 with HTTP; Mon, 4 Mar 2013 13:29:00 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E791714@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E791714@IMCMBX04.MITRE.ORG> Date: Mon, 4 Mar 2013 16:29:00 -0500 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=14dae939992d9eff4604d7200bcf X-Gm-Message-State: ALoCoQlLghsi4ZazNookgbLUbyFGvKkhO9dQVVWwKlBLu7gbcKan4EmWHRVjJWOeY1gQmEVF+jJI Cc: "jose@ietf.org" Subject: Re: [jose] Comments on json-web-algorithms-08 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, 04 Mar 2013 21:29:02 -0000 --14dae939992d9eff4604d7200bcf Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable These are excellent comments. Thanks, Mike. A couple of comments inline. Section 4.2:**** > > The content encryption algorithms defined in Section 4.2 are all AEAD > algorithms. I would suggest using the RFC 5116 authenticated encryption > interface for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as > defined in that RFC, and the AES-CBC+HMAC algorithms defined in > draft-mcgrew-aead-aes-cbc-hmac-sha2). This would provide an opportunity > for consistency across IETF protocols and the potential for easier re-use > of crypto library code that properly handles the details of authenticated > encryption. I see there was discussion along these lines on the mailing > list last November but did not see any outcome. > This should definitely be done, for the consistency reasons noted. If we do this, and use draft-mcgrew-aead-aes-cbc-hmac-sha2 as the general AEAD framework, then we can get rid of the separate ICV field in JWE. Section 4.6:**** > > The =93Direct Encryption with a Shared Symmetric Key=94 option seems to n= ot be > safe to use with AES-GCM because of the risk of re-using the same key and > IV pair. One potential way to resolve this may be for the sender to > provide a nonce (equal to the size of the shared symmetric key), and the > sender and recipient combine the nonce with their shared symmetric key to > form the CMK. For example, based on RFC 5869 Section 2.2, CMK =3D > HMAC-SHA-256(HMAC key =3D nonce, HMAC message input =3D shared symmetric = key). > When direct encryption is done with GCM (alg=3Ddir, enc=3DA128GCM), the key= is re-used, but a new IV is generated for every message. From Section 4.9: "U= se of an initialization vector of size 96 bits is REQUIRED with this algorithm= " That helps to mitigate the problem of key/IV re-use. But I agree that this is fragile; if IVs repeat, everything breaks. That seems like yet another argument for just disallowing direct encryption and requiring a random CMK. > ** > > Section 4.8 - A128CBC+HS256 and A256CBC+HS512:**** > > I don=92t understand why AES-128 is combined with HMAC-SHA-256 with a ful= l > 256-bit authentication tag, and similarly why AES-256 is combined with > HMAC-SHA-512 with a full 512-bit authentication tag. Section 4.8 states > that the integrity check provides =93matching strength=94 but in these ca= ses > the integrity check provides twice the strength of the encryption. **** > > Instead, how about truncating the HMAC output in half? Then the HMAC key > can also be truncated in half, and the CMK will only need to be the lengt= h > of the encryption key leading to additional compactness (and less chance = of > confusion about the provided security level). **** > > draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates the authentication > tag. draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to be provided a key th= at > is of the form ENC_KEY || MAC_KEY, but the JWE CMK could still be used in= a > way that is compatible: just have JWE take its CMK and derive ENC_KEY || > MAC_KEY before calling the aead-aes-cbc-hmac-sha2 interface > Or we could just have CMK =3D=3D ENC_KEY || MAC_KEY. That would avoid the issues with FIPS noted in Issue 3. --Richard --14dae939992d9eff4604d7200bcf Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable These are excellent comments. =A0Thanks, Mike. =A0A couple of comments inli= ne. =A0

Section 4.2:

The content encryption algorithms defined in Section= 4.2 are all AEAD algorithms.=A0 I would suggest using the RFC 5116 authent= icated encryption interface for all of these (AEAD_AES_128_GCM and AEAD_AES= _256_GCM as defined in that RFC, and the AES-CBC+HMAC algorithms defined in draft-mcgrew-aead-aes-cbc-hmac-sha2= ).=A0 This would provide an opportunity for consistency across IETF protoco= ls and the potential for easier re-use of crypto library code that properly= handles the details of authenticated encryption.=A0 I see there was discussion along these lines on the mailing= list last November but did not see any outcome.


This should definitely be done, for the consistency r= easons noted. =A0If we do this, and use draft-mcgrew-aead-aes-cbc-hmac-sha2= as the general AEAD framework, then we can get rid of the separate ICV fie= ld in JWE.
=A0

Section 4.6:

The =93Direct Encryption with a Shared Symmetric Key= =94 option seems to not be safe to use with AES-GCM because of the risk of = re-using the same key and IV pair. =A0One potential way to resolve this may= be for the sender to provide a nonce (equal to the size of the shared symmetric key), and the sender and recipient com= bine the nonce with their shared symmetric key to form the CMK.=A0 For exam= ple, based on RFC 5869 Section 2.2, CMK =3D HMAC-SHA-256(HMAC key =3D nonce= , HMAC message input =3D shared symmetric key).


When direct encrypti= on is done with GCM (alg=3Ddir, enc=3DA128GCM), the key is re-used, but a n= ew IV is generated for every message. =A0From Section 4.9: "Use of an initialization vector of size 96 bits is REQU= IRED with this=A0algorithm"= ; =A0That helps to mitigate the problem of key/IV re-use. =A0But I agree th= at this is fragile; if IVs repeat, everything breaks. =A0That seems like ye= t another argument for just disallowing direct encryption and requiring a r= andom CMK.

=A0=A0

<= /p>

Section 4.8 - A128CBC+HS256 and A256CBC+HS512:

I don=92t understand why AES-128 is combined with HM= AC-SHA-256 with a full 256-bit authentication tag, and similarly why AES-25= 6 is combined with HMAC-SHA-512 with a full 512-bit authentication tag.=A0 = Section 4.8 states that the integrity check provides =93matching strength=94 but in these cases the integrity ch= eck provides twice the strength of the encryption.=A0

Instead, how about truncating the HMAC output in hal= f?=A0 Then the HMAC key can also be truncated in half, and the CMK will onl= y need to be the length of the encryption key leading to additional compact= ness (and less chance of confusion about the provided security level).=A0

draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncate= s the authentication tag.=A0 draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to= be provided a key that is of the form ENC_KEY || MAC_KEY, but the JWE CMK = could still be used in a way that is compatible: just have JWE take its CMK and derive ENC_KEY || MAC_KEY befor= e calling the aead-aes-cbc-hmac-sha2 interface

=

Or we could just have CMK =3D=3D ENC_KEY || MAC_KEY. = =A0That would avoid the issues with FIPS noted in Issue 3.

--Richar= d

=A0
--14dae939992d9eff4604d7200bcf-- From ietf@augustcellars.com Mon Mar 4 18:03:26 2013 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 3F59111E80E8 for ; Mon, 4 Mar 2013 18:03:26 -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=[AWL=-0.001, 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 SnS8ojSUF2Zv for ; Mon, 4 Mar 2013 18:03:24 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ECB511E80BA for ; Mon, 4 Mar 2013 18:03:24 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C5A632CA11; Mon, 4 Mar 2013 18:03:21 -0800 (PST) From: "Jim Schaad" To: "'Peck, Michael A'" , References: <8B4C063947CD794BB6FF90C78BAE9B321E791714@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E791714@IMCMBX04.MITRE.ORG> Date: Mon, 4 Mar 2013 21:02:48 -0500 Message-ID: <009501ce1945$8a5c84c0$9f158e40$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0096_01CE191B.A1874010" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG4Cocwf5TRHKffQ+9R8hC+5Bt1NpjCdVZA Content-Language: en-us Subject: Re: [jose] Comments on json-web-algorithms-08 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: Tue, 05 Mar 2013 02:03:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0096_01CE191B.A1874010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A Sent: Sunday, March 03, 2013 11:00 PM To: jose@ietf.org Subject: [jose] Comments on json-web-algorithms-08 encryption Hi, I have comments on how encryption is performed as defined in draft-ietf-jose-json-web-algorithms-08 . Section 4.2: The content encryption algorithms defined in Section 4.2 are all AEAD algorithms. I would suggest using the RFC 5116 authenticated encryption interface for all of these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as defined in that RFC, and the AES-CBC+HMAC algorithms defined in draft-mcgrew-aead-aes-cbc-hmac-sha2). This would provide an opportunity for consistency across IETF protocols and the potential for easier re-use of crypto library code that properly handles the details of authenticated encryption. I see there was discussion along these lines on the mailing list last November but did not see any outcome. [JLS] I would note that S/MIME AuthEnvelopedData [RFC 5083] does not use this interface - so you will be consistent with somebody either way. Section 4.6: The "Direct Encryption with a Shared Symmetric Key" option seems to not be safe to use with AES-GCM because of the risk of re-using the same key and IV pair. One potential way to resolve this may be for the sender to provide a nonce (equal to the size of the shared symmetric key), and the sender and recipient combine the nonce with their shared symmetric key to form the CMK. For example, based on RFC 5869 Section 2.2, CMK = HMAC-SHA-256(HMAC key = nonce, HMAC message input = shared symmetric key). Section 4.8 - A128CBC+HS256 and A256CBC+HS512: I don't understand why AES-128 is combined with HMAC-SHA-256 with a full 256-bit authentication tag, and similarly why AES-256 is combined with HMAC-SHA-512 with a full 512-bit authentication tag. Section 4.8 states that the integrity check provides "matching strength" but in these cases the integrity check provides twice the strength of the encryption. Instead, how about truncating the HMAC output in half? Then the HMAC key can also be truncated in half, and the CMK will only need to be the length of the encryption key leading to additional compactness (and less chance of confusion about the provided security level). draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates the authentication tag. draft-mcgrew-aead-aes-cbc-hmac-sha2 expects to be provided a key that is of the form ENC_KEY || MAC_KEY, but the JWE CMK could still be used in a way that is compatible: just have JWE take its CMK and derive ENC_KEY || MAC_KEY before calling the aead-aes-cbc-hmac-sha2 interface. Thanks, Mike ------=_NextPart_000_0096_01CE191B.A1874010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Peck, Michael A
Sent: Sunday, March 03, 2013 11:00 = PM
To: jose@ietf.org
Subject: [jose] Comments on = json-web-algorithms-08 encryption

 

Hi,

 

I have = comments on how encryption is performed as defined in = draft-ietf-jose-json-web-algorithms-08 .

 

Section = 4.2:

The content encryption = algorithms defined in Section 4.2 are all AEAD algorithms.  I would = suggest using the RFC 5116 authenticated encryption interface for all of = these (AEAD_AES_128_GCM and AEAD_AES_256_GCM as defined in that RFC, and = the AES-CBC+HMAC algorithms defined in = draft-mcgrew-aead-aes-cbc-hmac-sha2).  This would provide an = opportunity for consistency across IETF protocols and the potential for = easier re-use of crypto library code that properly handles the details = of authenticated encryption.  I see there was discussion along = these lines on the mailing list last November but did not see any = outcome.

 

[JLS] I would note that = S/MIME AuthEnvelopedData [RFC 5083] does not use this interface – = so you will be consistent with somebody either = way.

 

Section 4.6:

The = “Direct Encryption with a Shared Symmetric Key” option seems = to not be safe to use with AES-GCM because of the risk of re-using the = same key and IV pair.  One potential way to resolve this may be for = the sender to provide a nonce (equal to the size of the shared symmetric = key), and the sender and recipient combine the nonce with their shared = symmetric key to form the CMK.  For example, based on RFC 5869 = Section 2.2, CMK =3D HMAC-SHA-256(HMAC key =3D nonce, HMAC message input = =3D shared symmetric key).

 

Section 4.8 = - A128CBC+HS256 and A256CBC+HS512:

I = don’t understand why AES-128 is combined with HMAC-SHA-256 with a = full 256-bit authentication tag, and similarly why AES-256 is combined = with HMAC-SHA-512 with a full 512-bit authentication tag.  Section = 4.8 states that the integrity check provides “matching = strength” but in these cases the integrity check provides twice = the strength of the encryption. 

Instead, how about truncating the HMAC output in = half?  Then the HMAC key can also be truncated in half, and the CMK = will only need to be the length of the encryption key leading to = additional compactness (and less chance of confusion about the provided = security level). 

draft-mcgrew-aead-aes-cbc-hmac-sha2 already truncates = the authentication tag.  draft-mcgrew-aead-aes-cbc-hmac-sha2 = expects to be provided a key that is of the form ENC_KEY || MAC_KEY, but = the JWE CMK could still be used in a way that is compatible: just have = JWE take its CMK and derive ENC_KEY || MAC_KEY before calling the = aead-aes-cbc-hmac-sha2 interface.

 

 

Thanks,

Mike

 

 

------=_NextPart_000_0096_01CE191B.A1874010-- From mamille2@cisco.com Mon Mar 4 18:39:50 2013 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 B0BBD21F85E0 for ; Mon, 4 Mar 2013 18:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 p1FTzJoBCptS for ; Mon, 4 Mar 2013 18:39:50 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5A21F85BD for ; Mon, 4 Mar 2013 18:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3762; q=dns/txt; s=iport; t=1362451190; x=1363660790; h=from:to:cc:subject:date:message-id:mime-version; bh=3/VJNZXDIhUZLjApVX/GwZRbt/kS+Jgmmq4FXxdCrxw=; b=h/ntM9SCkOBQ0XVfbzpXvVHA11JoA1z2I7r1CRv/58M3R03jKrG3fFHA KhmD2fQw5sdcYDeH8ft8R9lMNDItO4v9YxDEs8qvuJKiU4otoea1BkVzs sMAD0vb3VQrZkOQ7HfmebmP2iIDEjokm63C7rU6cEbdrjU/qoM2xZw7tX U=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAFBZNVGtJXG+/2dsb2JhbABEFoVzvEuBCBZzgiEBAgJ5EgEqJjAnBA4FCAaIBQyvNZAfjlsxgmZhA48pgSaWY4J7DYIn X-IronPort-AV: E=Sophos;i="4.84,784,1355097600"; d="p7s'?scan'208";a="183735350" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 05 Mar 2013 02:39:49 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r252dnIh011495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Mar 2013 02:39:49 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 4 Mar 2013 20:39:49 -0600 From: "Matt Miller (mamille2)" To: "jose-chairs@tools.ietf.org" Thread-Topic: Draft of Slideses Thread-Index: AQHOGUq053yKm1XnqUyipm8lkcnhlg== Date: Tue, 5 Mar 2013 02:39:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.46] Content-Type: multipart/signed; boundary="Apple-Mail=_E2B67F5E-11A5-4438-9223-208AA3C174F9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: [jose] Draft of Slideses 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, 05 Mar 2013 02:39:50 -0000 --Apple-Mail=_E2B67F5E-11A5-4438-9223-208AA3C174F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here is the first draft slides for my presentation on wrapped keys: < = http://outer-planes.net/~linuxwolf/ietf/ietf86-josewg-jwe-protected-jwk.pd= f > - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_E2B67F5E-11A5-4438-9223-208AA3C174F9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMwNTAyMzk0OFowIwYJKoZIhvcNAQkEMRYEFNudxBrYRBFvYWF6YSNQ0ARyjbC4MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCL93Nnv5sgOQXRGkPKg5u2PJ13iTNljc/2OszBcNwA /VxVJsxOjdeJE5jiRRHIIztstyEpVrJZ4bdPDOwMEsZlaUtirxD1FzFDcjWhKXXE1XOlEq3O35DI zieeebXgoA3WuuoWZrMOwlfT/0NsaOYOM79YPhwtQq31dBb7B+81+wg9MezBwW8UT4EKy0cOGlKO hrCorZMKbp9Qsfr4xh89gtXR+u/FVzHOKK1yuWqGjK/62VGzWTPmk0qBPhFUdaXp/DCN+op2MWMv 9uA5ZNzosgsmQubAfUvpeREoX8P8Lxa+pu0rZ8B2ygUTbZaWfcPmN8IJg8vqxnOIEtb9JAjlAAAA AAAA --Apple-Mail=_E2B67F5E-11A5-4438-9223-208AA3C174F9-- From jricher@mitre.org Tue Mar 5 06:41:03 2013 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 257A321F87ED for ; Tue, 5 Mar 2013 06:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 M8KggnWfnW3b for ; Tue, 5 Mar 2013 06:41:02 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 30E6E21F87E7 for ; Tue, 5 Mar 2013 06:40:59 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 851FA1F127E for ; Tue, 5 Mar 2013 09:40:58 -0500 (EST) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7CCCD1F09FA for ; Tue, 5 Mar 2013 09:40:58 -0500 (EST) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.318.4; Tue, 5 Mar 2013 09:40:58 -0500 Message-ID: <513603B6.60809@mitre.org> Date: Tue, 5 Mar 2013 09:39:50 -0500 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "jose@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Subject: [jose] Status of JPSK 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, 05 Mar 2013 14:41:03 -0000 I searched through the archives, but I couldn't find a conclusion to the discussion of JPSK: http://tools.ietf.org/id/draft-jones-jose-json-private-and-symmetric-key-00.html We see some utility in using it as a format for storing and managing server keys in a deployment setting (right now we're using Java Key Stores, which is less than ideal for this purpose), and we're looking to incorporate the format into an open source JOSE library that we use. The spec itself seems very straightforward, but I couldn't find information on the WG's intentions with it. Will it be incorporated into JWK? Will it become a standalone document in the JOSE canon? Will it remain an individual submission? -- Justin From bcampbell@pingidentity.com Tue Mar 5 09:02:34 2013 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 8E2B31F0D16 for ; Tue, 5 Mar 2013 09:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 te5PJeB3RH9L for ; Tue, 5 Mar 2013 09:02:34 -0800 (PST) Received: from na3sys009aog133.obsmtp.com (na3sys009aog133.obsmtp.com [74.125.149.82]) by ietfa.amsl.com (Postfix) with ESMTP id 333C81F0D15 for ; Tue, 5 Mar 2013 09:02:34 -0800 (PST) Received: from mail-ia0-f200.google.com ([209.85.210.200]) (using TLSv1) by na3sys009aob133.postini.com ([74.125.148.12]) with SMTP ID DSNKUTYlKDqX7aOrAd0ZsJiOumZQ/6+6Q1EW@postini.com; Tue, 05 Mar 2013 09:02:34 PST Received: by mail-ia0-f200.google.com with SMTP id u20so26498390iag.7 for ; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=Gn2hM53Y85+VGdUd7Rb7RHuSy1F7fbAdmdQ3V4bx4IA=; b=EErQ/vviAzKQNgXkHMI+LRFSfdh7yF3Jjoo2nR9waoSZjy/RintDLd7slOmrXQsZ6l nHShhrEAbBp3uqFy5l8jcP0ZRadHte22tiU/jeHkKfJV5dSKNPZ+PFx8edu1itnWA0i/ LOrUtcl4lVKvxWtWO57vtUlgZReThRFvxc9DAxYisifEDR8eQ1LmYj3Akemt05a9MCrc cBtKSBX41kI6B7hFCjmaoKBBYteawxNZlOogt2OeiHPs2X9vQwKvOFwQ1dUHPw3BcX5p 6YfI7T3a8SyVMzAfIO/hrLG9MHVFdk0OVpMlKl0e2VUiZyKfU7lmUdqP7M1Ko210wSBP Ds5A== X-Received: by 10.50.37.236 with SMTP id b12mr6840785igk.42.1362502948003; Tue, 05 Mar 2013 09:02:28 -0800 (PST) X-Received: by 10.50.37.236 with SMTP id b12mr6840776igk.42.1362502947880; Tue, 05 Mar 2013 09:02:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 5 Mar 2013 09:01:57 -0800 (PST) In-Reply-To: <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> References: <84036CCA-8C25-48CD-9699-700078670780@ve7jtb.com> <0dedf955ad704d53ae5cc31cbc4c6052@BY2PR03MB041.namprd03.prod.outlook.com> <3AE8D8EF-714C-4F6A-9B50-433AA2500C06@oracle.com> From: Brian Campbell Date: Tue, 5 Mar 2013 10:01:57 -0700 Message-ID: To: Phil Hunt Content-Type: multipart/alternative; boundary=f46d044788d936dc7804d7307037 X-Gm-Message-State: ALoCoQkm+DubXYD94R13zs2YghWzCjkkmQ5riAaOCv0o5dWSxJEGxtHN9ycF7E1LHbA/rPyYM7qJMXYD1O/P6ZZNbpcEKkygaCc6Co7507Enzx/+9SixmArNd0lUyZEThRhHXPHgK9XK Cc: Anthony Nadalin , Group Group , "openid-connect-interop@googlegroups.com" , "" , John Bradley , "webfinger@ietf.org" , Barry Leiba , "oauth@ietf.org WG" Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID Connect at IETF#86 in Sun Mar 10 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, 05 Mar 2013 17:02:34 -0000 --f46d044788d936dc7804d7307037 Content-Type: text/plain; charset=ISO-8859-1 Likewise, I'll be arriving in Orlando ~3:30pm, if there's anything happening later in the afternoon/evening? On Sat, Mar 2, 2013 at 5:19 PM, Phil Hunt wrote: > I should be in orlando at 7:30ish if anything is happening in the evening. > > Phil > > Sent from my phone. > > On 2013-03-02, at 16:12, Anthony Nadalin wrote: > > > I thought it was Sunday > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Barry Leiba > > Sent: Saturday, March 2, 2013 11:58 AM > > To: John Bradley > > Cc: openid-connect-interop@googlegroups.com; Group Group; oauth@ietf.orgWG; < > jose@ietf.org>; webfinger@ietf.org > > Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID > Connect at IETF#86 in Sun Mar 10 > > > >> The eventbrite page for people wanting to attend the openID Connect > >> session prior to IETF86 is now available at: > >> http://openid-ietf-86.eventbrite.com/ > > > > That page says this: > > OpenID Meeting at IETF 86 > > The OpenID Foundation > > Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT) > > Orlando, FL > > > > I do hope it means Thursday, 7 March. 11 April is about a month > > *after* the IETF meeting. > > > > Barry > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > > > > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d044788d936dc7804d7307037 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Likewise, I'll be arriving in Orlando ~3:30pm, if ther= e's anything happening later in the afternoon/evening?


On Sat, Mar 2, 2013 = at 5:19 PM, Phil Hunt <phil.hunt@oracle.com> wrote:
I should be in orlando at 7:30ish if anythin= g is happening in the evening.

Phil

Sent from my phone.

On 2013-03-02, at 16:12, Anthony Nadalin <tonynad@microsoft.com> wrote:

> I thought it was Sunday
>
> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Barry Leiba
> Sent: Saturday, March 2, 2013 11:58 AM
> To: John Bradley
> Cc: openid-= connect-interop@googlegroups.com; Group Group; oauth@ietf.org WG; <jose@= ietf.org>; webfinger@ietf.org<= /a>
> Subject: Re: [jose] [OAUTH-WG] Meeting for people interested in OpenID= Connect at IETF#86 in Sun Mar 10
>
>> The eventbrite page for people wanting to attend the openID Connec= t
>> session prior to IETF86 is now available at:
>> http://openid-ietf-86.eventbrite.com/
>
> That page says this:
> =A0 OpenID Meeting at IETF 86
> =A0 The OpenID Foundation
> =A0 Thursday, April 11, 2013 from 1:00 PM to 4:00 PM (EDT)
> =A0 Orlando, FL
>
> I do hope it means Thursday, 7 March. =A011 April is about a month
> *after* the IETF meeting.
>
> Barry
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_____________________________= __________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d044788d936dc7804d7307037-- From turners@ieca.com Wed Mar 6 04:48:23 2013 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 B1FA321F8917 for ; Wed, 6 Mar 2013 04:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.472 X-Spam-Level: X-Spam-Status: No, score=-102.472 tagged_above=-999 required=5 tests=[AWL=-0.207, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 8BWOn0zDFiYS for ; Wed, 6 Mar 2013 04:48:23 -0800 (PST) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [67.18.21.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6EC21F8916 for ; Wed, 6 Mar 2013 04:48:23 -0800 (PST) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id 28B2F7156880C; Wed, 6 Mar 2013 06:48:00 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 18A5C715687B9 for ; Wed, 6 Mar 2013 06:48:00 -0600 (CST) Received: from [108.45.16.214] (port=50013 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UDDld-0003mM-Hx; Wed, 06 Mar 2013 06:48:21 -0600 Message-ID: <51373B14.8030904@ieca.com> Date: Wed, 06 Mar 2013 07:48:20 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.16.214]:50013 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 12 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "jose-chairs@tools.ietf.org" , "jose@ietf.org" Subject: Re: [jose] Draft of Slideses 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, 06 Mar 2013 12:48:23 -0000 I know this isn't an "official" line but I appreciate getting early slides. I know non-english speaker do as well. spt On 3/4/13 9:39 PM, Matt Miller (mamille2) wrote: > Here is the first draft slides for my presentation on wrapped keys: > < http://outer-planes.net/~linuxwolf/ietf/ietf86-josewg-jwe-protected-jwk.pdf > > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From rlb@ipv.sx Wed Mar 6 07:50:05 2013 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 7977E21F8A35 for ; Wed, 6 Mar 2013 07:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.867 X-Spam-Level: X-Spam-Status: No, score=-1.867 tagged_above=-999 required=5 tests=[AWL=-3.107, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] 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 QaPdzK2unfki for ; Wed, 6 Mar 2013 07:50:05 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id EA14421F8A27 for ; Wed, 6 Mar 2013 07:50:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id tb18so3639734obb.17 for ; Wed, 06 Mar 2013 07:50:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Ps0XxSKhMIA1uBU5N9OsW6wintHtovpmrQOrk3E44YE=; b=H5/ZT1fR5z7MTcDu7bxjz6rw7bHJ3QWBz5NfB8ZTvXsVZQ23886eQo3Sy/UWrPlemQ L7X4+C/gDioJ4TqACKNMWQrGXZdJgjaXlwvos83uHIyINi3uw6jKoyT3Xi1gQTjDZDz/ VglVpj8+1/PHK1YUQ3mJojShxdfA+GgQrfgZm9ZQRsJxzwPwLaTubbijuVwi6kciYOss EiAlfYE5H6uqsniP+vPHamsUAV7R/pqho76YgnH6NQZaBq8eNe2WUVbpuaEdVgMwGbKj GE+rxuUszbKYKr+LGiBxDpZ2bFFBrvPm7SxkEqrTIsj1r6XEi0pFxYmZxZQoFbaZj4uO t+/A== MIME-Version: 1.0 X-Received: by 10.182.144.6 with SMTP id si6mr23045653obb.38.1362585004476; Wed, 06 Mar 2013 07:50:04 -0800 (PST) Received: by 10.60.150.131 with HTTP; Wed, 6 Mar 2013 07:50:04 -0800 (PST) X-Originating-IP: [128.89.254.55] In-Reply-To: <513603B6.60809@mitre.org> References: <513603B6.60809@mitre.org> Date: Wed, 6 Mar 2013 10:50:04 -0500 Message-ID: From: Richard Barnes To: Justin Richer Content-Type: multipart/alternative; boundary=14dae9398ead2b26a004d7438bbf X-Gm-Message-State: ALoCoQnEixzanXBnb9HsJUtKnzGm3lHUF2nsDdd9MxidmWZIub2TZ9nQONS/u8qpr/UHC1eOtAeN Cc: "jose@ietf.org" Subject: Re: [jose] Status of JPSK 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, 06 Mar 2013 15:50:05 -0000 --14dae9398ead2b26a004d7438bbf Content-Type: text/plain; charset=ISO-8859-1 That question is on the agenda for discussion next Wednesday. My preference would be to fold these considerations into JWK and JWA, as appropriate. On Tue, Mar 5, 2013 at 9:39 AM, Justin Richer wrote: > I searched through the archives, but I couldn't find a conclusion to the > discussion of JPSK: > > http://tools.ietf.org/id/**draft-jones-jose-json-private-** > and-symmetric-key-00.html > > We see some utility in using it as a format for storing and managing > server keys in a deployment setting (right now we're using Java Key Stores, > which is less than ideal for this purpose), and we're looking to > incorporate the format into an open source JOSE library that we use. The > spec itself seems very straightforward, but I couldn't find information on > the WG's intentions with it. Will it be incorporated into JWK? Will it > become a standalone document in the JOSE canon? Will it remain an > individual submission? > > -- Justin > ______________________________**_________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/**listinfo/jose > --14dae9398ead2b26a004d7438bbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That question is on the agenda for discussion next Wednesday. =A0

<= /div>
My preference would be to fold these considerations into JWK and = JWA, as appropriate.


On Tue, M= ar 5, 2013 at 9:39 AM, Justin Richer <jricher@mitre.org> wro= te:
I searched through the archives, but I could= n't find a conclusion to the discussion of JPSK:

http://tools.ietf.org/id/draft-j= ones-jose-json-private-and-symmetric-key-00.html

We see some utility in using it as a format for storing and managing server= keys in a deployment setting (right now we're using Java Key Stores, w= hich is less than ideal for this purpose), and we're looking to incorpo= rate the format into an open source JOSE library that we use. The spec itse= lf seems very straightforward, but I couldn't find information on the W= G's intentions with it. Will it be incorporated into JWK? Will it becom= e a standalone document in the JOSE canon? Will it remain an individual sub= mission?

=A0-- Justin
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae9398ead2b26a004d7438bbf-- From mpeck@mitre.org Wed Mar 6 09:28:15 2013 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 AD8FA21F8ABA for ; Wed, 6 Mar 2013 09:28:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.299 X-Spam-Level: X-Spam-Status: No, score=-5.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, 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 pglfj9EUEMc1 for ; Wed, 6 Mar 2013 09:28:15 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 18EBD21F8AA0 for ; Wed, 6 Mar 2013 09:28:12 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B066C1F0A33 for ; Wed, 6 Mar 2013 12:28:10 -0500 (EST) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 9FEB41F085D for ; Wed, 6 Mar 2013 12:28:10 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.36]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 12:28:10 -0500 From: "Peck, Michael A" To: "jose@ietf.org" Thread-Topic: draft-ietf-jose-json-web-signature-08 "jwk" header parameter Thread-Index: Ac4ajmfcUtg/GEh+RS6fPsHjKFQpbQ== Date: Wed, 6 Mar 2013 17:28:09 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 06 Mar 2013 17:28:15 -0000 What is the use case for the "jwk" (JSON Web Key) Header Parameter describe= d in section 4.1.3 of draft-ietf-jose-json-web-signature-08? It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.=20 I would think this field makes it too easy for implementations to do the wr= ong thing. Thanks, Mike From stpeter@stpeter.im Wed Mar 6 10:03:25 2013 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 7AC6621F8884 for ; Wed, 6 Mar 2013 10:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.445 X-Spam-Level: X-Spam-Status: No, score=-101.445 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, 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 xcyczy9P9KhN for ; Wed, 6 Mar 2013 10:03:20 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B96F221F87E4 for ; Wed, 6 Mar 2013 10:03:17 -0800 (PST) Received: from [10.129.24.65] (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B10E54004E for ; Wed, 6 Mar 2013 11:11:28 -0700 (MST) Message-ID: <513784E4.5080609@stpeter.im> Date: Wed, 06 Mar 2013 11:03:16 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: "jose@ietf.org" X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [jose] JCARDCAL WG 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, 06 Mar 2013 18:03:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, in case you missed it, we've formed a JCARDCAL Working Group to define JSON representations of both vCard and iCalendar information: https://datatracker.ietf.org/wg/jcardcal/charter/ Given past discussions in the JOSE WG, I figure that some people here might be interested in this initiative. If so, please join the jcardcal@ietf.org mailing list: https://www.ietf.org/mailman/listinfo/jcardcal The working group aims to complete its work in the next few months, so your timely participation would be very much appreciated. :-) Thanks! Peter, co-chair - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRN4TkAAoJEOoGpJErxa2psSgP/iAYLRoXk4EDvD8vgSzwjfBo zg7yVQneq45FdTgkjJYciddwf7AcBMLm5R8ofadiIB6I2Z8aYIe6W1yNAST/hOYi KBCidRgqMZf4rC+XiNDu6dp9YX14FVPXqbs43RxAHGxPrYNTlm/zXe1iGWyHE+uc xsDBHpKfi52Ai/s3Q2w8FgqIcy8QfV8m92JA3HDK3vHIBuT2GGSGVRExRqKn5Wrs tjiU/dGe3korq31aC3hDCig+0dGq/IE3UuCLDwkuNVZ72vKHihDmt0IYSzLMX2ih rvzRsoxkawI8BdJbilDA8Bm1RXQ681SYsiyO1lZUKXLrNukpmYFi9diePjGhKDLP DQHBk7X8VeDPosOHyhBzOCywUxwj1a5cYoUkI4UASgkp69bqIQukKOsrm8BLd+UG hH5YeI8Uhp8u7NUQA584Aws6YEX8u0SSzYzO3KzgTK/LXG25YnJU3AkkimGUUN1b YW0QGLLzKNMKKW55Mt4r+7PQdH6nYkHTmWTHC74nwWV7PuI7RKLulyW/ViyaJ425 Y4EwNeMZws5NFJiz8IX7dPu6/2xvNXcTVR0RZ7VX+posNnD2lhqZuWu+i7WbZd8/ jzQbrADSDhbC56KgbQcSgnLMRFZ3Asm1y+yeXrwihoa/3VR3+5/voX8kDMfq89cm W/qv1KE0jKvTFr/4hP+M =m4Og -----END PGP SIGNATURE----- From rlb@ipv.sx Wed Mar 6 10:45:12 2013 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 F07CE21F8900 for ; Wed, 6 Mar 2013 10:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 qPe9iPkYPLWl for ; Wed, 6 Mar 2013 10:45:08 -0800 (PST) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B8E121F8833 for ; Wed, 6 Mar 2013 10:45:06 -0800 (PST) Received: by mail-oa0-f51.google.com with SMTP id h2so13157232oag.10 for ; Wed, 06 Mar 2013 10:45:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UtjcYafnP2ACKWEslRSAV1WQFdrzNdIfJdGnmBIJMnQ=; b=Ho+DJa1RigKEqENuXn1HjDgzbvDlBE7iP/UZx3KoV/kY/k3fLlgHfd26nOU4HGYvgb fEnOqEXVwEyxXvs1oTOTWYqiMAu62NZK2KZphTan7/DJWQQNuLUd9LDMtbVXCE8w33lD bTjBGkMBdFsCDE8Rh8Hi/fOIfdkEo9rTiax2RupSCrKZ13thXRysfCTYkj9p4vCRnfrZ HO71Jyr5NzrPeUdZiCsxQuP9NaiyA0SPjM7T4oaPVk/F8UpTCvF9CwAjCp+/qu3sa8Gn vDNmETBWf757WhGK2AR+kRFErL8xyquYQTmSOrjuoU1hZx2F50t2eFRWlb29wpq+7Qli gZ3g== MIME-Version: 1.0 X-Received: by 10.182.118.103 with SMTP id kl7mr24049206obb.13.1362595505767; Wed, 06 Mar 2013 10:45:05 -0800 (PST) Received: by 10.60.150.131 with HTTP; Wed, 6 Mar 2013 10:45:05 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> Date: Wed, 6 Mar 2013 13:45:05 -0500 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=f46d044787c9181c7104d745fd69 X-Gm-Message-State: ALoCoQntpRVoyXBrJ9ZjOJ2dL28asdCnZYZGylql+aosA4kf02Mv6+n+z5Hk6Ga9iHf0BRsPp+Ah Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 06 Mar 2013 18:45:12 -0000 --f46d044787c9181c7104d745fd69 Content-Type: text/plain; charset=ISO-8859-1 What's your threat scenario here? I would note that the signed content of an X.509 certificate also does not carry any indication of the signer's public key (unless the issuer chooses to include the optional AuthorityKeyIdentifier extension). Likewise for CMS SignedData. Both of those structures are exactly analogous to JWS in this regard. For both JWS and CMS SignedData, the method in which the recipient authenticates the key used to verify the signature is out of scope. You could even say the same thing about X.509, since the issuer public key could be either a certified key or a trust anchor (provisioned through some other channel). On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A wrote: > What is the use case for the "jwk" (JSON Web Key) Header Parameter > described in section 4.1.3 of draft-ietf-jose-json-web-signature-08? > > It seems unsafe for a signature to provide, unauthenticated (not in a > signed certificate or protected by other means), the public key to be used > to verify itself. > I would think this field makes it too easy for implementations to do the > wrong thing. > > Thanks, > Mike > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d044787c9181c7104d745fd69 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What's your threat scenario here?

I would note that = the signed content of an X.509 certificate also does not carry any indicati= on of the signer's public key (unless the issuer chooses to include the= optional AuthorityKeyIdentifier extension). =A0Likewise for CMS SignedData= . =A0Both of those structures are exactly analogous to JWS in this regard.<= /div>

For both JWS and CMS SignedData, the method in which th= e recipient authenticates the key used to verify the signature is out of sc= ope. =A0You could even say the same thing about X.509, since the issuer pub= lic key could be either a certified key or a trust anchor (provisioned thro= ugh some other channel).


On Wed, Mar 6= , 2013 at 12:28 PM, Peck, Michael A <mpeck@mitre.org> wrote:
What is the use case for the "jwk" (JSON Web Key) Header Paramete= r described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d044787c9181c7104d745fd69-- From mpeck@mitre.org Wed Mar 6 11:21:05 2013 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 2D38221F89D2 for ; Wed, 6 Mar 2013 11:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.649, 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 x-tYa59U1b71 for ; Wed, 6 Mar 2013 11:21:01 -0800 (PST) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 3CDC621F8994 for ; Wed, 6 Mar 2013 11:20:56 -0800 (PST) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AA9791F0A5F; Wed, 6 Mar 2013 14:20:55 -0500 (EST) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 829061F0A5C; Wed, 6 Mar 2013 14:20:55 -0500 (EST) Received: from IMCMBX04.MITRE.ORG ([169.254.4.36]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 14:20:55 -0500 From: "Peck, Michael A" To: Richard Barnes Thread-Topic: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter Thread-Index: Ac4ajmfcUtg/GEh+RS6fPsHjKFQpbQANjiyAAAm+cYA= Date: Wed, 6 Mar 2013 19:20:54 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.59] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321E7A3558IMCMBX04MITREOR_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 06 Mar 2013 19:21:05 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321E7A3558IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the case of JWS, it looks like with the "jwk" header parameter, the sign= ed message itself can contain the raw public key to be used to verify it. My concern is that the verifier will grab and use the public key without en= suring its authenticity. This would be analogous to automatically trusting a self-signed X.509 certi= ficate. There should at least be some Security Considerations language that when "j= wk" is used the verifier needs to use out of bands means to assure that the= provided public key is trusted. CMS SignedData does not contain the raw public key used to sign the message= itself. It contains a SignerIdentifier to reference the public key and optionally c= ontains certificates (which would convey the public key, but along with pro= of that it should be trusted). Rather than directly including the "raw" public key, JWS provides lots of o= ther safer header parameters to reference the public key. From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Wednesday, March 06, 2013 1:45 PM To: Peck, Michael A Cc: jose@ietf.org Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header para= meter What's your threat scenario here? I would note that the signed content of an X.509 certificate also does not = carry any indication of the signer's public key (unless the issuer chooses = to include the optional AuthorityKeyIdentifier extension). Likewise for CM= S SignedData. Both of those structures are exactly analogous to JWS in thi= s regard. For both JWS and CMS SignedData, the method in which the recipient authenti= cates the key used to verify the signature is out of scope. You could even= say the same thing about X.509, since the issuer public key could be eithe= r a certified key or a trust anchor (provisioned through some other channel= ). On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A > wrote: What is the use case for the "jwk" (JSON Web Key) Header Parameter describe= d in section 4.1.3 of draft-ietf-jose-json-web-signature-08? It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself. I would think this field makes it too easy for implementations to do the wr= ong thing. Thanks, Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B4C063947CD794BB6FF90C78BAE9B321E7A3558IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the case of JWS, it lo= oks like with the “jwk” header parameter, the signed message it= self can contain the raw public key to be used to verify it.

My concern is that the ve= rifier will grab and use the public key without ensuring its authenticity.<= o:p>

This would be analogous t= o automatically trusting a self-signed X.509 certificate.=

There should at least be = some Security Considerations language that when “jwk” is used t= he verifier needs to use out of bands means to assure that the provided public key is trusted.

 <= /p>

CMS SignedData does not c= ontain the raw public key used to sign the message itself.

It contains a SignerIdent= ifier to reference the public key and optionally contains certificates (whi= ch would convey the public key, but along with proof that it should be trusted).

 <= /p>

Rather than directly incl= uding the “raw” public key, JWS provides lots of other safer he= ader parameters to reference the public key.

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, March 06, 2013 1:45 PM
To: Peck, Michael A
Cc: jose@ietf.org
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

 

What's your threat scenario here?

 

I would note that the signed content of an X.509 cer= tificate also does not carry any indication of the signer's public key (unl= ess the issuer chooses to include the optional AuthorityKeyIdentifier exten= sion).  Likewise for CMS SignedData.  Both of those structures are exactly analogous to JWS in this regard= .

 

For both JWS and CMS SignedData, the method in which= the recipient authenticates the key used to verify the signature is out of= scope.  You could even say the same thing about X.509, since the issu= er public key could be either a certified key or a trust anchor (provisioned through some other channel).=

 

 

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <= ;mpeck@mitre.org&g= t; wrote:

What is the use case for the "jwk" (JSON W= eb Key) Header Parameter described in section 4.1.3 of draft-ietf-jose-json= -web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321E7A3558IMCMBX04MITREOR_-- From rlb@ipv.sx Wed Mar 6 11:26:44 2013 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 E1D7C21F8C6C for ; Wed, 6 Mar 2013 11:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 LsN06Uwa2upn for ; Wed, 6 Mar 2013 11:26:40 -0800 (PST) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2749221F8C1F for ; Wed, 6 Mar 2013 11:26:38 -0800 (PST) Received: by mail-oa0-f42.google.com with SMTP id i18so13334622oag.29 for ; Wed, 06 Mar 2013 11:26:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ChxM8b0m51lo1ljbnkikeuNTPjFCJuiZlSO8BQODEn0=; b=No5noAcdU7JfFSN/je6snXMm0FPaEStlrI7ebn7h6i/E8zX46lmYiqjRr4EF+shIUx 07MoYNvF4f6HK7mcv8QzZi+y8mdz07BdgDx8vPDwEMzOavdgzce0tHVBCPGPQQdZv+uB 2Lx2JCbfNPIS4UgLUIkJ+DWtSfuJiuCUNQlafn2bH3EBaZnrJMIe2gTcI4wDtYS4QL72 0PRKSSVx25L68DGu5rJ3+E+veK3k5fpvrtk65GbVcbFqKc1PZY0ajg7HkV2U7JvDOUVB L79Oc/7tqhtGRGKe8gFHG5Y0BAQo0dCj1BkVyrs53gD7Sbm6jWdUDknQuHRFK84XzJbj 0Geg== MIME-Version: 1.0 X-Received: by 10.60.3.103 with SMTP id b7mr23613337oeb.86.1362597997709; Wed, 06 Mar 2013 11:26:37 -0800 (PST) Received: by 10.60.150.131 with HTTP; Wed, 6 Mar 2013 11:26:37 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> Date: Wed, 6 Mar 2013 14:26:37 -0500 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=e89a8ff2514aa023c604d7469105 X-Gm-Message-State: ALoCoQnxDCRFvnyDpV8WDqvgH6EOKAIH0Y4iftqM045UX65O8jUT3hPmMJwpNwCe0B8Np3gryKua Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 06 Mar 2013 19:26:45 -0000 --e89a8ff2514aa023c604d7469105 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No, this is analogous to accepting a certificate signed under a trust anchor, where that trust anchor was provisioned through some other protocol. SignedData doesn't contain the raw key, but it contains a hash (SignerIdentifier ::=3D CHOICE { ... subjectKeyIdentifier [0] SubjectKeyIdentifier }). So th= e only difference is that the client has to know how to look up the key. The right way to handle this is, as you say, to add some security considerations that mention the risks associated with choosing which keys should be used to validate signatures. On Wed, Mar 6, 2013 at 2:20 PM, Peck, Michael A wrote: > In the case of JWS, it looks like with the =93jwk=94 header parameter, t= he > signed message itself can contain the raw public key to be used to verify > it.**** > > My concern is that the verifier will grab and use the public key without > ensuring its authenticity.**** > > This would be analogous to automatically trusting a self-signed X.509 > certificate.**** > > There should at least be some Security Considerations language that when > =93jwk=94 is used the verifier needs to use out of bands means to assure = that > the provided public key is trusted.**** > > ** ** > > CMS SignedData does not contain the raw public key used to sign the > message itself.**** > > It contains a SignerIdentifier to reference the public key and optionally > contains certificates (which would convey the public key, but along with > proof that it should be trusted).**** > > ** ** > > Rather than directly including the =93raw=94 public key, JWS provides lot= s of > other safer header parameters to reference the public key.**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Wednesday, March 06, 2013 1:45 PM > *To:* Peck, Michael A > *Cc:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > ** ** > > What's your threat scenario here?**** > > ** ** > > I would note that the signed content of an X.509 certificate also does no= t > carry any indication of the signer's public key (unless the issuer choose= s > to include the optional AuthorityKeyIdentifier extension). Likewise for > CMS SignedData. Both of those structures are exactly analogous to JWS in > this regard.**** > > ** ** > > For both JWS and CMS SignedData, the method in which the recipient > authenticates the key used to verify the signature is out of scope. You > could even say the same thing about X.509, since the issuer public key > could be either a certified key or a trust anchor (provisioned through so= me > other channel).**** > > ** ** > > ** ** > > On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A wrote:= * > *** > > What is the use case for the "jwk" (JSON Web Key) Header Parameter > described in section 4.1.3 of draft-ietf-jose-json-web-signature-08? > > It seems unsafe for a signature to provide, unauthenticated (not in a > signed certificate or protected by other means), the public key to be use= d > to verify itself. > I would think this field makes it too easy for implementations to do the > wrong thing. > > Thanks, > Mike > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --e89a8ff2514aa023c604d7469105 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No, this is analogous to accepting a certificate signed under a trust ancho= r, where that trust anchor was provisioned through some other protocol. =A0=

SignedData doesn't contain the raw key, but it contains a hash = (SignerIdentifier ::=3D CHOICE { ...=A0subjectKeyIdentifier [0] SubjectKeyIdentifie= r }). =A0So the only difference is that the client has to know how t= o look up the key.

The right way to handle this is, as you say, to add some sec= urity considerations that mention the risks associated with choosing which = keys should be used to validate signatures.

On Wed, Mar 6, 2013 at 2:20 PM, Peck, Michael A <mpeck@mitre.org> wrote:

In the case of JWS, it lo= oks like with the =93jwk=94 header parameter, the signed message itself can= contain the raw public key to be used to verify it.

My concern is that the ve= rifier will grab and use the public key without ensuring its authenticity.<= u>

This would be analogous t= o automatically trusting a self-signed X.509 certificate.

There should at least be = some Security Considerations language that when =93jwk=94 is used the verif= ier needs to use out of bands means to assure that the provided public key is trusted.

=A0<= /p>

CMS SignedData does not c= ontain the raw public key used to sign the message itself.

It contains a SignerIdent= ifier to reference the public key and optionally contains certificates (whi= ch would convey the public key, but along with proof that it should be trusted).

=A0<= /p>

Rather than directly incl= uding the =93raw=94 public key, JWS provides lots of other safer header par= ameters to reference the public key.

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, March 06, 2013 1:45 PM
To: Peck, Michael A
Cc: jose@ietf.org=
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

=A0

What's your threat scenario here?<= /p>

=A0

I would note that the signed content of an X.509 cer= tificate also does not carry any indication of the signer's public key = (unless the issuer chooses to include the optional AuthorityKeyIdentifier e= xtension). =A0Likewise for CMS SignedData. =A0Both of those structures are exactly analogous to JWS in this regard.

=A0

For both JWS and CMS SignedData, the method in which= the recipient authenticates the key used to verify the signature is out of= scope. =A0You could even say the same thing about X.509, since the issuer = public key could be either a certified key or a trust anchor (provisioned through some other channel).<= /u>

=A0

=A0

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <= ;mpeck@mitre.org&g= t; wrote:

What is the use case for the "jwk" (JSON W= eb Key) Header Parameter described in section 4.1.3 of draft-ietf-jose-json= -web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--e89a8ff2514aa023c604d7469105-- From James.H.Manger@team.telstra.com Wed Mar 6 19:55:35 2013 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 D824021F85AC for ; Wed, 6 Mar 2013 19:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 sy7bb4n-budb for ; Wed, 6 Mar 2013 19:55:35 -0800 (PST) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE6221F881A for ; Wed, 6 Mar 2013 19:55:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.84,799,1355058000"; d="scan'208,217";a="122626699" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 07 Mar 2013 14:55:33 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7006"; a="115930752" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcbvi.tcif.telstra.com.au with ESMTP; 07 Mar 2013 14:55:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Thu, 7 Mar 2013 14:55:32 +1100 From: "Manger, James H" To: "Peck, Michael A" Date: Thu, 7 Mar 2013 14:55:32 +1100 Thread-Topic: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter Thread-Index: Ac4ajmfcUtg/GEh+RS6fPsHjKFQpbQANjiyAAAm+cYAAAsk9cA== Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B476F63WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 07 Mar 2013 03:55:36 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B476F63WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSwgTWljaGFlbC4gQSByYXcgcHVibGljIGtleSBpbiBhIEpXUyBpcyBpbnZpdGluZyBk YW5nZXJvdXMgY29kZS4NCg0KS2V5IGlkcyBhcmUgZXZlbiB3b3JzZSBpbiBKV0UuIEFuIG9yaWdp bmF0b3IgZW5jcnlwdHMgZGF0YSB3aXRoIGEgcmVjaXBpZW504oCZcyBwdWJsaWMga2V5LiBUaGUg cmVjaXBpZW50IG5lZWRzIHRvIGtub3cgd2hpY2ggb2YgaGlzIG9yIGhlciBwcml2YXRlIGtleXMg dG8gdXNlIHRvIGRlY3J5cHQuIEpXRSBkZWZpbmVzIHdheXMgZm9yIHRoZSBvcmlnaW5hdG9yIHRv IGluY2x1ZGU6IHRoZSByYXcgcHVibGljIGtleSAoandrKTsgYSBVUkkgZm9yIHRoZSByYXcgcHVi bGljIGtleSAoamt1KSAoYWN0dWFsbHkgYSBVUkkgZm9yIGEgY29sbGVjdGlvbiBvZiByYXcgcHVi bGljIGtleXMsIG9uZSBvZiB3aGljaCBpcyB0aGUgcmlnaHQgb25lLCBidXQgdGhlcmUgaXMgbm8g aW5kaWNhdGlvbiB3aGljaCBvbmUgdGhhdCBpcyk7IHRoZSBjZXJ0aWZpY2F0ZSBjaGFpbiAoeDVj KTsgYW5kL29yIGEgVVJJIGZvciB0aGUgY2VydGlmaWNhdGUgY2hhaW4gKHg1dSkuIFRoaXMgaXMg YWxsIHBvaW50bGVzcyDigJQgdGhlIHJlY2lwaWVudCBkb2VzbuKAmXQgbmVlZCB0byBiZSBnaXZl biBpdHMgb3duIHB1YmxpYyBrZXkgb3IgY2VydGlmaWNhdGUuIE9ubHkgdGhlIOKAnGtpZOKAnSAo a2V5IGlkKSBmaWVsZCBtYWtlcyBzZW5zZS4NCg0KVGhlIG9yaWdpbmF0b3IgY2FuIGFsc28gaW5j bHVkZSBhIGhhc2ggb2YgdGhlIGNlcnRpZmljYXRlICh4NXQpLiBUaGUgb25seSB1c2UgSSBjYW4g dGhpbmsgb2YgZm9yIHRoYXQgaXMgd2hlbiB0aGUgb3JpZ2luYXRvciBkb2VzbuKAmXQga25vdyBh IGtleSBpZCAoZWcgdGhlcmUgaXMgbm8gaWQtY2Utc3ViamVjdEtleUlkZW50aWZpZXIgZXh0ZW5z aW9uIGluIHRoZSBjZXJ0aWZpY2F0ZSkgc28gaXQgc3ludGhlc2lzZXMgb25lLiBJbiB0aGlzIHNp dHVhdGlvbiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gaGFzaCB0aGUgcHVibGljIGtleSAobm90IHRo ZSBjZXJ0aWZpY2F0ZSkgYXMgcGVyIFJGQyA1MjgwIOKAnFBLSVggY2VydGlmaWNhdGUgYW5kIENS TCBQcm9maWxl4oCdLCBzZWN0aW9uIDQuMi4xLjIuIOKAnFN1YmplY3QgS2V5IElkZW50aWZpZXLi gJ0uDQoNCkkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55IGV4YW1wbGVzIHRoYXQgdXNlIGtp ZCwgandrLCBqa3UsIHg1dSwgeDVjLCBvciB4NXQgaW4gYSBKT1NFIG1lc3NhZ2UgaW4gSldFLCBK V1MsIG9yIEpXVC4gUGVyaGFwcyBlbnN1cmluZyBlYWNoIGRlZmluZWQgZmllbGQgZG9lcyBhcHBl YXIgaW4gYW4gZXhhbXBsZSB3b3VsZCBiZSBhIGdvb2QgcXVhbGl0eSBjaGVjay4NCg0KLS0NCkph bWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBQZWNrLCBNaWNoYWVsIEENClNlbnQ6IFRodXJz ZGF5LCA3IE1hcmNoIDIwMTMgNjoyMSBBTQ0KVG86IFJpY2hhcmQgQmFybmVzDQpDYzogam9zZUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2ln bmF0dXJlLTA4ICJqd2siIGhlYWRlciBwYXJhbWV0ZXINCg0KSW4gdGhlIGNhc2Ugb2YgSldTLCBp dCBsb29rcyBsaWtlIHdpdGggdGhlIOKAnGp3a+KAnSBoZWFkZXIgcGFyYW1ldGVyLCB0aGUgc2ln bmVkIG1lc3NhZ2UgaXRzZWxmIGNhbiBjb250YWluIHRoZSByYXcgcHVibGljIGtleSB0byBiZSB1 c2VkIHRvIHZlcmlmeSBpdC4NCk15IGNvbmNlcm4gaXMgdGhhdCB0aGUgdmVyaWZpZXIgd2lsbCBn cmFiIGFuZCB1c2UgdGhlIHB1YmxpYyBrZXkgd2l0aG91dCBlbnN1cmluZyBpdHMgYXV0aGVudGlj aXR5Lg0KVGhpcyB3b3VsZCBiZSBhbmFsb2dvdXMgdG8gYXV0b21hdGljYWxseSB0cnVzdGluZyBh IHNlbGYtc2lnbmVkIFguNTA5IGNlcnRpZmljYXRlLg0KVGhlcmUgc2hvdWxkIGF0IGxlYXN0IGJl IHNvbWUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbGFuZ3VhZ2UgdGhhdCB3aGVuIOKAnGp3a+KA nSBpcyB1c2VkIHRoZSB2ZXJpZmllciBuZWVkcyB0byB1c2Ugb3V0IG9mIGJhbmRzIG1lYW5zIHRv IGFzc3VyZSB0aGF0IHRoZSBwcm92aWRlZCBwdWJsaWMga2V5IGlzIHRydXN0ZWQuDQoNCkNNUyBT aWduZWREYXRhIGRvZXMgbm90IGNvbnRhaW4gdGhlIHJhdyBwdWJsaWMga2V5IHVzZWQgdG8gc2ln biB0aGUgbWVzc2FnZSBpdHNlbGYuDQpJdCBjb250YWlucyBhIFNpZ25lcklkZW50aWZpZXIgdG8g cmVmZXJlbmNlIHRoZSBwdWJsaWMga2V5IGFuZCBvcHRpb25hbGx5IGNvbnRhaW5zIGNlcnRpZmlj YXRlcyAod2hpY2ggd291bGQgY29udmV5IHRoZSBwdWJsaWMga2V5LCBidXQgYWxvbmcgd2l0aCBw cm9vZiB0aGF0IGl0IHNob3VsZCBiZSB0cnVzdGVkKS4NCg0KUmF0aGVyIHRoYW4gZGlyZWN0bHkg aW5jbHVkaW5nIHRoZSDigJxyYXfigJ0gcHVibGljIGtleSwgSldTIHByb3ZpZGVzIGxvdHMgb2Yg b3RoZXIgc2FmZXIgaGVhZGVyIHBhcmFtZXRlcnMgdG8gcmVmZXJlbmNlIHRoZSBwdWJsaWMga2V5 Lg0KDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdDQpTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDA2LCAyMDEzIDE6NDUgUE0NClRvOiBQZWNrLCBNaWNoYWVsIEENCkNjOiBq b3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtqb3NlXSBk cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA4ICJqd2siIGhlYWRlciBwYXJhbWV0 ZXINCg0KV2hhdCdzIHlvdXIgdGhyZWF0IHNjZW5hcmlvIGhlcmU/DQoNCkkgd291bGQgbm90ZSB0 aGF0IHRoZSBzaWduZWQgY29udGVudCBvZiBhbiBYLjUwOSBjZXJ0aWZpY2F0ZSBhbHNvIGRvZXMg bm90IGNhcnJ5IGFueSBpbmRpY2F0aW9uIG9mIHRoZSBzaWduZXIncyBwdWJsaWMga2V5ICh1bmxl c3MgdGhlIGlzc3VlciBjaG9vc2VzIHRvIGluY2x1ZGUgdGhlIG9wdGlvbmFsIEF1dGhvcml0eUtl eUlkZW50aWZpZXIgZXh0ZW5zaW9uKS4gIExpa2V3aXNlIGZvciBDTVMgU2lnbmVkRGF0YS4gIEJv dGggb2YgdGhvc2Ugc3RydWN0dXJlcyBhcmUgZXhhY3RseSBhbmFsb2dvdXMgdG8gSldTIGluIHRo aXMgcmVnYXJkLg0KDQpGb3IgYm90aCBKV1MgYW5kIENNUyBTaWduZWREYXRhLCB0aGUgbWV0aG9k IGluIHdoaWNoIHRoZSByZWNpcGllbnQgYXV0aGVudGljYXRlcyB0aGUga2V5IHVzZWQgdG8gdmVy aWZ5IHRoZSBzaWduYXR1cmUgaXMgb3V0IG9mIHNjb3BlLiAgWW91IGNvdWxkIGV2ZW4gc2F5IHRo ZSBzYW1lIHRoaW5nIGFib3V0IFguNTA5LCBzaW5jZSB0aGUgaXNzdWVyIHB1YmxpYyBrZXkgY291 bGQgYmUgZWl0aGVyIGEgY2VydGlmaWVkIGtleSBvciBhIHRydXN0IGFuY2hvciAocHJvdmlzaW9u ZWQgdGhyb3VnaCBzb21lIG90aGVyIGNoYW5uZWwpLg0KDQoNCk9uIFdlZCwgTWFyIDYsIDIwMTMg YXQgMTI6MjggUE0sIFBlY2ssIE1pY2hhZWwgQSA8bXBlY2tAbWl0cmUub3JnPG1haWx0bzptcGVj a0BtaXRyZS5vcmc+PiB3cm90ZToNCldoYXQgaXMgdGhlIHVzZSBjYXNlIGZvciB0aGUgImp3ayIg KEpTT04gV2ViIEtleSkgSGVhZGVyIFBhcmFtZXRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjEu MyBvZiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA4Pw0KDQpJdCBzZWVtcyB1 bnNhZmUgZm9yIGEgc2lnbmF0dXJlIHRvIHByb3ZpZGUsIHVuYXV0aGVudGljYXRlZCAobm90IGlu IGEgc2lnbmVkIGNlcnRpZmljYXRlIG9yIHByb3RlY3RlZCBieSBvdGhlciBtZWFucyksIHRoZSBw dWJsaWMga2V5IHRvIGJlIHVzZWQgdG8gdmVyaWZ5IGl0c2VsZi4NCkkgd291bGQgdGhpbmsgdGhp cyBmaWVsZCBtYWtlcyBpdCB0b28gZWFzeSBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGRvIHRoZSB3 cm9uZyB0aGluZy4NCg0KVGhhbmtzLA0KTWlrZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1h aWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9qb3NlDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B476F63WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4 dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SSBhZ3JlZSwgTWljaGFlbC4gQSByYXcgcHVibGljIGtleSBpbiBhIEpXUyBpcyBp bnZpdGluZyBkYW5nZXJvdXMgY29kZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPktleSBpZHMgYXJlIGV2 ZW4gd29yc2UgaW4gSldFLiBBbiBvcmlnaW5hdG9yIGVuY3J5cHRzIGRhdGEgd2l0aCBhIHJlY2lw aWVudOKAmXMgcHVibGljIGtleS4gVGhlIHJlY2lwaWVudCBuZWVkcyB0byBrbm93IHdoaWNoIG9m IGhpcyBvciBoZXIgcHJpdmF0ZSBrZXlzIHRvIHVzZSB0byBkZWNyeXB0LiBKV0UgZGVmaW5lcyB3 YXlzIGZvciB0aGUgb3JpZ2luYXRvciB0byBpbmNsdWRlOiB0aGUgcmF3IHB1YmxpYyBrZXkgKGp3 ayk7IGEgVVJJIGZvciB0aGUgcmF3IHB1YmxpYyBrZXkgKGprdSkgKGFjdHVhbGx5IGEgVVJJIGZv ciBhIGNvbGxlY3Rpb24gb2YgcmF3IHB1YmxpYyBrZXlzLCBvbmUgb2Ygd2hpY2ggaXMgdGhlIHJp Z2h0IG9uZSwgYnV0IHRoZXJlIGlzIG5vIGluZGljYXRpb24gd2hpY2ggb25lIHRoYXQgaXMpOyB0 aGUgY2VydGlmaWNhdGUgY2hhaW4gKHg1Yyk7IGFuZC9vciBhIFVSSSBmb3IgdGhlIGNlcnRpZmlj YXRlIGNoYWluICh4NXUpLiBUaGlzIGlzIGFsbCBwb2ludGxlc3Mg4oCUIHRoZSByZWNpcGllbnQg ZG9lc27igJl0IG5lZWQgdG8gYmUgZ2l2ZW4gaXRzIG93biBwdWJsaWMga2V5IG9yIGNlcnRpZmlj YXRlLiBPbmx5IHRoZSDigJxraWTigJ0gKGtleSBpZCkgZmllbGQgbWFrZXMgc2Vuc2UuPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGUgb3JpZ2luYXRvciBjYW4gYWxzbyBpbmNsdWRlIGEgaGFzaCBvZiB0 aGUgY2VydGlmaWNhdGUgKHg1dCkuIFRoZSBvbmx5IHVzZSBJIGNhbiB0aGluayBvZiBmb3IgdGhh dCBpcyB3aGVuIHRoZSBvcmlnaW5hdG9yIGRvZXNu4oCZdCBrbm93IGEga2V5IGlkIChlZyB0aGVy ZSBpcyBubyBpZC1jZS1zdWJqZWN0S2V5SWRlbnRpZmllciBleHRlbnNpb24gaW4gdGhlIGNlcnRp ZmljYXRlKSBzbyBpdCBzeW50aGVzaXNlcyBvbmUuIEluIHRoaXMgc2l0dWF0aW9uIGl0IHdvdWxk IGJlIGJldHRlciB0byBoYXNoIHRoZSBwdWJsaWMga2V5IChub3QgdGhlIGNlcnRpZmljYXRlKSBh cyBwZXIgUkZDIDUyODAg4oCcUEtJWCBjZXJ0aWZpY2F0ZSBhbmQgQ1JMIFByb2ZpbGXigJ0sIHNl Y3Rpb24gNC4yLjEuMi4g4oCcU3ViamVjdCBLZXkgSWRlbnRpZmllcuKAnS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPkkgZG9u4oCZdCB0aGluayB0aGVyZSBhcmUgYW55IGV4YW1wbGVzIHRoYXQgdXNlIGtp ZCwgandrLCBqa3UsIHg1dSwgeDVjLCBvciB4NXQgaW4gYSBKT1NFIG1lc3NhZ2UgaW4gSldFLCBK V1MsIG9yIEpXVC4gUGVyaGFwcyBlbnN1cmluZyBlYWNoIGRlZmluZWQgZmllbGQgZG9lcyBhcHBl YXIgaW4gYW4gZXhhbXBsZSB3b3VsZCBiZSBhIGdvb2QgcXVhbGl0eSBjaGVjay48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9w PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHls ZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YgPC9iPlBlY2ss IE1pY2hhZWwgQTxicj48Yj5TZW50OjwvYj4gVGh1cnNkYXksIDcgTWFyY2ggMjAxMyA2OjIxIEFN PGJyPjxiPlRvOjwvYj4gUmljaGFyZCBCYXJuZXM8YnI+PGI+Q2M6PC9iPiBqb3NlQGlldGYub3Jn PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1z aWduYXR1cmUtMDggJnF1b3Q7andrJnF1b3Q7IGhlYWRlciBwYXJhbWV0ZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SW4gdGhlIGNhc2Ugb2YgSldTLCBpdCBsb29rcyBsaWtlIHdpdGggdGhlIOKAnGp3a+KAnSBoZWFk ZXIgcGFyYW1ldGVyLCB0aGUgc2lnbmVkIG1lc3NhZ2UgaXRzZWxmIGNhbiBjb250YWluIHRoZSBy YXcgcHVibGljIGtleSB0byBiZSB1c2VkIHRvIHZlcmlmeSBpdC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5N eSBjb25jZXJuIGlzIHRoYXQgdGhlIHZlcmlmaWVyIHdpbGwgZ3JhYiBhbmQgdXNlIHRoZSBwdWJs aWMga2V5IHdpdGhvdXQgZW5zdXJpbmcgaXRzIGF1dGhlbnRpY2l0eS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz5UaGlzIHdvdWxkIGJlIGFuYWxvZ291cyB0byBhdXRvbWF0aWNhbGx5IHRydXN0aW5nIGEgc2Vs Zi1zaWduZWQgWC41MDkgY2VydGlmaWNhdGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlcmUgc2hvdWxk IGF0IGxlYXN0IGJlIHNvbWUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbGFuZ3VhZ2UgdGhhdCB3 aGVuIOKAnGp3a+KAnSBpcyB1c2VkIHRoZSB2ZXJpZmllciBuZWVkcyB0byB1c2Ugb3V0IG9mIGJh bmRzIG1lYW5zIHRvIGFzc3VyZSB0aGF0IHRoZSBwcm92aWRlZCBwdWJsaWMga2V5IGlzIHRydXN0 ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q01TIFNpZ25lZERh dGEgZG9lcyBub3QgY29udGFpbiB0aGUgcmF3IHB1YmxpYyBrZXkgdXNlZCB0byBzaWduIHRoZSBt ZXNzYWdlIGl0c2VsZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JdCBjb250YWlucyBhIFNpZ25lcklkZW50 aWZpZXIgdG8gcmVmZXJlbmNlIHRoZSBwdWJsaWMga2V5IGFuZCBvcHRpb25hbGx5IGNvbnRhaW5z IGNlcnRpZmljYXRlcyAod2hpY2ggd291bGQgY29udmV5IHRoZSBwdWJsaWMga2V5LCBidXQgYWxv bmcgd2l0aCBwcm9vZiB0aGF0IGl0IHNob3VsZCBiZSB0cnVzdGVkKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5SYXRoZXIgdGhhbiBkaXJlY3RseSBpbmNsdWRpbmcg dGhlIOKAnHJhd+KAnSBwdWJsaWMga2V5LCBKV1MgcHJvdmlkZXMgbG90cyBvZiBvdGhlciBzYWZl ciBoZWFkZXIgcGFyYW1ldGVycyB0byByZWZlcmVuY2UgdGhlIHB1YmxpYyBrZXkuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBSaWNo YXJkIEJhcm5lcyBbPGEgaHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giPm1haWx0bzpybGJAaXB2LnN4 PC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE1hcmNoIDA2LCAyMDEzIDE6NDUgUE08 YnI+PGI+VG86PC9iPiBQZWNrLCBNaWNoYWVsIEE8YnI+PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWls dG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJl OiBbam9zZV0gZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wOCAmcXVvdDtqd2sm cXVvdDsgaGVhZGVyIHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+V2hhdCdzIHlvdXIgdGhy ZWF0IHNjZW5hcmlvIGhlcmU/PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+SSB3b3VsZCBub3RlIHRo YXQgdGhlIHNpZ25lZCBjb250ZW50IG9mIGFuIFguNTA5IGNlcnRpZmljYXRlIGFsc28gZG9lcyBu b3QgY2FycnkgYW55IGluZGljYXRpb24gb2YgdGhlIHNpZ25lcidzIHB1YmxpYyBrZXkgKHVubGVz cyB0aGUgaXNzdWVyIGNob29zZXMgdG8gaW5jbHVkZSB0aGUgb3B0aW9uYWwgQXV0aG9yaXR5S2V5 SWRlbnRpZmllciBleHRlbnNpb24pLiAmbmJzcDtMaWtld2lzZSBmb3IgQ01TIFNpZ25lZERhdGEu ICZuYnNwO0JvdGggb2YgdGhvc2Ugc3RydWN0dXJlcyBhcmUgZXhhY3RseSBhbmFsb2dvdXMgdG8g SldTIGluIHRoaXMgcmVnYXJkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPkZvciBib3Ro IEpXUyBhbmQgQ01TIFNpZ25lZERhdGEsIHRoZSBtZXRob2QgaW4gd2hpY2ggdGhlIHJlY2lwaWVu dCBhdXRoZW50aWNhdGVzIHRoZSBrZXkgdXNlZCB0byB2ZXJpZnkgdGhlIHNpZ25hdHVyZSBpcyBv dXQgb2Ygc2NvcGUuICZuYnNwO1lvdSBjb3VsZCBldmVuIHNheSB0aGUgc2FtZSB0aGluZyBhYm91 dCBYLjUwOSwgc2luY2UgdGhlIGlzc3VlciBwdWJsaWMga2V5IGNvdWxkIGJlIGVpdGhlciBhIGNl cnRpZmllZCBrZXkgb3IgYSB0cnVzdCBhbmNob3IgKHByb3Zpc2lvbmVkIHRocm91Z2ggc29tZSBv dGhlciBjaGFubmVsKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTPk9uIFdlZCwgTWFyIDYsIDIwMTMgYXQgMTI6MjggUE0sIFBlY2ssIE1pY2hhZWwg QSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1wZWNrQG1pdHJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1w ZWNrQG1pdHJlLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5XaGF0IGlzIHRoZSB1c2UgY2FzZSBmb3IgdGhl ICZxdW90O2p3ayZxdW90OyAoSlNPTiBXZWIgS2V5KSBIZWFkZXIgUGFyYW1ldGVyIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDQuMS4zIG9mIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUt MDg/PGJyPjxicj5JdCBzZWVtcyB1bnNhZmUgZm9yIGEgc2lnbmF0dXJlIHRvIHByb3ZpZGUsIHVu YXV0aGVudGljYXRlZCAobm90IGluIGEgc2lnbmVkIGNlcnRpZmljYXRlIG9yIHByb3RlY3RlZCBi eSBvdGhlciBtZWFucyksIHRoZSBwdWJsaWMga2V5IHRvIGJlIHVzZWQgdG8gdmVyaWZ5IGl0c2Vs Zi48YnI+SSB3b3VsZCB0aGluayB0aGlzIGZpZWxkIG1ha2VzIGl0IHRvbyBlYXN5IGZvciBpbXBs ZW1lbnRhdGlvbnMgdG8gZG8gdGhlIHdyb25nIHRoaW5nLjxicj48YnI+VGhhbmtzLDxicj5NaWtl PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmpv c2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGll dGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1150B476F63WSMSG3153Vsrv_-- From rlb@ipv.sx Fri Mar 8 06:37:15 2013 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 5163121F8578 for ; Fri, 8 Mar 2013 06:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-1.420, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 vO-gqGPvNrGb for ; Fri, 8 Mar 2013 06:37:14 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id E8D4521F8570 for ; Fri, 8 Mar 2013 06:37:13 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id ef5so1274013obb.25 for ; Fri, 08 Mar 2013 06:37:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=1xTT++opcQ/fYZ7IzR5KZeVgqHM7FK5M1hB4Hiu5L5A=; b=WZIVLOZQSa3KMiAN4OUSXXgEbnzGs8K5+wanXsFsN69F9yt3LKra3si+VI5z264w/K gIvTBwBbDmwSm1ny/QTtVSB/vvJzjsW/z+rIZ9zeJfVUwla8Y4+uWukivHNZTK68l7i3 NCJ9b0blQZ2OFWzJBXaDA9puc5jFg1HhXGJzwKnxFLHLtd5AiQM5/vYVVs+NFSn6bC5D VwgMH8JHkFy/+1gu1910y8NqVIDhNCzkbCUaqIMzzghWG9TTCKiS/7bM5XVtr8fzorSW XT22zN62cZheLuZvKoRMvanEnBrS3vn8pIkoqO3MzrpOzAaPbP+ErBFlZSTL5NKR6333 fATQ== MIME-Version: 1.0 X-Received: by 10.182.93.193 with SMTP id cw1mr1611326obb.93.1362753433323; Fri, 08 Mar 2013 06:37:13 -0800 (PST) Received: by 10.60.150.131 with HTTP; Fri, 8 Mar 2013 06:37:13 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 8 Mar 2013 09:37:13 -0500 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae93a17235073e204d76ac28b X-Gm-Message-State: ALoCoQkFZIDhBYOrmN8XfYSPmA+utmMNQBB6CbVirQy4/NOaPLaOmnU3i7a5RAGdbzuzcBmP6/sa Cc: "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 08 Mar 2013 14:37:15 -0000 --14dae93a17235073e204d76ac28b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I agree, Michael. A raw public key in a JWS is inviting dangerous code. > Could you be a little more precise here? What's the danger? The only difference between a key and a cert is that the cert provides the recipient with some attributes that go along with the key (signed under some authority) -- assuming the recipient supports X.509 and has an appropriate trust anchor. So the only danger is that the recipient might not check the attributes before accepting the signature. This is a completely separate question from whether the signature is valid, in a cryptological / mathematical sense. And the answer you're implying (that not checking attributes is dangerous) is clearly not true in all cases. For example, in PGP, you've validated the public key through some out-of-band channel, and you really do just need the key here. JOSE should stick to crypto, and stay away from policy. To do otherwise would cut off use cases unnecessariliy. > Key ids are even worse in JWE. An originator encrypts data with a > recipient=92s public key. The recipient needs to know which of his or her > private keys to use to decrypt. JWE defines ways for the originator to > include: the raw public key (jwk); a URI for the raw public key (jku) > (actually a URI for a collection of raw public keys, one of which is the > right one, but there is no indication which one that is); the certificate > chain (x5c); and/or a URI for the certificate chain (x5u). This is all > pointless =97 the recipient doesn=92t need to be given its own public key= or > certificate. Only the =93kid=94 (key id) field makes sense. > > ** ** > > The originator can also include a hash of the certificate (x5t). The only > use I can think of for that is when the originator doesn=92t know a key i= d > (eg there is no id-ce-subjectKeyIdentifier extension in the certificate) = so > it synthesises one. In this situation it would be better to hash the publ= ic > key (not the certificate) as per RFC 5280 =93PKIX certificate and CRL > Profile=94, section 4.2.1.2. =93Subject Key Identifier=94.**** > > ** ** > > I don=92t think there are any examples that use kid, jwk, jku, x5u, x5c, = or > x5t in a JOSE message in JWE, JWS, or JWT. Perhaps ensuring each defined > field does appear in an example would be a good quality check. > I agree that some of these are not tremendously useful, but they're pretty harmless except for the additional complexity of trying to support all of them. --Richard > --**** > > James Manger**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Peck, Michael A > *Sent:* Thursday, 7 March 2013 6:21 AM > *To:* Richard Barnes > > *Cc:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > ** ** > > In the case of JWS, it looks like with the =93jwk=94 header parameter, th= e > signed message itself can contain the raw public key to be used to verify > it.**** > > My concern is that the verifier will grab and use the public key without > ensuring its authenticity.**** > > This would be analogous to automatically trusting a self-signed X.509 > certificate.**** > > There should at least be some Security Considerations language that when > =93jwk=94 is used the verifier needs to use out of bands means to assure = that > the provided public key is trusted.**** > > ** ** > > CMS SignedData does not contain the raw public key used to sign the > message itself.**** > > It contains a SignerIdentifier to reference the public key and optionally > contains certificates (which would convey the public key, but along with > proof that it should be trusted).**** > > ** ** > > Rather than directly including the =93raw=94 public key, JWS provides lot= s of > other safer header parameters to reference the public key.**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx ] > *Sent:* Wednesday, March 06, 2013 1:45 PM > *To:* Peck, Michael A > *Cc:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > ** ** > > What's your threat scenario here?**** > > ** ** > > I would note that the signed content of an X.509 certificate also does no= t > carry any indication of the signer's public key (unless the issuer choose= s > to include the optional AuthorityKeyIdentifier extension). Likewise for > CMS SignedData. Both of those structures are exactly analogous to JWS in > this regard.**** > > ** ** > > For both JWS and CMS SignedData, the method in which the recipient > authenticates the key used to verify the signature is out of scope. You > could even say the same thing about X.509, since the issuer public key > could be either a certified key or a trust anchor (provisioned through so= me > other channel).**** > > ** ** > > ** ** > > On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A wrote:= * > *** > > What is the use case for the "jwk" (JSON Web Key) Header Parameter > described in section 4.1.3 of draft-ietf-jose-json-web-signature-08? > > It seems unsafe for a signature to provide, unauthenticated (not in a > signed certificate or protected by other means), the public key to be use= d > to verify itself. > I would think this field makes it too easy for implementations to do the > wrong thing. > > Thanks, > Mike > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --14dae93a17235073e204d76ac28b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">I agree, Michael. A raw public key in a JWS is in= viting dangerous code.


Could you be a little more precise h= ere? =A0What's the danger?

The only difference= between a key and a cert is that the cert provides the recipient with some= attributes that go along with the key (signed under some authority) -- ass= uming the recipient supports X.509 and has an appropriate trust anchor. =A0= So the only danger is that the recipient might not check the attributes bef= ore accepting the signature.

This is a completely separate question from whether the= signature is valid, in a cryptological / mathematical sense. =A0And the an= swer you're implying (that not checking attributes is dangerous) is cle= arly not true in all cases. =A0For example, in PGP, you've validated th= e public key through some out-of-band channel, and you really do just need = the key here.

JOSE should stick to crypto, and stay away from policy.= =A0To do otherwise would cut off use cases unnecessariliy.

<= /div>
=A0

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">=A0Key ids are even worse in JWE. An originator encry= pts data with a recipient=92s public key. The recipient needs to know which= of his or her private keys to use to decrypt. JWE defines ways for the ori= ginator to include: the raw public key (jwk); a URI for the raw public key = (jku) (actually a URI for a collection of raw public keys, one of which is = the right one, but there is no indication which one that is); the certifica= te chain (x5c); and/or a URI for the certificate chain (x5u). This is all p= ointless =97 the recipient doesn=92t need to be given its own public key or= certificate. Only the =93kid=94 (key id) field makes sense.

=A0<= /p>

The originator can als= o include a hash of the certificate (x5t). The only use I can think of for = that is when the originator doesn=92t know a key id (eg there is no id-ce-s= ubjectKeyIdentifier extension in the certificate) so it synthesises one. In= this situation it would be better to hash the public key (not the certific= ate) as per RFC 5280 =93PKIX certificate and CRL Profile=94, section 4.2.1.= 2. =93Subject Key Identifier=94.

=A0<= /p>

I don=92t think there = are any examples that use kid, jwk, jku, x5u, x5c, or x5t in a JOSE message= in JWE, JWS, or JWT. Perhaps ensuring each defined field does appear in an= example would be a good quality check.


I agree that some of these are not t= remendously useful, but they're pretty harmless except for the addition= al complexity of trying to support all of them.=A0

--Richard



=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

--=

James Manger

=A0

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Beha= lf Of Peck, Michael A
Sent: Thursday, 7 March 2013 6:21 AM
To: Richard Barnes


Cc: jose@ietf.org
Subject: Re: [jose] draft= -ietf-jose-json-web-signature-08 "jwk" header parameter=

<= /u>=A0

In the case of JWS, it looks like with the =93jwk=94 header paramete= r, the signed message itself can contain the raw public key to be used to v= erify it.

My concern= is that the verifier will grab and use the public key without ensuring its= authenticity.

This would= be analogous to automatically trusting a self-signed X.509 certificate.=

There shou= ld at least be some Security Considerations language that when =93jwk=94 is= used the verifier needs to use out of bands means to assure that the provi= ded public key is trusted.

=A0=

CMS SignedData does not contain the raw public key used to sign the= message itself.

It contain= s a SignerIdentifier to reference the public key and optionally contains ce= rtificates (which would convey the public key, but along with proof that it= should be trusted).

=A0=

Rather than directly including the =93raw=94 public key, JWS provid= es lots of other safer header parameters to reference the public key.

=A0=

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Wednesday, March 06, 2013 1:45 PM
To: Peck, Michael = A
Cc: jose@iet= f.org
Subject: Re: [jose] draft-ietf-jose-json-web-signature-= 08 "jwk" header parameter

=A0

What's your threat= scenario here?

=A0

I would note that th= e signed content of an X.509 certificate also does not carry any indication= of the signer's public key (unless the issuer chooses to include the o= ptional AuthorityKeyIdentifier extension). =A0Likewise for CMS SignedData. = =A0Both of those structures are exactly analogous to JWS in this regard.=

=A0

For both JWS= and CMS SignedData, the method in which the recipient authenticates the ke= y used to verify the signature is out of scope. =A0You could even say the s= ame thing about X.509, since the issuer public key could be either a certif= ied key or a trust anchor (provisioned through some other channel).<= u>

=A0

=A0

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <mpeck@mitre.org> wrote:

What is the use case for the &q= uot;jwk" (JSON Web Key) Header Parameter described in section 4.1.3 of= draft-ietf-jose-json-web-signature-08?

It seems unsafe for a signat= ure to provide, unauthenticated (not in a signed certificate or protected b= y other means), the public key to be used to verify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike
______________________________________= _________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=

=A0


_______________________________________________=
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--14dae93a17235073e204d76ac28b-- From dholth@gmail.com Fri Mar 8 07:00:58 2013 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 D744421F853E for ; Fri, 8 Mar 2013 07:00:58 -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 OdAzC9NyJ4VL for ; Fri, 8 Mar 2013 07:00:58 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id 242B621F8532 for ; Fri, 8 Mar 2013 07:00:57 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id fg15so2572364wgb.25 for ; Fri, 08 Mar 2013 07:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aCfbBoUB0tSg2xc7YSM5bmVgRkOmOcg50XMtFlwYf3w=; b=A2qN1QCJ4bj8CuhACyrcL0tdiIKX/2UuQ/MaIpNOg5B6u5vmAOerZKLZQPKj5xxB5j Cisr/jtV94An/4D0zwiH9f6amvFTtfEoEnbeBcx7LUnosPjDmxheiMjfi3qI3OxKOgZe icHlQCXu+Qqj7JVR47K6doK9Y7VzBR9RpMUUIFKwrs6tIYRicpVTkPtKf6Ki1RINGuG1 WS8FTUvQ//0A2weYFW/NVmOrPLcCM4vRm3ux2wlYMa3wVXMmN9eQlushH1DNyjLuMLDs Vht94M99yVE03ry5bqZ/q/25hDKYiATFbD0KMSX40Dn8ylYic7bdXpJLLvzjvZ/lX67Y 2TyQ== MIME-Version: 1.0 X-Received: by 10.180.80.35 with SMTP id o3mr41543800wix.9.1362754852171; Fri, 08 Mar 2013 07:00:52 -0800 (PST) Received: by 10.194.122.67 with HTTP; Fri, 8 Mar 2013 07:00:52 -0800 (PST) In-Reply-To: References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 8 Mar 2013 10:00:52 -0500 Message-ID: From: Daniel Holth To: Richard Barnes Content-Type: text/plain; charset=ISO-8859-1 Cc: "Peck, Michael A" , "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 08 Mar 2013 15:00:58 -0000 I use and love the jwk feature "literal public keys". It's useful to me because the signature has more bandwidth than the mechanism used to convey trust (for example a signed list of hashes of public keys). Of course you have to establish trust somehow, but banning keys from signatures based on a particular notion of how this is accomplished is limiting. From rlb@ipv.sx Fri Mar 8 10:42:54 2013 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 A4EE421F88DB for ; Fri, 8 Mar 2013 10:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.884 X-Spam-Level: X-Spam-Status: No, score=-2.884 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Djsl1XYp9Xmr for ; Fri, 8 Mar 2013 10:42:54 -0800 (PST) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id D40FB21F8836 for ; Fri, 8 Mar 2013 10:42:53 -0800 (PST) Received: by mail-oa0-f53.google.com with SMTP id m1so2349335oag.40 for ; Fri, 08 Mar 2013 10:42:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=ShGu7klLKIUVJZfUx80qyB0KVG8fD3ks0cJ1qXgHwGU=; b=BW2GvHHNYXMgq3Z+oKZHxPOm8uTpBVo/OEvnQrNSGJwnrn9mcdLPF4ORH/aQeW+ncg +bNhSy4ZB0PuBuoG1IN070dM5hp7/tKNfQk13TqOZh1cOybybGgyHx49BHpxQ/AhhJ+G 6d/FfUX5+vEVZeMlP6OD5kkI508tURJf9/JqjQ0+L6xOcWQIcLZyuSEz146xncUuC3cV F5NHOcvpIJZ6OGH8CEM9wxF31PHpbUCyOsxCZJPNfYt7bze2QU8HT6vCReJJ/j1GAfy7 0yASvYGlCRFTAYjkc8kFa9xKXERaIyRzCkU5yjOY05c9jI6JEitRSu/vQfdi3Vazg2/8 Okng== MIME-Version: 1.0 X-Received: by 10.60.29.161 with SMTP id l1mr2658797oeh.111.1362768173180; Fri, 08 Mar 2013 10:42:53 -0800 (PST) Received: by 10.60.150.131 with HTTP; Fri, 8 Mar 2013 10:42:53 -0800 (PST) X-Originating-IP: [192.1.51.63] Date: Fri, 8 Mar 2013 13:42:53 -0500 Message-ID: From: Richard Barnes To: jose@ietf.org Content-Type: multipart/alternative; boundary=e89a8fb200fadfc05004d76e30fa X-Gm-Message-State: ALoCoQnTEtEshVIG9f/oSG8kAjT4nY+XmmCJOBZrHJmFojgPP+4CeSh0zkB/pi7Jz4YCXhO4cpke Subject: [jose] A Unified Theory of JOSE Keys 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, 08 Mar 2013 18:42:54 -0000 --e89a8fb200fadfc05004d76e30fa Content-Type: text/plain; charset=ISO-8859-1 I've posted some draft slides for my presentation on JOSE keys: Some thoughts are below to get the discussion started early... What I'm proposing here is that we re-factor JWK and JWA to address all of the use cases we have for keys -- including public keys, wrapped/unwrapped private/symmetric keys, and key attributes. That is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we should just do all key management in JWK. This actually entails less work than you might imagine. JWE provides us with a wrapped symmetric key format, and Mike's recent draft provides an unwrapped, JSON-based symmetric key format. From these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add attributes to keys as a bonus. The slide deck illustrates a proposed wrapping algorithm that would do this. At the end of the slide deck, there's a proposal to edit JWK and JWA to add key wrapping. To make that a little more precise, I would imagine the contents of the revised JWK draft to look something like the following (omitting identical sections): -----BEGIN----- 4. JSON Web Key (JWK) Format 4.1. "kty" (Key Type) Parameter 4.2. "use" (Key Use) Parameter 4.3. "alg" (Algorithm) Parameter 4.4. "kid" (Key ID) Parameter 4.5. "kat" (Wrapped Key Attributes) Parameter 4.6. "wk" (Wrapped Key) Parameter 4.7. "epk" (Ephemeral Public Key) Header Parameter 4.8. "jku" (JWK Set URL) Header Parameter 4.9. "jwk" (JSON Web Key) Header Parameter 4.10. "x5u" (X.509 URL) Header Parameter 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter 4.12. "x5c" (X.509 Certificate Chain) Header Parameter 4.13. "apu" (Agreement PartyUInfo) Header Parameter 4.14. "apv" (Agreement PartyVInfo) Header Parameter 5. Wrapped keys 5.1. Key Wrapping Procedure 5.2. Key Unwrapping Procedure -----END----- The revised JWA draft would just fold in the fields from draft-jones-jose-json-private-and-symmetric-key, and add the obvious encoding rules for RSA and EC keys. Comments welcome! Thanks, --Richard --e89a8fb200fadfc05004d76e30fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've posted some draft slides for my presentation on JOSE keys:
Some thoughts are below to get the discussion sta= rted early...

What I'm proposing here is that we re-factor JWK an= d JWA to address all of the use cases we have for keys -- including public = keys, wrapped/unwrapped private/symmetric keys, and key attributes. =A0That= is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, an= d the remainder somewhere else, we should just do all key management in JWK= .

This actually entails less work than you might imagine.= =A0JWE provides us with a wrapped symmetric key format, and Mike's rec= ent draft provides an unwrapped, JSON-based symmetric key format. =A0From t= hese we can extrapolate to wrapped private keys in a pretty straightforward= fashion, and pick up the ability to add attributes to keys as a bonus. =A0= The slide deck illustrates a proposed wrapping algorithm that would do this= .

At the end of the slide deck, there's a proposal to= edit JWK and JWA to add key wrapping. =A0To make that a little more precis= e, I would imagine the contents of the revised JWK draft to look something = like the following (omitting identical sections):
-----BEGIN-----
4. =A0JSON Web Key (JWK) Format
4.1. =A0"kty" (Key Type) Parameter
4.2. =A0"use= " (Key Use) Parameter
4.3. =A0"alg" (Algorithm) Pa= rameter
4.4. =A0"kid" (Key ID) Parameter
4.5. =A0"kat= " (Wrapped Key Attributes) Parameter
4.6. =A0"wk" = (Wrapped Key) Parameter
4.7. =A0"epk" (Ephemeral Public= Key) Header Parameter
4.8. =A0"jku" (JWK Set URL) Header Parameter
4.9. = =A0"jwk" (JSON Web Key) Header Parameter
4.10. "x5= u" (X.509 URL) Header Parameter
4.11. "x5t" (X.509= Certificate Thumbprint) Header Parameter
4.12. "x5c" (X.509 Certificate Chain) Header Parameter
=
4.13. "apu" (Agreement PartyUInfo) Header Parameter
4.14. "apv" (Agreement PartyVInfo) Header Parameter
5. Wrapped keys
5.1. Key Wrapping Procedure
5.2. Key Un= wrapping Procedure
-----END-----
The revised JWA = draft would just fold in the fields from draft-jones-jose-json-private-and-= symmetric-key, and add the obvious encoding rules for RSA and EC keys.

Comments welcome!

Thanks,
--Richard


--e89a8fb200fadfc05004d76e30fa-- From rlb@ipv.sx Fri Mar 8 11:26:58 2013 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 D804021F8870 for ; Fri, 8 Mar 2013 11:26:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.793 X-Spam-Level: X-Spam-Status: No, score=-2.793 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aWCy4-p08kkX for ; Fri, 8 Mar 2013 11:26:57 -0800 (PST) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0E821F886D for ; Fri, 8 Mar 2013 11:26:57 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id l20so2447720oag.37 for ; Fri, 08 Mar 2013 11:26:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Y3NzVtQ9EBCv3/mhEe+RvetgUfEV15edFOps92NDeTg=; b=HVX0Gw/uq+mWbLTgKr2/7Ydg2HgiLpinqmTlILstUYqNcvbHaF3hxz0A9fZDfkwq4A mt8mA8svuBgctp6htEqLlvMshgOeXss91dOulU48WN6BKUPtdTj2sIEcVQPQfsm6xa8P QAwJVrrusYnGNt05ANHgCaffFEcHLq1afepPiphn1B1QPL/eIIKHYQ59LVSDMJr+qe0n b1YbIKjOGx+p6IOz/Cwhwma82DtWFbq5zIOOwGWSZcTf2jTJfnsTr7J1RKz3CcxJSnY5 81t0my+w9obkF+QVTeWkyu73hrprUnNjYtBd7JKwXKHJ3XTxmqfFVWCAGupD5s3ySvlq 2wdg== MIME-Version: 1.0 X-Received: by 10.60.29.161 with SMTP id l1mr2859541oeh.111.1362770816583; Fri, 08 Mar 2013 11:26:56 -0800 (PST) Received: by 10.60.150.131 with HTTP; Fri, 8 Mar 2013 11:26:56 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: References: <1360628984.83146.YahooMailRC@web184403.mail.bf1.yahoo.com> <4E1F6AAD24975D4BA5B16804296739436747B244@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Mar 2013 14:26:56 -0500 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb200fa6ee65104d76ece82 X-Gm-Message-State: ALoCoQmgF3B2KwyRLJulhzgQzT+7pIbVE1IY5Ky5z8O0MmZaxT55wQRBhJzpNoRjq4KwNzyyMcuq Cc: Brian Campbell , Nat Sakimura , "jose@ietf.org" , Edmund Jay Subject: Re: [jose] Proposal about the SPI proposal 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, 08 Mar 2013 19:26:59 -0000 --e89a8fb200fa6ee65104d76ece82 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable -----BEGIN----- Section 4.1.X. "spi" (Security Parameters Index) Header Parameter The "spi" (Security Parameters Index) header parameter contains a base64url-encoded opaque byte string that labels a set of security parameters. This index is designed to enable the use of smaller headers in cases where entities use an out-of-band mechanism to negotiate cryptographic parameters. Entities using an out-of-band negotiation mechanism maintain a table of cached security parameters. The maintenance of this table, e.g., how entries are added or removed, is done by the out-of-band key management protocol. Each entry in the table is indexed by an SPI value, and contains pre-negotiated parameters for the JWE, such as values for the "alg" or "zip" parameters, or a value for the Encrypted Key component. A JWE whose header contains an SPI value MAY omit the Encrypted Key component, by making this field zero-length in the compact serialization. An entity receiving such a JWE reconstructs the full JWE by adding the cached header fields to the header, and adding the Encrypted Key components to the JWE. The reconstructed JWE is then processed as normal. If a JWE object contains an unrecognized SPI value, then the recipient MUST consider it invalid. The out-of-band management protocol MUST ensure that the SPI value is unique within the sender's context. To prevent the SPI value from being used to interfere with JOSE processing, the management protocol SHOULD also ensure that it is difficult for a third party (who has not participated in the management protocol) to guess an SPI value. As a simple way to meet both of these requirements, it is RECOMMENDED that the SPI value be a 128-bit random value. -----END----- On Wed, Feb 27, 2013 at 1:50 PM, Richard Barnes wrote: > Ah, sorry I never got around to those. Responses inline. > > - What are the security implications of repeatedly reusing the same >> CMK and IV and how can/should they be mitigated? >> > > Good point. Re-using IVs is a terrible idea. SPI should represent some > set of pre-negotiated parameters, where the set of parameters that are > pre-set is part of the pre-negotiation. So one application might > pre-negotiate algorithms, but pass keys in-band, but another might > pre-negotiate algorithms and keys. (You could even envision agreeing on = an > IV generation procedure...) > > >> **** >> >> - Is having the absence of an =93alg=94 field, paired with the presenc= e of >> an =93spi=94 field the best way to handle this? >> > > "alg" is an indicator of key wrapping technique. So if this is one of th= e > pre-negotiated parameters, then it should be absent. > > >> **** >> >> - What are the complexity implications of having JWEs no longer contai= n >> a fixed set of field? >> > > Very little. SPI would add a little pre-processing to populate the > missing fields in a JWE/JWS > > >> **** >> >> - Would JWSs similarly have a different number of fields? >> > > Yes. > > >> **** >> >> - Indeed, is the proposal even applicable in the JWS case, or does it >> only make sense for JWEs? >> > > There's less of a need for JWS. You could say SPI "1234" indicates that > I'm signing under a given 4096-bit RSA key, saving yourself hundreds of > octets. So it would be like "jku", with fewer octets and without the > implication that you could go fetch it over the Internet. > > >> **** >> >> - What are the motivating use cases for this functionality? >> > > As I said before, cases where there's some out-of-band mechanism to > pre-negotiate certain parameters. For example, the OpenID Connect > discovery process. > < > http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigu= rationRequest > > > > > >> **** >> >> - What syntax would be used for the =93spi=94 parameter? Unrestricted >> Unicode strings? Base64url-encoded byte strings? UUIDs? =85 >> > > Doesn't really matter. Make it the same as "kid" (i.e., string); they're > both opaque identifiers. > > > >> **** >> >> ** ** >> >> I don=92t think a number of them have been answered.**** >> >> ** ** >> >> Thanks,**** >> >> -- Mike**** >> >> ** ** >> >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *Richard Barnes >> *Sent:* Wednesday, February 20, 2013 10:04 AM >> *To:* Nat Sakimura >> *Cc:* Brian Campbell; jose@ietf.org; Edmund Jay >> *Subject:* Re: [jose] Proposal about the SPI proposal**** >> >> ** ** >> >> Obviously, this will not be in a -00 draft for Orlando. So discussion >> should continue based on the text proposed to the list.**** >> >> ** ** >> >> Does anyone have further technical comments?**** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura >> wrote:**** >> >> ditto. **** >> >> 2013/2/11 Edmund Jay **** >> >> +1 for new I-D. >> >> **** >> >> ** ** >> ------------------------------ >> >> *From:* Brian Campbell >> *To:* "jose@ietf.org" >> *Sent:* Fri, February 8, 2013 3:01:51 PM >> *Subject:* [jose] Proposal about the SPI proposal**** >> >> ** ** >> >> Maybe this was apparent from my comments/questions on the SPI proposal >> over the last couple days[1] but I have concerns that run the gamut from >> operational complexity and fragility to security problems. I believe >> strongly that, without considerably more analysis and specification deta= il, >> the current SPI work is much too risky to consider go in the current bas= e >> JOSE WG drafts.**** >> >> As an alternative I'd like to request/propose that the SPI stuff be >> submitted as new I-D to help facilitate that additional discussion and >> analysis that I think it needs.**** >> >> ** ** >> >> Thanks, >> Brian**** >> >> >> [1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html**** >> >> ** ** >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose**** >> >> >> >> **** >> >> ** ** >> >> -- >> Nat Sakimura (=3Dnat)**** >> >> Chairman, OpenID Foundation >> http://nat.sakimura.org/ >> @_nat_en**** >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > > --e89a8fb200fa6ee65104d76ece82 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
-----BEGIN-----
Section 4.1.X. "spi" (Security Parameters Index) Header Parameter

The "spi" (Security Pa= rameters Index) header parameter contains a base64url-encoded opaque byte s= tring that labels a set of security parameters. =A0This index is designed t= o enable the use of smaller headers in cases where entities use an out-of-b= and mechanism to negotiate cryptographic parameters.=A0

Entities using an out-of-band negotiation mechanism=A0maintain a table of c= ached security parameters. =A0The maintenance of this table, e.g., how entr= ies are added or removed, is done by the out-of-band key management protoco= l. =A0Each entry in the table is indexed by an=A0SPI=A0value, and contains pre= -negotiated parameters for the JWE, such as values for the "alg" = or "zip" parameters, or a value for the Encrypted Key component.<= /div>

A JWE whose header contains an=A0SPI=A0value MAY omit the Encrypted Key componen= t, by making this field zero-length in the compact serialization. =A0 An en= tity receiving such a JWE reconstructs the full JWE by adding the cached he= ader fields to the header, and adding the Encrypted Key components to the J= WE. =A0The reconstructed JWE is then processed as normal. =A0If a JWE objec= t contains an unrecognized=A0SPI=A0value, then the recipient MUST consider it in= valid.

The out-of-band management protocol MUST ensure that the SPI value is uniqu= e within the sender's context. =A0To prevent the SPI value from being u= sed to interfere with JOSE processing, the management protocol SHOULD also = ensure that it is difficult for a third party (who has not participated in = the management protocol) to guess an SPI value. =A0As a simple way to meet = both of these requirements, it is RECOMMENDED that the SPI value be a 128-b= it random value. =A0
-----END-----



On Wed, Feb 27, 2013 at 1:50 PM, Richard Barnes <rlb@ipv.sx>= wrote:
Ah, sorry I never got around to those. =A0Re= sponses inline.

=A0 - What are the securi= ty implications of repeatedly reusing the same CMK and IV and how can/shoul= d they be mitigated?


Good point. =A0Re-= using IVs is a terrible idea. =A0SPI should represent some set of pre-negot= iated parameters, where the set of parameters that are pre-set is part of t= he pre-negotiation. =A0So one application might pre-negotiate algorithms, b= ut pass keys in-band, but another might pre-negotiate algorithms and keys. = =A0(You could even envision agreeing on an IV generation procedure...)
=A0

=A0 - Is having the absen= ce of an =93alg=94 field, paired with the presence of an =93spi=94 field th= e best way to handle this?


"alg" is= an indicator of key wrapping technique. =A0So if this is one of the pre-ne= gotiated parameters, then it should be absent.
=A0

=A0 - What are the comple= xity implications of having JWEs no longer contain a fixed set of field?


Very little. =A0SP= I would add a little pre-processing to populate the missing fields in a JWE= /JWS
=A0

=A0 - Would JWSs similarl= y have a different number of fields?


Yes.
=A0
=

=A0 - Indeed, is the prop= osal even applicable in the JWS case, or does it only make sense for JWEs?<= /span>


There's less o= f a need for JWS. =A0You could say SPI "1234" indicates that I= 9;m signing under a given 4096-bit RSA key, saving yourself hundreds of oct= ets. =A0So it would be like "jku", with fewer octets and without = the implication that you could go fetch it over the Internet.
=A0

=A0 - What are the motiva= ting use cases for this functionality?


As I said before, cases where there's some ou= t-of-band mechanism to pre-negotiate certain parameters. =A0For example, th= e OpenID Connect discovery process.

=A0

=A0 - What syntax would b= e used for the =93spi=94 parameter?=A0 Unrestricted Unicode strings?=A0 Bas= e64url-encoded byte strings?=A0 UUIDs? =85


Doesn't really= matter. =A0Make it the same as "kid" (i.e., string); they're= both opaque identifiers.

=A0

=A0<= /p>

I don=92t think a n= umber of them have been answered.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 20, 2013 10:04 AM
To: Nat Sakimura
Cc: Brian Campbell; jose@ietf.org; Edmund Jay
Subject: Re: [jose] Proposal about the SPI proposal

=A0

Obviously, this will not be in a -00 draft for Orlan= do. =A0So discussion should continue based on the text proposed to the list= .

=A0

Does anyone have further technical comments?<= u>

=A0

--Richard

=A0

On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

ditto.=A0

2013/2/11 Edmund Jay <ejay@mgi1.com>

+1 for ne= w I-D.

=A0

From: Brian Campbell <bcampbell@pingidentity.com>=
To: "jose@ie= tf.org" <jos= e@ietf.org>
Sent: Fri, February 8, 2013 3:01:51 PM
Subject: [jose] Proposal about the SPI proposal=

=A0

Maybe this was appare= nt from my comments/questions on the SPI proposal over the last couple days= [1] but I have concerns that run the gamut from operational complexity and = fragility to security problems. I believe strongly that, without considerably more analysis and specification detail= , the current SPI work is much too risky to consider go in the current base= JOSE WG drafts.

As an alternative I'd like to request/propose th= at the SPI stuff be submitted as new I-D to help facilitate that additional= discussion and analysis that I think it needs.

=A0

Thanks,
Brian

=A0

_____________________= __________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Found= ation
http://nat.sakimura.= org/
@_nat_en


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0



--e89a8fb200fa6ee65104d76ece82-- From rlb@ipv.sx Fri Mar 8 11:27:19 2013 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 0A66E21F888E for ; Fri, 8 Mar 2013 11:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.538 X-Spam-Level: X-Spam-Status: No, score=-1.538 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 qnOELEkTnsmI for ; Fri, 8 Mar 2013 11:27:18 -0800 (PST) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id C3E1021F886D for ; Fri, 8 Mar 2013 11:27:17 -0800 (PST) Received: by mail-ob0-f171.google.com with SMTP id x4so1596049obh.16 for ; Fri, 08 Mar 2013 11:27:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XDa8k9QmppSXzSAeFIgEyJfpuZDA2JA3Zyu24VQblpI=; b=nC8+zKMaaUK2hMSgbESxmm6CmU7u0pzoZ/HJjLMBpRZb6AL2NKqqzgS/H7kiIRIxVB 7eHtTPaz4jmd1VB+j5OCwDbPX9hiR8d+8SOl3uLvsQ31DUIl3VCOSgTl47+DDSuo9tZN MJqHXghwucxzVn1WBzFHQ0izd8mRZM65zTTY4rTeHgZYjNfkOflFUP5/b14uZcArljpU YJUKtqplzddlybySCXdfX7A8yDK4bkDEH9FIudaoqKNjsJKaW27Q06b/x5oEzog8fb3z A3uPt5mw1K2XWLJHjUM2K1w0ptPbtCC08Dbvk9zDO4oiooRfdddz/Lv4S+nEUJJyjZYX d+gQ== MIME-Version: 1.0 X-Received: by 10.182.118.105 with SMTP id kl9mr2840762obb.52.1362770837312; Fri, 08 Mar 2013 11:27:17 -0800 (PST) Received: by 10.60.150.131 with HTTP; Fri, 8 Mar 2013 11:27:17 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: References: <1360628984.83146.YahooMailRC@web184403.mail.bf1.yahoo.com> <4E1F6AAD24975D4BA5B16804296739436747B244@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 8 Mar 2013 14:27:17 -0500 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0447a29fab2e7e04d76ecfb8 X-Gm-Message-State: ALoCoQkm1v+r3FZkzps1g5aMcDicjUB9TUH2OdadQy1jCUdVBDWPvlbiwYzl7PiZaxBGLFOq9TyF Cc: Brian Campbell , Nat Sakimura , "jose@ietf.org" , Edmund Jay Subject: Re: [jose] Proposal about the SPI proposal 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, 08 Mar 2013 19:27:19 -0000 --f46d0447a29fab2e7e04d76ecfb8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry, meant to start with: Revised text for the SPI proposal follows. On Fri, Mar 8, 2013 at 2:26 PM, Richard Barnes wrote: > -----BEGIN----- > Section 4.1.X. "spi" (Security Parameters Index) Header Parameter > > The "spi" (Security Parameters Index) header parameter contains a > base64url-encoded opaque byte string that labels a set of security > parameters. This index is designed to enable the use of smaller headers = in > cases where entities use an out-of-band mechanism to negotiate > cryptographic parameters. > > Entities using an out-of-band negotiation mechanism maintain a table of > cached security parameters. The maintenance of this table, e.g., how > entries are added or removed, is done by the out-of-band key management > protocol. Each entry in the table is indexed by an SPI value, and > contains pre-negotiated parameters for the JWE, such as values for the > "alg" or "zip" parameters, or a value for the Encrypted Key component. > > A JWE whose header contains an SPI value MAY omit the Encrypted Key > component, by making this field zero-length in the compact serialization. > An entity receiving such a JWE reconstructs the full JWE by adding the > cached header fields to the header, and adding the Encrypted Key componen= ts > to the JWE. The reconstructed JWE is then processed as normal. If a JWE > object contains an unrecognized SPI value, then the recipient MUST > consider it invalid. > > The out-of-band management protocol MUST ensure that the SPI value is > unique within the sender's context. To prevent the SPI value from being > used to interfere with JOSE processing, the management protocol SHOULD al= so > ensure that it is difficult for a third party (who has not participated i= n > the management protocol) to guess an SPI value. As a simple way to meet > both of these requirements, it is RECOMMENDED that the SPI value be a > 128-bit random value. > -----END----- > > > > On Wed, Feb 27, 2013 at 1:50 PM, Richard Barnes wrote: > >> Ah, sorry I never got around to those. Responses inline. >> >> - What are the security implications of repeatedly reusing the same >>> CMK and IV and how can/should they be mitigated? >>> >> >> Good point. Re-using IVs is a terrible idea. SPI should represent some >> set of pre-negotiated parameters, where the set of parameters that are >> pre-set is part of the pre-negotiation. So one application might >> pre-negotiate algorithms, but pass keys in-band, but another might >> pre-negotiate algorithms and keys. (You could even envision agreeing on= an >> IV generation procedure...) >> >> >>> **** >>> >>> - Is having the absence of an =93alg=94 field, paired with the presen= ce of >>> an =93spi=94 field the best way to handle this? >>> >> >> "alg" is an indicator of key wrapping technique. So if this is one of >> the pre-negotiated parameters, then it should be absent. >> >> >>> **** >>> >>> - What are the complexity implications of having JWEs no longer >>> contain a fixed set of field? >>> >> >> Very little. SPI would add a little pre-processing to populate the >> missing fields in a JWE/JWS >> >> >>> **** >>> >>> - Would JWSs similarly have a different number of fields? >>> >> >> Yes. >> >> >>> **** >>> >>> - Indeed, is the proposal even applicable in the JWS case, or does it >>> only make sense for JWEs? >>> >> >> There's less of a need for JWS. You could say SPI "1234" indicates that >> I'm signing under a given 4096-bit RSA key, saving yourself hundreds of >> octets. So it would be like "jku", with fewer octets and without the >> implication that you could go fetch it over the Internet. >> >> >>> **** >>> >>> - What are the motivating use cases for this functionality? >>> >> >> As I said before, cases where there's some out-of-band mechanism to >> pre-negotiate certain parameters. For example, the OpenID Connect >> discovery process. >> < >> http://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig= urationRequest >> > >> >> >> >>> **** >>> >>> - What syntax would be used for the =93spi=94 parameter? Unrestricte= d >>> Unicode strings? Base64url-encoded byte strings? UUIDs? =85 >>> >> >> Doesn't really matter. Make it the same as "kid" (i.e., string); they'r= e >> both opaque identifiers. >> >> >> >>> **** >>> >>> ** ** >>> >>> I don=92t think a number of them have been answered.**** >>> >>> ** ** >>> >>> Thanks,**** >>> >>> -- Mike**** >>> >>> ** ** >>> >>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *Richard Barnes >>> *Sent:* Wednesday, February 20, 2013 10:04 AM >>> *To:* Nat Sakimura >>> *Cc:* Brian Campbell; jose@ietf.org; Edmund Jay >>> *Subject:* Re: [jose] Proposal about the SPI proposal**** >>> >>> ** ** >>> >>> Obviously, this will not be in a -00 draft for Orlando. So discussion >>> should continue based on the text proposed to the list.**** >>> >>> ** ** >>> >>> Does anyone have further technical comments?**** >>> >>> ** ** >>> >>> --Richard**** >>> >>> ** ** >>> >>> On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura >>> wrote:**** >>> >>> ditto. **** >>> >>> 2013/2/11 Edmund Jay **** >>> >>> +1 for new I-D. >>> >>> **** >>> >>> ** ** >>> ------------------------------ >>> >>> *From:* Brian Campbell >>> *To:* "jose@ietf.org" >>> *Sent:* Fri, February 8, 2013 3:01:51 PM >>> *Subject:* [jose] Proposal about the SPI proposal**** >>> >>> ** ** >>> >>> Maybe this was apparent from my comments/questions on the SPI proposal >>> over the last couple days[1] but I have concerns that run the gamut fro= m >>> operational complexity and fragility to security problems. I believe >>> strongly that, without considerably more analysis and specification det= ail, >>> the current SPI work is much too risky to consider go in the current ba= se >>> JOSE WG drafts.**** >>> >>> As an alternative I'd like to request/propose that the SPI stuff be >>> submitted as new I-D to help facilitate that additional discussion and >>> analysis that I think it needs.**** >>> >>> ** ** >>> >>> Thanks, >>> Brian**** >>> >>> >>> [1] http://www.ietf.org/mail-archive/web/jose/current/msg01500.html**** >>> >>> ** ** >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose**** >>> >>> >>> >>> **** >>> >>> ** ** >>> >>> -- >>> Nat Sakimura (=3Dnat)**** >>> >>> Chairman, OpenID Foundation >>> http://nat.sakimura.org/ >>> @_nat_en**** >>> >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose**** >>> >>> ** ** >>> >> >> > --f46d0447a29fab2e7e04d76ecfb8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Sorry, meant to start with: Revised text for the SPI proposal follows.
<= br>
On Fri, Mar 8, 2013 at 2:26 PM, Richard Barne= s <rlb= @ipv.sx> wrote:
-----BEGIN-----
Section 4.1.X. "spi<= /span>" (Security Parameters Index) Header Parameter

The "s= pi" (Security Parameters Index) header parameter contains a bas= e64url-encoded opaque byte string that labels a set of security parameters.= =A0This index is designed to enable the use of smaller headers in cases wh= ere entities use an out-of-band mechanism to negotiate cryptographic parame= ters.=A0

Entities using an out-of-band negotiation mechanism=A0maintain a table of c= ached security parameters. =A0The maintenance of this table, e.g., how entr= ies are added or removed, is done by the out-of-band key management protoco= l. =A0Each entry in the table is indexed by an=A0SPI=A0value, and contains pre-negotiated par= ameters for the JWE, such as values for the "alg" or "zip&qu= ot; parameters, or a value for the Encrypted Key component.

A JWE whose header contains an=A0SPI=A0value MAY omit the Encrypted Key component, by making = this field zero-length in the compact serialization. =A0 An entity receivin= g such a JWE reconstructs the full JWE by adding the cached header fields t= o the header, and adding the Encrypted Key components to the JWE. =A0The re= constructed JWE is then processed as normal. =A0If a JWE object contains an= unrecognized=A0SPI=A0value, then the recipient MUST consider it invalid.

The out-of-band management protocol MUST ensure that the SPI value is uniqu= e within the sender's context. =A0To prevent the SPI value from being u= sed to interfere with JOSE processing, the management protocol SHOULD also = ensure that it is difficult for a third party (who has not participated in = the management protocol) to guess an SPI value. =A0As a simple way to meet = both of these requirements, it is RECOMMENDED that the SPI value be a 128-b= it random value. =A0
-----END-----



On Wed, Feb 27, 2013= at 1:50 PM, Richard Barnes <rlb@ipv.sx> wrote:
Ah, sorry I never got around to those. =A0Re= sponses inline.

=A0 - What are the securi= ty implications of repeatedly reusing the same CMK and IV and how can/shoul= d they be mitigated?


Good point. =A0Re-= using IVs is a terrible idea. =A0SPI should represent some set of pre-negot= iated parameters, where the set of parameters that are pre-set is part of t= he pre-negotiation. =A0So one application might pre-negotiate algorithms, b= ut pass keys in-band, but another might pre-negotiate algorithms and keys. = =A0(You could even envision agreeing on an IV generation procedure...)
=A0

=A0 - Is having the absen= ce of an =93alg=94 field, paired with the presence of an =93spi=94 field th= e best way to handle this?


"alg" is= an indicator of key wrapping technique. =A0So if this is one of the pre-ne= gotiated parameters, then it should be absent.
=A0

=A0 - What are the comple= xity implications of having JWEs no longer contain a fixed set of field?


Very little. =A0SP= I would add a little pre-processing to populate the missing fields in a JWE= /JWS
=A0

=A0 - Would JWSs similarl= y have a different number of fields?


Yes.
=A0

=A0 - Indeed, is the prop= osal even applicable in the JWS case, or does it only make sense for JWEs?<= /span>


There's less o= f a need for JWS. =A0You could say SPI "1234" indicates that I= 9;m signing under a given 4096-bit RSA key, saving yourself hundreds of oct= ets. =A0So it would be like "jku", with fewer octets and without = the implication that you could go fetch it over the Internet.
=A0

=A0 - What are the motiva= ting use cases for this functionality?


As I said before, cases where there's some ou= t-of-band mechanism to pre-negotiate certain parameters. =A0For example, th= e OpenID Connect discovery process.

=A0

=A0 - What syntax would b= e used for the =93spi=94 parameter?=A0 Unrestricted Unicode strings?=A0 Bas= e64url-encoded byte strings?=A0 UUIDs? =85


Doesn't really= matter. =A0Make it the same as "kid" (i.e., string); they're= both opaque identifiers.

=A0

=A0<= /p>

I don=92t think a n= umber of them have been answered.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Thanks,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Wednesday, February 20, 2013 10:04 AM
To: Nat Sakimura
Cc: Brian Campbell; jose@ietf.org; Edmund Jay
Subject: Re: [jose] Proposal about the SPI proposal

=A0

Obviously, this will not be in a -00 draft for Orlan= do. =A0So discussion should continue based on the text proposed to the list= .

=A0

Does anyone have further technical comments?<= u>

=A0

--Richard

=A0

On Wed, Feb 20, 2013 at 11:25 AM, Nat Sakimura <<= a href=3D"mailto:sakimura@gmail.com" target=3D"_blank">sakimura@gmail.com> wrote:

ditto.=A0

2013/2/11 Edmund Jay <ejay@mgi1.com>

+1 for ne= w I-D.

=A0

From: Brian Campbell <bcampbell@pingidentity.com>=
To: "jose@ie= tf.org" <jos= e@ietf.org>
Sent: Fri, February 8, 2013 3:01:51 PM
Subject: [jose] Proposal about the SPI proposal=

=A0

Maybe this was appare= nt from my comments/questions on the SPI proposal over the last couple days= [1] but I have concerns that run the gamut from operational complexity and = fragility to security problems. I believe strongly that, without considerably more analysis and specification detail= , the current SPI work is much too risky to consider go in the current base= JOSE WG drafts.

As an alternative I'd like to request/propose th= at the SPI stuff be submitted as new I-D to help facilitate that additional= discussion and analysis that I think it needs.

=A0

Thanks,
Brian

=A0

_____________________= __________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Found= ation
http://nat.sakimura.= org/
@_nat_en


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0




--f46d0447a29fab2e7e04d76ecfb8-- From tonynad@microsoft.com Fri Mar 8 11:43:24 2013 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 64F7721F888E for ; Fri, 8 Mar 2013 11:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] 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 RnnNdIjCLEWv for ; Fri, 8 Mar 2013 11:43:22 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id ED46921F8738 for ; Fri, 8 Mar 2013 11:43:21 -0800 (PST) Received: from BL2FFO11FD016.protection.gbl (10.173.161.201) by BL2FFO11HUB022.protection.gbl (10.173.161.46) with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Mar 2013 19:43:19 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 8 Mar 2013 19:43:19 +0000 Received: from co1outboundpool.messaging.microsoft.com (157.54.51.113) by mail.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 8 Mar 2013 19:43:07 +0000 Received: from mail157-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE005.bigfish.com (10.243.66.68) with Microsoft SMTP Server id 14.1.225.23; Fri, 8 Mar 2013 19:42:31 +0000 Received: from mail157-co1 (localhost [127.0.0.1]) by mail157-co1-R.bigfish.com (Postfix) with ESMTP id 50C133600F0 for ; Fri, 8 Mar 2013 19:42:31 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT002.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -15 X-BigFish: PS-15(zz9371Ic85fh4015Idb82hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1730fah1033IL177df4h17326ah1777e0h8275dh18c673h5eeeK8275bhf65c6kz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah17ej9a9j1155h) Received-SPF: softfail (mail157-co1: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT002.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB042; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail157-co1 (localhost.localdomain [127.0.0.1]) by mail157-co1 (MessageSwitch) id 136277174948689_21452; Fri, 8 Mar 2013 19:42:29 +0000 (UTC) Received: from CO1EHSMHS017.bigfish.com (unknown [10.243.78.228]) by mail157-co1.bigfish.com (Postfix) with ESMTP id 07AEC54004B; Fri, 8 Mar 2013 19:42:29 +0000 (UTC) Received: from BL2PRD0310HT002.namprd03.prod.outlook.com (157.56.240.21) by CO1EHSMHS017.bigfish.com (10.243.66.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 8 Mar 2013 19:42:28 +0000 Received: from BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) by BL2PRD0310HT002.namprd03.prod.outlook.com (10.255.97.37) with Microsoft SMTP Server (TLS) id 14.16.275.5; Fri, 8 Mar 2013 19:42:27 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB042.namprd03.prod.outlook.com (10.255.241.146) with Microsoft SMTP Server (TLS) id 15.0.620.20; Fri, 8 Mar 2013 19:42:25 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.143]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.89]) with mapi id 15.00.0620.020; Fri, 8 Mar 2013 19:42:25 +0000 From: Anthony Nadalin To: Richard Barnes , "jose@ietf.org" Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: AQHOHC0Jc61Dw5z8MEmuQ9Q5+y6VFZicMa0Q Date: Fri, 8 Mar 2013 19:42:25 +0000 Message-ID: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:2a:2:3946:6b19:608a:fa1] Content-Type: multipart/alternative; boundary="_000_63519de2d2c44b159bb7dad208368348BY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB042.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IPV.SX$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC104.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC104.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(243025002)(377454001)(189002)(199002)(164054002)(54356001)(76482001)(47976001)(59766001)(47736001)(53806001)(33646001)(74662001)(15395725002)(5343635001)(6806001)(4396001)(51856001)(512954001)(56776001)(16236675001)(50986001)(5343655001)(47446002)(15202345001)(20776003)(15380165003)(69226001)(44976002)(54316002)(16676001)(65816001)(15198665001)(74502001)(79102001)(56816002)(77982001)(31966008)(63696002)(561944001)(80022001)(46102001)(49866001)(10090945005)(42262001)(24736002)(3826001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB022; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 077929D941 Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 08 Mar 2013 19:43:24 -0000 --_000_63519de2d2c44b159bb7dad208368348BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Richard, As I read your note, you're proposing a special-purpose encryption format t= o use for keys. I think it would be simpler to use the general-purpose enc= ryption format we already have (JWE) to encrypt keys. Indeed, draft-miller= -jose-jwe-protected-jwk already clearly describes using JWE to encrypt JWKs= and it's straightforward. No invention required. I also think that you're wrong in saying that we don't have the capability = to encrypt private keys. The Miller draft can be used to encrypt both symm= etric and private keys. I also think that you're wrong in saying that we don't have the capability = to have attributes for keys. The JWK format allows fields to be added for = additional key attributes, as needed. Let's keep things simple and use the general-purpose encryption format we a= lready have, rather than inventing a special-purpose one. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, March 8, 2013 10:43 AM To: jose@ietf.org Subject: [jose] A Unified Theory of JOSE Keys I've posted some draft slides for my presentation on JOSE keys: Some thoughts are below to get the discussion started early... What I'm proposing here is that we re-factor JWK and JWA to address all of = the use cases we have for keys -- including public keys, wrapped/unwrapped = private/symmetric keys, and key attributes. That is, instead of doing wrap= ped symmetric keys in JWE, public keys in JWK, and the remainder somewhere = else, we should just do all key management in JWK. This actually entails less work than you might imagine. JWE provides us wi= th a wrapped symmetric key format, and Mike's recent draft provides an unwr= apped, JSON-based symmetric key format. From these we can extrapolate to w= rapped private keys in a pretty straightforward fashion, and pick up the ab= ility to add attributes to keys as a bonus. The slide deck illustrates a p= roposed wrapping algorithm that would do this. At the end of the slide deck, there's a proposal to edit JWK and JWA to add= key wrapping. To make that a little more precise, I would imagine the con= tents of the revised JWK draft to look something like the following (omitti= ng identical sections): -----BEGIN----- 4. JSON Web Key (JWK) Format 4.1. "kty" (Key Type) Parameter 4.2. "use" (Key Use) Parameter 4.3. "alg" (Algorithm) Parameter 4.4. "kid" (Key ID) Parameter 4.5. "kat" (Wrapped Key Attributes) Parameter 4.6. "wk" (Wrapped Key) Parameter 4.7. "epk" (Ephemeral Public Key) Header Parameter 4.8. "jku" (JWK Set URL) Header Parameter 4.9. "jwk" (JSON Web Key) Header Parameter 4.10. "x5u" (X.509 URL) Header Parameter 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter 4.12. "x5c" (X.509 Certificate Chain) Header Parameter 4.13. "apu" (Agreement PartyUInfo) Header Parameter 4.14. "apv" (Agreement PartyVInfo) Header Parameter 5. Wrapped keys 5.1. Key Wrapping Procedure 5.2. Key Unwrapping Procedure -----END----- The revised JWA draft would just fold in the fields from draft-jones-jose-j= son-private-and-symmetric-key, and add the obvious encoding rules for RSA a= nd EC keys. Comments welcome! Thanks, --Richard --_000_63519de2d2c44b159bb7dad208368348BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Richard,

 <= /p>

As I read your note, you&= #8217;re proposing a special-purpose encryption format to use for keys.&nbs= p; I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-j= ose-jwe-protected-jwk already clearly describes using JWE to encrypt JWKs a= nd it’s straightforward.  No invention required.

 <= /p>

I also think that youR= 17;re wrong in saying that we don’t have the capability to encrypt pr= ivate keys.  The Miller draft can be used to encrypt both symmetric and private keys.

 <= /p>

I also think that youR= 17;re wrong in saying that we don’t have the capability to have attri= butes for keys.  The JWK format allows fields to be added for addition= al key attributes, as needed.

 <= /p>

Let’s keep things s= imple and use the general-purpose encryption format we already have, rather= than inventing a special-purpose one.

 <= /p>

 

From: jose-b= ounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 8, 2013 10:43 AM
To: jose@ietf.org
Subject: [jose] A Unified Theory of JOSE Keys

 

I've posted some draft slides for my presentation on= JOSE keys:

Some thoughts are below to get the discussion starte= d early...

 

What I'm proposing here is that we re-factor JWK and= JWA to address all of the use cases we have for keys -- including public k= eys, wrapped/unwrapped private/symmetric keys, and key attributes.  Th= at is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we shou= ld just do all key management in JWK.

 

This actually entails less work than you might imagi= ne.  JWE provides us with a wrapped symmetric key format, and Mike's r= ecent draft provides an unwrapped, JSON-based symmetric key format.  F= rom these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add a= ttributes to keys as a bonus.  The slide deck illustrates a proposed w= rapping algorithm that would do this.

 

At the end of the slide deck, there's a proposal to = edit JWK and JWA to add key wrapping.  To make that a little more prec= ise, I would imagine the contents of the revised JWK draft to look somethin= g like the following (omitting identical sections):

-----BEGIN-----

4.  JSON Web Key (JWK) Format

4.1.  "kty" (Key Type) Parameter=

4.2.  "use" (Key Use) Parameter<= /o:p>

4.3.  "alg" (Algorithm) Parameter

4.4.  "kid" (Key ID) Parameter

4.5.  "kat" (Wrapped Key Attributes) = Parameter

4.6.  "wk" (Wrapped Key) Parameter

4.7.  "epk" (Ephemeral Public Key) He= ader Parameter

4.8.  "jku" (JWK Set URL) Header Para= meter

4.9.  "jwk" (JSON Web Key) Header Par= ameter

4.10. "x5u" (X.509 URL) Header Parameter

4.11. "x5t" (X.509 Certificate Thumbprint)= Header Parameter

4.12. "x5c" (X.509 Certificate Chain) Head= er Parameter

4.13. "apu" (Agreement PartyUInfo) Header = Parameter

4.14. "apv" (Agreement PartyVInfo) Header = Parameter

5. Wrapped keys

5.1. Key Wrapping Procedure

5.2. Key Unwrapping Procedure

-----END-----

The revised JWA draft would just fold in the fields = from draft-jones-jose-json-private-and-symmetric-key, and add the obvious e= ncoding rules for RSA and EC keys.

 

Comments welcome!

 

Thanks,

--Richard

 

 

--_000_63519de2d2c44b159bb7dad208368348BY2PR03MB041namprd03pro_-- From rlb@ipv.sx Fri Mar 8 11:58:43 2013 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 5DFB421F8870 for ; Fri, 8 Mar 2013 11:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 oaA61ELv20p9 for ; Fri, 8 Mar 2013 11:58:42 -0800 (PST) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by ietfa.amsl.com (Postfix) with ESMTP id 425E721F885E for ; Fri, 8 Mar 2013 11:58:42 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id k1so2501903oag.5 for ; Fri, 08 Mar 2013 11:58:41 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=eD5Mlwf3/lIQSLgY4QVVGc6qi7trCuJF7a5OTU2CNWQ=; b=J1rclf5zJQwh8tQ0CeSCbiQ+xovOJN/lK86ShgeDGjl0U6WEn91o+ZcVAexxENVr9N vJSizHfmuKO/9YsCueKRpr8qdgNsAyinDOO6GuUFLLGY9A/OxOKs5I562u/HGQ40dctv 0VbTdqZWyactDoTZc41wUcuZdF3t+Ey7LRk/HikPx+uLZEIvduPKXmD22fUnMx2cvIR0 UVafkBXPhfsGRo5AtznX4RzZXhC1JaBbnxblPS/Erj14wIbvASO0MTrN0m7vhnPH4Udb IcyS4ylY9F1CneZLKILldhzQcK/7BMiDZ6lRGXJJ0Wq0gs8aOjOrvYtQLBQfPsd+GSb/ vWCQ== MIME-Version: 1.0 X-Received: by 10.60.171.144 with SMTP id au16mr3040588oec.56.1362772721359; Fri, 08 Mar 2013 11:58:41 -0800 (PST) Received: by 10.60.150.131 with HTTP; Fri, 8 Mar 2013 11:58:41 -0800 (PST) X-Originating-IP: [192.1.51.63] In-Reply-To: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> Date: Fri, 8 Mar 2013 14:58:41 -0500 Message-ID: From: Richard Barnes To: Anthony Nadalin Content-Type: multipart/alternative; boundary=bcaec5523faaf9062204d76f3f4c X-Gm-Message-State: ALoCoQk7GWsE7Y0c8q3vLbUL01QLgKLqS4r5aiGlE1iarMI5f+6Tpo6N4Pd9rQyczSGgxT5e9njU Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 08 Mar 2013 19:58:43 -0000 --bcaec5523faaf9062204d76f3f4c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tony, On Fri, Mar 8, 2013 at 2:42 PM, Anthony Nadalin wrot= e: > Hi Richard,**** > > ** ** > > As I read your note, you=92re proposing a special-purpose encryption form= at > to use for keys. I think it would be simpler to use the general-purpose > encryption format we already have (JWE) to encrypt keys. Indeed, > draft-miller-jose-jwe-protected-jwk already clearly describes using JWE t= o > encrypt JWKs and it=92s straightforward. No invention required.**** > > I'm not proposing anything new here. The key wrapping is already in JWE. I'm just extending it to other than symmetric keys. And, for what it's worth, the same key wrapping techniques are used in CMS. > ** > > I also think that you=92re wrong in saying that we don=92t have the capab= ility > to encrypt private keys. The Miller draft can be used to encrypt both > symmetric and private keys. > The Miller draft invents a *second* way of encrypting keys, in addition to what JWE already has. It's also much more inefficient, since you end up doing two encryptions (JWE CMK, then key encryption) when you could be doing one. The Miller draft *is* a valuable contribution, though, because it adds PBE, a notable omission from JWE. That part should be folded into JWE or JWK, wherever the key wrapping ends up. > I also think that you=92re wrong in saying that we don=92t have the capab= ility > to have attributes for keys. The JWK format allows fields to be added fo= r > additional key attributes, as needed. > We don't have a way to cryptographically bind attributes to keys. JWK can express the attributes, but it can't prevent them being changed by en route= . Let=92s keep things simple and use the general-purpose encryption format we > already have, rather than inventing a special-purpose one. > I agree that we should keep things simple. This proposal is trying to keep the number of ways we have to encrypt keys to one, instead of adding a new way. Thanks, --Richard > > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 8, 2013 10:43 AM > *To:* jose@ietf.org > *Subject:* [jose] A Unified Theory of JOSE Keys**** > > ** ** > > I've posted some draft slides for my presentation on JOSE keys:**** > > **** > > Some thoughts are below to get the discussion started early...**** > > ** ** > > What I'm proposing here is that we re-factor JWK and JWA to address all o= f > the use cases we have for keys -- including public keys, wrapped/unwrappe= d > private/symmetric keys, and key attributes. That is, instead of doing > wrapped symmetric keys in JWE, public keys in JWK, and the remainder > somewhere else, we should just do all key management in JWK.**** > > ** ** > > This actually entails less work than you might imagine. JWE provides us > with a wrapped symmetric key format, and Mike's recent draft provides an > unwrapped, JSON-based symmetric key format. From these we can extrapolat= e > to wrapped private keys in a pretty straightforward fashion, and pick up > the ability to add attributes to keys as a bonus. The slide deck > illustrates a proposed wrapping algorithm that would do this.**** > > ** ** > > At the end of the slide deck, there's a proposal to edit JWK and JWA to > add key wrapping. To make that a little more precise, I would imagine th= e > contents of the revised JWK draft to look something like the following > (omitting identical sections):**** > > -----BEGIN-----**** > > 4. JSON Web Key (JWK) Format**** > > 4.1. "kty" (Key Type) Parameter**** > > 4.2. "use" (Key Use) Parameter**** > > 4.3. "alg" (Algorithm) Parameter**** > > 4.4. "kid" (Key ID) Parameter**** > > 4.5. "kat" (Wrapped Key Attributes) Parameter**** > > 4.6. "wk" (Wrapped Key) Parameter**** > > 4.7. "epk" (Ephemeral Public Key) Header Parameter**** > > 4.8. "jku" (JWK Set URL) Header Parameter**** > > 4.9. "jwk" (JSON Web Key) Header Parameter**** > > 4.10. "x5u" (X.509 URL) Header Parameter**** > > 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter**** > > 4.12. "x5c" (X.509 Certificate Chain) Header Parameter**** > > 4.13. "apu" (Agreement PartyUInfo) Header Parameter**** > > 4.14. "apv" (Agreement PartyVInfo) Header Parameter**** > > 5. Wrapped keys**** > > 5.1. Key Wrapping Procedure**** > > 5.2. Key Unwrapping Procedure**** > > -----END-----**** > > The revised JWA draft would just fold in the fields from > draft-jones-jose-json-private-and-symmetric-key, and add the obvious > encoding rules for RSA and EC keys.**** > > ** ** > > Comments welcome!**** > > ** ** > > Thanks,**** > > --Richard**** > > ** ** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec5523faaf9062204d76f3f4c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Tony,

On Fri, Mar 8, = 2013 at 2:42 PM, Anthony Nadalin <tonynad@microsoft.com>= wrote:

Hi Richard,=

=A0<= /p>

As I read your note, you= =92re proposing a special-purpose encryption format to use for keys.=A0 I t= hink it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.=A0 Indeed, draft-miller-jose= -jwe-protected-jwk already clearly describes using JWE to encrypt JWKs and = it=92s straightforward.=A0 No invention required.


I&#= 39;m not proposing anything new here. =A0The key wrapping is already in JWE= . =A0I'm just extending it to other than symmetric keys. =A0And, for wh= at it's worth, the same key wrapping techniques are used in CMS.=A0
=A0

I also think that you=92r= e wrong in saying that we don=92t have the capability to encrypt private ke= ys.=A0 The Miller draft can be used to encrypt both symmetric and private keys.


T= he Miller draft invents a *second* way of encrypting keys, in addition to w= hat JWE already has. =A0It's also much more inefficient, since you end = up doing two encryptions (JWE CMK, then key encryption) when you could be d= oing one.

The Miller draft *is* a valuable contribution, though, = because it adds PBE, a notable omission from JWE. =A0That part should be fo= lded into JWE or JWK, wherever the key wrapping ends up.
=A0

I also think that you=92r= e wrong in saying that we don=92t have the capability to have attributes fo= r keys.=A0 The JWK format allows fields to be added for additional key attributes, as needed.


We don't have a way to cryptographically bind attributes to key= s. =A0JWK can express the attributes, but it can't prevent them being c= hanged by en route.

Let=92s keep things simpl= e and use the general-purpose encryption format we already have, rather tha= n inventing a special-purpose one.


I agree that we should keep th= ings simple. =A0This proposal is trying to keep the number of ways we have = to encrypt keys to one, instead of adding a new way. =A0

Thanks,
--Richard


=A0

=A0

=A0

From: jose-bounces@ietf.org<= /a> [mailto:jose= -bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 8, 2013 10:43 AM
To: jose@ietf.org=
Subject: [jose] A Unified Theory of JOSE Keys

=A0

I've posted some draft slides for my presentatio= n on JOSE keys:

Some thoughts are below to get the discussion starte= d early...

=A0

What I'm proposing here is that we re-factor JWK= and JWA to address all of the use cases we have for keys -- including publ= ic keys, wrapped/unwrapped private/symmetric keys, and key attributes. =A0T= hat is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we shou= ld just do all key management in JWK.

=A0

This actually entails less work than you might imagi= ne. =A0JWE provides us with a wrapped symmetric key format, and Mike's = recent draft provides an unwrapped, JSON-based symmetric key format. =A0Fro= m these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add a= ttributes to keys as a bonus. =A0The slide deck illustrates a proposed wrap= ping algorithm that would do this.

=A0

At the end of the slide deck, there's a proposal= to edit JWK and JWA to add key wrapping. =A0To make that a little more pre= cise, I would imagine the contents of the revised JWK draft to look somethi= ng like the following (omitting identical sections):

-----BEGIN-----

4. =A0JSON Web Key (JWK) Format

4.1. =A0"kty" (Key Type) Parameter<= u>

4.2. =A0"use" (Key Use) Parameter

4.3. =A0"alg" (Algorithm) Parameter=

4.4. =A0"kid" (Key ID) Parameter=

4.5. =A0"kat" (Wrapped Key Attributes) Par= ameter

4.6. =A0"wk" (Wrapped Key) Parameter

4.7. =A0"epk" (Ephemeral Public Key) Heade= r Parameter

4.8. =A0"jku" (JWK Set URL) Header Paramet= er

4.9. =A0"jwk" (JSON Web Key) Header Parame= ter

4.10. "x5u" (X.509 URL) Header Parameter

4.11. "x5t" (X.509 Certificate Thumbprint)= Header Parameter

4.12. "x5c" (X.509 Certificate Chain) Head= er Parameter

4.13. "apu" (Agreement PartyUInfo) Header = Parameter

4.14. "apv" (Agreement PartyVInfo) Header = Parameter

5. Wrapped keys

5.1. Key Wrapping Procedure

5.2. Key Unwrapping Procedure

-----END-----

The revised JWA draft would just fold in the fields = from draft-jones-jose-json-private-and-symmetric-key, and add the obvious e= ncoding rules for RSA and EC keys.

=A0

Comments welcome!

=A0

Thanks,

--Richard

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec5523faaf9062204d76f3f4c-- From Michael.Jones@microsoft.com Fri Mar 8 16:57:19 2013 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 5D84A21F85E0 for ; Fri, 8 Mar 2013 16:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001] 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 wVdPW8r2OD0n for ; Fri, 8 Mar 2013 16:57:18 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0239.outbound.protection.outlook.com [207.46.163.239]) by ietfa.amsl.com (Postfix) with ESMTP id 5175821F859C for ; Fri, 8 Mar 2013 16:57:18 -0800 (PST) Received: from BL2FFO11FD026.protection.gbl (10.173.161.202) by BL2FFO11HUB023.protection.gbl (10.173.161.47) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sat, 9 Mar 2013 00:57:16 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD026.mail.protection.outlook.com (10.173.161.105) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sat, 9 Mar 2013 00:57:15 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Sat, 9 Mar 2013 00:57:12 +0000 From: Mike Jones To: Jim Schaad , Karen O'Donoghue Thread-Topic: Slides for my presentation on the JSON Private and Symmetric Key spec Thread-Index: Ac4cYQjQGZGdmnjFS+OW4peGS/ZE4g== Date: Sat, 9 Mar 2013 00:57:12 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674E68F9@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(53806001)(55846006)(16406001)(562884003)(51856001)(56776001)(76482001)(47976001)(47736001)(54356001)(20776003)(33656001)(59766001)(50986001)(16236675001)(512954001)(5343635001)(4396001)(74662001)(5343655001)(47446002)(15202345001)(80022001)(44976002)(69226001)(46102001)(54316002)(65816001)(74502001)(49866001)(31966008)(79102001)(66066001)(56816002)(77982001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB023; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07807C55DC Cc: "jose@ietf.org" Subject: [jose] Slides for my presentation on the JSON Private and Symmetric Key spec 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, 09 Mar 2013 00:57:19 -0000 --_004_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Attached --_000_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Attached

--_000_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.presentationml.presentation; name="JSON_Private_and_Symmetric_Key_-_IETF_86.pptx" Content-Description: JSON_Private_and_Symmetric_Key_-_IETF_86.pptx Content-Disposition: attachment; filename="JSON_Private_and_Symmetric_Key_-_IETF_86.pptx"; size=59842; creation-date="Sat, 09 Mar 2013 00:57:03 GMT"; modification-date="Sat, 09 Mar 2013 00:53:31 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCjuBQ45gEAANAOAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM l99O2zAUxu+R9g6Rb6fGLRsFpqZcwHY1oBLwACY5bb05tmWfdu3bc5L+IVSBriRRelPJdc73/ewk n3MGV4tUBXNwXhodsV7YZQHo2CRSTyL29Pirc8ECj0InQhkNEVuCZ1fDLyeDx6UFH1C19hGbItof nPt4CqnwobGgaWZsXCqQhm7CrYj/ignw0263z2OjETR2MNNgw8ENjMVMYfBzQX+vSP5YmLDgenVh 5hUxmWYC+QQvrXGg/E6NsFbJWCCtjs91skPWWVOFVJlf46fS+q+Ezsodspm3UEWDdd09baeTCQQj 4fBOpITOrUVuHXhadW4UfqxUgmrGYxlDYuJZSiJhUSxVb4ZhKqTeLOI9GK+I8FZ4pFvPC4Ne3WQF 7f9iWtM0w3EIwWkjO3EIwbfWCb63TnDWOkG/FYLs/R45Y33d7lvhfU/iXMK/Rgi2wvsIkE4T4Plv 9TjIZfY6imcFD7hUUPu+46v0Poo8Mn+LpZnhOg1Xg+qbsHNqFIw+y9RMSq7W+1mmZnKzGlMzSVqN qZlsrcbUTNpWYzqvO4NreO8ujpDp8giZet1jhGoryal9yI906sAcHL4xm3Ypq+5Y+joBhxK2DVNZ r7F1pEbpcMOdpgey/jCBpMSb5/3o8AUAAP//AwBQSwMEFAAGAAgAAAAhAGj4dKEFAQAA4gIAAAsA CAJfcmVscy8ucmVscyCiBAIooAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACskttKAzEQhu8F3yHMfTfbKiLSbG9E6J3I+gBjMrsb3RxIptK+ vaHgYWEtgr2c0z9f8s96s3ejeKeUbfAKllUNgrwOxvpewXP7sLgFkRm9wTF4UnCgDJvm8mL9RCNy GcqDjVkUFZ8VDMzxTsqsB3KYqxDJl0oXkkMuYeplRP2GPclVXd/I9FMDmomm2BoFaWuuQLSHWDb/ R1s6YjTIKHVItIipkCW25S2ixdQTKzBBP5Z0PnZUhRrkPNDqvEA87NyLRzvOoHzVqtdI/W9Ay78D ha6zmu6D3jnyPGOCnHZ8M8XIMibKZexo+6kfuj4nEO2ZvCFz2jSM8ZNITi6z+QAAAP//AwBQSwME FAAGAAgAAAAhAGNcI7TBAAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlMS54bWwucmVs c4SPwWrDMBBE74X8g9h7JDuHUoplX0IgkFNxPmCR1raILQmtEuq/r442BHqcHebNTtP9LrN4UWIX vIZaViDIm2CdHzXc+8vxCwRn9Bbn4EnDSgxde/hofmjGXEI8uciiUDxrmHKO30qxmWhBliGSL84Q 0oK5yDSqiOaBI6lTVX2qtGVAu2OKq9WQrrYG0a+xNP/PDsPgDJ2DeS7k85sKxbOzdMM1PHPBYhop a5Bye+etqGV5H1TbqN3c9g8AAP//AwBQSwMEFAAGAAgAAAAhAEv1Pey/AAAANwEAACAAAABwcHQv c2xpZGVzL19yZWxzL3NsaWRlMi54bWwucmVsc4SPwQrCMBBE74L/EPZuUj2ISFMvIgieRD9gSbZt sE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306rHQjO6C0OwZOGiRgOzXJRX2nA XELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYqzRnQfDHF2WpIZ7sGcZtiaf7P Dm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9zmw8AAAD//wMAUEsDBBQABgAI AAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTMueG1sLnJlbHOEj8EK wjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3mzU59eI+DeFFiF7yGtaxAkDfB Ot9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul2PQ0IssQyRenDWnEXGTqVETz wI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWDs3TBKTxzwWLqKGuQcn7nudjI 8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAHBwdC9zbGlkZXMv X3JlbHMvc2xpZGU0LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m5SPYhIUy8iCJ5EP2BJtm2wTUI2iv17 c6wgeJwd5s1OfXiPg3hRYhe8hrWsQJA3wTrfabjfTqsdCM7oLQ7Bk4aJGA7NclFfacBcQty7yKJQ PGvoc457pdj0NCLLEMkXpw1pxFxk6lRE88CO1KaqtirNGdB8McXZakhnuwZxm2Jp/s8ObesMHYN5 juTzjwrFg7N0wSk8c8Fi6ihrkHJ+57nYyPI+qKZWX3ObDwAAAP//AwBQSwMEFAAGAAgAAAAhAEv1 Pey/AAAANwEAACAAAABwcHQvc2xpZGVzL19yZWxzL3NsaWRlNS54bWwucmVsc4SPwQrCMBBE74L/ EPZuUj2ISFMvIgieRD9gSbZtsE1CNor9e3OsIHicHebNTn14j4N4UWIXvIa1rECQN8E632m4306r HQjO6C0OwZOGiRgOzXJRX2nAXELcu8iiUDxr6HOOe6XY9DQiyxDJF6cNacRcZOpURPPAjtSmqrYq zRnQfDHF2WpIZ7sGcZtiaf7PDm3rDB2DeY7k848KxYOzdMEpPHPBYuooa5Byfue52MjyPqimVl9z mw8AAAD//wMAUEsDBBQABgAIAAAAIQBL9T3svwAAADcBAAAgAAAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTYueG1sLnJlbHOEj8EKwjAQRO+C/xD2blI9iEhTLyIInkQ/YEm2bbBNQjaK/XtzrCB4nB3m zU59eI+DeFFiF7yGtaxAkDfBOt9puN9Oqx0IzugtDsGThokYDs1yUV9pwFxC3LvIolA8a+hzjnul 2PQ0IssQyRenDWnEXGTqVETzwI7Upqq2Ks0Z0HwxxdlqSGe7BnGbYmn+zw5t6wwdg3mO5POPCsWD s3TBKTxzwWLqKGuQcn7nudjI8j6oplZfc5sPAAAA//8DAFBLAwQUAAYACAAAACEAsls7dz8BAABr BgAAHwAIAXBwdC9fcmVscy9wcmVzZW50YXRpb24ueG1sLnJlbHMgogQBKKAAAQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAC8lctugzAQRfeV+g/I+2IgCX0okE1VKYtKVZt+gAPDQwXb8rhp+fta JKUERe7GYmM0g7hzNMNcrzffbeMdQGEteEJCPyAe8EzkNS8T8r57urkjHmrGc9YIDgnpAMkmvb5a v0LDtPkIq1qiZ1Q4JqTSWj5QilkFLUNfSODmTSFUy7QJVUklyz5YCTQKgpiqsQZJzzS9bZ4Qtc1N /V0nTeX/tUVR1Bk8iuyzBa4vlKBSAb4oIdGIMlWCTsiQ8g0poZchFi4hsKlz+APoQ6T9I7JB3M4E EdsgopkgQhtE6BzimaEGNRnKMXkazTGwYsXOsSZAJ5SVtTdOm6PZvoE33TVm7YeVGSVtJKuZ2rG0 QYTG0Nz5hza+NlrdPqT9af0xli4ZLPaxsHXi3iXEoYaviZEOqV8IenZFpD8AAAD//wMAUEsDBBQA BgAIAAAAIQCc3s0FbAIAADcNAAAUAAAAcHB0L3ByZXNlbnRhdGlvbi54bWzsl91u2jAUx+8n7R0i 3040JOSrEaHSNiFV6iQ06AO4yQGiOk5kGwZ9+h07hnigSX2A3MU+Pl+//HMw86dTw7wjCFm3vCDB w5R4wMu2qvmuIK+b5SQjnlSUV5S1HApyBkmeFl+/zLu8EyCBK6rQ1cMwXOa0IHulutz3ZbmHhsqH tgOOtm0rGqpwKXZ+JegfDN8wP5xOE7+hNSfWX3zGv91u6xJ+tuWhwfR9EAHM1CH3dScv0brPRHO7 +LckSY+wPrxJUMuWK4l0yALblqz6RaUC8Vy9SHWz49VVQcIgSqNslkTITuR6B88GxF/M/f+4u6Ge qz5InDjeofY2zldz6phnd+YEX+Q1d3Rvjh1zfG92gyf35sDxTrW5b8xtY/3hlaeCPAZRNJ1iMeW5 IEkWZ2ahzh1qSZYCgEcnWz1vFUjrdj2p3S4xDIIKtvTA1AZOaq3ODBZzmuPeaiXs0++V8BjV8gU+ eV2b6twj7MiCDs80VLwUBCujbIfSZ8TDMBv6tv64ZMQmFTNHgL7w7+JdSwBjq5rbJXrvMRWqeXXg peolYpLpKiRGCrBh4r2D0F8X6h0lRHPZsrpa1oyZhf5S4AcT3pFiNnXqlXJzymT1NLctLZHdt4ZP mNLN0RzojQFobyjljaGUAw6sEN8bzS0PHQgfwwFNFKe64JGPgWL5zAY+vSxHPkemoVg+0cAnmKVB MgpIf1WaigUUO4CyMDPjYZxAmooFlAyAwjBDAY0jCBWkqVhAqQMojWbjjDY/XJqKBZQNgDQdvH+M Q/rINBUL6NEBlMTpOKSNgjQVc5O9v2Li9db9n7D4CwAA//8DAFBLAwQUAAYACAAAACEAm3j4T2gD AAC/CQAAFQAAAHBwdC9zbGlkZXMvc2xpZGUyLnhtbLRW33PaOBB+70z/hx2/EwMhCfWEdIIbMu21 CVPS4V4VeQmaypIqCQfPzf3vt5JxWkhy5dIrD8aW9tf37Wq1p2/XpYQKrRNajZLeQTcBVFwXQt2N ki83k84wAeeZKpjUCkdJjS55e/b61anJnCyAtJXL2ChZem+yNHV8iSVzB9qgor2FtiXz9Gnv0sKy e7JayrTf7R6nJRMq2ejbffT1YiE4vtN8VaLyjRGLknmK3C2Fca01s481Y9GRmai9FdIZIeMzWYR/ Z24sYnhT1aU1MzO1cfuqmloQBfGVgGIl0ZKkm42NWPxUJEYv6Y76XWuJZeuFLc9OWUbYYD1KiPw6 PEmJZbj2wJtF/n2VL6+fkOXLiyek09YBRfDgNKBqED2G02/h3AgvEXoPqBpRRqofNf/qQGnCGeA3 8PhV1RoLmIN5swRfG2LGB1MbuWYz8tHKO+I0kuXXY13UAfgt/QcjLFNUPucrrxfCB0c/bknnZ76W GKkiQCyLGpYSI1moXVSdL7MECmF9ZA9c6XOJjKp8Q7A/u6bCrwTeB9M+OohGUBVTZtnnZ201wZBX gtLGTa8Nsc/Te9jSm2vlqfhgKhnHpZYFWuj/GtmioFJp8/ELPINUM8M/Y7Hi4WCRzS79Yv7+d/o/ zK6vwOKPRxGoY8BOOl6QWGNFxTwC9S1wdVmit4LDV6zdlm1Keyyd5hHSXckNiy+qp9mWK2BFgeRf KI7w/uJmAsMjMJTq+SWh/rZC57eioSP/s8LbLeItAC/gKdelkRj6qYMP8z/ArG5lQ9ROXn4vb3Mr PB0IYI4yBtT4UIX7CLwOUf1Xkh5O5ya7T/MiQqL/vT3kFqmIChBqv5LcwyTdOoauKwzQBDUB+vZw W8P8MIc53ua2NrSzg/jFAOaXW5b2qJY9IJxLp4FvqKFgS0QPCrFwoBfw56fpFFYEkDOHW96fL++f OG3CftxqY8dtL2gqmo+OeriJ9+bKks2/xuM3x/18OO6Me4NJZ/DuzUnnfHJ81JkcHQ4G+Xh4nh9e /J2QTm+QRUBUc+/bmYYWH80RpeBWO73wB1yXaTOQpEbfozWaskkzSa+7GWwqFjrJcW9w0j8ZDmNz p3gpynhptNHSUjtrcGk/MXNdxWTTCEW1kcclQ0NTKGkS/S4SsNOM8g8AAAD//wMAUEsDBBQABgAI AAAAIQDdILYsvAMAALUPAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTMueG1s5FdRb+I4EH4/6f6D5eej kBACRaUrSOG228KiBbbafTOOIb46sdc2Kdxq//uNDWnFtjp170463fESHHs8nvm+z2Hm4s02F6hk 2nBZ9HBw1sCIFVSmvFj38GI+qnUwMpYUKRGyYD28Ywa/ufz5pwvVNSJFsLswXdLDmbWqW68bmrGc mDOpWAFrK6lzYuFVr+upJg/gNRf1sNGI6znhBT7s16/ZL1crTtmVpJucFXbvRDNBLERuMq5M5U29 xpvSzIAbv/sopEvIjM5E6n6NmmvG3Kgof9VqpqbaL0/KqUY8BbwwKkgOsOD6YeFg5l8LMINB/bvt 68oT6W5XOr+8IF3IDW17GMDfuSdsIl22tYjuJ+nTLM3ev2BLs+EL1vXqAIjg8VCX1T6j5+m0gjCs MppzKxgKHhPbWxPYfSvpvUGFhFQdAvsM6aSs/Lm03QkqQ3anABzrXB3s9oseksreAKweL7sdyHTn cl/Cr58kXWHszO4E85hA5KQLzuEBDAjiRMqK2mKGUcq19TAhk9tEMAJyPiBpL4dCcGU5RReAiQVK Ki8/7irZ6JKhqeYlsQzdsN0/4HO4JbkCtI+igxghXUCqggWGe+r+lMBmRWAiCwsKR1NBKMukSJlG 4d+jk6egx4rxH2HSwVzAt6C/sXLFrZNMRbJbes4xSALlRN/6O8GLFBJxQ2e83EzgS7R34S9kxeX3 ijC/Q7BxAy7Vozb8YXDnC6/MFQDTw4ncaA7YTNgDRopbmo1IzgVoKTrHiGZEG+YP9wqk5i9udZJz 98Lp7ysmYo27eJjgX17g3BMPj/81BghTXQIG01rYik8YhiP+/3tSxlvgcHwzSOaTa3qzmF1xHgS7 mWm2wphffe70+Vy255v4Ztr/UravohNmGu8AqmhoRTz7cBd+4rcLPWmVq/Lj202m2tvOdCtsfncn lstxdD3ajU8ZqhSg6rQb40G8Xm3m76K3dlEsyk/j3TulW2zxeTKNBvdRc/kx/a3J+sNThmpjGIAF Rfspg3DPnWICfPQ13VdQJ/Fv+u0ocWgeinRKNPnwiproqF7+dwukp6h9gfhi+eur4Kotgx7p1kA9 r3y3BHVcD38dDM7jMOkMaoMgGtWiq/N2rT+KW7VRqxlFyaDTT5rDb1BJqiDqUs18B3hddbIw+ax7 zDnV0siVPaMyr+/b0LqSD0wryX0nGjQO7WxJRA+HnTBsh8F57NsPiBei9IV8FS1MVR0mFXpM1PvS F4bQOFumEz+loFV2NS6YPpm43KEz/QMAAP//AwBQSwMEFAAGAAgAAAAhAH1aQApAAwAAQgkAABUA AABwcHQvc2xpZGVzL3NsaWRlMS54bWysVtty2yAQfe9M/4HRcxVJvkcTOxM7cadpLp7a+QCMcEyC gAHs2O3037sgyY5zaa4vusDucvZwduHgcJVztKTaMCm6QbIXB4gKIjMmrrvB1WQYdgJkLBYZ5lLQ brCmJjjsff1yoFLDMwTewqS4G8ytVWkUGTKnOTZ7UlEBczOpc2zhV19HmcZ3EDXnUS2OW1GOmQhK f/0afzmbMUKPJVnkVNgiiKYcW0Bu5kyZKpp6TTSlqYEw3nsHUg8yI2OeubdRE02p+xLL71qN1Uj7 6YvlSCOWAV8BEjgHWoKonCjN/K8AM/iIHrhfV5FwuprpvHeAU8gNrboBkL92T3DCKV1ZRIpBsh0l 88snbMn85AnrqFoAEGwWdVkVGT1Op1alM2GWU5RssipMMbieSXJrkJCQp0u/SI9cLKtgLmcXXs2R XStghljto5WmxbynpHIxntYK64aMVqfZiQtGklYc12K/2paXdrtdazgDxw5IKq41PXP3sy5Cq9Su +jJbO1an8HYIcSpAm0cLK2fMuizuT3Fjx3bNqd8HYAun3kPDrnPsCoOK8GocoIxp67cGmdwOOMVQ QuXu2d7p+PICubjWRy8i+FhvCjPSbIktfWMkj9z2oG7ReJ3n1GpG0E+6foBn+kJeJTH/wW5+A/l+ nzZklGtDvc9seANdw8DT0PDGSBGqIp0QkIWmQhbePkJGRTbCGv96yNXT6wHLsE2gqmqj4bOQ+fNi r1diHy+m1uu99hl6N4tpoXdoEFC9VYk8o3vgagu6kqAn8GMadDozkrNsyDj3P64x0wHXaIl5N7Cr AtiOFbAIEnfWtnfObik6dZu3I5mCaM/2i0XxcQxYkzlK6t/eKP6davwwCmg89Xdz8LlQfpxMhqjT 2kEDDfGZUtkU5Hsp2Ab2HezJCvOFVp2ScGSdGWh3yh9eC826wZ9+f79VG3T6YT9pDMPG8X47PBq2 muGwWW80Bv3O0aB+8jcAn6SREk39gfyjuljA4KPDPGdESyNndo/IPCpuBZGSd1QryfzFIInL24WX etJsdpJ6XC8PIMDoO0WFFRKojnvC9TlWl0tfAnCLsVRDwcCQgnuLa4VgujVxmcM14R8AAAD//wMA UEsDBBQABgAIAAAAIQAMsUjUBwkAAEAuAAAVAAAAcHB0L3NsaWRlcy9zbGlkZTQueG1s7FrZkurI EX13hP+B4NlMa186bt8JCZBaLAKJRYgXQvteEtoQmph/dyGaO8Gd9vh6HHZ0T/cLCFVVKvPUyawE zpefmyTu1U5eBCl46qM/If2eA6zUDoD31N+shQHT7xWlAWwjToHz1D87Rf/nr3//25fssYjtHlwN ikfjqe+XZfb48FBYvpMYxU9p5gA45qZ5YpTwY+492LlxglaT+AFDEOohMQLQf1mf/8j61HUDyxml VpU4oLwayZ3YKKHnhR9kxc1a9iPWstwpoJlu9Z1LX2Fk1iq2L+9Fts4d53IFajHPVtky74blepn3 Ahvi1e8BI4Gw9B9eBl6mdR8BnAYvHr5b7t0sGY+NmydfvxiPMLZe89SH4J8vr3CR8eg0Zc+63rR+ u2v5i1fmWv74ldkPtwdAD7499BLVNaLfh0OiGHaLaB2UsdNDvwV2nW3A1bPUiooeSGGoFwSuEVpy fbN3CfvyhMzvlecMglNeTL3Muw52kNzmFx2sN1+/gUGQNCTKa4gwGMZSl6ELLixKEPD64sXNBLR+ tZk9lg2f2ucLnCZ877bDeIyLclWeY6eDGYJhPEIPeo4xA3wedZvqG8CDXF1WwCpfYjQeYVDwBc6M 4ehT3wGDzarfs4O87LanVyTlMHYMmEYvO1h+VVdc7+JX2Xl3NfCfW1nmQW2UTm/qnHvjxkiy2PnO qAPspZEb6g87B32CgUOgbgB1mF127Q/Zgd/YMUxBCdOnt4wNy/HT2HbyHvbfcSWwIdlvdPpTNEER imKuXPgtfRgS7wjSkYWkcOZlxo+w5bJVIOWqMnWD8sqwK40uA6+zKDHyWZfIAbAhQJfLy2SzkmH5 vJp4ofvrdCpaCAJKQ3K/TqzuybBqgS63XIj+U3+YVnkAN0B2Tv1eFpSWLxhJEENWEixMEt/IC6fz pCO8VfzJpRAxyP6LA+XXX/pG7PUf+5Dg/X/ckfHKrI5e17z6HyDyRkDo9e8i/1cV4pUtfSMBgHfu PyQgUje04aWOKVrKqqqWwWyy22elzAJg50pi7sZZgRkBJ5iaP6eZma81hGWaLseV2zVDtacKVae0 sRSEpvJHKjqjytUdKh+Jz71eah34yXi4dExtqu5Cfj8MhC0B8DQCoT8vSkAR5f6AaQNyUog68WyR gD3zOy4/xSweH0v6oMrkiRq6iE8oZ4WsBxSpi+EHRlRRkYMw0jClbo86TjGKMg8srjRWx7ZgppO9 B3STtWgbaT2b2z+3FXWcK7U6I30jzAEKWHRoLjJTWo0Q5ijPzrkdlQNT+MCIrjWfk4h6rgg+pTn7 CnHnRCzYmGyppxzfLaNCkp8NZSAeGh4E0tE8IbMCDQWCGFiFMKzyQTT2NoxxMrJJOwXH0dQ7fR5i F0L9QYP6dg+x73vhH+6r3sghDA8xTuH4Twa+Wwbad8X4lkbffxd7uxkEGbgjrHXpTPSDBwhBXxY7 nsntXdCQ9anwUGEmk2N8bIiUOkm3z4Pn2Ww6Yue03ZBpSosbNQKWD3L15GyiIe2vSXcymyN3qHys NkozBW4qzzQdq2uap+TjbtVu6maNHPSVewzCU4ar6zbmjWGjZYSdChEpYykjng/gWZ7mKTeSoglB Zeom9Yvd+WSqDmfrxgdGdH4SCrasGftgLbc6HiC0gZfMXKbW8ilB7JVxStiaoDfBMMZXEbkPRLpJ w+WsIgrTQzdY2BASv5b5FpiTVSs8TykqXDPmB0bUi6pjESFiWESjSYSye+J4Ck9mAQARYhofBLg6 G2wKLBa3kc64kdAmDtoiz6YUuS2iU8kRLPTyaCE7InStacoNGeXzELsQ6l22UdldKtyCeFeHGIMH A1qq5+Iune+GRVTT+HqaMxROC8GC3mN0WzNpSGWmtlHOs6XCK0253ILTCEPUAYU461EywqoQzEty mR7necKo7h0qH+sQS2R/q43KMJwnw3m4yFa7wBKeQ3q3qLaSrpyPWy3Wxj5lyzglbvd6xOIyw1ts rRNoc2Z4Vm3bhbhV2l0tj2tALxCwNd3is0a82xpxvMuGd1kjcNtdqKxV6ccBshokkTBrPan05mNX aHnsiPua488rEUmH1RGYeJ2as3OVHMPtXlmgtpTbJ28Nhnamt7y1cDUyx+mP3Ohywi4MNLc8yOI4 SOsUBK0/zVJ2u13RzLoVvCaS7NyxVKct9gM00u1DgR5HZlNGo7HnctKaE9nZBnCjChC1ZJnU2Ymb 6LNGvNsaYf8FGgmRKJa7yKJ0gz0z6URjD9IsJJoqyyokboPDM71dRyumCcmVvcOtdIykQaKfGinA nGTNVQ6yWRiknXmCeOYnhMWUyl3l/Fh9BLYVCATbqZU3Ha2XjBHpvpCSJcfRtOIc5KSs9L2FD/EE lzBCxMRaJYvVqNmcORlrj8zMBex4kxRUruMLk9GdYBqtAz5EPovE+y0Sf4FOomBj7pl1PY8vUkFl FoaFqYcx5p0wBsvXWCQuOL+W4ni8HqOOm3OUX2029dzlrXkGmPjoaFTdtkDXydVKEehsbg8/cJE4 GJ6EA5GRzAzlNyYy2QRQzyIfN+7MtxTzYLOiQIx82qEJzVSL1FRTUIVrXUabobGk1gsKDWst3w1m KFM2uxPBEsrB8j47iX+nPHq7P0sfg7t8eJdfN8Tz/JBRk3x3XgUtWqaCNzW17WBiS3ioEOesYnNz rjV4rkx4NykRIdVbbyPtx1thbC2OJydRZQZt0xFnGAM+QqaafAfKx+okxFE4ed6P7FEi+BrOyXQs DbKqiQ7J816coGjenGEhJsndbOXgq2WiutPTXqLOG4zYN7UyFXSptGN7MxXbBSUZVLue+txW3Xzk TiIKbPj/D4ag6AAhBhh7r2n6f/DrTjj5Rv6U/fWVLPu9WrITTd4kwlCvOyug0DPrlLtQkffU/4Xn WQobMvyARwlhQIxYesAJFDkQLqLEIc9wQ3z8ax+uQYlHK3c6NbJ0U1XDm79TMieBladF6pY/WWny cJVEP2TpycmzNOhU0SjyIq2ujRiqY2mSolGSJl7kt9DJTvZ5cxZGcBM7W3E+N7JF3f16DTXcpZMP u1sZVMJelItw6m9TLqFDkfQ/AQAA//8DAFBLAwQUAAYACAAAACEAXX2rGWQDAABLCgAAFQAAAHBw dC9zbGlkZXMvc2xpZGU2LnhtbLxWW28TOxB+R+I/jPYBgUS6SZuWZE+TKgkUcSgQkSKejXfSteq1 je2kidD574y9u6DtBYW2Oi+bjT0z+8031+OTTSlhjdYJrUZJb6+bACquc6EuRsmX89POIAHnmcqZ 1ApHyRZdcjJ++uTYZE7mQNrKZWyUFN6bLE0dL7Bkbk8bVHS31LZknv7aizS37IqsljLd73aP0pIJ ldT6dhd9vVwKjq81X5WofGXEomSekLtCGNdYM7tYMxYdmYnaLUhj8owvZB5+nTm3iOFNrd9aszBz G68/rucWRE58JaBYSbQkaX1Ri8W/isToJb2mftFYYtlmacvxMcvIN9iMEiJ/G56kxDLceODVIf99 yotPt8jy4s0t0mnzAULw66PBq8qjm+4MesN+49G58BKh98uxSpqR9pnmlw6UJlcDA5WH/OO6sRfc Dl8wBfitIXJ8MFXLVZeRkkbeEa2RL7+Z6nwbfP9Gv/GQZdL5hd9KjJwQcpaROCA7U1N7GSNQMHVB iTVfKe5rQCwjBPQgSUm3owRV58sigVxYH7kEV/qZREY5X9Ptx5/x+wqdB0pa+PoWJjxk1jGR6CmG 0SI9CQGBb5DSa8XmHzk9bDidaeUp6WAuGcdCyxwt7D+MYZFTijRB+BtyAz+KynOy8nopfIhiw3u4 +v9pJ8pz5CI0IvA6u4X4yH4Vf7mWu4Y6Jo4fT1oG75UguTYeHm7GGeTA3CNYIsoeDof68tK3zFRp fp3tmKj34u25VhzBIi+Y9WipVkE44Lo0Ej2+aH2b+p7K58yyz9drV8Riv7OCW6DvsrGb9r16Bw0i zB8jHHUNtAvgblp2cyn0zL+omdva46LQK5r4vqDYxRT+htQqqYflIJTX8O/X9/CMleYfeptECXfS Cm0rQo8A6LxAqFMKroSUwKTUV7By1D5eAjVxAnWJaEB4cGgopzy2AN2b1JsTIA6CZlmgyX3maGiY OMNXljL3x3Q6PNqfDaadaa9/2um/Hr7qTE6PDjunhwf9/mw6mMwO3vyXkE6vn3GLcS951+xXdHhj pykFt9rppd+jQkqr5Sg1+gqt0RQP2o963XrJWjNqlvv9V4fdg+HgaFhPYkIZZ1mDllxo9h4u7Qdm Pq1jIdA6R0U7i0eGajdMChL9LRJ8p33pJwAAAP//AwBQSwMEFAAGAAgAAAAhAFv8tVM/AwAALw0A ABUAAABwcHQvc2xpZGVzL3NsaWRlNS54bWzkV9tOGzEQfa/Uf7D83LC5AcmKBCWBoCoUUAOlr8br ZC28tmU7ly3i3zv2ZonCpQL60LR92Ys9M55zznh3fHC4zASaM2O5kh1c26lixCRVCZfTDr66HFZa GFlHZEKEkqyDc2bxYffjhwMdW5Eg8JY2Jh2cOqfjKLI0ZRmxO0ozCXMTZTLi4NVMo8SQBUTNRFSv VveijHCJV/7mNf5qMuGUHSk6y5h0RRDDBHGQuU25tmU0/Zpo2jALYYL3RkpdQEbHIvF3qy8NY/5J zk+MHusLE6bP5hcG8QT4wkiSDGjB0WpiZRZeJZjBQ/TIfVpGIvFyYrLuAYkBG1p2MJCf+ys4kZgt HaLFIF2P0vT8GVuaHj9jHZULQAYPi3pUBaKncHZr9XqJ6JI7wVDtAVhhTcD7VNFbi6QCqJ6BAiE9 m5fxPGy/gk6RyzWQ43yolV0xGSgp7S3QGvhyy75Kco/9Bu5hkMTCurHLBQucQOYkhuBwAQUE8UXK ZOVqjFHCjVvT5LrjPMuYM5yiEcvR8ZJkWrADoMSBIqsgTCYXxJCvL8ZCNnMDwQhsjaAKOEIKkH2Z KjwWdP6S1EZJ6kBJB1WHLgShLFUiYQbVf49inkCNlCq8hV3PooT92Zs5NeHOy1gS76ee8g4yoYyY 01CnXCYAxD9645vZGXwdihBhk7ykkv0Bye5VodAf9AqLwT6UoVomQEwHD9TMcODmjC0w0tzRdEgy LkDfZhsjmhJjWVg8VAW173T1deBr1RfFHb51OY6xog5/2qiTQvSgPFz+aRLQBvA3iLixUbZEUfxe MFuSPxFTqMderd4aXf+BktxGSdHfruktKPrestxGQU7IYjqdDfMTcz0i8/3e9+a30dV0E+J/9P28 f6TtSw3G1v0G14mGNuDZJif0OmVDDN3pqYVWSoc+Ff7WHXzX77f36oNWv9KvNYeV5lF7v9Ib7u1W hruNZnPQb/UGjeN76Bd0rRlTw0Lv/bk8Q8Dgk74949QoqyZuh6osKg4AkVYLZrTi4QxQq64OEnMi oLNoNNqtVrXVaK+6TcgytGtltgCh7O2pMF+IPp+H3z8cWRwzgzCk4ZDiOxkwXZt47HAm+AkAAP// AwBQSwMEFAAGAAgAAAAhANXRkvG+AAAANwEAAC0AAABwcHQvc2xpZGVMYXlvdXRzL19yZWxzL3Ns aWRlTGF5b3V0MTEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+b YwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXi WcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxj Ip9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLx vgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1sLnJlbHOE j8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LIC Qd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJT ryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95 LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRl TGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw 4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7E sG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZ GsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsD BBQABgAIAAAAIQDV0ZLxvgAAADcBAAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDMueG1sLnJlbHOEj8EKwjAQRO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+ww b3aa/WsaxZMSu+A11LICQd4E63yv4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wp xWagCVmGSL44XUgT5iJTryKaO/ak1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCge naUzcqZUsJh6yhqknN95LmpZ3gfVNuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcB AAAsAAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHOEj8EKwjAQ RO+C/xD2btJ6EJGmXkTw4EX0A5Zk2wbbJGSj6N+bYwXB4+wwb3aa/WsaxZMSu+A11LICQd4E63yv 4XY9rrYgOKO3OAZPGt7EsG+Xi+ZCI+YS4sFFFoXiWcOQc9wpxWagCVmGSL44XUgT5iJTryKaO/ak 1lW1UWnOgPaLKU5WQzrZGsT1HUvzf3boOmfoEMxjIp9/VCgenaUzcqZUsJh6yhqknN95LmpZ3gfV NuprbvsBAAD//wMAUEsDBBQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAcHB0L3NsaWRlTGF5b3V0 cy9fcmVscy9zbGlkZUxheW91dDEwLnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOW ZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vm QiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L 83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYA CAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5 LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1r GsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZ hki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3Km VLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAA AHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzhI/BCsIwEETvgv8Q 9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62 IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFp zoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277 AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3Jl bHMvc2xpZGVMYXlvdXQ3LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRk o+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLB RRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn 6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA 1dGS8b4AAAA3AQAALAAAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5y ZWxzhI/BCsIwEETvgv8Q9m7SehCRpl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvg NdSyAkHeBOt8r+F2Pa62IDijtzgGTxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1I E+YiU68imjv2pNZVtVFpzoD2iylOVkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoa pJzfeS5qWd4H1Tbqa277AQAA//8DAFBLAwQUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAHBwdC9z bGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ1LnhtbC5yZWxzhI/BCsIwEETvgv8Q9m7SehCR pl5E8OBF9AOWZNsG2yRko+jfm2MFwePsMG92mv1rGsWTErvgNdSyAkHeBOt8r+F2Pa62IDijtzgG TxrexLBvl4vmQiPmEuLBRRaF4lnDkHPcKcVmoAlZhki+OF1IE+YiU68imjv2pNZVtVFpzoD2iylO VkM62RrE9R1L83926Dpn6BDMYyKff1QoHp2lM3KmVLCYesoapJzfeS5qWd4H1Tbqa277AQAA//8D AFBLAwQUAAYACAAAACEAti7mSgsIAAD3LwAAIQAAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0 ZXIxLnhtbOxaW27jxhL9D3D3QPB+BhyJb0oYOdBjlAzgTIzYWUCLbFmMm480Wx47QYDZQ3aQXST5 u0uZldyqflCULU1k2AZsw4Ahkd3NYnedepwq6+03VwWzLilv8qoc2e6bvm3RMq2yvDwf2T+dzZ3E thpByoywqqQj+5o29jdH//nqbT1sWPY9aQTlFsgomyEZ2Ssh6mGv16QrWpDmTVXTEuaWFS+IgFt+ 3ss4+QiyC9bz+v2oV5C8tPXz/JDnq+UyT+msStcFLYUSwikjAvbfrPK6MdLqQ6TVnDYgRj69taUj OF96yjL8Xpyrzx/p0sqzK9BSv+/aR2/JUJ6TThm3Lgkb2Ytz1+4dve3hI7BYX+HDTX3GKcWr8vJb Xp/WJxxv0g+XJxxkgkjbKkkB+kUBckIvk7clLFOCtx4/N5LI8GrJC9wRqMeCHQKK1/gJD5EhvRJW qgbTzWi6+mHH2nT1bsfqnnkBHK19KZ5Knej2cTxznLNcMGqdMJLSVcUysBWpInlC9RhosT6u0ovG Kis4M6pCHRWUYwTj+fFV9coS1zVoSaBYvU5Nws7Kdn0j9Ws23WolCGMwOqkaLw4iP9nWT+J5gwjn UUuuG/h9uMG9bATVvBHf0qqw8GJkc5oKaQjk8rgRaqlZItFXG6mH4mpSZdcIxgK+AXPwOHh+VfFf bYu9L5uRPXCDAN4t5I3cqW3x7sxia0awaQUmB0+QMgU5IzsVXO6lBG8br0W1zPWO1Cvx5awRp+Ka UWkWAB4ZglrhAzbECDo8LZ2fTsHhCzFllEBA0CYkjqYsTy8sUVk0y4Wl/V7CAOEBRKKWhNSVFEnL 7IRw8uMNyVpFUjdGJ4CcMqT95uS35oS23LUmDwG6rzWhgmzt2vcxKhesBw1Mqtd43ZZVBaEXDiL/ 6VsVmsWdDAk8zmKX0iLl8e9pWKg9aVfNlmGBkUmzVR/mlTJi3MGWT2lalZnF6CVlB4iXNnYH8Wer nB8uXRrDHaTPqzUXq4M3HyhrPBiOeb7cKR3SyIO6dGBcekbEdoKQCrmvS2cCotivEGEJW2rXljDK NIHJ5I75IvJD+Lvh2p7r+23C8KPQ9cKn79lb+UK6qskKMkNcMhddmbBziP7MxrGMLjGOozpdDG84 1lQsz+Y5Y/IG6d6GBokrxY5EXgpFjOJwk0pbziSTRUcO+LZ6k5yAWIIbUdc6beG7pOcvWSZZ02++ N/XmbjR1gkk/coIomjnjvu87s5k79vu+N47G498hqUrSkIGlibyg8/x8zekPa5W6D0l+fi8Bpun6 m2ABO8Dd7PEJK8u5MFRLxSywtzskvNB4x7yqkGB3U5706Pv6xxLIgkT0lzXh8AbtIyozIZU61Ed8 1wsMqdrtJMkgfNFOYnjX03OTx7LOyFjnKQQBan1YF4sbNirj4H1tFOpLEL3LTKUL3CmUR2Hof9lM X3osV8XB0zPSNpa7c891383GzmTmx07guzNnMvfmzrQ/j11v7scD329jeYOWV4J1YBQ+JIR//vTX fz9/+vtBIzhY4KawB8YKNSAWI8hd1zwf2b9NJoPImyYTZ+IGcyeYDWJnPI9CZx76QTCdJOOp/+53 OELtBsOUU9mGeJ/pdggM3mphFHnKq6ZaijdpVfRUL6RXVx8pryvItpik+rqnIjsSXn+QuIN+2Dfk B/YmuY/ZLRzBtDlSxr8ntQVNDEj8AhoSkMdHdnYBV4tzD8egqhdXcJVdwBVJU+icwAp9YUZgXo20 a3wzAmWcmoKD6QszEpoRyHxqKjIjEG1WLC8vQBn4ZVvLin2nBswVsi7AgmXH5Lpai/eZRqIzIvmC 5wZxkPhRMIDaeoh9F/4+0w2JfWuB9G3W6nJz71rQVStX89i9a0E/7Vqd0/euBc21a3Vs3bsWmHW7 NrqlmS09hKDtdm38L2sBh3at7JxsaXxbbtxZO/gXudBgbOW6kmF/QfAWcKZT1FGFBl5cyT5Hg2Yh mxTyFmOF5pWa4GLutiAmnpHFKdBb2YNBvIVqrVByXE44WB7gii3GUt/CkhX0S6CPebIuU2jk6HZg nU6w7YctrfQk1eRXHglIIIzp2cX6A/RSJffuxGNo/4DcC8qxD3sozwYhKLrLxuVGJeVdQtdtZH9d /OwwgSAAXyU3JihRE2lzYyJtcGIfJ9/WKvQ7oYNyS8UF4ccj2w+8AR4sLyFgg6ocM2BKjMfWP6hS 9WRuYDCvoDzBykCpacxzwmyrzkW6mpMiZ8DfffCldEV4Q2HjuvhbrKcwIodH9udPfyr9dXBUPOMx cCz34Vg6e3AsnS/iKN3Bw3pPYRUDVhjvWqy8JITaDUKyLgefN1Z/3MLKSx7L5x4QKwRIhy5/g5Vp UHfA8hJZaL0MsG47lvdoAfIBwUKENFhBByzdGX6pYO3wLAy6j5LNHhAsREiDFW7A8vphLE1tEwZf kGf975/bUfA5YIUAaayiDlahG8ig9yKx2kUvkM48ecdChDRYcQesQezKhPsK1pd65wdx+geMgoiQ BivZgKVo+hYZfEFR8Nl6FiKkwRp0wEqSSLY3Xz3rKXkWIiTbbZ36uB5WYkV5Wy1D5XiiINU1ZPeX GG0JrpeY7oUq1x6lMOtUsipYP8tK1vzU5+Froeemn93Vo+l0vepnT8Hmx/hrnsfofDw3A9pdJLmJ l0gu92pBeyoTyZZeLQhS1p5qIA5Uq/TVgvYwcGB0sg/xqqA9rDcK49cgLZv4LdPskkv5myPzjzD8 Z7X5wf7R/wEAAP//AwBQSwMEFAAGAAgAAAAhAGmiXyEeAQAAxwcAACwAAABwcHQvc2xpZGVNYXN0 ZXJzL19yZWxzL3NsaWRlTWFzdGVyMS54bWwucmVsc8TV3WrDIBQH8PvB3kHO/WKStukHNb0Zg8Ku RvcAEk8+WKKidixvPykMEiiOQsCbgIrn/Pgr5nj6GXryjcZ2SjLIkhQIykqJTjYMPi9vLzsg1nEp eK8kMhjRwql8fjp+YM+d32TbTlviq0jLoHVOHyi1VYsDt4nSKP1KrczAnR+ahmpeffEGaZ6mBTXT GlDOapKzYGDOwve/jNp3/r+2quuuwldVXQeU7k4LavtO4Dsf1dX5stw06BgkyXTeTge7xPOB3pet YspWIdk2pmwbkmX5kjTnrxnODvI2Q2/fLORYlPHorcpDsmzJgB6VBTMrYsqKYGZxQwumtomZ2iaY mn/r4z2tWRqyrWPS1iHZPqZs/yejs99v+QsAAP//AwBQSwMEFAAGAAgAAAAhADrK4LC/AwAAtQsA ACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWy0Vu9u2zYQ/z5g70BonxX9tZwI sQtbjoYBaRLM6QMwEhVxpUSNpFW7Q4G+1vY4fZIdKTFdUhdwau+LbFF3P9797vjjXb7ZNgz1REjK 25kTnPkOIm3BS9o+zpx397l77iCpcFtixlsyc3ZEOm/mP/902aWSldd4xzcKAUYrUzxzaqW61PNk UZMGyzPekRa+VVw0WMGrePRKgT8AdsO80PcTr8G0dUZ/cYg/rypakBUvNg1p1QAiCMMK4pc17aRF 6w5B6wSRAGO8n4ekdh1kyx/+cJAxEj28Bs4c8i7WrEQtbmDhnipGELCDMt4qQDIGsrsXhGjTtv9V dOvuThi/m/5OIFpqnNHf8cYPo5l5bcEM/ngv3B8tEk63lWjmlzgFMtB25kDNdvoJTjglW4WKYbH4 ulrUt3tsi/pqj7VnN4AInjaFcndDRt+mE9p0BjqCp6wGUwyu17x4L1HLIU+d/pBecdNbMJ2zhu9q NDCvNLOj3fDR8GHtJXBqyFLbJS93OvEH+DWLOGVSrdWOEUMIhI1TAIcH0M+wbmzSuu/W0NiNyhjB 0PgjeWqeMVq8R4ojUlKF3mKpiEAmGDgGAHkJ7CgozghJ2vIOC/z7C2SdH05hZwjaRgh/Bwq/T2Rk iRy7Cd0xXJCasxKCCI+jlZbQFJb5EzAKBUCsZ0/UHcmwbltDsHzG8MCioRIedkuTxiuKuiYFhzPK SE/YAfCG6VfA39dUHI4e6Tq+Aj3nG6Hqg4OPXwtPq73ooCQn7e3Y9vYKK/KssQ0hIKtWDX5IL0oF x/kjaD5mlQMiq5vdHGojG1pcjtKPCiRfK/dfUZiFeZBkbrz0EzdOkpW78KPIXa2CReRH4SJZLD45 o4iVkKqiDcnp40aQ242+HqDyL8RinwxF3jncbUH0tVshAu38naKgkgpl5f5HpGdiy5NzriXvv8pj WurYAlVKDBX6c4MF7GCLdEJJ+r+4SSw3a0ZLgm42zcMLhibHafNw5cE8BdB7STKKdOJODvIwCK5W C3e5iqZuHAUrd5mHuZv5+TQI82h6EUVPnSx15i1Ed2gDf/n89y9fPv9z0v41N6gdreDCuJZwE3dm 4tkICodzubxIwux86S6DOHfj1cXUXeTJxM0nURxny/NFFl19ghS6IE4LQczY91s5jp+w+M3I2NBC cMkrdVbwxhtmT6/jH4joODXjZ+CPM2yP4S6M/IsoSKYTI2kQLgRphMcGC0t6etRRF0y8xd1tD8qE UxiW4UhkZqmD8VjPD89MdOp23J7/CwAA//8DAFBLAwQUAAYACAAAACEAP0YIYBMDAACHBwAAIQAA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ3LnhtbLRV226bQBB9r9R/QPSZcFmCbWQ74hKq Smli1ckHbGCxUWB3u7t27FaR8lvt5+RLOiyQtEkqRar7YsMwMzvnnNmZ6cmuqY0tEbJidGa6R45p EJqzoqKrmXl1mVlj05AK0wLXjJKZuSfSPJm/fzfloayLM7xnG2VADipDPDPXSvHQtmW+Jg2WR4wT Ct9KJhqs4FWs7ELgW8jd1LbnOIHd4Iqafbx4SzwryyonKcs3DaGqSyJIjRXUL9cVl0M2/pZsXBAJ aXT0nyWpPQe01zWmN6ah3cQWDK45B+T5si4MihswxNqjNUp+KQhpn+j2o+BLvhDa93y7EEZVtLF9 jGn3H3o3/UrBDR7sZ+GrIRMOd6Vo5lMcAgXGbmaCUvv2F4JwSHbKyDtj/mTN1xev+Obr01e87eEA qODx0BZVh+glHG+Ak2JFjEWNc7JmdUGE4T4C7KIwZDlj+Y00KAPILRMd0vx8O+Rt4bcn8bXRUV8o aLxvICKuSxP4A3CuBqsZap31wxAvgW7No9rFrNi3nFzDvzbisJZqqfY10VwBIhyWoGArynfkJV7m Bonlx05g+UGQWpGDkJWmboQc5EVBFN2ZQ1EAVVUNyarVRpCLjYJ2wKEAgaEN4MIQal0toe5GJTXB cKF6edQc2WNoVhdNgWcFtesKtHK0WGCBvzzPUVRCDUqCNxQNeAdw8NgJ83d50CBPxpgCUX4XyDuE QKUSnUJfN1jACYNIg7idov8kEvlP3PgDN8u6KohxvmmunzGEDsEQDEhI/SpJWgHNzeE62c081z1N IytO0cjykZtaceZlVuJkI9fL0GiC0GMnyxY5here2sAP9z8+PNz/PGj/6jYepiaMsDMJV4PrYbYR FVzOOJ4EXjKOrdj1M8tPJyMryoJjKztGvp/E4yhBp3cAgbt+mAui5/inot8nYHyxA5oqF0yyUh3l rLG7ZWJzdksEZ5XeJ67TL6UtrmHkeBPPOT72A78fWVClvolDtQCh3QZt2XktPmN+sYXRhENYf3An Em3isPD6gffk0mIfFuj8FwAAAP//AwBQSwMEFAAGAAgAAAAhAMzbidpMAwAA2QgAACEAAABwcHQv c2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Ni54bWy0Vl1u2zgQfl+gdyDUZ0U/VOxEiF1YUrRYIE2C OjkAS9GxUIrkkrRr76JAr7V7nJ6kQ0pK0jQFgtZ90c9wZjjfNzMcnr3ZdRxtmTatFLMgOYoDxASV TSvuZsHtTR2eBMhYIhrCpWCzYM9M8Gb+6o8zlRveXJC93FgEPoTJySxYW6vyKDJ0zTpijqRiAtZW UnfEwq++ixpNPoLvjkdpHE+ijrQiGOz1S+zlatVSVkm66ZiwvRPNOLEQv1m3yoze1Eu8Kc0MuPHW 34Zk9wrQ2tZydiX4PkBeVW9BmARzQE+XvEGCdCC4cVrIq7kVo240Y+5LbP/UaqmutTe43F5r1DbO wWAYRMPCoOZ/BajBR/TE/G70RPLdSnfzM5IDF2g3CyBle/cEI5KznUW0F9IHKV1fPaNL1+fPaEfj BhDB/aYOVY/oezjpCKfnIblH1asSML2Q9INBQgJOB7+HRy+3ozOH2blXa/SI+EGvX/R8jPoGOPVk 2V0hm70D/h7eXkhybuzS7jnzhEDYJAfn8AD6OXF1zUR4u4S67mzJGYG6H8iz85K39AOyErGmtegt MZZp5KsAugBcngE7FpIzuGSiuSaavHvi2eEjOewMQY8RwmdP4Y+JxCORFbEMXXNC2VryBiJID8Fp YwHyP9AWhK8CKESoksQD99S6BPwSxyvoB1fd/+K0TOtkUoZZEU/CbDKpwkWMcVhVyQLHOF1MFotP wZDoBqDatmN1e7fR7Gpjg5emCkcn0P4JfkgJROCMf5AU1LTaji3xM+nJxvTUUrqyeJwgfIgErazu M/T3hmjYYUzS2DAHaITfxc3xyM2Stw1Dl5vu/ROGskMwBCMHXD9Lkm+RA1dyUqdJcl4twqLC0zDD SRUWdVqHZVxPk7TG01OM7yvZOOQContpAX/5/N/rL5//P2j9+lNmHD8wCy4MnFbKT4WNbqE5i+J0 kpYnRVgkWR1m1ek0XNST47A+xllWFieLEp9/AggqyXKqmZ+MfzXDhAbhd1O1a6mWRq7sEZVd1I/n SMmPTCvZ+gmdxMOY3xIOR04aZ6fJFKdTVxAQL0Q5vn20IHKz1YVNuX5L1NUWjiaSw4UCeqL0IgVX iN76kYrDPl5J5l8BAAD//wMAUEsDBBQABgAIAAAAIQCZMl7q5AUAAFccAAAhAAAAcHB0L3NsaWRl TGF5b3V0cy9zbGlkZUxheW91dDUueG1s7FnrbqNGFP5fqe+A6G/WDGCwrTgrX5aqUjaJGu8DTGAc 0wWGDmMn2Wqlfa32cfZJes7A2Pi2S5xUWqn5Y2P88XEucz4OZ87ePmSpsWKiTHg+NMkb2zRYHvE4 ye+G5odZaPVMo5Q0j2nKczY0H1lpvj3/+aezYlCm8QV95EtpAEdeDujQXEhZDDqdMlqwjJZveMFy +G/ORUYl/BR3nVjQe+DO0o5j234no0lu1teLNtfz+TyJ2JRHy4zlsiIRLKUS7C8XSVFqtqINWyFY CTTq6m2T5GMB3sp7PnuY3fOr2z9MQ4HFCk4T8xz8j27S2MhpBicmPCuoSEqeq3/KYiYYQ0y++lUU N8W1UBdcrq6FkcRIUF9oduo/apj6mQMMDjo7l99pJjp4mIvs/IwOIBrGw9CEpD3iJ1xEB+xBGlF1 MtqcjRZXB7DR4t0BdEffACxY3xTyXVQe7bvjaHdmiUyZQdZeVVAKl17w6GNp5Bz8RPcr96LLlSZD n5G+WBh16JGqxlV/qnhofAkxVcGSD2MeP6Ljt/CtTtJBWsob+ZhCCuB4lRKVADqI2fz3KrSN0+Bt Ew5O0gGYAh+QrJRiHbDc+nADdZDJScoo1Ekdank+SZPooyG5weJEGu9pKZkwpIpCiQacAbuEVNaU LI+vqaBgxBYzRoMO4M7govYHDquAHw+7uw475vw6pRFb8DQGC5yXyADG04TlCmtJJ+xIIjBaO0vS 6wZQ4Gpdkq7bJcRFkzar07M9m/RAXHCN+m4/8JXNEIaKSLlfLQkdEZ1hg+bRgoNa3FaUzezVyTYy Ki5UXSR5DAWOh3j32+UlqJgypFoLRvlpaDoeWnqr3WysDXXowOqpCbVXrVjtfVakQjvATHfD2iee sqANK+ntsyJVzeptWIkbEB/BrWgVcjsEyFXTdhu0PaenbDiVFrlqWn9D6zg9MOEZ1iJXTRs0aAPP VevwVGuRq6btbWiRs33KDsQWuWrafoPW7wbPShlyKS1p1oRSNLwJrLq1dKm7n65wKDhK4MothTtF xTytYhOeS6jVLSFTqgGPWv2geOKjBKt7QdN5LWOVxOBjVYUJD5rPE0zIcRlzSOD1gu43ZMztdwkU ByLa6JiSoWai9p5UG3WqKBsAONRi0lQyLKE1VgMAqyWigVVKssZqAGB13TexuCrXWA0ArC7mo1gN AKyu0KNYDQCsLrujWA0ArK6lo1gNAGxVILoTUPFVIrn27ceoINUMwIcuWvX8fUJbcsMinsdGylYs PVCgu/SqLp5AP1skoj17/eRvrTghXwq5aG28V1Vke/pkfpAdepMX7c66Wtdmu92Zsvh0Uav646o7 Q4H7c0kFtJ21xqloq1a5tcb5Xtd2wFzoxI71aiQA5Xvt1Ybma68G/fJrrzY03f9jr+ZrTTvUq6nW 6HRZ25cypZMnS9mxfm0jZa/9GsZ8u/957deOzHS++caz21C99ms4QqveBndj86P2a4HWtimVbOsl 1McO83Rhq/q1WMIAcft1lFTvVEffR9Vdd6dfcHIzsFQ/1Pv9HGbROFn+y3UmTkj8ieWNbd/yfH9q jWzXtaZTMnJt1xn5o9Fnsx6yxuCqTDIWJndLwa6W0kT2NmMBt9OD4TtxN28XYAFefKSJNuJESD2O PmVMAKPCatYeco5D1ua4M3iJBM0ltND7DyHyndnnU5L0X8Wmr2NzkyYxMy6X2e1OhNRQ4rlLGDZ8 gPpgkL4zWXlKkNYrmYQOIe+mI2s8dQPLc8nUGodOaE3sMCBO6AZ9112v5BI9z8G6tgv465e/f/n6 5Z8XXb9qaK23fuCBcVHC7L9QOzJLkUBxjsd935n0xtaYeKHlTfuBNQr9rhV2Xc+bjHujifvuM7hQ EG8QCab2pX6L6/0xOLm3p5UlkeAln8s3Ec861eZYp+D3TBQ8UftjxK432VYUpn/E7fdt6Iy6elWD lWrbQVsLLuC+ltK7VLynxdUKlJwOYDsPqm6iThWwgQcZRegGgr7rDcHzfwEAAP//AwBQSwMEFAAG AAgAAAAhANEmVRuFBAAAiBIAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NC54bWzs WNtu4zYQfS/QfyDUZ0UXyrIjJF74EhUFsklQZz+AkehYXUpUSdqxt1hgf6v9nP2SDinRcRyntjfp W15siToczpy5cMizD8uSoQUVsuDVuROc+A6iVcbzoro/dz7dpm7PQVKRKieMV/TcWVHpfOj//NNZ nUiWX5IVnysEMiqZkHNnplSdeJ7MZrQk8oTXtIJvUy5KouBV3Hu5IA8gu2Re6PuxV5Kictr54pD5 fDotMjrm2byklWqECMqIAv3lrKillVYfIq0WVIIYM/upSmpVg7XqgV/f/eEggxMLGAmcPpieTViO KlLCwO0DRyNeKRBjPsn6VlCqQdXiV1FP6hthZlwtbgQqci2hnel47YcWZl4rgMGDtzX93koiyXIq yv4ZSYAJtDx3wGEr/QuTSEKXCmXNYPY4ms2ud2Cz2cUOtGcXAA3Wi4Kv68ai5+aE1pzbQjGKgrVV DZTA1EuefZao4mCnNr8xL7taWGHaZi2+nqGWdi2qxTUfDR8WL4FTQ5ZaDnm+0obfwb8ZJAmTaqJW jBpCQG2SgHD4AfoZ0VFNK/fTBKK6VCNGCUR9S57qj1iRfUaKI5oXCn0kUlGBlLFLapFnwI4C57Qi aZXfEEF+35Ks7SMJrAxKWw3hsaHwZSKxJbKNJnTDSEZnnOWgRPg6WuUXyAbCpg5EIISH9cEL3Gq6 tqIs6nQhX02oBbHv62fDrw24yMc9GHeQDruoE3ZOY2wcaCUZAho3W052ek2vzRYsMGlDkpxONb1a /7DXLArcbgDgMdyBjTaxFgBYvAPrb2ItALDRc2zwRAcLAGxnH9YCABvvw1oAYLv7sBYA2N4+rAUA 9nQftgFortt00o4x2QQzEUhYp80rs0tHkEku+SS7mgzaXtIE7hEJPaEZr3LE6IKyA8SbLDtC/O2s EIdLNwlxhPSUz4WaHax81GTkwe5Ii+lO6bCLvGldi/6rrhlOYD+1m8GR28VWXTP+M1uFrjTmYXPP 2FXX4qj3XthgR3gvbMl7YVs3Qu+F7YCGrWML25go+qRbM6X4x6ta0wTnCnrUrb7NOOjlAndMUzyF E4w+jvyFw1GYBvHIjYZ+7EZxPHYHPsbueBwMsI/DQTwYfHXazjwHU1VR0rS4nwt6PddnHtjStjrg Xb019npwWgvw4zYMGujJL+w2KC+EsmeYH+mnY+uelHPdx2+2053XtdONg6ZKNB76c04ErGCb6z3d 9TFO+r+46VpuJqzIKbqal3dbDMVvwRDcEIDonSTt2aqPIWkdyUEaBsHFeOAOx7jrRjgYu8M0TN2R n3aDMMXdU4zXkSy15RVod2gAf//29y/fv/3zpvFrqoy9L4BO+FLC8bI2x/i5KCA5h8PTOBz1hu4w iFI3Gp923UEad9y0g6NoNOwNRvjiK5hQB1GSCWouMn7L2wsVGHx2CVIWmeCST9VJxkuvuU3xav5A Rc0Lc6ES+O2tzIJAk487XR93QhxZh4GWprWy2oIJ+jZEq50x8ZHU1wvovUgC9z+QEyMzVMOND3hU Qx8h2nZ7g9T/FwAA//8DAFBLAwQUAAYACAAAACEAQ5UzDfYEAAB5EQAAIQAAAHBwdC9zbGlkZUxh eW91dHMvc2xpZGVMYXlvdXQzLnhtbMxY227jNhB9L9B/INRnRaIkS7IQZ+FL1BbIJsE6+wGMRMfC UpdStNduscD+Vvs5+yWdoUTbyWaxbjYN8pLI1HB45swZcqjTN5tSkDWXbVFXI4ueuBbhVVbnRXU3 st7fpHZskVaxKmeirvjI2vLWenP280+nTdKK/IJt65Ui4KNqEzaylko1ieO02ZKXrD2pG17Bu0Ut S6bgp7xzcsk+gu9SOJ7rhk7Jisrq58tj5teLRZHxWZ2tSl6pzonkginA3y6LpjXemmO8NZK34EbP vg9JbRuItuXZb5zlFtGGcg1D1DqD2LO5yEnFShiY8wwXJ2jIpX7bNjeSc7Sr1r/KZt5cSz3pcn0t SZGjk36y5fQvejP9swIzeHAeTL8znliyWcjy7JQlwAbZjCxI2hb/wiSW8I0iWTeY7Uez5dUjttny /BFrxywACHaLQr6bLqKvw/FMODeFEpzQXVSdKYOpF3X2oSVVDXFi+F142eXaOMOY0X2zJB31Cl31 dt1LzYexbzWnBuiOicjzfOprOoLADYfuA1KiKPICGCRIDfVDz40GehHjCRbpXDeJ2kzqfIuU3sJ/ yByrsmUNKlU4gyWiVXO1FZBneF4LCogIE3dQRgJUwJKcL97BUPvnyIIlYc1bnfiMAQNMiH7Zfiak +75HIJslQAn8ASeCYT3yyn4/h3os1VRwBgv10amzqSiyD0TVhOeFIm9Zq7gkmkKoXsCI3pVeQ7vk VX7NJEN4h54xKyyBlYEFE70mBDPz7fQD310p3KD2rgXL+LIWUAzEwyChWkyen6QEZN+CsgFNG+E8 SRDe0A0jEIdOnqmS+4IYuC6Noz4zXZEdI4jbzudjgiiZvNAFWlQ57DT4iDm9XV3CdqqRHMgEtsTu dVuLIk8LIdBW76Z8KiRZMwHq2+AWBOksKtWNRABbKwGStzPWqTzwA++6lfSLneq0dD2Uboc0GESA Aug+Ai6NXxAuYsSwAbm/hzukUObHwg1fEC5i7OEGe7jUjyiiOI5ejEwL4AXUgCB7vIMDvLEXY5Jf H14E2eMN93g9LwZ6XyNeBNnjjQ7wRoF/fLm9pB4QZI833uNFsMfX20viRZA93uEB3nAQvc56Q5Dd TnzQRegzH9HDJrc73HVYT+8B8KDTLUB7rwd4yjkfmHN+xhS/d87rQ/VHz/lcQWsDzdKSiYU577tj DRthTRc+zDVzXZumuwvTqZg+TZ+q5izWPzSvC+jYsff+y/emXkrDqR1M3NAOwnBmj13ft2czOvZd 3xuH4/Enq29DcwhVFSVPi7uV5FcrZaHKjkmH78RwPaH+nnZAgJO/0XyRvJDKNOxPSc/ApCeta2z/ Dhux4DkasYWSXYb+WDEJK5gkfacr+y9J+r+4CQ03c2isOLlclbcPGNLXgB+VMFyJwfWjJOlWGJrJ 51QyTT1Kz2djezLzIzvw6cyepF5qT900ol7qR0Pf3ym5xcgrQHesgL98/vuXL5//eVb96m7aXI5h a7po4VbS6DvrShZQnJPJMPSm8cSe0CC1g9kwssdpOLDTgR8E00k8nvrnnyCEhgZJJrm+uf+e918Q YPCrW39ZZLJu64U6yerS6T4fOE39kcumhg4aS9TtP0Po9poGYUzjOKChvgZobPpCZNBCCHj71/ca Id+y5mqtt2j44AE1AW06DDXwiQNkj6Z7E4zdfDI5+xcAAP//AwBQSwMEFAAGAAgAAAAhAKXJ3KOp BAAAJREAACEAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWzMWNtu2zgQfV9g/4HQ Piu6UJYUIXbhS7RYIE2COv0ARqJjodRlKdq1uyjQ39r9nH7JzlCi7aQpahTehV9siRqOzszhkGd0 9WZTCrLmsi3qamh5F65FeJXVeVE9Da33D6kdW6RVrMqZqCs+tLa8td6Mfv3lqklakd+wbb1SBHxU bcKG1lKpJnGcNlvykrUXdcMreLaoZckU3MonJ5fsI/guheO7buiUrKisfr48Zn69WBQZn9XZquSV 6pxILpgC/O2yaFrjrTnGWyN5C2707OeQ1LaBaFWhBLeINpNrGPCsEUSezUVOKlbCwANakLkocq4f tc2D5ByNqvXvspk391LPuF3fS1Lk6KGfaTn9g95M31ZgBhfOi+lPxhNLNgtZjq5YAokgm6EFfG3x FyaxhG8UybrBbD+aLe9esc2W169YO+YFgGD3UqC66SL6NhzfhNMlwttF1ZkymHpTZx9aUtUQJ4bf hZfdro0zjBndN0vSZT1TUnvrTbvnOiVmSqvTarDukhHGg9jtMuJ71A38wfO8RFHkB2iA2fGCyHU7 i8OoO9dNojaTOt9iVh/hX7PCEtGqudoKrrMNOWEJIIcf4FYwrBhe2e/nUDGlmgrOoKJ6ZtRoKors A1E14XmhyFvWKi6J0qunRZdXAEIB871LXuX3TLJ3Lzxj8lgCb4Z0GIRw2fHzfZaoYWm+euze6Z+C qHb12BEFKxuWneH2eMI8GnlhzxiN4xD2hOeMhUCXplQzFg18tO6S0BWCDr5bPyYfrzKGNIm18GDh kJLJG105RZVD9etLJp6ALVh5UMXgYHULu51mOecLIAEH2xqqPC2E0De4xfGpkGTNBGwUG9wZgMGi Ut1INHB3UPV+iMaavQM/wKXxD5c9PvQDl/4eajCIMDPk/PAiyB4v3eO99AJdZueHF0H2eIM93t0y PD/AiLIHPDgAHPuxLovzA4woe8DhHrDvx1C5Z7mEEWUPODoAHAX0TGsOUfaA4z1gRHumRYcoe8CX B4DDQaT3/vNbw4hSb9XmvEf0Jzju4bz8v078wJz4M6Y4uRcs48ta5KA56ClO/lyByPkEEpuJBZxL +vTvDmZUrjp7eDHXiUR9ogXUXrO8ekbvVdUC9DWK5b+oP/VTL5zawcQN7SAMZ/bYpdSezbwxdak/ Dsfjz1avG3MIVRUlT4unleR3K2Uhb8eIM+rE0Ep4dC/CAAFO/o4MI3khlVHYPyPIBoaetK5RCB4S FJyCoAUoGc3Qnysm4Q2GpB9oNKDgaJL+q9yEJje6qyK3q/LxRYa0rIc2zPQQP9VlQPsKrl9NkhbH uuE43Ur2Ut/zrmdjezKjkR1Qb2ZPUj+1p24aeX5Ko0tKdyu5xX6yAnTHLuCvX/7+7euXf066frW0 Nt0stJY3LfQnjW4yV7KA4pxMLkN/Gk/siRekdjC7jOxxGg7sdECDYDqJx1N6/RlCaLwgySTXXfYf ed/tw+A3HXpZZLJu64W6yOrS6Vp9p6k/ctnUIKyxRN3+k4FW3ZQGNA4DL450T6Cx6dbIoIUQsFdH 2JmQb1lzt4aNnSXwcQJqAgQ5DDXwOQI7imcmGLv5vDH6FwAA//8DAFBLAwQUAAYACAAAACEAKmhz P2IFAADiEgAAIQAAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQ4LnhtbMxY63LiNhT+35m+ g8b97YAsX4AJ2eESdzqTTTKFfQBhi+CubbmyILCdndnXah9nn6RHskWAkMUk6Uz/gBGfPp37Odbl h3WWohUTZcLzvoUv2hZiecTjJH/oW5+mod2xUClpHtOU56xvbVhpfbj6+afLolem8Q3d8KVEwJGX Pdq3FlIWvVarjBYso+UFL1gO/825yKiEn+KhFQv6CNxZ2nLabb+V0SS36v2iyX4+nycRG/NombFc ViSCpVSC/OUiKUrDVjRhKwQrgUbv3hdJbgrQls/+mK4tpGFiBQvYugLNo0kao5xmsDDiuQQG9JjI BRrRQsmhMWUxFYwpdL76VRST4l7orbere4GSWFHVFFar/qOG6Z85wOChdbD9wTDR3nousqtL2gOL oHXfAsdt1Cdsoj22liiqFqOn1WhxdwQbLa6PoFvmAJBgeyj4vKg0eq6OY9SZJjJlCG+1qqAUtt7w 6HOJcg56KvUr9aLblSFTOiv6YoEq80tFVeOqP7U9DL7UNjWCbi3hegHEljaHE5C2d2AT0m53CCYW UpbB2HdqxK7GFXPRk+shjzfKojP4BsfRPFpwCNRZZee0lBO5ScHNtJeuUgwCIZo+QCalEAS0F7P5 77BUfulbIBLINDOKb/HgY3je4QEL0x7YAT5ga0pVIrLc/jSBRMzkKGUU6Gud5NUoTaLPSHLE4kSi j7SUTCBtN0hbkEyxS32GpmR5fE8FVULtMitX0B6cDPY1OsNj5e2XfQ5G3M+C+5RGbMHTGIRw3hYB SQzxa4KkufOJF3jKoSoZjnnfwxgDovK+1/EIhlCo1K8SSqtdxaGxhPG+Tq1dV9UuP/A0UdFXUe4A 4NGp43U3Kjq7WAMALDmCdXexBgBY9whWRdtWBgMArHcKawCA9U9hDQCwwSmsAQC2cwprAIDtnsJW gGM5BDsRMGyT5Y05pWqqTqlyL6eqvNHJAx/mSB24Z6TxhEU8j1HKVixtQK9z6wz66SIRzdl1QpzB HvKlgO7XVHhXBeY59Mn8KDu0uXetZq6pZlPl6t1Spg0Cbd+0qlc1M9VBoIRDK1jQdG7BDAAFTjtS NzVVcvTDREe8Kr5q6UfdDbvEw1WeP7X8vfbm+l3c9t9c4FBGxY0eMZI8hmlHPSrRZstbGAq1N3dq Gt6rU6onKixkoipvNZXp0Y349urpQY2s+brYVaeiRnx7tfGgjtZ8mATYb0rY/UGtNXwdp6NKfSMB 9/gO6nHN5zgdEO81fAc12/AFrm5b58t3UNdrPkXW2CF7+h7UfsPne8Hr/PH/6A+Q2Waa0AOGGnNf nqs8U4nGVLK9SqRr51srUSyf1SFcTQvqbeNoIYIcf9Lg6Dykq4CeXefwcqRecP4izsgJsT+y3WHb t13fH9uDNiH2eIwHpE2cgT8YfLXqWT8GVWWSsTB5WAp2t5S6wjQZgUmrA++BmDz1TZBAlZwX2gOK EyHNW9Frxl7fuCfkXI3bu63CU83trQ6aS1F56M8lFXBC3SzwiXH4HCf9V7YJjG0maRIzdLvMZgcW 8t/DQnD3ANRHjXSipZ5jpG0k49DB+Ho8sIdjEtguwWN7GDqhPWqHAXZCEnQJ2UZyqTTPQToVg00C +Pu3v3/5/u2fd41fXWXMDQTMMzclvAUW+mJgKRJIzuGw6zujztAeYje03XE3sAeh79mhR1x3NOwM RuT6K6hQYLcXCaavSH6L66saWHx2vZIlkeAln8uLiGet6p6mVfBHJgqe6Ksa3K7ve1YUpnLiOFAS vI6vAwLkBSn1CGSkhSV10aLTKRUfaXG30pME3CxBToz0UgF3SeBRBX2CKN3N3dTVvwAAAP//AwBQ SwMEFAAGAAgAAAAhAIhfozHXAwAA7AsAACIAAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0 MTAueG1stFbbbts4EH1foP9AqM+KrIvlRIhdWHZULJAmQe3uO0vREVFKVEnatXdRoL+1+zn9kg4p MW1SB3AS74tsUTOHM2eGh3P+ZltztKFSMdGMvfBk4CHaEFGy5nbsfVgW/qmHlMZNiblo6NjbUeW9 mbz647zNFC8v8U6sNQKMRmV47FVat1kQKFLRGqsT0dIGvq2ErLGGV3kblBJ/AeyaB9FgkAY1Zo3X +8tD/MVqxQidC7KuaaM7EEk51hC/qlirHFp7CForqQIY630/JL1rIVsgRi+3HrJ2cgMroTeB1MmC l6jBNSwsmeYUAUHoLzBmBHO0pFttzVS7lJQah2bzVraL9kZa76vNjUSsNGg9ihf0H3oz+9qAGfwJ HrjfOiScbVeynpzjDFhB27EHxduZJzjhDIJApFskP1dJdb3HllQXe6wDtwFEcLcp1L3tMvo9ncil 05ES3mXVmWJwvRTkk0KNgDxN+l165GrjwEzOBr6tUFcCbfjt7bqPlg9nr4BTS5be5qLcmcQ/wq9d xBlXeqF3nFpCIGycATg8gH6OTYfTxv+wgA6v9YxTDCegJ09PZpyRT0gLREum0TusNJXIBgPnASDP gR0NxekhaVPeYInfP0A2+eEMdoagXYTwt6PwcSJjR+S9nkI3HBNaCV5CKNExyDVUeUhIBoeg63YP +hKaxlXmKYwbGQEUik3QJrp9/EO5EN/wO6JfWA/T5LYc6l49Os4t8fBwW9qkntACC0oEnGtON5Qf AG8r8gT4ZcXk4ehxx+jBfBViLXV1cPDJU+HZai866M5RT0LiTsIca3rvAFhCQIqddjxLXUoNh/9v uCowX7nWtxJgRcZI0YvUZgXXhNH5f+JoFhVhOvOTfJD6SZrO/ekgjv35PJzGgziaptPpV6+XvBJS 1aymBbtdS3q9NpfJYaIVB6dwJYbxz26FCIzzI0VBJZPaXQ7PEaqhK08hhBHIXxXKttRLC7TSsqvQ 5zWWsIMr0nME6hFJ+r+4SR03C85Kiq7W9ccHDA2PoeEwhgH0XpKsIh25k8MiCsOL+dTP5/HIT+Jw 7udFVPizQTEKoyIencXxXScrk3kD0R3awN+//fv6+7f/jtq/9r51gxhcGJcK7u3WzkdryeBw5vlZ Gs1Ocz8Pk8JP5mcjf1qkQ78Yxkkyy0+ns/jiK6TQhklGJLXT4p9lP7XC4m+TZs2IFEqs9AkRddCN rEErvlDZCman1nDQj74bDHdhmg5HcTgcjEw/QLgQpPu1wcKSmThN1ITLd7i93oAy4QxmbDgSM7vU wlTdef9iYlJ3U/rkBwAAAP//AwBQSwMEFAAGAAgAAAAhAAiPlEQeBQAAWxIAACEAAABwcHQvc2xp ZGVMYXlvdXRzL3NsaWRlTGF5b3V0OS54bWy0WOtu2zYU/j9g70BovxWZkizZQpzCl2gYkCbBnD4A I9GxUN1G0a7doUBfa3ucPsnOoUTbSpzVUd0/tkQdfjzX75C8fLfJUrLmokqKfGTQi55BeB4VcZI/ jYwPD6E5MEglWR6ztMj5yNjyynh39esvl2VQpfEN2xYrSQAjrwI2MpZSloFlVdGSZ6y6KEqew7dF ITIm4VU8WbFgnwA7Sy271/OsjCW50cwXp8wvFosk4rMiWmU8lzWI4CmToH+1TMpKo5WnoJWCVwCj ZrdVktsSrC2T6GFjECUm1jBAjSuwPJqnMclZBgP3SSRXgpNPiVySKStRDyVTlQ+Cc5TO17+Lcl7e CzX1dn0vSBIjVANhWM2HRky95iAGD9az6U8aiQWbhciuLlkAHiGbkQGB2+IvTGIB30gS1YPRfjRa 3h2RjZbXR6QtvQBosFsUYl7WFr00x9bmPCQy5YTurKpFGUy9KaKPFckLsBPNr82LbtcaDG1G+HJJ avdLhGrk6o/KH1q+Uj7Viu48Qf2hbQ8gb8FydwBZ1nvmlb478FwYJOibvuf5zkAtopFgkRq6DORm UsRbdOkj/EPkWB4tC8jUR5zBgrSSc7lNIc7wvE4paERY+gSllEIWsCDmiz9hqPo8MiDfYclHbflO HoLcxgEXswAcAT8wNWVYiTw3P8yhEjM5TTkD+MYkeTVNk+gjkQXhcSLJe1ZJLohyHNQtaIboUq2h IHke3zPBUKlDZIwFC2BlsF3brNyA8Xg96I4Oui6D+5RFfFmkMShho4ugWHSAO6UAVKAB5QK5rBOm WyJ41Pb9fh00XR2tPHApxWQ5NRFejX7GxI2qxiSPgVrwEUP5uLoF/lSzDnLCgaRoVmyyB2Xh0cZE qqHcvo9S5BQ8e29BA9LgOXu8IXVV8p+Eh5J1bgAegjR47h6POj7FEjtNQSyCHSCiNID9A8ABVG83 QERpAL09ILABKNhJQ0RpAP0DQN9VketgMqI0gIM9IKKdHpSWDxGlARweAHp9v2NQEOU4J73CHSRO hNRdpguLuJpFHrAyDynEwVz5UQpB5gbqBApesnTRsIkiJ9VNlLXYZufKcM39uhkcbSt9B5pG3TX2 zbZFJ4MeNJl6EY30P21F8cKxXvImNqGtasVe1CRGRzahLXZCkAavI5vQVuKegU2GZyaTFt4ZuKSF dwYqaeGdgUlaeGcgkhbe6zwCiUSgnew2MSqtuu91kDTUVqdq7XW6MFFfM9GMSd5iIvccTBTLFzxE 63aI/HOUiBT/6R2Z3oW26EK9qD3jAk4leLL427Gndki9qelOep7pet7MHPccx5zN6NjpOfbYG4+/ GM0mOwZTZZLxMHmCg8zdShpY5aeEw7EGcACjzt7toAFO/lmNwtPhCYsCt7mHrULt7X60VSykqCP0 14oJWEFvPb+z93xLkH6Wb3ztm3maxJzcrrLHZx7yzpHCcOgH6KNO+k5LfYuTdplMQ5vS69nYnMwc 33QdOjMnoR2a017oUzt0/KHj7DK5Qstz0O7UBP729Z/fvn3996z5q7q8PvoDNd1UcPoq1Yl8JRIo zslk6NnTwcScUDc03dnQN8eh1zfDvuO608lgPHWuv4AJJXWDSHB1N/FH3NyRwOCLe40siURRFQt5 ERWZVV+QWGXxiYuySNQdCe01Fy1rBqxre3DQcXu+qwMGWqqDn9YWTMAbDrXzSsV7Vt6tFUXDlQ7U xFQNlXCJAxFF0b0I2q4vha7+AwAA//8DAFBLAwQUAAYACAAAACEAdLywyyMEAADNDAAAIgAAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWy0V9tu4zYQfS/QfyDUZ0VXy7YQe+FLVBTI JkHt7TtXomNiKZElaa/dYoH9rfZz9ks6pERn43hRZ5N9kS1peDhzzsxwdPlmVzO0JVJR3oy86CL0 EGlKXtHmfuS9Wxb+wENK46bCjDdk5O2J8t6Mf/7pUuSKVdd4zzcaAUajcjzy1lqLPAhUuSY1Vhdc kAberbissYZbeR9UEn8E7JoFcRhmQY1p43Xr5Tnr+WpFSzLn5aYmjW5BJGFYg/9qTYVyaOIcNCGJ Ahi7+rFLei8gWiBGL6lmZNJUy52HrL3cwpvIGwMF5YJVqME1PPgDTGmJGbL2CBhDS7LT1kyJpSTE LGi2v0qxEHfSrr7Z3klEK4PWoXhB96Izs7cNmMGf4Gj5vUPC+W4l6/ElzoEdtBt5IOLeXGERzsEJ VLYPy4en5fr2hG25vjphHbgNwIPDpqC/aCN6Gk7swjkiJTqE167BgHHNyw8KNRwCNjy0cZY3W4dq gjf7iDVqNdFGDw9xSUG5VqJuVWtqaXKrlaXa+X8gKMviYRq2NMX9NEsGj7mKw17fvjeM9Qa9qBf3 7CYOCTZpoUWud1Ne7Q3T7+EXBDVJM/IINsG3sEzphd4zYvUA1nAOIcEFjBk2hUYa/90CCq3WM0Yw FGKnnR7PGC0/IM0RqahGb7HSRCJLAZQlQF6COBpyo4MkTXWHJf79CNmwinPYGfx2/toQDLPf1jF5 qqPJpjuGS7LmrAJXYhMhFIIT7LskNcQdKQplATnr8uF8ZdNeHxqLzf9TwmZhNByY9z9KWMg3xLbs oOALhTZ0W53VI6FbMa2icHFbWraekVsLUnJoU4xsCTsD3kr9DPjlmsrz0ZO2VM7mq+AbqddnO58+ F56uTqJDP33VEktdic2xJo8qyxLy0sqqNHSVv+AoxGzldTVle4vtkqaz2j9ft0tbz65JuKZmO9fT NraC48+cX38n8Swuomzmp9Mw89Msm/uTMEn8+TyaJGEST7LJ5JPXdfAKQtW0JgW930hyuzGH5Hnd MAkGcORHyUO2ggdm8TdEQRWV2h1639MBe06egnPTeb9ufTalXirQSstWoT83WMIOTqT/6XzPEelH cZM5bhaMVgTdbOr3RwzZM/OlDMGYCdAnSbId6ZUzOSriKLqaT/zpPOn7aRLN/WkRF/4sLPpRXCT9 YZIcMlmZyBvw7twE/vL5n1++fP73VfPXHuRuwIQD41rBQCDs3LeRFIpzOh1m8Www9adRWvjpfNj3 J0XW84tekqaz6WAyS64+QQgiSvNSEjsN/1Z1Uzk8fDJJ17SUXPGVvih5HbQjeSD4RyIFp3Yqj8Ju tN9iOAujtD/oR8N46AQDL23ncd5CCGaUtpMEk2+xuN1Ca8I5fERATczsIwGfDZD2xvTBxMTuPkPG /wEAAP//AwBQSwMECgAAAAAAAAAhAJGILoAAVAAAAFQAABcAAABkb2NQcm9wcy90aHVtYm5haWwu anBlZ//Y/+AAEEpGSUYAAQEBAGAAYAAA/9sAQwABAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/9sAQwEBAQEBAQEBAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEB/8AAEQgAwAEA AwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMF BQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGhCCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkq NDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqi o6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/E AB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKC//EALURAAIBAgQEAwQHBQQEAAECdwABAgMR BAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVG R0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKz tLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A /v4ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKK8P8YftJfA74e+PNf+Gvjr4iaN4Q8V+FPgj4i/ aP8AFEfiKDVNI8P+Hfgh4S1pPD3ib4ha540vbCHwXpWkaHqkgTUbe+8QQarbWaTaq+njSoJ72OJ1 adO3tKkKd44ia55xjeGDwmIzDFzXM1eOFwGExeNxElpQwmFxGJqONGhVnGoxnL4Yyl7+Hp+7Fv8A eYvFUMDhaei+PE43FYbB4ePxVsViKGHpqVWtThL3CivlH4Q/tt/s2fGzwX44+IXhbxp4k8J+Dvhx 4UsfiD401n47/CT4x/swponw11PStW1rTfio1n+0l4A+FGo33wmv9M0DxBdWfxU0yzvfh7c/8I94 ghh8SPcaHqsVnxPw4/4KOfsk/FHx94E+G+g+MfiV4b8QfFcXo+EGp/F39mr9pz4CfD/40TWWnLrX 2L4K/Fj44/B74efCz4xanqPh1n8VeH9K+GfjLxTqXibwfbX3i/w7a6p4Z0++1W32dOoq/wBWcJrE 2g/q7i1XtVbjTfsre0tUlGSg+X33FqN2mZucVTdVyiqSc06ra9mnThTqVE5/CnCnVpVJ6+7CrTlK 0Zxb+5KK+SPBH7dv7J/xG8RftXeEvBfxf07W/FH7D9/cad+1JoCeGvG1lq3wqnt9B1fxK01zY6l4 Zs7jxVp02j6Brc9jq/gVPFGlajc6TqGmafe3OqWk1mntFp8Zfhtf/Bi1/aEtPEfm/CC8+GEPxltv F39j68nmfDa48KL43h8R/wBgSaWnidN/hh11P+x5NFXXlz9ibS11AG0HPKvRhh6mLnWpRwlHB4LM a2KlUhHD0svzLD4jF5djqlZtU6eDzDC4TF4nBYqUlQxWHwuIrUJ1KdCpKOqhOWIhg1CbxdTEYrCU 8Kot4ipi8DUw1HG4WFBL2ksRg62NwdLFUYxdTD1MXhoVYwlXpKfp9FfGX7PX/BQD9ln9qHxPYeCv hR4v8fW/i7XPh/afFjwj4c+L37P37RH7OOsfET4YXk1nbj4h/Cux/aK+FXwrn+K/guyl1PRl1nxN 8N08U6PoH/CQeG21u709PEmhNqHuni745fC3wJ8U/hB8FfFfij+yvib8eV8fv8KPDX9ieIr7/hK1 +F3h+28U+Oj/AGzpukXnh/Q/7D0G8t77HiTVdHOp+Z9l0f8AtC8SS3XoqUqtJwjVpzpyqe19mqkJ QdT2E61KtyKSTl7GphsRTq8t/Zzw9aE7SpTUcIVaVRNwqU5qPsuZwnGSXt6VKvRu03b21GvQrUr/ AMSlWpVIXhUg36zRRWbrGs6R4d0jVfEHiDVdN0LQdC02+1jW9b1i+ttM0jR9I0y1lvdS1XVdSvZY LPT9N0+zgmu76+u5obW0tYZZ7iWOKN3GU5xpwlUqSjCEIynOc2owhCKcpSlKTSjGKTcpNpJJtuxt GMpyjCEZSnKSjGMU5SlKTtGMYq7cm2kkldvRGlRWToOvaH4q0PRfE/hjWdJ8R+GvEek6dr3h7xDo Oo2esaHr2h6xZw6hpOtaLq2nzXFhqmk6pYXFvfadqNjcT2d7Zzw3NtNLDKjtrVpKMoSlCcZQnCTj OEouMoyi7SjKLs4yi0000mmrPUzhONSMZwlGcJxU4Tg1KM4yScZRkm1KMk0002mmmnYKKKKkoKK8 F1n9ojwVof7TPw+/ZUu9L8UyfEP4k/Bb4p/HbQ9Zt7LSX8GWnhH4ReM/hV4G8Sadq2oy63DrkHiO 91b4v+GrjQ7Sz8O32mXOnWOuS3+r6bc21haanxXxu/bc/Zt/Z48e6N8Mfif4w8Vw+ONW8JSfEK+0 PwH8HPjV8Yj4F+G0WsHQH+KHxf1H4PfDzx5pPwQ+Fv8Aa0Oo2i/Ez4w3/gbwJJ/YPim4j8QNa+E/ Es2lOK544OUfeWYSxUMClrLFzwWJx+DxcKEPjqTw+IyvMadSMYuUfqeInb2dNzK5ZKeIhyy5sJHD zxSSb9hHF0MHicNKq1pCNajmGCnTcmlL61Rj8c1E+r6KZHIksaSxOkkUiLJHJGweOSNwGR0dSVdH UhlZSVYEEEg0+k7rRqzWjT6ERkpJSi1KMkpRlF3Uk1dNNaNNaprRoKKKKBhRRXMeGfG/gzxo3iNP B3i7wx4sfwd4n1LwR4uTwzr+la83hbxnosVnPrHhHxGulXd0dD8T6TBqFhNqWgamLXVbCK+s5Lq0 iS5hZxO8nFayVOVVxWslShOlSlUa3VONSvRpyn8KnWpQb5qkExuyTeilNUot6J1JQqVI003vOVOj VqKC95wpVJJcsJNdPRXkw+OXwtPx0b9mseKP+L1p8KB8b28F/wBieIuPhe3i7/hBB4n/AOEj/sj/ AIRM58V/8Sr+xRrp8Q/8vx0n+zf9Mr1miL56dOtH3qVX2ypVY606n1bFV8FiPZzXuz9hjcLicJW5 W/ZYrD18PPlq0akIjdqlSk9KtH2Kq03pUpfWMNQxlD2kPih7bB4nDYujzJe0w2IoV4c1KrTlIorz Dxb8Zvht4G+Ivwo+E/inxJ/ZXj/44XHja1+F2gHSNevR4nn+HXhlvGPjJDqun6Xd6Jon9jeHEbUd /iLUtITUMfZNLa+viLU5XwN/aA+Ef7SfhDVPiB8EvFjeO/AumeNvGXw/TxhaeH/FGkeGte8Q+Adb ufDfim48E634i0XSNO+IHhOz16yvtKsPiB4GuPEXgLX7zT9Qi8PeJdU+wXhhIvmlOMfelTh7WpGO soU+enT9pNLWMPaVqUOd2jz1acb804pptJKTaUXVjQUnonXnSq140U9nVlQoVq0afxulRq1EnCnN r2SiiigYUUUUAFFFFABX4K/Gbxt+yv8AtBf8FAv2sNJ8UeN/Dnxa+AHww/4JY/Ez9n79sd/hJq9/ 8Sr34T3/AI6+P93Z6/8ADrxzbfCMeJvFvg34hR+FvCvjrVLjw+tlbeMPDdl4b1PXbmx0+HTjdp+9 VFc9ShGriMPXmozWGw+eUo0Zxk6dSpnXDmccNTdflnCcqFHCZ3i6zo05UqlWtChbEUYRqRq6KrKO Hq0qU6lGtUxeR4mGJpySnR/sXiLKeIo+zi4P99Wr5Ph6MKrk40ITqTdGtLkUf5OvGXi/44fHT9nP 9rv9kz4E/tJ6V/wVQ/ZN+BPhP9jb4seCf2g/hv4e8H/Er4qa74e8A/tG+F/E3xv/AGJ/iH4y+BVq vwV/ai+KL/AT4aDxRp1n4G8IeF/iTremeK9P8J/Frw34h1H4jeG9f1f7h/a5/a7/AGU/+CgHg79l 74G/sUfGv4c/tO/GLxB+1p+x/wDG2w0v4FeKLLxt4j+AXw0+Dvxv+HnxP+J3xb+Mtv4auJNT+AOn aB8OtP1zwd9i+Kv/AAgut654x8U2fwssbC58U6tc6In7m/8ACQ6D/b58K/23pH/CUDSB4gPhv+0r L+3xoDXraautnR/O/tEaQ2oq1gNS+z/Yjeq1qJvPBSsD4jfEv4c/B/wXr3xJ+Lfj/wAE/C34d+Fr eG78T+PfiN4q0LwR4L8OWlzeW+n291r3inxNf6ZoekW89/eWljDPqF9bxy3l1b2yM008aN2wxHLW y/GV5yxH1LOcrz6GJrTp/WMbmeTZrh8QnjcWqajXoe0yfLcul7OnRx3NhMwxeNx+Mz7MsZmi51h1 7PG4PC04UXi8Fi8rp4SlS5sNgsLmmT08C6WFwLbUZVY4ivmCoVJVMFNYrDYOjgqWT4XDYA/k0+PP h3xp8F/hx/wU0/b3+FGiaxr958Lv2zf29PgN+1J4O8O2Rv8AUfH/AOyL8Zfhd8MtP1XX/sCfNeaz +zh8TH8L/GrR70bLnTPA1v8AGDSbeeG18W6mlx+43hH/AJQx+GP+0Ymi/wDrKttX6Ma34x8I+GfD c/jLxJ4p8OeH/CFra2t/deK9b1vTNK8N21jeyQRWV5Prt/dQaXDa3ct1bR2txJdLDcSXECRO7TRh ujryK2WOXDGZ8Luq4LGcNcK8NUsTKm74Cnw1w9nOTV5UsIp04OhmWZ53mPEEsK5wr4fMMbmFOrjc bHEUp4Tpw+IjDiDLuIl+8lhc64pzupQjNcuN/wBZeIMqzqgp4hqpP2+X4LKcJkkcVadHE5fhcudH B4L6pUhiv5mIP2fP2g/Dv/BM4ftw/FT9pjQ9a8c/s8/8EV/ix4a/ZF0L9n74Q+Jf2dm+DP8Awsf9 mXwv4s8R+PvFvjbVPjr8afGvxE+Llpb/AAx+GWkeFvFfhfVfhF4U8MyaHr+vWPw9bXPEOn3nhn6S tfBXiX4efFv/AIJYfDbTPj5+1Lrtl+1B4a/af8RfHvX/ABl+0r8ZPFOu+P8AxVqH7H1lqP8AwkEN vqfi9/C3w+h0bxG8ni/wZ4L+FHhrwF8NPh14rdtb+Hngnwrc7dv7q1h+JfE/hrwZod/4m8YeIdD8 KeG9Kjjl1TxB4l1aw0LQ9NimnitYZL/VtUuLWws45bqeC2je4uI1eeaKFSZJEU+1mVaGZV+IJzpc mGzuphvZ4bncp4HCrM+JM1zHDfW0qdfE/wBrYrPqNXGV5OlUqVsqwtat7eUcOsHwYOhUweXcO4KF e9XIVWlLERpqnSxdeWD4aweFrQwSk8PglgqWQYn2VGl7Sm3nONklCc8VPG/zbfBX9pf9obVrbxB8 PfiH49/aQ1zV/wDgjr+zT+0XB+1zN8JdRPiD42/H/wCOoj8a/Df9l7XU03X49Q8FfGDxZ4l/Z18D +Kf2lIfCXxKsvE/hC9+IvxL+EvinxP4a1HUNN06Sx+WPgP8AGHWP2lfFv7U/wG8F/FC6+JHwh+MP /BK34z/E/VdG+AX/AAVh/bF/4KKNcfHDwZ4p8IR+GrK3+L/jDwV8I7r4BfFtNO+IU2kfE39nv4Ae IZfDuveH/EHhO08eeELDw3qPgqy1z+wyivMxeGnj8PjqWNryr1MwyHMcrxNflUHUzLN8u4pw+OzS dKDVKWHhmXEOAzDLsq5VTwNPhjI6MsVicfhaObUfSpVlhqmHlhKfsKWDzrLswwdFSclh8uynNuHc xwGUxqP97Nwo5NmWGr4+pOVarPiLMqlOnQwtSvl+K/j3/wCF2eHPB37JX/BKbR/gb+0V4e1X9i3x P8GvFh/aS+JXxO/4K0ftR/sufDfw/wDtXeGfg58EB4P+BvxC/bv+H1r+0L8XfgHLoVpqPxP1Lwt+ yrYa78Hfh9qHiPQI9Ca2tZdD07wN4g/aX9mL4xfEDwT/AMEufGXxj8e/F/Q/2mZ/h14G/aK8ReCf iT+xJ8aNO/bW8T6/8MfA+s+OZPhx4e8DfGv4ifDbwfpH7QHxz+HnhTTNN8A6v4w8ffD+4/4Tj4h+ E7jV/iFba7q+peIjd/qPonifw14lbWk8OeIdD8QP4c1y98MeIV0TVrDVW0HxLp0VtPqHh7WlsLic 6XrlhDe2c17pN8IL+1iu7aSe3RJ4i+5XoZrXq5lSzt0pfVauefWcThsTD344X+0ZVcXhsQoQ9jHH fUaeIp4TJ60pU3hsip4fL4TqRX1mXDldCll0Mkw8o/WaOSToUMRTnaNTGwwPtsPXw9WpJVZYapip t1s0hCLo4nNY1MdUwsavJTo/x8/AT9r/AMcaz4l/a+0v4Q/HHTda8A65/wAEjP2jPjs2q/CT/gqV +01/wUt0/wAM/Hf4e3WhL4d162+LXxm+G/w60f8AZv8AjZ4X0j4iXUvjP4RfAfVm03TYNS8CeIdf 0DwzDbfDi5v/AKf8eax+0x+yprtxp/7OHxj/AGm/jf8AFH40/wDBF79q39pW40H4zfFr4j/tBXfi f9qb4Nap+z9/wr3x98Nfh74nu9e8LfDnxJqMvxq8X2dx8MvgV4K8C/DjxTPF4T0e2+HsZ0bTI0/p nrD1DxP4a0nWfD/h3VfEOh6Z4g8WSanF4V0LUNWsLLWfEsui2LaprMfh/TLm4jvdZk0nTEbUdTTT oLlrCxVru6EVuDJWVRU267p01CFfLcZlvs5zqTj7PEUPEmjh4ylCdGo8Ngpcc5JLDYSnUpQow4Iy elhZ4ZLL5ZN00ak6dSjUrv6yqeZYLMZwqK8K1TC1PD2VSM1N1OaeKjwXmsK1ap7WpUXF2ZSrvESj jHmv82f7DGt/sy+Iv+Cof7MWo/ssftX/ABd/a48Ix/8ABMj9o6Hx543+IX7Q/wATf2qdF0r4oXHx g/YnvNegi+K3xG8QePo/CfxS1zTZNI1T4rfALwt48s9D+Fip4N1eL4R/DOXx8+oeOvc/+CnvxK+G 37PHxl8WftJfAn9tHw7+zV/wUP8ACn7Peg+GvDX7NvxV8PWviv4bf8FA/BOkeJvF3i/4W/A7Sfg/ rNhoPxJ+L3ju58fah4o8F+D/ABf+x745g+KfgDX/AIgnQPGWneJLLWtD8JXX760Vvi68q8cpVCVT Bzyqrm9SjXpewnUp/wBrZzxFm0qeGo1MO8BToYenxBUyyOCxmBzDLa+X0JYXFYGthsTOhDLCwVB4 xVl9ep46jlFLFUsVKcli/wCyMuyLA06mLqwnDFVMRXrZFh8zqYyhiMNjqWZTWMw+KpYijTqn83Hx e+Mv7S/hz9pG6/YEuPGfxt8FfED/AIKceKf2e/2i/gfrX/CceO9W1P8AZq+GWiaPpF7/AMFFfg/4 N+Jmm/Z7r4dx/DHw98K/tnw5s9Mv9GsbfxN+0RYL4YNk0Fzb2Pid3o3xb8U6Ro3xfk/a/wD21dD8 Z+K/+C8Hxt/Y/kj8O/tO/EvT/BWi/sueJf2ifjP8KNT+DOi/C+XVLv4ZCxs/D882oeDfiJq3hHVv jV8MNZi0JvhZ8TfBWj+CvAWjeFv6Pb/9nvwXqv7Sfhv9qTVNS8Tah498G/BrxP8ABLwhodzeaU3g nwz4d8ceMPDnjLxrr+k6YuiprMfjDxVd+DfB+k6tqdx4huNP/sHw1p1lY6RZTy6nd6h7tWNBU4VM uxM6MH7GtXjicvd6lCOVYbjDhzE5fkdCrVlVlLLa3BPCNDIMV9ZjicTXlxTxBWx9fF0q1bL8Qqvt 3hMwwFLEVIfWMPQVHMLR+sSzCvwjxBl+ZZtVUVTm8XPijib+3IQp1KGHoVeG8rhgqVCbpY6h/Lrq mr/FhPGun/skaZ+0n+1Lo3wv8Hf8F4dH/Zp0zxBb/tE/FbVfjTf/ALOnjH/gnRqH7RPiP4MeJfj3 4n8S6/8AGDxT4XufHXjLW7fSNb8QeMtR+IHg7So/Dl34I8Z+GvFvgjwR4p8O4+i23xT+EHh/xl8V tE/am/bC8Ua5+z3/AMFwPhX+x38LNE+JH7UHxg+IHg21/Zl+K37Rvwb8G+L/AIV/EPwv4k8UXunf HkHRPj14xg8PfEX9oFfil8YPCCaT4Hs/CvxD0fS/B2kafF/UXoPiHQfFWk2mv+GNb0jxHoWoCZrD WtB1Ky1jSb0W9xLaXBtNR0+a4s7kQXUE9tMYZnEVxDLC+2SN1GvV5fUeDxOWYmq5Yz6lLIKuKVSb UsyxGT0fDPDYnEYirL2spVc0w3BHEmHrzq/WJRoeIWeUqksTD6/HOqzD/baOIoUrYSlXjnMYQppS hQhmtTxFrU4Uox9moxwdXjXJatNU/ZqVTgvKpwVCUsG8p/kw0X49ftI65+2L4z0rxx+09+zh8Cv2 o9D/AOChGq+EPB3w8/aJ/wCCtnx7+BXiPXv2bLT4w6f4Z8DfC/wb/wAEpH/Z91D9nL4q6F8a/wBn G8trf4V/E/TPFXibxx40+IvjPT/idp3xU0zxtoieHPDnG3qeBvgL8KP+CsHgz4L/ALTvx0+FH7W2 nf8ABTn4Q6RN4bg/bD+Nfin4u+C/gV8Wf2qv2KdL0z4tab8Hvi98TPHmhfZ/G+k+MdQ0KP4z638N 9aX4g+HNSPgHxJ4g8VeDJp/C0n9gNFYYCCwcsrlNKu8Bl39nYiVlTljISzLgnMa0lKXtfq8cXLhC vSx1D99Sxb4iznFVV9cxmOr47TFTeIxM8RG1Nf2/g89o0HarQovBriaFLAuE1+8wuHp8SOOXxlaO XrK8tp0oTw2Hp4en+B3x/uvj9+zN8ePjd8Jf2P8Axd8dfHPiTwR/wR8/aD+LXwV+H3xK+M3xl/aQ 1LXf2g4Pjjbf8Ip4pmHxu8Y/EzXfHPjaC4vDo3he01u41cppclp4F0i2tfDLw6Mn09/wTa8b/sge MrPVb39lP9tX4ufta3V78K/hbrnxbt/Gn7THxM/al0Hwv4t1WLV5bfXNf1P4h698QLf4AfFzxPJ/ bCeK/gF4V8TfDrSdIs9Lt7j/AIUtoSaXaagv6p1h2Pifw1qeua94Z03xDoeo+JPC0eky+J/D9jq1 hd654ci1+C4utCk17Sbe4kv9Ij1q1tLq50l9Qt7ddRgtriazM0cMjLeFc6FGnSrTeIqQp42m8S3K NeosZn3FedKlNznWg8NRp8Q4DBLDqCU3kGBxbnGpRyyGUYYimqtapVg/ZKeKoYn2bcpxcqeR8L5R OVSXNCpVxLq8PY3HUcU5KdJ8RZxh6kcRDF42eN/B7/gtR8Eviv8AtE/GL9gL4Q/BTxu3gj4h+LP+ G0YdKE+rah4c0Px5p9l+zut/4g+EHi/xb4ejHjXwV4M+L+gW2pfDjxR42+HmoaL4+8I6R4kufEPh bVodS0+OC5+Z/wBpn9tpfiH4J/YKPw1tfDX7KP7Ium6f8fvhP+0p8K/ip+2p8V/+CWfhT9nX9p/4 I6P8P/DPw9/ZY+Mf7VP7NHwz8eeOPhNfeEtKm+JmpfDv4aWUnw08CfG+x0Pwt4hsfEuvaAnhHwz4 l/p91HxDoGkahoGk6trmj6Xqviq/utK8L6ZqOp2VlqHiTVLHSNR8QX2m6BZXM8VzrF/Z6Do+ra3d WenR3Fxb6Rpeo6lNGllZXM0WxXPGjKFStLmjOnXr4fFyo1qUakHiMNhq+CpOTbTqUadHFVsTh6FT njgM3oYLM8tlg6ks6pZ5spJOnKz9pS+t0ozjOULYbG0sP7eEVFr2eIliMFg3UxNNwWMy/wCs5bmV HHwhk1fJf5g7v9q34w/sSfs3/sp/8FBfil+0Zo37UfwE8PP+0j+zJ4+tv2Zf2k/G/wC2d8I/Eng7 x54v1/U/2LfFdx8SH8B+BJfjR8avhv4/8B+FP2UfiD8bbzwPZeN/E+pfEXUNX8a3up36a9f2/wC8 X7Gvw9+K3wt/Ze+C3g347eNtd+InxttfBdnrPxf8W+IPEOseJ7m++Jvi24ufFnjiy03Vddubq/Xw toPiTW9R8P8AgzSw8VloXhLS9F0XTLSy06wtbSHpPj7+z34L/aO0T4f+GfiBqXiaDw34A+Mvwv8A jaNC0C80q007xj4i+EHiW38a+C9A8aR6loury6j4PtvGem6B4ovdM0qbRdQvNU8OaQjaumnC/sL/ AN2ruhVToY1TjN1KmaNYONWo6zw+VUsJSxjqe3dqlbHZrn+bZ/ic2rYjmlVWFytUIYajR5auNSm/ rGHnTcVT+qVamLUKcaar5jWxtejSSpr3cPh8ryXB5XgsDQwkaWHUK2J5oynaNEooorE0CiiigAoo ooA/n8+HH7H37WHij4ueP9Q+I2i/tdeBIfFviPSfCfxZ+Kt1+2tczyfEnw/a/tK+JvG/iXW/2bbn wL+0Brfj/wDZ1+CviT4S6joGiaf4H8EaN+z14l0OO01C20D4beEvFWn2Xi3XeY8A/sdftl/FD4g/ tN+F/jv4W/aV8I/BPVP2if2XvH/wo06L9s346wI9n8PP2tNe8Q+PPEPgL4jJ/wAFNP2hPicdBs/g fcaV4ha0svAv7F2h32s2Hh5/Df7Ndj458H+GZ9E/oqoqMvhHLsPleFp/v6OU47F4+jHFWqrEVMVm WX5sqGKjFQhLCYPH5dTr5fhqMaNPByrYh0VGUqbpPGN42vmGIqXhUzGnlVOo6ba9isrjUpc2HlUd SoquZYWp9SzitVnWq5jhIQpVp6OUvwCsfhl8ev2NP2Rfi74a034lan+z94Qn+N/7QfhzSNG+P3xO +IXxp+Nfxv8AH3xi+N2tf8M7+JP2Zv2lPEH7cvjD/hVOj+N9L8ReDNOj+FHib4Rn4l+NPiHD431f UfDWgeMPGuoeK9ck8Pfsv/twePPEvjPQfGU37Znw30HxP8Sfhzp/x78Yy/tx39vpXxkt9K/aTufE Ov8AxE/ZGsvh3+0Frvin9lv4Q3HwJGseHfEfgrwdo/7Mnj290zxL4Z0ay8BeIfF/hGPxtp3780Vc PdxWWYup/tFTK61KcKVf97hsbRoywVZYXNKU+aWNw88RhZznhZVYYClSlhKWCwWDllWXVcPFaLq4 fMsLGc6EM0ounVqUZyhiMLUc8S1iMBUT5cNiIQrUlDFezqY6dSlWq4rF4n6/jYVv55NK/Z//AOCn Hh39ob9n/WNY8U/tL6l8JfBfwo0fwreN4I8eeHPiHqGk2fha1+I1hruhfEjWPin/AMFJvg74C8Z/ Ez4j6dL4Tt9N+KvxL/Y6/bR8Y2Woz6N4juPi/wCA9ch1i68N9jZQftkfAP8AYMhHxJ+LEXwHcy+M PAEPhf8AaC17x/44/a3+J3xJ+IXjj+xfgk3hX9orU/8Agpb+1R4Z+GvjDxFqep6Vo9n8LtE8dftB ReKmhWTwRL8Hf+Eoh+F3w9/eqijCuWGVVOpUxP1ivVrV6mKm6tdxxONni8VThWdmozdfE+xpV44j B0cXWWaSwdbMqVPEpYmEcRGKt7H2dGhSpqh+7hfCYOrhMLOcF9qCnB1alGVDE1qFKOBWJp4L9wv5 zPGXwF/4KC33hD9oOO08G/t4xeL/ABA1hp3iK50P9r/w14m8PfG/4m6V8cNa8TeHPiX+zr4SsP8A gox+y94g/Zt/ZxT4ZQTaJ438B/Dn42/sT/EnULbxH4I0O78BfEiPwl4mnvfZPhr8Ff8Agp1Y/trf FPxhdePfEfgPwJr/AIHu0+Hut+ONL8Q/tGfsxeHraTwV4HsfDHw91/wrc/8ABUf4beJNe8Q+EPEV lreoaj4v8GfsKfBn4g+MNZt7x/Fn7UXizQdV1CLxT+59FZ4SmsJSjRhKpUjHC4vCRlVqS9ooY2gs NUqRqUnSnCtQw6+rZfODj/ZWDlUwGWRweArVsLU0xTeLqyqz9yU8Xh8W400uR1MNLCShTlGoqntK NSeCoVcXSquosdiYrGY36xjIUcRT/n50SL9sL42/G3QvH3we8f8Aj/4y6H4W+MX7Qvg+4+MHw/8A iu3hj9ijRfEFh8LfBvgWXW38A+Hv27NP8YXg8C/G7w34rFh8J/G/wD/bo+Hum3cOreB2n+FfjK78 WfFq2yPCX7I37aHxF8EQ6FrkX7fPwP8AA0us6p4m1PwJ48/4KK+Jdc+N198T9I/Zg8baJeeIH+Nn wh/ah8a+ItN+CPjj4/XPw51fwZ8LfC3xc8OeHNO1jw1q+r658Ivhn4K8Qa5oGtf0O0VKpNZY8ujV q05yyrLcu+v0HHDY2hWwFGClmOBnQhTp4XFYjGwjj25U6/LVw2WKcq0soy6pQpTazCOPSuqeZ4/H U8JOU6mGqUMZjMXiIYDGxqTlPF0aGHxU8IpudOapzxjwywkMyzCliPwz/bD0z9tJNJ/Z58JeOtQ+ JvxyX4i+Jdbs9O+Cf7EnjfXP2I/j5Fd6D+zn4412ey+JH7Rd5+2v4I8I/EaDQvihp/hvxZquo+Ct Z+BWltouh6xZweC/iRZ6l/whes+hW37Ln7aL6F4g8R6j8Xfi/L8dvEtt4lhvvEEH7QXjCH4Q6brX g34GaH/wqu78LfCS08aaf4H8PeD/ABD+0BBr2q+KrbTfBFj4r8TaPrV1o/jmeXwVp/hjSND/AGKo rrqVZSrZtXpqGGnmuGnheWhTh7LLozrYOt7bLaVWNWnSxXLgaWGrYrERxNbG4R/V8wni6dLCrD8t LDwp0cpoTlUxFLKcVDFRjWqVG8fyUXSWHzCUJQc8IpyeKhhcJ9To0MXbE4eFKs5Tl+AXxw+FH/BS nxVdfsR+MvCngn402HjjUPitf/F79oKHwt+0Zrr6N8GdM8cfHzwJ4vm+BvjXwtoX/BQn9mj4K+Jv B/wv+Cw1fwIuvQ/BH9vHRvEl74f1228MfDbwofEB8T+NPDU/Yy/b9+F+tfCHwz8Crb9rnwJ8NfCP 7S/7RmseJmufj/qv7QN3fXHi/wDaLg8X+B/jyIPHf/BWr9nm0vfg7qvwdnsbE/DX4seHv2jI5/HM PxK8U+M/2Mh4w8V3/i34l/030VNGaw9TBToQjShgMdi8dQw8XP2D+sVIzw+ErQc262CyyFOjTy2h OTdCeHw+Oqzr5ph6OPhpVg61HFUqs5zljMLRwuIxHuxxM/Z/WXWxCqQjFQxOMqYzEyxNWEYpUK9b LsNDD5TWrYCp+IH7Yfwn/wCCmWufFn9lfUvA+ov8TI/C/wAZbfxB4t+IX7Ns/wAUv2cvBXhf4ZH4 q/Ce9k8G/F34PeK/+CrvgHwR49e2+H+m+PZtT+IWvfCD9sa38VJcT+F9C/Z2+FL7tY8acb4h/ZX/ AG0fCnhzxhqUV1+2f8WdM+JPirTvF/xv+Hvg79ufxB4f+KHiTRtI/ay8c6vpngX9m7xX4q/aP+HP hn9nRrb4D6x4Oa/s/hN8RvgBpfi/wV4fm8L+MfF2q+OmNne/vjRWFKn7GGVwjKUoZXj8Vj1GooVK eP8ArXLfB5pSlB0sdgYTo4Ou6NWClisVgcLjMwqYzFqtWrbVZuq8W3eDxeHwmHcqUp0quHeDxX1u licHXhOOIwuLU516NKvSqp4LC4mphstWCpU8LHD/AJD6P8CP2yfBn7Cfg/4V+G9b1vwu+ifAfx54 S8afCPwNo9n4t/a71nx5r2qeIP8AhFdR+Gn7U99+2n+zv8L/AApfaXHqemX/AIsvNR1Gx8VeIrSD W5fCHxo+GPjO+0bxFoflnwy0v9ray+K3wJ/Z91XVfiZ4WbUf2TrP9oX4oeHNS+Nnjbxl4q8G/EL4 WaD43+COleANe8W+LPjt8fvEmnW3xt8VfEH4V/EwaJP+0J8ZtEg8TfAT4q6bqXxe+KC3V3428Sfu XRUV6CxCxFKpOqqGMjVWJ5Kkni1OOD4gjl+IwuPrOtiKOJwGbZ3RzaFas8VKayrCYBeyw7k4uhUe HjRdONN1cNGlCg6lNPD+yeLySWPo1cJS9jRlTx+WZRVyuoqH1b2f9o18bepiKdJH4ZfDr9jX9rv4 aXvgzxNp3xJ/az8WeI9G0T4H3mp2nxH/AG1fiN4/8PXni7xz8F/HfhT9rO41fwp4l+MV74Q1i3h8 a2fwz8QeENFn0i58IfDTxXbT69+zro/g6w1rx4usnw6/Y0/bJ+Gt54M8S+Gfix+1BrHjfR9E+B92 bj4w/tkfEX4o+BYvHvjr4LeO/Cf7U+reLfAfif4n+KPB/ifRdO8e2fwv8UeH/DFx4P1/wf8AD7xD ZXur/s6+FPDthr3jyz179zaK6cTKWJlmsnKVB5rmeCzB/VZSw/8AZ+FwTqOWQ5VKm1PA5BjvbV/r +XwlJ1/b1HGvTbi48lGgqMMvg51K6y/K8blr+tOOI/tCrjVZZxmkakXDG51grU/qGOqRSw/saS9j NQSP5j/g3+xl+3ddaN8B/FP7Qukftm+PPG/wh/aW1PWNP0mz/aN1j4WXnh6DxV+zr4+8I6x8a21a 4/4K/ftW3fxP+GNz8Wn8ATeIfAeveOfBa6L4QPi3w58Mv2RtL8H/ABB+KHhzxZ9WeJv2bv2ofAdj 8J/D93on7c37Qnwcs5fh7qHxV8IfCv8Abr1bwZ+0HrfxIvfh94mvvEfjd/i746/as+B2sJ8M/Dfx Pvbv/hNPhR4N+MPhDwtqa634MtvA/gHX/h74ETwjZfuJRV+2leu1GnCNfEZHiFTpQjRo4f8AsFVv q9LCUqShTw0MVOsquOnSjHEVKuGwMqFfDfUcIqNeyVsMnOtP6tTzqCdStUrSrTzycZ4mviZ1ZTnX q4e1SGEjOTowhiseq1Gu8fjZV/yV/ba+AH7d/wAUtT+HWo/Db4h/D7WvD3g/45ar4y0nQvhz4P8A EfwL+LHhr4IXPwJ+MPg/x78Nb34561+0f4t+1/FX4rr4n0z4ceB/jd8OPA3w0vvhLrHiL/hNYtBt 5tPh8aeEfmbxb8IP+Cgmm/tMftXfE7XviZ8a/hp8Ez8IvH3jL4WeLb3xalx8IPCdt4V+HnhfXvhZ 4I8XXbf8FG/ENnoOr+C/G3hyTVPiZr3gn/gnT4c1fxzZ23i3wz4u/ac+IXgjxJqU3iv+gOiuOVOv BV54TEOjiZZbjMBhatalHF08LUxeDhgvrzpVHGpicTSpUqfK6+Ies8fKDp1M4zipj+mm6N8PDE0n Xw1LH4XG1qFOo8M8RHDYqni5YRSpR5KGHrzpxVWnRoxhJU8FzwmsryqOC+Vv2KtW+IPi79m74efF H4px+I9P8dfG621L456r4T8T6pc6nqHw2034uard+OfCHwoVZZ57XTk+FvgnWfDngK6stKEOnSap 4f1HUkja51G6uJ/qmiiu3ETo1K9WWGofVcLzOOFwvtJVlhMJD3MLhY1ZRjKpHDUI06EJuMXKNNPl jsuXD061OhTjiK31nE258VivZql9axVRupisT7KMpRpPEV5VKzpRk4U+fki+WKCiiisTYKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKAMbxHd3Fh4e16+tJPKurLRtUu7aXYknlXFtYzzQybJV eN9kiK2yRHRsYdWUkH+ZvwB/wUZ/a51v9mP9l74b3fxr0vWP2t9O8cfszfF/9pn4jt4B+HGl6n4h /ZK+Ovjv4FXPgqW18CWvg648DaLd/Edv2jfDnwUTxNo2geHP7Rn+DXxz17wfPofinQVXTf6eZoYr iGW3uIo54J43hngmRZYZoZVKSRSxuGSSORGZHR1KupKsCCRXlVr8BPgXZW32Oz+C/wAJrS0/4R34 b+EPstr8OfB8Ft/wifwb1i78Q/CHwv5EWjpF/wAI78K9fv77XPhvou3+zfA+sXt3qfhi20u9uJp3 eFfscTXq1v39GpUySdOhJL9zLK8TmWLrzpyd0njKtbLsPi8PVhXwWYZdRxmDxmGlVngMXgHVtUoU 6cb05QlivaSjZOvTxcMNhJ0Z1EvaU40sHLMK+GrUHTxWFzP6hisNiKPsq3tPygi/4KL+OvDvxn+C 3g1dO13xPbfGf4s/t4/Azw/ovxB1jw1oHgGx8dfBP9urw98DPA/iD4g/HHwX8DbDT/hj4Vg8H2/i Twh8I/C+p+HNa8UeP/Gfir4b/CTUda+KvxR1hPiRc+8fsvf8FFfEn7TH7Snjv4Raf+zX8Q/Dnwf0 O++Mei+Dvj5L4L/amh0HWNe+CnxDHw317T/F2vePv2RPhl+zZp0finV7DxLd+BpPg7+1T8fr/UrP QZLfxBpXhfVX1DTtI+6L74C/AzU9N1TRtS+C/wAJ9Q0fXIvG0GtaVffDnwfd6brEHxK8YW/xC+I0 OqWNxo8lrqEXj/x9a2vjjxtHdxTJ4q8YW1v4m10X+tQx3q4Hhb9lr9mTwP8AF7xR+0F4K/Zz+BHg /wCPXjiDULbxr8bvC3wh+H/h/wCL3jC21eexudWt/FHxJ0nw9aeM/EEGp3Ol6ZcahFq2tXcd7Pp1 jLcrLJaW7RvDuNOngqNdOqqNLPfrFbRVKtbGYupicngkoxnOnl6qVITrVa7n7OdPCxo1MLhcNTgs Z+9xeZ18J/s1HFZhh6+Dw0vfWFwkcXiZ4iipP3KangJYLCwowpTSrYati/rEKmKmo/LHx8/aw+Jf wT+OHxT8K+GvDOn/ABQln8C/sP8Ahn4OfDPXvEun/DPwkfjB+0p8d/2jPhff6141+Ktp4I8ceI/C /hKWx8G+EJtYu4fC3jy7tU8PR2PgvwTqfifxE1hq/h3ij/gpl8edLtz4d8Nfsj/DnxN8U/AfhP8A az8Z/HzQ7n9qnWdC+G/g7Sv2P/Enw50Tx1afCb4j/wDDMuq+IPi/q3i20+J2g3Hgm38Q/DD4P2Ka zZa74d8bal4Mn0xr2X9ET+yh+y0dB+MHhY/s1fAE+GP2hddu/FHx98OH4N/Ds6D8cfE2oXJvL/xF 8YNIPhz+z/iXrt7eM13d6v40t9a1C5uWM81w8pLVt+F/2df2ffA/hnQvBXgr4FfBzwh4N8L+CvFP w18M+EvC/wAMfBPh/wAM+Hfh145v7PVfG3gHQtB0nRLTStI8FeMNU07T9S8U+FdPtLfQvEF/Y2d5 q1hd3FtDImNP2sZynUcKi9hinTo8vLTWJrZZThg4VJw5as8Nl+b061avNShXzXB42lCCyiWVSp5z rOVKeJhNRlDDOeEhXjFr2sqGHm6OJrUr3p0sVmGE9hWpQcZUMtxuGxHtlnUc09rlnwLoP/BTHxD4 z/bBuP2dPAX7LnxQ8Y/DPSPEtp4A8UfGXSPBn7TN1L4c8dX/AMGdL+MdsNR1Ww/ZQ1D9kDTPBUdt 4k8KeENR1rxL+2/4c8c6d4k1rdN8MTpC6bqWsfRv7Fn7TnxA/aV8KeO7v4s/Cvwn8DPiT4B8ZDwx r/wl0jxl8Z/E/irw5azaXa3ljqHjCz+OH7L37K2v2Y1W8/te18PeIPBPhj4h/CPxtp+jza98Ovi3 4z003L2Po2tfsgfsl+JPijY/HHxF+y5+zrr/AMatM0QeGdN+L+tfBL4aap8UdP8ADa6DeeFV8P2P xAvvDM/iy00RfC+o6h4bGlW+rR2A0G+vNHFv/Z1zNbv1PwV/Z5+AP7NnhjUPBP7OnwN+D3wC8Gat rlx4m1Twj8Ffhn4L+FfhjUvEl1Y6fpl14g1DQPAuiaFpV5rlzpuk6Xp9xq1xaSX81jpun2klw0Fn bxx9FJ0owqqpGUpvDKnTnfmX1mniqbWIjGPsfYxr4RV3Wo1PrqpzqYbDUZJ4SvmGY8jjX/c/vIO1 SEqyUOX939XxEalGLcqntJLESwrjWX1fnVGvUdGnHE08LhPYaKKKzNgooooAKKKKACiiigAooooA KKKKACiiigAooooAKKKKACiiigAooooAK/Mb/gpd8cfj58DbH9lnXPgP4sm0A3X7QGr678WvDdv4 P8NeMLn4q/BX4R/Ab4yfHL4i/Cixh17SdR1DRNY8b6H8NJtK8PeIfCV1o/iXSvEL6VNBe3Nh/aGk an+nNc9rfhHwp4mvNA1HxH4Y8PeINQ8Kahe6v4Wvtb0XTdVvPDWq6loWreF9R1PQLm/tp5tH1C/8 M69rnh29vdOe2ubrQtZ1bSJ5ZNP1G8t5on7VJToOmq9GpSxGH9vGVTDvEYerCvQjiqMZRWIwsqtO EcVhajdHF4d1MNXhUo1alOVwdO841lUdKrRxFCboyjCtGOIoVKDqUKs4VFRxFP2ntKFdQlOhVjCt TXPCLX4Z6D/wUm+L1/8AEr9rT41eCdc8BfGL9m1vhl8BfEP7Gfw2kk8dWui+O7HW/jf8T/gL4i8d aH4q/Z2/Zh/aZ/aD8ea18YPFvgXXNc+HnhvwV8LPixpus+DtP8CXeg6b4eh13xT4hh+g/hB/wUp+ InxfsvgNLpv7M+n6FeePPCH7VXxC+NVr4n+I3xY8G3fwp8I/sjfGvw98FviBD4H8HfEb9ljwL8YP iH448Saj4ls9c8FeBvif8Kv2c9QktbTUNM8X3fg/U0sor/7x1/8AZY/Zi8V+Bbj4X+Kf2cfgN4l+ Gl34H8HfDK7+Hev/AAg+H2s+Bbn4bfDrVW134ffD248Jaj4eudAm8D+Bdcd9Z8HeE5NPbQfDGqs2 o6JYWN2xmPRfDz4D/A74RWHhTSvhP8GfhR8MNL8B6Dr/AIV8D6b8PPh34Q8FWHgzwv4r1jTfEPin w34Us/Dej6Zb+HdB8S+ING0jXNf0fSI7PT9Y1jStN1PUbe5vbG1nitRUaToxqTfsJY2GEr14Qq1q 1CeEziOAqZmqcsMq2Ip5hicqxmOWGnhoV6eFr4TBvL8L7KiKclKtKvype3xGDniKFK9GhRw9PAZd hsXRy9SeIdByr4fFzwcsQsVOn7RYnMp5ri8RXnH8x/Fn7YH7dniDwz+w748+H3wH+AGjap+098ax H4P+GA/ao1vWPCnxA+B/iH9k74v/ABk0S9+MHxYuv2O7jVvg54m0PUPD+h69e6H8HPBHxut77WNC s/D1n4/1Pwxrmq6lD9y+Hfif48/aB/ZD8P8Axb+Gt9Y/A/x78SPhXpHi+yn1/RLb4qw/DvUr6xt7 zxJYWdmmqeENM8U6lpUUer6b4V1/Uli0QaqukeJdf8F65pcF/wCCdR7H4dfsr/swfB+5lvPhL+zh 8BvhdeT+ONS+Js138Ovg/wDD3wTczfEnWdB1PwrrHxBln8NeHdMlk8car4Y1rWPDmpeLHY69faDq 2p6PdX8un391by9X4o+CfwZ8b/DC9+CPjT4R/DHxf8GNS0y20TUfhF4o8A+Fdf8Ahhf6NZXcF/Z6 Te+AdV0m78KXWmWl9a2t7bWE+kvawXdtBcxRJNDG645nTeKwWYYfBc+EqYyk1hqssRUlXy6csHGh yUsXh4YWVdQxHNiKmJlhqNSvWip4ejltCo8FTeCk6OIwFXFSjXWFjThieTDwjSxzhjsRiJYiphKs 68KTlh50qFPDKvUjCknRxOIx8qdPFP8AIT40/GP9rzUP+Ccn7K/7UHw6+LX7SOi/EmT9lbwx8W/i z44+FXgv9iLV/gta63dfCPwr481v4p/tWeCfjN4C1L4yaj8JNHvbbW9S17wh+wloknxjvtCvPEmm eC/BGoeID4Lgs/2C8Y6vJqHwl8Sa9o/xD0j4bm88AanrNl8VdT0ywudF8DQTaBLfL48u9L8VXFhp JsfDtux15rbxPPFpcUdoBriSWaXcL+Ey/wDBPn9gm40f4beHZ/2If2QpvD/wavtW1T4QaHL+zX8G ZNH+FOp69rdt4m13Ufhtpj+C2svA19rXiOys/EGrXfhiDS7jUdbtLbVbySa/ginT0PTP2avhDDpP x70LxR4V074m6J+054y1nxl8bdC+J+laB4y8OeO21bwZ4W+G0PhjWvC1/o6+Gb7wdpHw38EeEfAt joN7o90l7oehQTeIp9c1u+1fWNR7MwqQxbzj6vShhY4yvmePy+mk4wwlTE1sPChlrq4eVGtHBKjU rYmjLDxoyy2phauHofWKeYYb+ycsNH2P9lqrKdRYOnSwmKmmqlTGQSjP65KlXjKn9YouhOjVniKu MljfrmH/AHWGWDxlXMPzT8JeOP2qPFWmfBD4M3v7XPxX8LeGPj58ePjenwm/az1f4W/su6N+0t8Q Pgf8NfhZZ+NPBumQeGtZ+Dh/Z2t/EXxG8WW/jzxJ4X8Q237Lgu9a/Zr8E2WoP4V0TxjrFz8Rbfe+ Ev7Qn7TPjE/8EwvGOrfGzwvrXgf42eM/ij8KPitpfhr4X6BYN8bNQ8DfB39pbXtM+Lc/i6+utQXQ NA8V3Xwl8C+NvD3hb4ceGvA8Vne6pr7XfiLxF4T1jR/DHh/7Rs/2Av2ENO+FmsfAzT/2KP2SLD4J +IfFVn461/4PWf7N/wAHLX4Wa5430+0hsLDxjrHw+g8Gp4S1PxVY2Ntb2Vn4hvdIn1e2tIIbaG8S GJEXq/Gf7Hv7JHxH8VfDjx18Q/2Wv2c/Hnjf4O2Wg6Z8I/GPjP4I/DPxR4q+Fmm+Fb9NV8L6f8OP EOueGL7V/BFl4b1SKPUtBtPDN5pkGj38aXmnx29wiyCYuKrU9ZOhCeWU5TnClOvUo4TKI5fiMVVh CNHDyxleqpVa9CjDDYPG4urPOHHBYqGGwtDP2dR08RzTvVrYbNFFQlUp0qOKxuYVMXQjRbnUq08N hlUj9WqTlVxeDw1GGUKpisJKdc+R/hV43/aG8Kf8FB/Efwq+InxI/aLvPg349+Hnxp8UfDrwr+0T 4V/ZAn8NeKtc8F+OfhZLZ6x+yz4p/ZL8H6f4/wBA+Gnw+8MeN9R8P+NNH/bZ1bSvip4nk8QfDq++ H2n+KpdA+KmuaZ+oleEfDL9lr9mT4KeNfHPxJ+DX7OfwI+EnxF+J9xd3nxK8ffDL4Q/D/wABeNfi Hd3+rXGvX11458U+FfD2la74tuL3Xbq61q7n1+/1CS51a5uNRmZ7yaSZvd6zp+5gsuw8verYTCSo Yiq/enXqyxmLxCqVa7tUxVRUa9KjLEVY03L2ShSo4fDQoYelvUfPisZWS5YYjEe1p01aNOnBUaNJ Ro0EuXCwbpym6EatdKpOpV9s3VcYFFFFAgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKAPwr1/wD4KF/tNa78VPgp8NfCeq/Dj4eR/EL4s/8ABQXwZrGt2f7CP7XX7ac9 xpP7KH7aej/s1/Dayn0L9nT40eDLn4P2uv8Ag/Vm1v4h/Gb4mXV38MdL8S20cv2Pwvpl9BpaVvGv 7Wn/AAUP+Fnh79tDxD4z+L/7IviOx/Zo/aK/Z3/Zt8PD4d/8E9P2qfFfiTVdR+PCfsheJrj4jS/D fwR+3h8RPHnxBPhLwt+0f4g0Cw+Dfw90qPxZ428SeHNF1rS/F2nx31x4Ok/QjxV/wT4/Ze8V6n4X 1w6J8XvBWueD/Efxs8U6Jrfwc/an/ap+A+tHVP2jPifD8ZvjPDrWrfBT40eANR8UaD43+JltbeKr jwp4nudY8LaPc21tY+HdG0jSbeHT09nuf2cvg1eT/EK5ufBxln+Knxb+GXx18eyt4j8WBtf+Kvwc s/hVYfDjxU23XQNNPh20+CXwxiOi6ONP8O6wfDPma/pGqS614hfVnhlCFPCKveVSDxEcY1z1adaN XijKsZCok61Gp7SHC1PN8q5KVTCwhia2DqUHSxHtM0pdNWrReZZjXp03/Z9bHSxOAoP2cKuGoU8b i62GwzShVpKmqFalGrGf1lVZRdHEfW8LRwtKl47efHT4ieEf2FvFX7Qmsav4P8XfEzwx8FPHXxCt dS8ZfCH4hfsT+DNc8SaJpmuah4ctfEnwg/ac+IU3j/4J2FxPa6ZpupaV8VviXpUwk83Ub/xJ4Z0z UYbjS/zV1D/gpn+0XoXwr0nSbzV/AGu/F/xr+1Rb/BTwx4/0f/gnl+3i3iDwr8Obb9n2b47694y8 ef8ABMPwp46+JP7Z+n+IxdaB4i8CeEtN8T/Ez4baL4v8P3mmfHq21Sy+GMOjR+Ov3B+Jvw28FfGL 4feMPhb8RtGPiDwP480DUPDXibSY9S1fRLq50vUoGhlfTte8PX+leIvD2r2jFLzRvEfh3VtJ8Q+H 9Vt7PWdC1TTtWsbO9g+U7f8A4Jyfsp23g/VfCK6H8aJrvWPHemfEq8+Kd9+1t+1xqP7R8fjHRfC1 x4H0rUNM/aq1D45XP7S+iWNh4KvtV8H23h7RvixYeG4/C2veJPD40j+yfEmvWmozUcpYjGVVGKhX WBVKlKUlGPss2o4zFKUaEaEKDngqdTCwqYKOHdaNerQqxhSWHnh+enywoYKnrKph/ryqVGm+Z1ct 9hhKn76pWliJUsZGNT2eMlXo0ozqYicMZXUIH0F+z38RIviz8Efhf8RovG3h74jP4t8H6Tqt7408 LfDvxj8IND13Vmg8jWZ7X4S/EPxF4t+IHwunttWhvbHUvhz478Sav4z8Eana3nhnxTdtrul36J7H XG/Dv4feDvhP4G8KfDX4faHB4b8FeCND0/w54a0WCe9vBY6XpsCwQLcajqdze6rq1/Pta51PWdYv r/WdZ1Ga61TV7++1K7urubsq2rzhOvWnSTVOdWpKmpRpwkoSm3BShRjCjFqLV40oQpxekIxikljQ VSNGjGry+1jSpxqckqk4e0UEp8s6rdWUea/LKo3UkrObcmwooorI1CiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKK ACiiigAooooAKKKKACiiigD/2QBTAHAAbABpAHQAQgB1AHQAdABvAG4AQwBvAG0AbQBhAG4AZABF AHYAZQBuAHQAaQBuAGcASQB0AGUAbQBPAHUAdABTAHAAYQBjAGUARABhAHQAYQBTAG8AdQByAGMA ZQBkAEQAYQB0AGEAUwBvAHUAcgBjAGUALgBBAG4AYwBoAG8AcgBEAGEAdABhAFMAbwB1AHIAYwBl AC4ASQBzAEEAbgBjAGgAbwByAFAAcgBlAHMAcwBlAGQARABhAHQAYQBTAG8AdQByAGMAZQAuAEkA cwBUAHIAYQBuAHMAcABhAHIAZQBuAGMAeQBFAG4AYQBiAGwAZQBkAEQAYQB0AGEAUwBvAHUAcgBj AGUALgBJAHMAQQB1AHQAbwBDAG8AbQBwAGwAZQB0AGUARQBuAGEAYgBsAGUAZABEAGEAdABhAFMA bwB1AHIAYwBlAC4ASQBzAEQAcgBvAHAARgB1AGwAbABXAGkAZAB0AGgARQBuAGEAYgBsAGUAZABE AGEAdABhAFMAbwB1AHIAYwBlAC4AVABvAG8AbAB0AGkAcABTAGgAbwB3AEkAdABlAG0ASQBtAGEA ZwBlAFMAbwB1AHIAYwBlAEQAYQB0AGEAUwBvAHUAcgBjAGUALgBTAGgAbwB3AEkAdABlAG0ASQBt AGEAZwBlAFMAbwB1AHIAYwBlAFMAaABvAHcATABhAGIAZQBsAEQAYQB0AGEAUwBvAHUAcgBjAGUA LgBTAGgAbwB3AEwAYQBiAGUAbABEAGEAdABhAFMAbwB1AHIAYwBlAC4AQQBuAGMAaABvAHIAUgBl AHAAcgBlAHMAZQBuAHQAYQB0AGkAdgBlAFMAdAByAGkAbgBnAEQAYQB0AGEAUwBvAHUAcgBjAGUA LgBBAG4AYwBoAG8AcgBQAHIAbwBtAHAAdABEAGEAdABhAFMAbwB1AHIAYwBlAC4ARABhAHQAYQBC AGkAYQBzAEQAYQB0AGEAUwBvAHUAcgBjAGUALgBPAG4AQQB1AHQAbwBDAG8AbQBwAGwAZQB0AGUA UwB0AGEAcgB0AEMAbwBtAG0AYQBuAGQARABhAHQAYQBTAG8AdQByAGMAZQAuAE8AbgBDAGwAbwBz AGkAbgBnAEMAbwBtAG0AYQBuAGQARABhAHQAYQBTAG8AdQByAGMAZQAuAE8AbgBEAHIAbwBwAHAA aQBuAGcAQwBvAG0AbQBhAG4AZABEAGEAdABhAFMAbwB1AHIAYwBlAC4ARQB2AGUAbgB0AGkAbgBn AEkAdABlAG0ARABhAHQAYQBTAG8AdQByAGMAZQAuAE8AbgBDAG8AbgB0AGUAeAB0AE0AZQBuAHUA RAByAG8AcABwAGkAbgBnAEMAbwBtAG0AYQBuAGQARABhAHQAYQBTAG8AdQByAGMAZQAuAE8AbgBD AG8AbgB0AGUAeAB0AE0AZQBuAHUAQwBsAG8AcwBpAG4AZwBDAG8AbQBtAGEAbgBkAEQAYQB0AGEA UwBvAHUAcgBjAGUALgBPAG4ATABpAHYAZQBQAHIAZQB2AGkAZQB3AFMAdABhAHIAdABDAG8AbQBt AGEAbgBkAEQAYQB0AGEAUwBvAHUAcgBjAGUALgBPAG4ATABpAHYAZQBQAHIAZQB2AGkAZQB3AFMA dABvAHAAQwBvAG0AbQBhAG4AZABEAGEAdABhAFMAbwB1AHIAYwBlAC4ATwBuAEkAdABlAG0AUwBl AGwAZQBjAHQAaQBvAG4AQwBvAG0AbQBhAG4AZABEAGEAdABhAFMAbwB1AHIAYwBlAC4ATwBuAFMA cABsAGkAdABCAHUAdAB0AG8AbgBDAG8AbQBtAGEAbgBkAFMAdAByAGkAbgBnAFMAZQBsAGUAYwB0 AGkAbwBuAEMAbwBtAG0AYQBuAGQARABhAHQAYQBTAG8AdQByAGMAZQAuAE8AbgBTAGUAbABlAGMA dABlAGQAUwB0AHIAaQBuAGcAQwBoAGEAbgBnAGUAajDKFUxWElOufI/wq8b/ALQ3hT/goP4j+FXx E+JH7Rd58G/Hvw8+NPij4deFf2ifCv7IE/hrxVrngvxz8LJbPWP2WfFP7Jfg/T/H+gfDT4feGPG+ o+H/ABpo/wC2zq2lfFTxPJ4g+HV98PtP8VS6B8VNc0z9RK8I+GX7LX7MnwU8a+OfiT8Gv2c/gR8J PiL8T7i7vPiV4++GXwh+H/gLxr8Q7u/1a416+uvHPinwr4e0rXfFtxe67dXWtXc+v3+oSXOrXNxq MzPeTSTN7vWdP3MFl2Hl71bCYSVDEVX7069WWMxeIVSrXdqmKqKjXpUZYirGm5eyUKVHD4aFDD0t 6j58VjKyXLDEYj2tOmrRp04KjRpKNGgly4WDdOU3QjVrpVJ1Kvtm6rjAooooEFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFF FABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAH/2QAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAFBLAwQUAAYACAAAACEAuX/uc5YGAACwGwAAFAAAAHBwdC90aGVt ZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3YaB3WK2LGbrU0bxG6HHmmJllhTokDSSX0b2uOA AcO6YZcBu+0wbCvQArt0nyZbh60D+hX2SEqyGMtI0gbbsMWHRCJ/fP/f4yN1/cajmKFDIiTlSdur X615iCQ+D2gStr17w/6VDQ9JhZMAM56Qtjcj0rux9f571/GmikhMEKxP5CZue5FS6ebKivRhGMur PCUJzI25iLGCVxGuBAIfAd2YrazWausrMaaJhxIcA9m74zH1CRpqkt5WTrzH4DVRUg/4TAw0aeKs MNhgUtcIOZNdJtAhZm0P+AT8aEgeKQ8xLBVMtL2a+XkrW9dX8Ga2iKkla0vr+uaXrcsWBJNVw1OE o4Jpvd9oXdsp6BsAU4u4Xq/X7dULegaAfR80tbKUaTb6G/VOTrMEso+LtLu1Zq3h4kv01xZkbnU6 nWYrk8USNSD72FjAb9TWG9urDt6ALL65gG90trvddQdvQBa/voDvX2utN1y8AUWMJpMFtHZov59R LyBjznYr4RsA36hl8DkKoqGILs1izBO1LNZi/JCLPgA0kGFFE6RmKRljH6K4ixkdCaoZ4E2CSzN2 yJcLQ5oXkr6gqWp7H6YYMmJO783L79+8fI7evHx2/PjF8eOfjp88OX78o6XlLNzFSVhe+Prbz/78 +mP0x/NvXj/9ohovy/hff/jkl58/rwZCBs0levXls99ePHv11ae/f/e0Ar4t8KgMH9KYSHSHHKED HoNuxjCu5GQkzrdiGGFaXrGdhBInWHOpoN9TkYO+M8MMV+A6xLXgfQEVpAp4c/rQEXgQianKXO5o diuKHeAe56zDRaUVbmleJTMPp0lYzVxMy7gDjA+reHdx4vi3N02hdNIqkt2IOGLuM5woHJKEKKTn +ISQCns9oNSx6x71BZd8rNADijqYVppkSEdONM0X7dIY/DKrEhD87dhm7z7qcFal9Q45dJGQFZhV CD8kzDHjTTxVOK4iOcQxKxv8NlZRlZCDmfDLuJ5U4OmQMI56AZGyas1dAfqWnH4Lqke12/fYLHaR QtFJFc3bmPMycodPuhGO0yrsgCZRGfuBnECIYrTPVRV8j7sZot/BDzhZ6u77lDjuPr0a3KOhI9I8 QPTMVFT48ibhTvwOZmyMiSk1UNedch3T5LJ2n7l2bwtamTy7Jyr2MtzJOt3lIqD//jK9g6fJPoHM WNyrLqv0ZZX2/vNVelk+X3xtnpdjqNS6d7JNt2nB46Ud+JgyNlAzRm5L04RL2ISCPgzqdeb0SYoT WRrBo85kYODgQoHNGiS4+oiqaBDhFBr4uqeJhDIjHUqUcgkHRzNcSVvj4RCg7LGzqQ8ktnJIrPZ4 YIfX9HB+7ijIGKlCc7jNGa1pAmdltnYtIwq6vQ2zuhbqzNzqRjRTFB1uhcraxOaADiYvVIPBwprQ 3SDoicDK63D+16zh4IMZCbTdrY9ytxgvXKSLZIQDkvlI673oo7pxUh4rC4poPWww6EPkKVYrcWtp su/A7SxOKrNrLGGXe+9dvJRH8NxLQO1kOrKknJwsQUdtr9VcbXrIx2nbG8OZGR7jFLwudUOJWQgX T74SNuxPTWaT5XNvtnLF3CSowzWItfuCwk4dSIVUO1hGNjTMVBYCLNGcrPyrTTDrRSlQUY3OJsXa BgTDPyYF2NF1LRmPia/Kzi6NaNvZ16yU8qkiYhAFR2jEpuIAg/t1qII+AZVw9WEqgn6BezptbTPl Fucs6cq3YwZnxzFLI5yVW52ieSZbuClIhQzmrSQe6FYpu1Hu/KqYlL8gVcph/D9TRe8ncA2xFmgP +HBNLDDSmdL2uFARhyqURtTvC2gcTO2AaIG7XpiGoILLavNfkEP93+acpWHSGk6T6oCGSFDYj1Qk CNmHsmSi7xRi9WzvsiRZRshEVElcmVqxR+SQsKGuget6b/dQBKFuqklWBgzuZPy571kGjULd5JTz zalkxd5rc+Dv7nxsMoNSbh02DU1u/0LEoj2Y76p2vVme771lRfTEvM1q5FkBzEpbQStL+7cU4Zxb ra1YCxqvNnPhwIuLGsNg0RClcJmE9B/Y/6jwmf3yoTfUIT+A2orgQ4YmBmEDUX3FNh5IF0g7OILG yQ7aYNKkrGmz1klbLd+sL7jTLfieMLaW7Cz+Pqexi+bMZefk4kUaO7OwY2s7ttTU4NmTKQpD4/wg YxxjPpmVv2rx0UNw9A58P5gyJU0wwTcrgaGHHpg8gOS3HM3Srb8AAAD//wMAUEsDBBQABgAIAAAA IQDY/Y2PrAAAALYAAAATAAAAcHB0L3RhYmxlU3R5bGVzLnhtbAzMSQ6CMBhA4b2Jd2j+fS1DUSQU wiArd+oBKpQh6UBooxLj3WX58pIvzT9KopdY7GQ0A//gARK6Nd2kBwaPe4NjQNZx3XFptGCwCgt5 tt+lPHFPeXOrFFfr0KZom3AGo3NzQohtR6G4PZhZ6O31ZlHcbbkMpFv4e9OVJIHnHYnikwbUiZ7B N6qCIKK0wKfL5YhpSANcejTGcVTW1bmp/SosfkCyPwAAAP//AwBQSwMEFAAGAAgAAAAhAABBtFWM AQAASwMAABEAAABwcHQvdmlld1Byb3BzLnhtbIxSy27CMBC8V+o/WL5DHqVAIwKXqr1wqATt3XJM sJTYlteEwNd3nYSEUg6css/ZmYkXq7osSCUsSK1SGo1DSoTiOpMqT+n39mM0pwQcUxkrtBIpPQmg q+Xz08IklRTHL0sQQEHCUrp3ziRBAHwvSgZjbYTC3k7bkjlMbR5klh0RuCyCOAynQcmkot2+fWRf 73aSi3fND6VQrgWxomAOycNeGrigmUfQjBWAMM32H0pLFKc87eKnkehznHXaimwtdo7AGa16ncYh Da57W22a1ttkOm1awX8cKGQmBli+KbI2I7DXx88DdgHBqcflXadidsNZge63dfDJcsESqIn/aS8x JRl+w+Yolk93ysil2zOJtjKXitQpHUVhNKHkhNFs7tXgWHfWM8g9nzW4Pia4ip6hvdqeKTEaycZR q7Yb74rz+cWCAcSD94KbWzd2KO0EbEXtrhwawlvdrWrPutc8lO7rxeeNWi/MeqU4fOd0bmW2MYzj kyUczZrhH0cAjght2PpVtY/kFwAA//8DAFBLAwQUAAYACAAAACEADy2vrlEBAACLAgAAEQAAAHBw dC9wcmVzUHJvcHMueG1srJDNasMwEITvhb6D0V2RLDt2bGIHO3ah0EMO7QMIW04E1g+S8lNK373C cUtDLzn0tssys9/MenMRY3BixnIlCxAuMAiY7FTP5b4Ab69PcAUC66js6agkK8A7s2BTPj6sda4N s0w66rx0ZwJvJG1OC3BwTucI2e7ABLULpZn0t0EZQZ1fzR71hp79AzEignGCBOUSzHpzj14NA+9Y o7qj8ABXE8PGicQeuLbfbvoet985bpBKH5Jd3It18xQcDS/AR5sm2zaLK5jgaAvjMCawztoaJk0Y pRiHuCLpJ/CaMM57bjtq+mdB96ztuWuoo3NUf/6DJ3hnlFWDW3RKoGtOpNWZGa34FDXEc18nOhYA A1Su0YR5y9hEYYUTUsE0W1UwjkgGq7ppYF1Xq2WSELwM8Q8jG+hxdBNjo/k/4hFyA3gFnfr04+/e d6b8AgAA//8DAFBLAwQUAAYACAAAACEAw1Fs+HkCAACKBQAAEAAIAWRvY1Byb3BzL2FwcC54bWwg ogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACcVEtP20AQvlfqf1j51B6MA01pG20W oQBFtJAIGzhv7XGyYO9udxZD+us7tuPgFKtSm0M0j8/z+GZn+NFzWbAKHCqjp8H+3ihgoFOTKb2c BjfJWfg5YOilzmRhNEyDNWBwJN6+4QtnLDivABmF0DgNVt7bSRRhuoJS4h65NXly40rpSXXLyOS5 SuHEpI8laB8djEaHETx70Blkod0GDNqIk8r/b9DMpHV9eJusLRUseGK8LBJVgjgYfeHRi8rvjMtQ HByOeNSK/NjaQqXSEyPiUqXOoMk9mze1s4V5ArcwSnse9YHEByA11Xx21vQs5jrE1AFoFq/ME3s3 nnx4z6MBIF9IJ5dO2hWKj4cEeVF5XKgMUJB1I/Er48lA9bYCP1dZBnrjJfOOzi8vZ4WyDb4TeZzK AmZEkMhlgUChtwZ+DrIe/kIqh4JXflJB6o1jqH7R+McB+yERalqnQSWdktoTvTWsVRq5sOidSOgd UGzytXoj9mF9WY3FfgMg4a/ANlbTLUuULwD/IQWxSOW8SlEb2zYp9y4BbYp5TiPxA3x86vPRlNay 0Va5eTOviNhSchHPr9jCqUp6YLRkLF6XJXinUvYN1ixzMvfhPS0e0j9CeI9G06I0+JDwIXb48AHW fSK2Kea03JWCp0HnaUFvw1O22aOrYFtJnfv0WZa2ADb43XV8PAQexO62tAk7iLyGn4+AntHJYHdf 2XFar2AfuTOnPyYzM6WVet3b2Jlx1rhmIXnUufl3pR/wxibmhDjv3v+ukccr6SCjO9X5Xwz8nJ6+ K+ogs5XUS8g6zGtHfUlu29Mq9sd7I/o1R6Oz1begO6LiNwAAAP//AwBQSwMEFAAGAAgAAAAhAEaJ zUSFAQAA5wIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAHxSy27CMBC8V+o/WL4HO0RFYIUg9cEBlbZSqKh6s+wFLBLHsl0e/fo6AVJQUSVf dnd2dnbW6WhXFmgD1qlKD3HcoRiBFpVUejnE77Nx1MfIea4lLyoNQ7wHh0fZ7U0qDBOVhTdbGbBe gUOBSTsmzBCvvDeMECdWUHLXCQgdiovKltyH0C6J4WLNl0C6lPZICZ5L7jmpCSPTMuIjpRQtpfmy RUMgBYECStDekbgTk1+sB1u6qw1N5QxZKr83Yaej3HNuKQ7FFr1zqgVut9vONmlkBP0x+Zg+582q kdK1VwJwlkrBvPIFZJP89QXlYBUv1Df3wWeUGxBqoUQTOYYm8xxdgU3mT1fSKWmp6yHCAveVzaZq DWgSbuQawCld36ngzk/DSRcK5P3+Avm3WjdY2Kj6Q2TdfkrO4zCwMfEwFSQKtrCDiafKPHl4nI1x 1qVxN6L9iMYz2mPJgNHeZ63sor+26ZAoj/r+Z0wiGt5gRim7S1gSnzGeCLJG8eXXzH4AAAD//wMA UEsBAi0AFAAGAAgAAAAhAKO4FDjmAQAA0A4AABMAAAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5 cGVzXS54bWxQSwECLQAUAAYACAAAACEAaPh0oQUBAADiAgAACwAAAAAAAAAAAAAAAAAfBAAAX3Jl bHMvLnJlbHNQSwECLQAUAAYACAAAACEAY1wjtMEAAAA3AQAAIAAAAAAAAAAAAAAAAABVBwAAcHB0 L3NsaWRlcy9fcmVscy9zbGlkZTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAA IAAAAAAAAAAAAAAAAABUCAAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTIueG1sLnJlbHNQSwECLQAU AAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABRCQAAcHB0L3NsaWRlcy9fcmVscy9z bGlkZTMueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABO CgAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTQueG1sLnJlbHNQSwECLQAUAAYACAAAACEAS/U97L8A AAA3AQAAIAAAAAAAAAAAAAAAAABLCwAAcHB0L3NsaWRlcy9fcmVscy9zbGlkZTUueG1sLnJlbHNQ SwECLQAUAAYACAAAACEAS/U97L8AAAA3AQAAIAAAAAAAAAAAAAAAAABIDAAAcHB0L3NsaWRlcy9f cmVscy9zbGlkZTYueG1sLnJlbHNQSwECLQAUAAYACAAAACEAsls7dz8BAABrBgAAHwAAAAAAAAAA AAAAAABFDQAAcHB0L19yZWxzL3ByZXNlbnRhdGlvbi54bWwucmVsc1BLAQItABQABgAIAAAAIQCc 3s0FbAIAADcNAAAUAAAAAAAAAAAAAAAAAMkPAABwcHQvcHJlc2VudGF0aW9uLnhtbFBLAQItABQA BgAIAAAAIQCbePhPaAMAAL8JAAAVAAAAAAAAAAAAAAAAAGcSAABwcHQvc2xpZGVzL3NsaWRlMi54 bWxQSwECLQAUAAYACAAAACEA3SC2LLwDAAC1DwAAFQAAAAAAAAAAAAAAAAACFgAAcHB0L3NsaWRl cy9zbGlkZTMueG1sUEsBAi0AFAAGAAgAAAAhAH1aQApAAwAAQgkAABUAAAAAAAAAAAAAAAAA8RkA AHBwdC9zbGlkZXMvc2xpZGUxLnhtbFBLAQItABQABgAIAAAAIQAMsUjUBwkAAEAuAAAVAAAAAAAA AAAAAAAAAGQdAABwcHQvc2xpZGVzL3NsaWRlNC54bWxQSwECLQAUAAYACAAAACEAXX2rGWQDAABL CgAAFQAAAAAAAAAAAAAAAACeJgAAcHB0L3NsaWRlcy9zbGlkZTYueG1sUEsBAi0AFAAGAAgAAAAh AFv8tVM/AwAALw0AABUAAAAAAAAAAAAAAAAANSoAAHBwdC9zbGlkZXMvc2xpZGU1LnhtbFBLAQIt ABQABgAIAAAAIQDV0ZLxvgAAADcBAAAtAAAAAAAAAAAAAAAAAKctAABwcHQvc2xpZGVMYXlvdXRz L19yZWxzL3NsaWRlTGF5b3V0MTEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAA LAAAAAAAAAAAAAAAAACwLgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDIueG1s LnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAAC4LwAAcHB0L3Ns aWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDEueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS 8b4AAAA3AQAALAAAAAAAAAAAAAAAAADAMAAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxh eW91dDMueG1sLnJlbHNQSwECLQAUAAYACAAAACEA1dGS8b4AAAA3AQAALAAAAAAAAAAAAAAAAADI MQAAcHB0L3NsaWRlTGF5b3V0cy9fcmVscy9zbGlkZUxheW91dDQueG1sLnJlbHNQSwECLQAUAAYA CAAAACEA1dGS8b4AAAA3AQAALQAAAAAAAAAAAAAAAADQMgAAcHB0L3NsaWRlTGF5b3V0cy9fcmVs cy9zbGlkZUxheW91dDEwLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAA AAAAAAAAAAAA2TMAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ5LnhtbC5yZWxz UEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA4TQAAHBwdC9zbGlkZUxh eW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ4LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAA NwEAACwAAAAAAAAAAAAAAAAA6TUAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ3 LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA8TYAAHBw dC9zbGlkZUxheW91dHMvX3JlbHMvc2xpZGVMYXlvdXQ2LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAh ANXRkvG+AAAANwEAACwAAAAAAAAAAAAAAAAA+TcAAHBwdC9zbGlkZUxheW91dHMvX3JlbHMvc2xp ZGVMYXlvdXQ1LnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALYu5koLCAAA9y8AACEAAAAAAAAAAAAA AAAAATkAAHBwdC9zbGlkZU1hc3RlcnMvc2xpZGVNYXN0ZXIxLnhtbFBLAQItABQABgAIAAAAIQBp ol8hHgEAAMcHAAAsAAAAAAAAAAAAAAAAAEtBAABwcHQvc2xpZGVNYXN0ZXJzL19yZWxzL3NsaWRl TWFzdGVyMS54bWwucmVsc1BLAQItABQABgAIAAAAIQA6yuCwvwMAALULAAAhAAAAAAAAAAAAAAAA ALNCAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0Mi54bWxQSwECLQAUAAYACAAAACEAP0YI YBMDAACHBwAAIQAAAAAAAAAAAAAAAACxRgAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxheW91dDcu eG1sUEsBAi0AFAAGAAgAAAAhAMzbidpMAwAA2QgAACEAAAAAAAAAAAAAAAAAA0oAAHBwdC9zbGlk ZUxheW91dHMvc2xpZGVMYXlvdXQ2LnhtbFBLAQItABQABgAIAAAAIQCZMl7q5AUAAFccAAAhAAAA AAAAAAAAAAAAAI5NAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0NS54bWxQSwECLQAUAAYA CAAAACEA0SZVG4UEAACIEgAAIQAAAAAAAAAAAAAAAACxUwAAcHB0L3NsaWRlTGF5b3V0cy9zbGlk ZUxheW91dDQueG1sUEsBAi0AFAAGAAgAAAAhAEOVMw32BAAAeREAACEAAAAAAAAAAAAAAAAAdVgA AHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQzLnhtbFBLAQItABQABgAIAAAAIQClydyjqQQA ACURAAAhAAAAAAAAAAAAAAAAAKpdAABwcHQvc2xpZGVMYXlvdXRzL3NsaWRlTGF5b3V0MS54bWxQ SwECLQAUAAYACAAAACEAKmhzP2IFAADiEgAAIQAAAAAAAAAAAAAAAACSYgAAcHB0L3NsaWRlTGF5 b3V0cy9zbGlkZUxheW91dDgueG1sUEsBAi0AFAAGAAgAAAAhAIhfozHXAwAA7AsAACIAAAAAAAAA AAAAAAAAM2gAAHBwdC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMC54bWxQSwECLQAUAAYACAAA ACEACI+URB4FAABbEgAAIQAAAAAAAAAAAAAAAABKbAAAcHB0L3NsaWRlTGF5b3V0cy9zbGlkZUxh eW91dDkueG1sUEsBAi0AFAAGAAgAAAAhAHS8sMsjBAAAzQwAACIAAAAAAAAAAAAAAAAAp3EAAHBw dC9zbGlkZUxheW91dHMvc2xpZGVMYXlvdXQxMS54bWxQSwECLQAKAAAAAAAAACEAkYgugABUAAAA VAAAFwAAAAAAAAAAAAAAAAAKdgAAZG9jUHJvcHMvdGh1bWJuYWlsLmpwZWdQSwECLQAUAAYACAAA ACEAuX/uc5YGAACwGwAAFAAAAAAAAAAAAAAAAAA/ygAAcHB0L3RoZW1lL3RoZW1lMS54bWxQSwEC LQAUAAYACAAAACEA2P2Nj6wAAAC2AAAAEwAAAAAAAAAAAAAAAAAH0QAAcHB0L3RhYmxlU3R5bGVz LnhtbFBLAQItABQABgAIAAAAIQAAQbRVjAEAAEsDAAARAAAAAAAAAAAAAAAAAOTRAABwcHQvdmll d1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQAPLa+uUQEAAIsCAAARAAAAAAAAAAAAAAAAAJ/TAABw cHQvcHJlc1Byb3BzLnhtbFBLAQItABQABgAIAAAAIQDDUWz4eQIAAIoFAAAQAAAAAAAAAAAAAAAA AB/VAABkb2NQcm9wcy9hcHAueG1sUEsBAi0AFAAGAAgAAAAhAEaJzUSFAQAA5wIAABEAAAAAAAAA AAAAAAAAztgAAGRvY1Byb3BzL2NvcmUueG1sUEsFBgAAAAAvAC8AIg4AAIrbAAAAAA== --_004_4E1F6AAD24975D4BA5B1680429673943674E68F9TK5EX14MBXC283r_-- From kent@bbn.com Sun Mar 10 07:39:50 2013 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 9B00A21F8570 for ; Sun, 10 Mar 2013 07:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 fVnrCbulCJ-t for ; Sun, 10 Mar 2013 07:39:49 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 958F321F85C6 for ; Sun, 10 Mar 2013 07:39:49 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:51416 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UEhPf-0000N9-12; Sun, 10 Mar 2013 10:39:47 -0400 Message-ID: <513C9B32.2050502@bbn.com> Date: Sun, 10 Mar 2013 10:39:46 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org, tonynad@microsoft.com References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: multipart/alternative; boundary="------------090905000101040002000104" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 10 Mar 2013 14:39:50 -0000 This is a multi-part message in MIME format. --------------090905000101040002000104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Anthony, > Hi Richard, > > As I read your note, you're proposing a special-purpose encryption > format to use for keys. I think it would be simpler to use the > general-purpose encryption format we already have (JWE) to encrypt > keys. Indeed, draft-miller-jose-jwe-protected-jwk already clearly > describes > Without looking at the details of what is defined now, let me observe that it is generally considered to be a bad idea to use the same mechanism to encrypt keys and data. Because one wants to prevent inadvertent exposure of keys, we usually employ a different mechanism to encrypt them, and we mark them as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an implementation of the crypto used to support JOSE, it probably will be necessary to adhere to such conventions. Steve --------------090905000101040002000104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Anthony,

Hi Richard,

 

As I read your note, you’re proposing a special-purpose encryption format to use for keys.  I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly describes


Without looking at the details of what is defined now, let me observe that it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because one wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to encrypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an implementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conventions.

Steve
--------------090905000101040002000104-- From leifj@mnt.se Sun Mar 10 08:06:36 2013 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 79DD021F86CE for ; Sun, 10 Mar 2013 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.998, 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 9-iNdTGOf7tW for ; Sun, 10 Mar 2013 08:06:32 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id 88F8D21F8640 for ; Sun, 10 Mar 2013 08:06:31 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so2843743pbc.12 for ; Sun, 10 Mar 2013 08:06:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:x-gm-message-state; bh=bIFg/8JKX0n1ju2PfevNiZYssCa96TAzCjm3hgXvt/s=; b=dilsD8dTZ3VhWb03IyTLbwVInX0FPutT5n1bp7a7K3Oe0g3LA9/7llM118SmAx6slZ yB20ZUlOfX19uA/Lgp5jrPp/hg0hp2nHZkqJ8NG4IdnFiymTZw6ThOaPGCkaL1mB5DkG YRv4cvwSe0/3w4wRG1XsMTpO7hOkuntmBr00bBxB4voGoXYLrKHQu38sHCyr7eNpX0X2 ifBhO2PveklqMFATXajeMdFIqXDTjwngOzifXApR/MKYXP8/lFKA+qDXHt3Imx+hq0Th oDirrXHGUaMJhT5N/LrNTXEKJUL+9xf4kwSFxvtB/NPHbm/Z55pKiwEZQx1bpTqjZdcr BTEA== X-Received: by 10.69.1.70 with SMTP id be6mr20765013pbd.185.1362927990818; Sun, 10 Mar 2013 08:06:30 -0700 (PDT) Received: from ?IPv6:2001:df8:0:8:a987:76ca:481f:363c? ([2001:df8:0:8:a987:76ca:481f:363c]) by mx.google.com with ESMTPS id 4sm15753437pbn.23.2013.03.10.08.06.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 08:06:30 -0700 (PDT) Message-ID: <513CA173.1020103@mnt.se> Date: Sun, 10 Mar 2013 16:06:27 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> In-Reply-To: <513C9B32.2050502@bbn.com> Content-Type: multipart/alternative; boundary="------------010509000108070105050802" X-Gm-Message-State: ALoCoQlbmZWHokhucwtjhSrH1LVZH6LIs3LqxS1Ay7gpKZoyezRM+NvkaSG4okyBWwNPSxxwm+Z4 Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 10 Mar 2013 15:06:36 -0000 This is a multi-part message in MIME format. --------------010509000108070105050802 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/10/2013 03:39 PM, Stephen Kent wrote: > Anthony, > >> Hi Richard, >> >> >> >> As I read your note, you're proposing a special-purpose encryption >> format to use for keys. I think it would be simpler to use the >> general-purpose encryption format we already have (JWE) to encrypt >> keys. Indeed, draft-miller-jose-jwe-protected-jwk already clearly >> describes >> > > Without looking at the details of what is defined now, let me observe > that it is generally considered to > be a bad idea to use the same mechanism to encrypt keys and data. > Because one wants to prevent > inadvertent exposure of keys, we usually employ a different mechanism > to encrypt them, and we mark them > as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for > an implementation of the crypto > used to support JOSE, it probably will be necessary to adhere to such > conventions. > Interesting. Would you say that is a convention applied by FIPS 140 labs or is that somewhere in the FIPS specs? Cheers Leif --------------010509000108070105050802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/10/2013 03:39 PM, Stephen Kent wrote:
Anthony,

Hi Richard,

 

As I read your note, you’re proposing a special-purpose encryption format to use for keys.  I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly describes


Without looking at the details of what is defined now, let me observe that it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because one wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to encrypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an implementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conventions.

Interesting. Would you say that is a convention applied by FIPS 140 labs or is that somewhere
in the FIPS specs?

        Cheers Leif
--------------010509000108070105050802-- From kent@bbn.com Sun Mar 10 08:29:22 2013 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 7BDA421F8457 for ; Sun, 10 Mar 2013 08:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[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 wb7RbKSGdIne for ; Sun, 10 Mar 2013 08:29:21 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id A1C8721F8442 for ; Sun, 10 Mar 2013 08:29:20 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15]:50400 helo=dhcp-1067.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1UEiBb-0000bB-C3; Sun, 10 Mar 2013 11:29:19 -0400 Message-ID: <513CA6CE.50007@bbn.com> Date: Sun, 10 Mar 2013 11:29:18 -0400 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org, leifj@mnt.se References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> In-Reply-To: <513CA173.1020103@mnt.se> Content-Type: multipart/alternative; boundary="------------080002020808080902020402" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 10 Mar 2013 15:29:22 -0000 This is a multi-part message in MIME format. --------------080002020808080902020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Leif, I fear my choice of words was poor, re "convention." NIST Special Pub 800-38E defines key wrap modes for AES (and tripe DES). FIPS 140-2, section 4.7.4, says (with regard to key entry): *All encrypted secret and private keys, entered into or output from a cryptographic module and used in an Approved mode of operation, shall be encrypted using an Approved algorithm. * ** FIPS 140- So, combining these two NIST specs, one can infer that keys entered into a module, electronically, should be wrapped, not just encrypted as data. Steve > On 03/10/2013 03:39 PM, Stephen Kent wrote: >> Anthony, >> >>> Hi Richard, >>> >>> As I read your note, you're proposing a special-purpose encryption >>> format to use for keys. I think it would be simpler to use the >>> general-purpose encryption format we already have (JWE) to encrypt >>> keys. Indeed, draft-miller-jose-jwe-protected-jwk already clearly >>> describes >>> >> >> Without looking at the details of what is defined now, let me observe >> that it is generally considered to >> be a bad idea to use the same mechanism to encrypt keys and data. >> Because one wants to prevent >> inadvertent exposure of keys, we usually employ a different mechanism >> to encrypt them, and we mark them >> as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for >> an implementation of the crypto >> used to support JOSE, it probably will be necessary to adhere to such >> conventions. >> > Interesting. Would you say that is a convention applied by FIPS 140 > labs or is that somewhere > in the FIPS specs? > > Cheers Leif > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------080002020808080902020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Leif,

I fear my choice of words was poor, re "convention." NIST Special Pub 800-38E defines key wrap
modes for AES (and tripe DES). FIPS 140-2, section 4.7.4, says (with regard to key entry):

All encrypted secret and private keys, entered into or output from a cryptographic module and used in an Approved mode of operation, shall be encrypted using an Approved algorithm.

FIPS 140- So, combining these two NIST specs, one can infer that keys entered into a module, electronically, should be wrapped, not just encrypted as data.

Steve
On 03/10/2013 03:39 PM, Stephen Kent wrote:
Anthony,

Hi Richard,

 

As I read your note, you’re proposing a special-purpose encryption format to use for keys.  I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-jose-jwe-protected-jwk already clearly describes


Without looking at the details of what is defined now, let me observe that it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because one wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to encrypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an implementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conventions.

Interesting. Would you say that is a convention applied by FIPS 140 labs or is that somewhere
in the FIPS specs?

        Cheers Leif


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--------------080002020808080902020402-- From Michael.Jones@microsoft.com Sun Mar 10 08:30:18 2013 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 1273F21F8457 for ; Sun, 10 Mar 2013 08:30:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1ljyO-fzjkrp for ; Sun, 10 Mar 2013 08:30:16 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id D0A1721F8442 for ; Sun, 10 Mar 2013 08:30:15 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.203) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.620.12; Sun, 10 Mar 2013 15:30:12 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Sun, 10 Mar 2013 15:30:12 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Sun, 10 Mar 2013 15:29:35 +0000 From: Mike Jones To: Leif Johansson , "jose@ietf.org" Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: AQHOHCz8TA/lbdHIh02svEbrBuyFqpicMcOAgALQGwCAAAd0gIAAA+GA Date: Sun, 10 Mar 2013 15:29:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> In-Reply-To: <513CA173.1020103@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674EBA47TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(479174001)(24454001)(199002)(189002)(33656001)(76482001)(56776001)(20776003)(47736001)(56816002)(16406001)(47976001)(63696002)(51856001)(512954001)(54316002)(59766001)(80022001)(77982001)(47446002)(50986001)(15202345001)(65816001)(69226001)(55846006)(53806001)(54356001)(5343655001)(4396001)(49866001)(16236675001)(66066001)(79102001)(31966008)(46102001)(74662001)(5343635001)(74502001)(44976002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB034; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07817FCC2D Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 10 Mar 2013 15:30:18 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674EBA47TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll note that in JSON Web Encryption, we are already using standard method= s for encrypting key values for the Content Master Key - specifically AES K= ey Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreeme= nt). What we're talking about here, however, is encrypting potentially more than= just key values - in this case, key values with associated key use informa= tion, algorithm information, key ID information, and potentially other attr= ibutes. As such, using the JWK JSON representation of this information as = the payload of a standard JWE encryption seems like the obvious solution, w= hich doesn't require inventing anything we don't already have. draft-miller-jose-jwe-protected-jwk already describes doing that. I believ= e that we should adopt this as a working group document as soon as the rech= artering is complete. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Lei= f Johansson Sent: Sunday, March 10, 2013 8:06 AM To: jose@ietf.org Subject: Re: [jose] A Unified Theory of JOSE Keys On 03/10/2013 03:39 PM, Stephen Kent wrote: Anthony, Hi Richard, As I read your note, you're proposing a special-purpose encryption format t= o use for keys. I think it would be simpler to use the general-purpose enc= ryption format we already have (JWE) to encrypt keys. Indeed, draft-miller= -jose-jwe-protected-jwk already clearly describes Without looking at the details of what is defined now, let me observe that = it is generally considered to be a bad idea to use the same mechanism to encrypt keys and data. Because o= ne wants to prevent inadvertent exposure of keys, we usually employ a different mechanism to en= crypt them, and we mark them as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an im= plementation of the crypto used to support JOSE, it probably will be necessary to adhere to such conve= ntions. Interesting. Would you say that is a convention applied by FIPS 140 labs or= is that somewhere in the FIPS specs? Cheers Leif --_000_4E1F6AAD24975D4BA5B1680429673943674EBA47TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll note that in J= SON Web Encryption, we are already using standard methods for encrypting ke= y values for the Content Master Key – specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).

 <= /p>

What we’re talking = about here, however, is encrypting potentially more than just key values &#= 8211; in this case, key values with associated key use information, algorithm information, key ID information, and potentially other attribute= s.  As such, using the JWK JSON representation of this information as = the payload of a standard JWE encryption seems like the obvious solution, w= hich doesn’t require inventing anything we don’t already have.

 <= /p>

draft-miller-jose-jwe-pro= tected-jwk already describes doing that.  I believe that we should ado= pt this as a working group document as soon as the rechartering is complete.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.o= rg] On Behalf Of Leif Johansson
Sent: Sunday, March 10, 2013 8:06 AM
To: jose@ietf.org
Subject: Re: [jose] A Unified Theory of JOSE Keys<= /p>

 

On 03/10/2013 03:39 PM, Stephen Kent wrote:

Anthony,

 

Hi Richard,

 <= /p>

As I read your note, you&= #8217;re proposing a special-purpose encryption format to use for keys.&nbs= p; I think it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.  Indeed, draft-miller-j= ose-jwe-protected-jwk already clearly describes


Without looking at the details of what is defined now, let me observe that = it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because o= ne wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to en= crypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an im= plementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conve= ntions.

Interesting. Would you say that is a convention appl= ied by FIPS 140 labs or is that somewhere
in the FIPS specs?

        Cheers Leif

--_000_4E1F6AAD24975D4BA5B1680429673943674EBA47TK5EX14MBXC283r_-- From odonoghue@isoc.org Sun Mar 10 11:13:07 2013 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 2FC7221F88B1 for ; Sun, 10 Mar 2013 11:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 e95KT7jZ-tOV for ; Sun, 10 Mar 2013 11:13:06 -0700 (PDT) Received: from smtp134.ord.emailsrvr.com (smtp134.ord.emailsrvr.com [173.203.6.134]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9221F88AC for ; Sun, 10 Mar 2013 11:13:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp17.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 0CF5538012B for ; Sun, 10 Mar 2013 14:13:06 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp17.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id D24C2380119 for ; Sun, 10 Mar 2013 14:13:05 -0400 (EDT) Message-ID: <513CCD31.8050408@isoc.org> Date: Sun, 10 Mar 2013 14:13:05 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] updated draft charter text incorporating AD's comments X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 18:13:07 -0000 Folks, Here is the updated charter text based on Sean's comments and Mike's response. If there are any errors, please identify them asap as I plan to forward this back to Sean (and thus the IESG) in the very near future. Regards, Karen Description of JOSE Working Group JavaScript Object Notation (JSON) is a text format for the serialization of structured data described in RFC 4627. The JSON format is often used for serializing and transmitting structured data over a network connection. With the increased usage of JSON in protocols in the IETF and elsewhere, there is now a desire to offer security services for JSON with encryption, digital signatures, and message authentication codes (MACs). Different proposals for providing such security services have already been defined and implemented. This Working Group will standardize the mechanism for integrity protection (signature and MAC) and encryption as well as the format for keys and algorithm identifiers to support interoperability of security services for protocols that use JSON. The Working Group will base its work on well-known message security primitives (e.g., CMS), and will solicit input from the rest of the IETF Security Area to be sure that the security functionality in the JSON format is sound. As JSON adoption expands, the different applications utilizing JSON security services will grow and this leads to the need to support different requirements. The WG will develop a generic syntax that can be used by applications to secure JSON-data, but it will be up to the application to fully specify the use of the WG's documents much the same way S/MIME is the application of CMS to MIME-based media types. This group is chartered to work on the following deliverables: (1) A Standards Track document or documents specifying how to apply JSON-structured integrity protection to data, including (but not limited to) JSON data structures. "Integrity protection" includes public-key digital signatures as well as symmetric-key MACs. (2) A Standards Track document or documents specifying how to apply a JSON-structured encryption to data, including (but not limited to) JSON data structures. (3) A Standards Track document specifying how to encode public keys as JSON- structured objects. (4) A Standards Track document specifying algorithms and algorithm identifiers for the previous three documents. (5) A Standards Track document specifying how to encode private and symmetric keys as JSON-structured objects. This document will build upon the concepts and structures in (3). (6) A Standards Track document specifying a means of protecting private and symmetric keys via encryption. This document will build upon the concepts and structures in (2) and (5). This document may register additional algorithms in registries defined by (4). (7) An Informational document detailing Use Cases and Requirements for JSON Object Signing and Encryption (JOSE). (8) An Informational document that tells an application what needs to be specified in order to implement JOSE. One or more of these goals may be combined into a single document, in which case the concrete milestones for these goals will be satisfied by the consolidated document(s). From rlb@ipv.sx Sun Mar 10 12:29:12 2013 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 1399821F8314 for ; Sun, 10 Mar 2013 12:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.421 X-Spam-Level: X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 wvVRifL4Xbso for ; Sun, 10 Mar 2013 12:29:10 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 963CB11E80AE for ; Sun, 10 Mar 2013 12:29:10 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so3793365oag.26 for ; Sun, 10 Mar 2013 12:29:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yEmYn3R+Lpyh9UygRyPQFqpr8FCBU8zv8pgXsydlKq8=; b=c7dEXWjoO8Zb1Wn/jycnkeAqqx71E9KGOhqr14Wmf0fsRralPOWhCkhB5zwsvuLE/7 ZKCNtXnn6+iH1tSnFpzckNXAb7izIN6eUBn/SYHglSD1dC1bW4q3nxXLH+ThiMUjKB8l b/UuXZ5SPwUauJ4nrsIGSUvxPnXsXU/VxBhX0pb6VDRuG5T1ghIvbScYB+I3S9+SxTXB +IBX4CtHx9hJ2TyIEUcxqEvwAIQybO0W4oeJTAHcIfQnt+Di/ivHQR2TX0+qTF0oAL+c vvCsP2mhfM/oG/NANILQ+PTK3nj3R5MS5cBD/C0dyG3FcjYKlHgcXXF7KHyEJe/JmZXs moMw== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr6806383obc.30.1362943750036; Sun, 10 Mar 2013 12:29:10 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Sun, 10 Mar 2013 12:29:09 -0700 (PDT) X-Originating-IP: [128.89.254.10] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Sun, 10 Mar 2013 15:29:09 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=f46d0444709d11f55804d79712d9 X-Gm-Message-State: ALoCoQm3PknBrETjjG5f6ce1rDjE6j7lWIvrVonFiIsp0cSsRrR71AxgkKFZAlSS1HIq7L7tAWzA Cc: Leif Johansson , "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 10 Mar 2013 19:29:12 -0000 --f46d0444709d11f55804d79712d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable So it seems to me that the group has three questions to answer when it comes to wrapped keys: Q1(Encryption): What mechanism will be used to encrypt key material, possibly containing attributes? Answer 1.A: JWE Answer 1.B: Key wrap, derived from JWE Q2(Packing): How should the wrapped key+attributes be expressed? Answer 2.A: JSON format (not packed) Answer 2.B: JSON, with binary parts expressed directly JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in my Unified Theory is 1.B / 2.B. For context, I'm working from a few principles here: -- We should not define multiple ways to wrap symmetric keys -- We should not do things that would preclude accreditation under major security standards (e.g., FIPS) -- We should choose encodings that minimize the size overhead imposed by the encoding If we agree on these principles, then the answers to the above questions seem pretty clear. It seems to me that Steve's point on Question 1 pretty much decides the question for B. If we want systems using JOSE to have any hope of getting accreditation (e.g., under FIPS), then they will have to use standard mechanisms for protecting keys, even if those keys are packaged with other attributes. Mike's message misses the point that the key wrap algorithm isn't actually being used to protect the key itself -- for that you would use a normal, content-oriented encryption algorithm, in contravention of the FIPS requirements. Question 2 is mostly a question of backward compatibility and efficiency. If we want to have any hope of being backward-compatible with JWE key wrapping -- that is, avoiding having two ways to do the same thing -- then we need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object. That would be option 2.B. There are also compactness arguments for 1.B and 2.B. If you do 1.A, then in addition to the header, you have to carry a separate CMK, IV, and MAC value. If you're using AES-GCM with a 128-bit key, that's a total of 44 octets (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key wrap, the wrapping algorithm adds a maximum of 16 octets to the object. The difference in case 2 is even greater, because you're talking about double-base64 encoding, which entails a penalty of 30% of the payload. If you're protecting an AES key, this might only be a few octets, but if you're protecting a 2048-bit RSA key, then you're talking hundreds of octets. So if you care about compactness, 1.B and 2.B make a lot more sense. To respond to Mike's specific points: I=92ll note that in JSON Web Encryption, we are already using standard > methods for encrypting key values for the Content Master Key =96 specific= ally > AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key > agreement). > However, the actual key you're wrapping is still protected with a content-oriented algorithm. So you're still violating the FIPS requirements. What we=92re talking about here, however, is encrypting potentially more th= an > just key values =96 in this case, key values with associated key use > information, algorithm information, key ID information, and potentially > other attributes. As such, using the JWK JSON representation of this > information as the payload of a standard JWE encryption seems like the > obvious solution, which doesn=92t require inventing anything we don=92t a= lready > have. > Absolutely agree that JSON is the right representation. But the key is still included in that representation, so you need to apply key wrapping algorithms to it. And, as discussed above, it's a lot more efficient if you pack the JSON so that the binary isn't double-encoded. > draft-miller-jose-jwe-protected-jwk already describes doing that. I > believe that we should adopt this as a working group document as soon as > the rechartering is complete. > That draft has some excellent suggestions for password-based key wrapping. We should incorporate that into whatever solution we come up with. But for the reasons discussed above, it's wrong in using JWK for the encapsulation. I also disagree that we need a separate document for this. If we're going to avoid having two ways to wrap keys, this needs to be part of JWE/JWK. --Richard > **** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Leif Johansson > *Sent:* Sunday, March 10, 2013 8:06 AM > *To:* jose@ietf.org > *Subject:* Re: [jose] A Unified Theory of JOSE Keys**** > > ** ** > > On 03/10/2013 03:39 PM, Stephen Kent wrote:**** > > Anthony,**** > > ** ** > > Hi Richard,**** > > **** > > As I read your note, you=92re proposing a special-purpose encryption form= at > to use for keys. I think it would be simpler to use the general-purpose > encryption format we already have (JWE) to encrypt keys. Indeed, > draft-miller-jose-jwe-protected-jwk already clearly describes**** > > > Without looking at the details of what is defined now, let me observe tha= t > it is generally considered to > be a bad idea to use the same mechanism to encrypt keys and data. Because > one wants to prevent > inadvertent exposure of keys, we usually employ a different mechanism to > encrypt them, and we mark them > as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an > implementation of the crypto > used to support JOSE, it probably will be necessary to adhere to such > conventions.**** > > Interesting. Would you say that is a convention applied by FIPS 140 labs > or is that somewhere > in the FIPS specs? > > Cheers Leif**** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d0444709d11f55804d79712d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
So it seems to me that the group has three questions to answer when it= comes to wrapped keys:

Q1(Encryption): What mecha= nism will be used to encrypt key material, possibly containing attributes? = =A0
=A0 =A0 Answer 1.A: JWE
=A0 =A0 Answer 1.B: Key wrap, derive= d from JWE

Q2(Packing): How should the wrapped key= +attributes be expressed?
=A0 =A0 Answer 2.A: JSON format (not pa= cked)
=A0 =A0 Answer 2.B: JSON, with binary parts expressed directly=A0

JWE-within-JWK represents answer 1.A / 2.A. =A0The sol= ution proposed in my Unified Theory is 1.B / 2.B. =A0

<= div>For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys
-- We should not do things that would preclude accreditation under major s= ecurity standards (e.g., FIPS)
-- We should choose encodings that= minimize the size overhead imposed by the encoding
If we agree on these principles, then the answers to the above questio= ns seem pretty clear.

It seems to me that Steve= 9;s point on Question 1 pretty much decides the question for B. =A0If we wa= nt systems using JOSE to have any hope of getting accreditation (e.g., unde= r FIPS), then they will have to use standard mechanisms for protecting keys= , even if those keys are =A0packaged with other attributes. =A0Mike's m= essage misses the point that the key wrap algorithm isn't actually bein= g used to protect the key itself -- for that you would use a normal, conten= t-oriented encryption algorithm, in contravention of the FIPS requirements.=

Question 2 is mostly a question of backward compatibili= ty and efficiency. =A0If we want to have any hope of being backward-compati= ble with JWE key wrapping -- that is, avoiding having two ways to do the sa= me thing -- then we need a way to handle the octets of a key directly, as o= pposed to base64-encoded within a JSON object. =A0That would be option 2.B.=

There are also compactness arguments for 1.B and 2.B. = =A0If you do 1.A, then in addition to the header, you have to carry a separ= ate CMK, IV, and MAC value. =A0If you're using AES-GCM with a 128-bit k= ey, that's a total of 44 octets (16 CMK, 16 MAC, 12 IV). =A0In contrast= , if you just do AES key wrap, the wrapping algorithm adds a maximum of 16 = octets to the object. =A0The difference in case 2 is even greater, because = you're talking about double-base64 encoding, which entails a penalty of= 30% of the payload. =A0If you're protecting an AES key, this might onl= y be a few octets, but if you're protecting a 2048-bit RSA key, then yo= u're talking hundreds of octets. =A0So if you care about compactness, 1= .B and 2.B make a lot more sense.

To respond to Mike's specific points:

I=92ll note that in JSON = Web Encryption, we are already using standard methods for encrypting key va= lues for the Content Master Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).


However, the actual key= you're wrapping is still protected with a content-oriented algorithm. = =A0So you're still violating the FIPS requirements.
=A0

What we=92re talking abou= t here, however, is encrypting potentially more than just key values =96 in= this case, key values with associated key use information, algorithm information, key ID information, and potentially other attribute= s.=A0 As such, using the JWK JSON representation of this information as the= payload of a standard JWE encryption seems like the obvious solution, whic= h doesn=92t require inventing anything we don=92t already have.


Absolutely agree that JSON is the right representation. =A0But the ke= y is still included in that representation, so you need to apply key wrappi= ng algorithms to it. =A0And, as discussed above, it's a lot more effici= ent if you pack the JSON so that the binary isn't double-encoded.
=A0=A0

draft-miller-jose-jwe-pro= tected-jwk already describes doing that.=A0 I believe that we should adopt = this as a working group document as soon as the rechartering is complete.


That d= raft has some excellent suggestions for password-based key wrapping. =A0We = should incorporate that into whatever solution we come up with. =A0But for = the reasons discussed above, it's wrong in using JWK for the encapsulat= ion.

I also disagree that we need a separate document for th= is. =A0If we're going to avoid having two ways to wrap keys, this needs= to be part of JWE/JWK.

--Richard






=
=A0

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Sunday, March 10, 2013 8:06 AM
To: jose@ietf.org=
Subject: Re: [jose] A Unified Theory of JOSE Keys

=A0

On 03/10/2013 03:39 PM, Stephen Kent wrote:

Anthony,

=A0

Hi Richard,=

=A0<= /p>

As I read your note, you= =92re proposing a special-purpose encryption format to use for keys.=A0 I t= hink it would be simpler to use the general-purpose encryption format we already have (JWE) to encrypt keys.=A0 Indeed, draft-miller-jose= -jwe-protected-jwk already clearly describes


Without looking at the details of what is defined now, let me observe that = it is generally considered to
be a bad idea to use the same mechanism to encrypt keys and data. Because o= ne wants to prevent
inadvertent exposure of keys, we usually employ a different mechanism to en= crypt them, and we mark them
as keys vs. data. If anyone ever wants to get FIPS 140 evaluation for an im= plementation of the crypto
used to support JOSE, it probably will be necessary to adhere to such conve= ntions.

Interesting. Would you say that is a convention appl= ied by FIPS 140 labs or is that somewhere
in the FIPS specs?

=A0=A0=A0 =A0=A0=A0 Cheers Leif


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d0444709d11f55804d79712d9-- From Michael.Jones@microsoft.com Mon Mar 11 10:23:05 2013 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 DD63E11E816E for ; Mon, 11 Mar 2013 10:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 1Xqz4XNZKjgT for ; Mon, 11 Mar 2013 10:23:05 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id CA87111E815E for ; Mon, 11 Mar 2013 10:23:04 -0700 (PDT) Received: from BN1BFFO11FD020.protection.gbl (10.58.52.201) by BN1BFFO11HUB006.protection.gbl (10.58.53.116) with Microsoft SMTP Server (TLS) id 15.0.620.12; Mon, 11 Mar 2013 17:23:02 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD020.mail.protection.outlook.com (10.58.53.80) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Mon, 11 Mar 2013 17:23:01 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Mon, 11 Mar 2013 17:22:06 +0000 From: Mike Jones To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] updated draft charter text incorporating AD's comments Thread-Index: AQHOHbsFzhPDcbJYm0e4TO3t5oFBJZigvmCg Date: Mon, 11 Mar 2013 17:22:05 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F6B1E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <513CCD31.8050408@isoc.org> In-Reply-To: <513CCD31.8050408@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.33] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(199002)(189002)(377454001)(20776003)(80022001)(50986001)(74662001)(47736001)(47976001)(5343655001)(50466001)(66066001)(53806001)(16406001)(47446002)(23726001)(56776001)(49866001)(76482001)(46102001)(561944001)(51856001)(31966008)(79102001)(74502001)(63696002)(54356001)(33656001)(56816002)(47776003)(46406002)(54316002)(77982001)(4396001)(69226001)(65816001)(55846006)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB006; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0782EC617F Subject: Re: [jose] updated draft charter text incorporating AD's comments 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, 11 Mar 2013 17:23:06 -0000 Looks good to me -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Sunday, March 10, 2013 11:13 AM To: jose@ietf.org Subject: [jose] updated draft charter text incorporating AD's comments Folks, Here is the updated charter text based on Sean's comments and Mike's respon= se. If there are any errors, please identify them asap as I plan to forward= this back to Sean (and thus the IESG) in the very near future. Regards, Karen Description of JOSE Working Group JavaScript Object Notation (JSON) is a text format for the serialization of= structured data described in RFC 4627. The JSON format is often used for = serializing and transmitting structured data over a network connection. Wit= h the increased usage of JSON in protocols in the IETF and elsewhere, there= is now a desire to offer security services for JSON with encryption, digit= al signatures, and message authentication codes (MACs). Different proposals for providing such security services have already been = defined and implemented. This Working Group will standardize the mechanism= for integrity protection (signature and MAC) and encryption as well as the= format for keys and algorithm identifiers to support interoperability of s= ecurity services for protocols that use JSON. The Working Group will base i= ts work on well-known message security primitives (e.g., CMS), and will sol= icit input from the rest of the IETF Security Area to be sure that the secu= rity functionality in the JSON format is sound. As JSON adoption expands, the different applications utilizing JSON securit= y services will grow and this leads to the need to support different requir= ements.=20 The WG will develop a generic syntax that can be used by applications to secure JSON-da= ta, but it will be up to the application to fully specify the use of the WG= 's documents much the same way S/MIME is the application of CMS to MIME-bas= ed media types. This group is chartered to work on the following deliverables: (1) A Standards Track document or documents specifying how to apply JSON-st= ructured integrity protection to data, including (but not limited to) JSON = data structures. "Integrity protection" includes public-key digital signatures as well as sy= mmetric-key MACs. (2) A Standards Track document or documents specifying how to apply a JSON-= structured encryption to data, including (but not limited to) JSON data str= uctures. (3) A Standards Track document specifying how to encode public keys as JSON= - structured objects. (4) A Standards Track document specifying algorithms and algorithm identifi= ers for the previous three documents. (5) A Standards Track document specifying how to encode private and symmetr= ic keys as JSON-structured objects. This document will build upon the conc= epts and structures in (3). (6) A Standards Track document specifying a means of protecting private and= symmetric keys via encryption. This document will build upon the concepts= and structures in (2) and (5). This document may register additional algo= rithms in registries defined by (4). (7) An Informational document detailing Use Cases and Requirements for JSON= Object Signing and Encryption (JOSE). (8) An Informational document that tells an application what needs to be sp= ecified in order to implement JOSE. One or more of these goals may be combined into a single document, in which= case the concrete milestones for these goals will be satisfied by the cons= olidated document(s). _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From prvs=6782dedd61=dbrown@certicom.com Mon Mar 11 11:44:59 2013 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 81FE121F8E9E for ; Mon, 11 Mar 2013 11:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 ZJ2EGILtAfNA for ; Mon, 11 Mar 2013 11:44:58 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 7514821F8E9A for ; Mon, 11 Mar 2013 11:44:58 -0700 (PDT) X-AuditID: 0a41282f-b7fa06d000002431-d3-513e261c4a3a Received: from XCT108CNC.rim.net (xct108cnc.rim.net [10.65.161.208]) by mhs060cnc.rim.net (SBG) with SMTP id 02.6E.09265.C162E315; Mon, 11 Mar 2013 13:44:44 -0500 (CDT) Received: from XCT116CNC.rim.net (10.65.161.216) by XCT108CNC.rim.net (10.65.161.208) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 11 Mar 2013 14:44:44 -0400 Received: from XMB111CNC.rim.net ([fe80::fcd6:cc6c:9e0b:25bc]) by XCT116CNC.rim.net ([::1]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 14:44:43 -0400 From: Dan Brown To: 'Mike Jones' , "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] updated draft charter text incorporating AD's comments Thread-Index: AQHOHbsEEMu3ADlKPk6w4aZVomhFEpihAX+A///M3hA= Date: Mon, 11 Mar 2013 18:44:43 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF511144B@XMB111CNC.rim.net> References: <513CCD31.8050408@isoc.org> <4E1F6AAD24975D4BA5B1680429673943674F6B1E@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F6B1E@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.251] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBKsWRmVeSWpSXmKPExsXC5bjwgq6Mml2gwZxVahZr1nQzWeyd9onF Ytaj/cwOzB5Llvxk8ng1rZHVo3XHX/YA5qgGRpukxJKy4Mz0PH07m8S8vPySxJJUhZTU4mRb JZ/U9MQchYCizLLE5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsu BQxgA1SWmaeQmpecn5KZl26r5Bnsr2thYWqpa6hkp5vQyZPRfegQU8Fy1YovV2eyNTDuk+ti 5OCQEDCReNxj1MXICWSKSVy4t56ti5GLQ0hgFaPEnkUHmCCclYwSt18fZYVw5jBKbN94jhWk hU1AVeL+0XPMILaIQI1Ed+cCMFtYwEvi156Z7BBxb4nXy+azQNhWEseOHQHrZQHqvbXuMBuI zSvgJnF5ywSwGiGBOokfDW/AejkFEiVeXtgLFmcUkJXYffY6E4jNLCAucevJfCaIswUkluw5 zwxhi0q8fPyPFcJWlHgx+RwLRL2OxILdn9ggbG2JZQtfM0PsFZQ4OfMJ1F4FiSvX97FMYBSf hWTFLCTts5C0z0LSvoCRZRWjYG5GsYGZQXJesl5RZq5eXmrJJkZwUtHQ38H49r3FIUYBDkYl Hl4dJbtAIdbEsuLK3EOMEhzMSiK8KzfZBArxpiRWVqUW5ccXleakFh9idAWG0ERmKe7kfGDC yyuJNzYwwM1REucVCRQNFBJIB6ar7NTUgtQimDlMHJwge7ikRIqBSSe1KLG0JCMelBrji4HJ UaqBUd5eK+mTz4UkxdyFChLJ5yYHTmYU3N3fETfBUvq24fvqeZMaQw2UGu+pV277sj0uyC3Y IjvKeP3+B4ELT+WGCrmvqnh4qf7Rn7QvBvMnrv+0vrjyxqVVfS6vA5oTPFenMwV+8D3yb4tj WqrdAR8vFW4u5xNb5lwQMdiy7WDL5F/LjgSenso/VYmlOCPRUIu5qDgRAGJa1uprAwAA Subject: Re: [jose] updated draft charter text incorporating AD's comments 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, 11 Mar 2013 18:44:59 -0000 I just joined JOSE, and have a brief comment about JWA: For ECC-based encryption, it may make sense to use ECIES, because it complie= s with ANSI X9.63, IEEE P1363, ISO 18033-2, and SEC1. (The current CMS-base= d approach is slightly different.) If the list has already discussed this i= ssue, then please excuse me (and point me to the archive thread). Best regards, Daniel Brown Research In Motion Limited > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Mike Jones > Sent: Monday, March 11, 2013 1:22 PM > To: odonoghue@isoc.org; jose@ietf.org > Subject: Re: [jose] updated draft charter text incorporating AD's > comments > > Looks good to me > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Karen O'Donoghue > Sent: Sunday, March 10, 2013 11:13 AM > To: jose@ietf.org > Subject: [jose] updated draft charter text incorporating AD's comments > > Folks, > > Here is the updated charter text based on Sean's comments and Mike's > response. If there are any errors, please identify them asap as I plan > to forward this back to Sean (and thus the IESG) in the very near > future. > > Regards, > Karen > > > Description of JOSE Working Group > > JavaScript Object Notation (JSON) is a text format for the > serialization of structured data described in RFC 4627. The JSON > format is often used for serializing and transmitting structured data > over a network connection. With the increased usage of JSON in > protocols in the IETF and elsewhere, there is now a desire to offer > security services for JSON with encryption, digital signatures, and > message authentication codes (MACs). > > Different proposals for providing such security services have already > been defined and implemented. This Working Group will standardize the > mechanism for integrity protection (signature and MAC) and encryption > as well as the format for keys and algorithm identifiers to support > interoperability of security services for protocols that use JSON. The > Working Group will base its work on well-known message security > primitives (e.g., CMS), and will solicit input from the rest of the > IETF Security Area to be sure that the security functionality in the > JSON format is sound. > > As JSON adoption expands, the different applications utilizing JSON > security services will grow and this leads to the need to support > different requirements. > The WG will > develop a generic syntax that can be used by applications to secure > JSON-data, but it will be up to the application to fully specify the > use of the WG's documents much the same way S/MIME is the application > of CMS to MIME-based media types. > > This group is chartered to work on the following deliverables: > > (1) A Standards Track document or documents specifying how to apply > JSON-structured integrity protection to data, including (but not > limited to) JSON data structures. > "Integrity protection" includes public-key digital signatures as well > as symmetric-key MACs. > > (2) A Standards Track document or documents specifying how to apply a > JSON-structured encryption to data, including (but not limited to) JSON > data structures. > > (3) A Standards Track document specifying how to encode public keys as > JSON- structured objects. > > (4) A Standards Track document specifying algorithms and algorithm > identifiers for the previous three documents. > > (5) A Standards Track document specifying how to encode private and > symmetric keys as JSON-structured objects. This document will build > upon the concepts and structures in (3). > > (6) A Standards Track document specifying a means of protecting private > and symmetric keys via encryption. This document will build upon the > concepts and structures in (2) and (5). This document may register > additional algorithms in registries defined by (4). > > (7) An Informational document detailing Use Cases and Requirements for > JSON Object Signing and Encryption (JOSE). > > (8) An Informational document that tells an application what needs to > be specified in order to implement JOSE. > > One or more of these goals may be combined into a single document, in > which case the concrete milestones for these goals will be satisfied by > the consolidated document(s). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From odonoghue@isoc.org Mon Mar 11 17:31:12 2013 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 4079521F8D10 for ; Mon, 11 Mar 2013 17:31:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.82 X-Spam-Level: X-Spam-Status: No, score=-103.82 tagged_above=-999 required=5 tests=[AWL=-0.556, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 m-zb7LA-v1Jd for ; Mon, 11 Mar 2013 17:31:10 -0700 (PDT) Received: from smtp176.dfw.emailsrvr.com (smtp176.dfw.emailsrvr.com [67.192.241.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6A321F8D09 for ; Mon, 11 Mar 2013 17:31:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp7.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id CF2A32583B0 for ; Mon, 11 Mar 2013 20:31:09 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp7.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 9E4B3258311 for ; Mon, 11 Mar 2013 20:31:09 -0400 (EDT) Message-ID: <513E774C.6090605@isoc.org> Date: Mon, 11 Mar 2013 20:31:08 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org References: <513E6A73.1090403@isoc.org> In-Reply-To: <513E6A73.1090403@isoc.org> X-Forwarded-Message-Id: <513E6A73.1090403@isoc.org> Content-Type: multipart/alternative; boundary="------------070907060503010507020100" Subject: [jose] Proposed resolution of header criticality issue X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 00:31:12 -0000 This is a multi-part message in MIME format. --------------070907060503010507020100 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks, A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting. In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has not been rolled into the summary text below yet. Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone). Regards, Karen 1: Change the language "Additional members MAY be present in the JWK. If present, they MUST be understood by implementations using them." to "Additional members MAY be present in the JWK. If not understood by implementations encountering them, they MUST be ignored." (And make the same change for JWK Set as well.) 2: Characterize all existing JWS and JWE header fields as either must be understood or may be ignored. "alg", "enc", and "zip" must be understood. "kid", "x5u", "x5c", "x5t", "jwk", "jku", "typ", and "cty" can be ignored because while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation -- just degraded functionality. Other fields such as "epk", "apu", "apv", "epu", and "epv" must be understood and used when "alg" or "enc" values requiring them are used, and otherwise they may be ignored. 3. Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present. For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon. One possible name for this would be "crit" (critical). An example use, along with a hypothetical "exp" (expiration-time) field is: {"alg":"ES256", "crit":["exp"], "exp":1363284000 } 4. All additional header fields not defined in the base specifications and not contained in the "crit" list MUST be ignored if not understood. 5. Define a new header field "asd" (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds. The intended use of this field is to have a standard place to provide application-specific metadata about the payload or plaintext. --------------070907060503010507020100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Folks,

A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has not been rolled into the summary text below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone).

Regards,
Karen

1:  Change the language “Additional members MAY be present in the JWK.  If present, they MUST be understood by implementations using them.” to “Additional members MAY be present in the JWK.  If not understood by implementations encountering them, they MUST be ignored.”  (And make the same change for JWK Set as well.)

2:  Characterize all existing JWS and JWE header fields as either must be understood or may be ignored.  “alg”, “enc”, and “zip” must be understood.  “kid”, “x5u”, “x5c”, “x5t”, “jwk”, “jku”, “typ”, and “cty” can be ignored because while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation – just degraded functionality.  Other fields such as “epk”, “apu”, “apv”, “epu”, and “epv” must be understood and used when “alg” or “enc” values requiring them are used, and otherwise they may be ignored.

3.  Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present.  For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon.  One possible name for this would be “crit” (critical).  An example use, along with a hypothetical “exp” (expiration-time) field is:

  {"alg":"ES256",
   "crit":["exp"],
   "exp”:1363284000
  }

4.  All additional header fields not defined in the base specifications and not contained in the “crit” list MUST be ignored if not understood.

5.  Define a new header field “asd” (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.  The intended use of this field is to have a standard place to provide application-specific metadata about the payload or plaintext.



--------------070907060503010507020100-- From tbray@textuality.com Mon Mar 11 18:42:39 2013 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 16F0B21F8935 for ; Mon, 11 Mar 2013 18:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 Jr98aej6eqp5 for ; Mon, 11 Mar 2013 18:42:38 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id AD9AA21F88EF for ; Mon, 11 Mar 2013 18:42:37 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ec20so4637628lab.37 for ; Mon, 11 Mar 2013 18:42:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=q06PoW06gSd7v0rLKx9KdX+mmaaPCQBgqE+84AFXkQc=; b=R7rzLkx7JxFlpuqX5qco3lymiL/NYw5FaojBdXNfg3+ez5V8EdU2pwT/JnQsOrCLzJ AcRwcPdXUtcgd6yRalHq6tiovGlnEogTs6DfCpEuVuSzReokm1OvDuDGcEye/MBMxVqy Muf9foXH7O1er9uMrLK5EsyNnOO4cU4qhwaGTp/feQcg3A9M+SYJF33GUlVjUA69j0EZ /Y4nHebS6Qr7eOl8hrI3+2qMH7wSdUFmOTNDQQcJXwsBAr/5sfJ7yCbdj+I7SwN5NZQn Ab4NOGG2mrb5pz+RtRYrRErEahm5IOZ4fPuYV6nxv2/r+3fTmQ3c75rwv6mXSwuJvqJy l7ZA== MIME-Version: 1.0 X-Received: by 10.152.110.6 with SMTP id hw6mr12227436lab.43.1363052556526; Mon, 11 Mar 2013 18:42:36 -0700 (PDT) Received: by 10.114.37.228 with HTTP; Mon, 11 Mar 2013 18:42:36 -0700 (PDT) X-Originating-IP: [172.26.50.12] In-Reply-To: <513E774C.6090605@isoc.org> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> Date: Mon, 11 Mar 2013 18:42:36 -0700 Message-ID: From: Tim Bray To: Karen ODonoghue Content-Type: multipart/alternative; boundary=bcaec54b48d071445804d7b06703 X-Gm-Message-State: ALoCoQniJzAl/RvxhRH1EgQu/bHYn8uQnGFU5BLFOEO9f/8pmSNX1ii+QLMez8Fxhje4rKYQ2pkS Cc: jose Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 01:42:39 -0000 --bcaec54b48d071445804d7b06703 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cue wild cheers from the peanut gallery where non-cryptographers sit. MustIgnore is infinitely more robust and open-ended than MustUnderstand. -= T On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue wrote= : > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the meeting. > Point 5 of the proposed resolution below is actually independent of the > other 4 points, and could be considered separately. This will all be > discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must process". > However, that text has not been rolled into the summary text below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the JWK. = If > present, they MUST be understood by implementations using them.=94 to > =93Additional members MAY be present in the JWK. If not understood by > implementations encountering them, they MUST be ignored.=94 (And make th= e > same change for JWK Set as well.)******** > > 2: Characterize all existing JWS and JWE header fields as either must be > understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 must b= e understood. > =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ= =94, and =93cty=94 can be ignored > because while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as =93epk= =94, > =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be understood and use= d when =93alg=94 or > =93enc=94 values requiring them are used, and otherwise they may be ignor= ed.** > ** > **** > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon when > present. For instance, an expiration-time extension field could be marke= d > as must-be-understood-and-acted-upon. One possible name for this would b= e > =93crit=94 (critical). An example use, along with a hypothetical =93exp= =94 > (expiration-time) field is:**** > > {"alg":"ES256",**** > "crit":["exp"],**** > "exp=94:1363284000**** > }**** > **** > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not understoo= d.*** > ***** > > 5. Define a new header field =93asd=94 (application-specific data) whose > value is a JSON structure whose contents are opaque to and ignored by JWS > and JWE implementations but for which its contents MUST be provided to > applications using JWS or JWE, provided that the signature/MAC validation > or decryption operation succeeds. The intended use of this field is to > have a standard place to provide application-specific metadata about the > payload or plaintext.**** > **** > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54b48d071445804d7b06703 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Cue wild cheers from the peanut gallery where non-cryptogr= aphers sit.=A0 MustIgnore is infinitely more robust and open-ended than Mus= tUnderstand.=A0 -T


On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <= ;odonoghue@isoc.org= > wrote:
=20 =20 =20

Folks,

A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has no= t been rolled into the summary text below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone).

Regards,
Karen

1:=A0 Change the language =93Additional members MAY be present in the JWK. =A0If present, they MUST be understood by implementations using them.=94 to =93Additional members MAY be present in the JWK. =A0If not understood by implementations encountering them, they MUST be ignored.=94=A0 (And make the same change for JWK Set as well.)

2:=A0 Characterize all existing JWS and JWE header fields as either must be understood or may be ignored.=A0 =93alg=94, =93enc= =94, and =93zip=94 must be understood.=A0 =93kid=94, =93x5u=94, =93x5c= =94, =93x5t=94, =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored bec= ause while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation =96 just degraded functionality.=A0 Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and = =93epv=94 must be understood and used when =93alg=94 or =93enc=94 values requiring = them are used, and otherwise they may be ignored.

3.=A0 Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present.=A0 For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon.=A0 One possible name for this would be =93crit=94 (critical).=A0 An example use, along with a hypothetical =93exp=94 (expiration-time) field is:<= br>
=A0 {"alg":"ES256",
=A0=A0 "crit":["exp"],
=A0=A0 "exp=94:1363284000
=A0 }

4.=A0 All additional header fields not defined in the base specifications and not contained in the =93crit=94 list MUST be ignored if not understood.

5.=A0 Define a new header field =93asd=94 (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.=A0 The intended use of this field is to have a standard place to provide application-specific metadata about the payload or plaintext.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec54b48d071445804d7b06703-- From James.H.Manger@team.telstra.com Mon Mar 11 19:30:35 2013 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 0DF2521F8A9B for ; Mon, 11 Mar 2013 19:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 natYR397eZdm for ; Mon, 11 Mar 2013 19:30:33 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id DA31D21F8A74 for ; Mon, 11 Mar 2013 19:30:32 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,827,1355058000"; d="scan'208,217";a="123353436" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 13:30:31 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="117578207" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcbvi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 13:30:31 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 12 Mar 2013 13:30:31 +1100 From: "Manger, James H" To: Richard Barnes , "jose@ietf.org" Date: Tue, 12 Mar 2013 13:30:29 +1100 Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: Ac4dxY1cMwQeZzZXQPyZ1OP6DJCbhwA9qj6w Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B7865C8WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 12 Mar 2013 02:30:35 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B7865C8WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcQSBVbmlmaWVkIFRoZW9yeSBvZiBKT1NFIEtleXPigJ0gPGh0dHA6Ly93d3cuaXB2LnN4L2ll dGY4Ni9qb3NlLWtleXMucGRmPiBsb29rcyBxdWl0ZSBnb29kLg0KDQpJdCBsb29rcyBsaWtlIGEg a2V5IGlzIGEgSlNPTiBvYmplY3Qgd2l0aCBhbnkgbnVtYmVyIG9mIG5hbWUvdmFsdWUgcGFpcnMu IEZvciBzb21lIG5hbWVzLCB0aGUgdmFsdWUgaXMgYSBiYXNlNjRbdXJsXS1lbmNvZGluZyBvZiBi aW5hcnkgZGF0YS4NCg0KVG8gd3JhcCBhIGtleSwgaXRzIG5hbWUvdmFsdWUgcGFpcnMgYXJlIGRp dmlkZWQgaW50byAzIGdyb3VwczoNCg0KMS4gICAgICAgbm9uLWNvbmZpZGVudGlhbCBuYW1lL3Zh bHVlIHBhaXJzDQoNCjIuICAgICAgIGNvbmZpZGVudGlhbCBub24tYmluYXJ5IG5hbWUvdmFsdWUg cGFpcnMNCg0KMy4gICAgICAgY29uZmlkZW50aWFsIGJpbmFyeSBuYW1lL3ZhbHVlIHBhaXJzDQoN ClRoZSBmaXJzdCBncm91cCBhcmUgcHV0IGludG8gdGhlIOKAnGthdOKAnSAoa2V5IGF0dHJpYnV0 ZXM/KSBmaWVsZCBvZiB0aGUgb3V0cHV0Lg0KDQpUaGUgc2Vjb25kIGdyb3VwIOKAlCBpZiBpdHMg bm90IGVtcHR5IOKAlCBiZWNvbWVzIHRoZSBmaXJzdCBiaW5hcnkgc2VnbWVudCBvZiB0aGUgcGxh aW50ZXh0IChhcyBhIFVURi04LWVuY29kZWQgSlNPTiBvYmplY3QpLiDigJx3auKAnTp0cnVlIGlu IHRoZSBvdXRwdXQgaW5kaWNhdGVzIHRoZSBzZWNvbmQgZ3JvdXAgaXMgcHJlc2VudC4NCg0KVGhl IHRoaXJkIGdyb3VwIChpbiBvcmRlcikgYmVjb21lIHN1YnNlcXVlbnQgYmluYXJ5IHNlZ21lbnRz IG9mIHRoZSBwbGFpbnRleHQuIFRoZSBuYW1lcyBpbiB0aGUgdGhpcmQgZ3JvdXAgKGFuZCB0aGVp ciBvcmRlcikgaXMgZGV0ZXJtaW5lZCBieSB0aGUgdHlwZSBvZiB0aGUga2V5IGJlaW5nIHdyYXBw ZWQgKOKAnGt0eeKAnSBhdHRyaWJ1dGUpLg0KDQpUaGUgcGxhaW50ZXh0IGlzIHdyYXBwZWQgKGVu Y3J5cHRlZCksIHRoZW4gYmFzZTY0dXJsLWVuY29kZWQgdG8gZ2l2ZSB0aGUg4oCcd2vigJ0gYXR0 cmlidXRlIGluIHRoZSBvdXRwdXQuDQoNCg0KUTEuIFRoZSBleGFtcGxlcyBvZiB3cmFwcGluZyBh biBSU0Ega2V5IGluY2x1ZGUg4oCcZOKAnTrigKYgaW4g4oCca2F04oCdLiBJIGFzc3VtZSB0aGlz IGlzIGEgdHlwby4g4oCca2F04oCdIHdvdWxkIGluY2x1ZGUg4oCcbuKAnSBhbmQg4oCcZeKAnSwg YnV0IOKAnGTigJ0gKHRoZSBwcml2YXRlIGV4cG9uZW50KSB3b3VsZCBhbHdheXMgYmUgZW5jcnlw dGVkIGFuZCBoZW5jZSBiZSBpbnNpZGUg4oCcd2vigJ0uDQoNClEyLiBEb2VzIGtleSB3cmFwcGlu ZyBnaXZlIGludGVncml0eSBwcm90ZWN0aW9uIHRoYXQgeW91IG1pZ2h0IHdhbnQgZm9yIG5hbWUv dmFsdWUgcGFpcnMgZXZlbiB3aGVuIHRoZXkgYXJlIG5vdCBjb25maWRlbnRpYWwuIEZvciBpbnN0 YW5jZSwgY291bGQgaXQgYmUgdXNlZnVsIHRvIGluY2x1ZGUsIHNheSwg4oCcZeKAnSBpbnNpZGUg 4oCcd2vigJ0gaW5zdGVhZCBvZiB3aXRoaW4g4oCca2F04oCdPyBEbyByZWNpcGllbnRzIG5lZWQg dG8gY2hlY2sgYm90aCB0aGUgZmlyc3QgYmluYXJ5IHNlZ21lbnQgYW5kIOKAnGthdOKAnSB3aGVu IGxvb2tpbmcgZm9yIGFueSBhdHRyaWJ1dGUgbm90IGV4cGxpY2l0bHkgbGlzdGVkIGluIHRoZSDi gJxlbmNvZGluZyBydWxlc+KAnT8gRG9lcyB0aGUgZmlyc3QgYmluYXJ5IHNlZ21lbnQgdGFrZSBw cmVjZWRlbmNlIG92ZXIg4oCca2F04oCdPw0KDQpRMy4gU2hvdWxkIOKAnGt0eeKAnSAoa2V5IHR5 cGUpIGFwcGVhciB3aXRoaW4g4oCca2F04oCdPyBUaGUgZXhhbXBsZXMgc2hvdyBpdCBhcyBhIHRv cC1sZXZlbCBhdHRyaWJ1dGUgaW5zdGVhZC4NCg0KQTQuIFRoZSBzeW1tZXRyaWMga2V5IGV4YW1w bGVzIGRvbuKAmXQgaW5jbHVkZSBhIGtleSB0eXBlICjigJxrdHnigJ0pLiBJcyBpdCBpbXBsaWVk IGJ5IHNvbWV0aGluZyBhdCBhIGhpZ2hlciBsZXZlbCAoZWcgYSBKV0UpLCBvciBpcyB0aGVyZSBh IGRlZmF1bHQgdmFsdWUgbWVhbmluZyDigJxhIHNoYXJlZCBzeW1tZXRyaWMgc2VjcmV0LCB3aXRo IG5vIHNwZWNpZmljIGFzc29jaWF0ZWQgY3J5cHRvIGFsZ29yaXRobeKAnT8NCg0KUTUuIFVzaW5n IGEgVkFSSU5UICh2YXJpYWJsZS1sZW5ndGggaW50ZWdlcikgaW5zdGVhZCBvZiAyIGJ5dGVzIHdv dWxkIGJlIGJldHRlciBmb3IgZW5jb2RpbmcgdGhlIGxlbmd0aCBvZiBiaW5hcnkgc2VnbWVudHMu IDIgYnl0ZXMgKDY0IEtCIG1heCkgbWlnaHQgYmUgdG9vIHNtYWxsLCBwYXJ0aWN1bGFybHkgaWYg dGhlIGJpbmFyeSBlbmNvZGluZyBpcyB1c2VkIGZvciBhbGwgSk9TRSBtZXNzYWdlcyAoZWcgSldF KSBub3QganVzdCBrZXlzLg0KDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogam9zZS1ib3Vu Y2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2Yg UmljaGFyZCBCYXJuZXMNClNlbnQ6IE1vbmRheSwgMTEgTWFyY2ggMjAxMyA2OjI5IEFNDQpUbzog TWlrZSBKb25lcw0KQ2M6IExlaWYgSm9oYW5zc29uOyBqb3NlQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW2pvc2VdIEEgVW5pZmllZCBUaGVvcnkgb2YgSk9TRSBLZXlzDQoNClNvIGl0IHNlZW1zIHRv IG1lIHRoYXQgdGhlIGdyb3VwIGhhcyB0aHJlZSBxdWVzdGlvbnMgdG8gYW5zd2VyIHdoZW4gaXQg Y29tZXMgdG8gd3JhcHBlZCBrZXlzOg0KDQpRMShFbmNyeXB0aW9uKTogV2hhdCBtZWNoYW5pc20g d2lsbCBiZSB1c2VkIHRvIGVuY3J5cHQga2V5IG1hdGVyaWFsLCBwb3NzaWJseSBjb250YWluaW5n IGF0dHJpYnV0ZXM/DQogICAgQW5zd2VyIDEuQTogSldFDQogICAgQW5zd2VyIDEuQjogS2V5IHdy YXAsIGRlcml2ZWQgZnJvbSBKV0UNCg0KUTIoUGFja2luZyk6IEhvdyBzaG91bGQgdGhlIHdyYXBw ZWQga2V5K2F0dHJpYnV0ZXMgYmUgZXhwcmVzc2VkPw0KICAgIEFuc3dlciAyLkE6IEpTT04gZm9y bWF0IChub3QgcGFja2VkKQ0KICAgIEFuc3dlciAyLkI6IEpTT04sIHdpdGggYmluYXJ5IHBhcnRz IGV4cHJlc3NlZCBkaXJlY3RseQ0KDQpKV0Utd2l0aGluLUpXSyByZXByZXNlbnRzIGFuc3dlciAx LkEgLyAyLkEuICBUaGUgc29sdXRpb24gcHJvcG9zZWQgaW4gbXkgVW5pZmllZCBUaGVvcnkgaXMg MS5CIC8gMi5CLg0KDQpGb3IgY29udGV4dCwgSSdtIHdvcmtpbmcgZnJvbSBhIGZldyBwcmluY2lw bGVzIGhlcmU6DQotLSBXZSBzaG91bGQgbm90IGRlZmluZSBtdWx0aXBsZSB3YXlzIHRvIHdyYXAg c3ltbWV0cmljIGtleXMNCi0tIFdlIHNob3VsZCBub3QgZG8gdGhpbmdzIHRoYXQgd291bGQgcHJl Y2x1ZGUgYWNjcmVkaXRhdGlvbiB1bmRlciBtYWpvciBzZWN1cml0eSBzdGFuZGFyZHMgKGUuZy4s IEZJUFMpDQotLSBXZSBzaG91bGQgY2hvb3NlIGVuY29kaW5ncyB0aGF0IG1pbmltaXplIHRoZSBz aXplIG92ZXJoZWFkIGltcG9zZWQgYnkgdGhlIGVuY29kaW5nDQpJZiB3ZSBhZ3JlZSBvbiB0aGVz ZSBwcmluY2lwbGVzLCB0aGVuIHRoZSBhbnN3ZXJzIHRvIHRoZSBhYm92ZSBxdWVzdGlvbnMgc2Vl bSBwcmV0dHkgY2xlYXIuDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgU3RldmUncyBwb2ludCBvbiBR dWVzdGlvbiAxIHByZXR0eSBtdWNoIGRlY2lkZXMgdGhlIHF1ZXN0aW9uIGZvciBCLiAgSWYgd2Ug d2FudCBzeXN0ZW1zIHVzaW5nIEpPU0UgdG8gaGF2ZSBhbnkgaG9wZSBvZiBnZXR0aW5nIGFjY3Jl ZGl0YXRpb24gKGUuZy4sIHVuZGVyIEZJUFMpLCB0aGVuIHRoZXkgd2lsbCBoYXZlIHRvIHVzZSBz dGFuZGFyZCBtZWNoYW5pc21zIGZvciBwcm90ZWN0aW5nIGtleXMsIGV2ZW4gaWYgdGhvc2Uga2V5 cyBhcmUgIHBhY2thZ2VkIHdpdGggb3RoZXIgYXR0cmlidXRlcy4gIE1pa2UncyBtZXNzYWdlIG1p c3NlcyB0aGUgcG9pbnQgdGhhdCB0aGUga2V5IHdyYXAgYWxnb3JpdGhtIGlzbid0IGFjdHVhbGx5 IGJlaW5nIHVzZWQgdG8gcHJvdGVjdCB0aGUga2V5IGl0c2VsZiAtLSBmb3IgdGhhdCB5b3Ugd291 bGQgdXNlIGEgbm9ybWFsLCBjb250ZW50LW9yaWVudGVkIGVuY3J5cHRpb24gYWxnb3JpdGhtLCBp biBjb250cmF2ZW50aW9uIG9mIHRoZSBGSVBTIHJlcXVpcmVtZW50cy4NCg0KUXVlc3Rpb24gMiBp cyBtb3N0bHkgYSBxdWVzdGlvbiBvZiBiYWNrd2FyZCBjb21wYXRpYmlsaXR5IGFuZCBlZmZpY2ll bmN5LiAgSWYgd2Ugd2FudCB0byBoYXZlIGFueSBob3BlIG9mIGJlaW5nIGJhY2t3YXJkLWNvbXBh dGlibGUgd2l0aCBKV0Uga2V5IHdyYXBwaW5nIC0tIHRoYXQgaXMsIGF2b2lkaW5nIGhhdmluZyB0 d28gd2F5cyB0byBkbyB0aGUgc2FtZSB0aGluZyAtLSB0aGVuIHdlIG5lZWQgYSB3YXkgdG8gaGFu ZGxlIHRoZSBvY3RldHMgb2YgYSBrZXkgZGlyZWN0bHksIGFzIG9wcG9zZWQgdG8gYmFzZTY0LWVu Y29kZWQgd2l0aGluIGEgSlNPTiBvYmplY3QuICBUaGF0IHdvdWxkIGJlIG9wdGlvbiAyLkIuDQoN ClRoZXJlIGFyZSBhbHNvIGNvbXBhY3RuZXNzIGFyZ3VtZW50cyBmb3IgMS5CIGFuZCAyLkIuICBJ ZiB5b3UgZG8gMS5BLCB0aGVuIGluIGFkZGl0aW9uIHRvIHRoZSBoZWFkZXIsIHlvdSBoYXZlIHRv IGNhcnJ5IGEgc2VwYXJhdGUgQ01LLCBJViwgYW5kIE1BQyB2YWx1ZS4gIElmIHlvdSdyZSB1c2lu ZyBBRVMtR0NNIHdpdGggYSAxMjgtYml0IGtleSwgdGhhdCdzIGEgdG90YWwgb2YgNDQgb2N0ZXRz ICgxNiBDTUssIDE2IE1BQywgMTIgSVYpLiAgSW4gY29udHJhc3QsIGlmIHlvdSBqdXN0IGRvIEFF UyBrZXkgd3JhcCwgdGhlIHdyYXBwaW5nIGFsZ29yaXRobSBhZGRzIGEgbWF4aW11bSBvZiAxNiBv Y3RldHMgdG8gdGhlIG9iamVjdC4gIFRoZSBkaWZmZXJlbmNlIGluIGNhc2UgMiBpcyBldmVuIGdy ZWF0ZXIsIGJlY2F1c2UgeW91J3JlIHRhbGtpbmcgYWJvdXQgZG91YmxlLWJhc2U2NCBlbmNvZGlu Zywgd2hpY2ggZW50YWlscyBhIHBlbmFsdHkgb2YgMzAlIG9mIHRoZSBwYXlsb2FkLiAgSWYgeW91 J3JlIHByb3RlY3RpbmcgYW4gQUVTIGtleSwgdGhpcyBtaWdodCBvbmx5IGJlIGEgZmV3IG9jdGV0 cywgYnV0IGlmIHlvdSdyZSBwcm90ZWN0aW5nIGEgMjA0OC1iaXQgUlNBIGtleSwgdGhlbiB5b3Un cmUgdGFsa2luZyBodW5kcmVkcyBvZiBvY3RldHMuICBTbyBpZiB5b3UgY2FyZSBhYm91dCBjb21w YWN0bmVzcywgMS5CIGFuZCAyLkIgbWFrZSBhIGxvdCBtb3JlIHNlbnNlLg0KDQpUbyByZXNwb25k IHRvIE1pa2UncyBzcGVjaWZpYyBwb2ludHM6DQoNCknigJlsbCBub3RlIHRoYXQgaW4gSlNPTiBX ZWIgRW5jcnlwdGlvbiwgd2UgYXJlIGFscmVhZHkgdXNpbmcgc3RhbmRhcmQgbWV0aG9kcyBmb3Ig ZW5jcnlwdGluZyBrZXkgdmFsdWVzIGZvciB0aGUgQ29udGVudCBNYXN0ZXIgS2V5IOKAkyBzcGVj aWZpY2FsbHkgQUVTIEtleSBXcmFwLCBSU0EgUEtDUyAjMSAxLjUsIGFuZCBSU0EgT0FFUCAocGx1 cyBzdXBwb3J0aW5nIEVDREgtRVMga2V5IGFncmVlbWVudCkuDQoNCkhvd2V2ZXIsIHRoZSBhY3R1 YWwga2V5IHlvdSdyZSB3cmFwcGluZyBpcyBzdGlsbCBwcm90ZWN0ZWQgd2l0aCBhIGNvbnRlbnQt b3JpZW50ZWQgYWxnb3JpdGhtLiAgU28geW91J3JlIHN0aWxsIHZpb2xhdGluZyB0aGUgRklQUyBy ZXF1aXJlbWVudHMuDQoNCg0KV2hhdCB3ZeKAmXJlIHRhbGtpbmcgYWJvdXQgaGVyZSwgaG93ZXZl ciwgaXMgZW5jcnlwdGluZyBwb3RlbnRpYWxseSBtb3JlIHRoYW4ganVzdCBrZXkgdmFsdWVzIOKA kyBpbiB0aGlzIGNhc2UsIGtleSB2YWx1ZXMgd2l0aCBhc3NvY2lhdGVkIGtleSB1c2UgaW5mb3Jt YXRpb24sIGFsZ29yaXRobSBpbmZvcm1hdGlvbiwga2V5IElEIGluZm9ybWF0aW9uLCBhbmQgcG90 ZW50aWFsbHkgb3RoZXIgYXR0cmlidXRlcy4gIEFzIHN1Y2gsIHVzaW5nIHRoZSBKV0sgSlNPTiBy ZXByZXNlbnRhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGFzIHRoZSBwYXlsb2FkIG9mIGEgc3Rh bmRhcmQgSldFIGVuY3J5cHRpb24gc2VlbXMgbGlrZSB0aGUgb2J2aW91cyBzb2x1dGlvbiwgd2hp Y2ggZG9lc27igJl0IHJlcXVpcmUgaW52ZW50aW5nIGFueXRoaW5nIHdlIGRvbuKAmXQgYWxyZWFk eSBoYXZlLg0KDQpBYnNvbHV0ZWx5IGFncmVlIHRoYXQgSlNPTiBpcyB0aGUgcmlnaHQgcmVwcmVz ZW50YXRpb24uICBCdXQgdGhlIGtleSBpcyBzdGlsbCBpbmNsdWRlZCBpbiB0aGF0IHJlcHJlc2Vu dGF0aW9uLCBzbyB5b3UgbmVlZCB0byBhcHBseSBrZXkgd3JhcHBpbmcgYWxnb3JpdGhtcyB0byBp dC4gIEFuZCwgYXMgZGlzY3Vzc2VkIGFib3ZlLCBpdCdzIGEgbG90IG1vcmUgZWZmaWNpZW50IGlm IHlvdSBwYWNrIHRoZSBKU09OIHNvIHRoYXQgdGhlIGJpbmFyeSBpc24ndCBkb3VibGUtZW5jb2Rl ZC4NCg0KZHJhZnQtbWlsbGVyLWpvc2UtandlLXByb3RlY3RlZC1qd2sgYWxyZWFkeSBkZXNjcmli ZXMgZG9pbmcgdGhhdC4gIEkgYmVsaWV2ZSB0aGF0IHdlIHNob3VsZCBhZG9wdCB0aGlzIGFzIGEg d29ya2luZyBncm91cCBkb2N1bWVudCBhcyBzb29uIGFzIHRoZSByZWNoYXJ0ZXJpbmcgaXMgY29t cGxldGUuDQoNClRoYXQgZHJhZnQgaGFzIHNvbWUgZXhjZWxsZW50IHN1Z2dlc3Rpb25zIGZvciBw YXNzd29yZC1iYXNlZCBrZXkgd3JhcHBpbmcuICBXZSBzaG91bGQgaW5jb3Jwb3JhdGUgdGhhdCBp bnRvIHdoYXRldmVyIHNvbHV0aW9uIHdlIGNvbWUgdXAgd2l0aC4gIEJ1dCBmb3IgdGhlIHJlYXNv bnMgZGlzY3Vzc2VkIGFib3ZlLCBpdCdzIHdyb25nIGluIHVzaW5nIEpXSyBmb3IgdGhlIGVuY2Fw c3VsYXRpb24uDQoNCkkgYWxzbyBkaXNhZ3JlZSB0aGF0IHdlIG5lZWQgYSBzZXBhcmF0ZSBkb2N1 bWVudCBmb3IgdGhpcy4gIElmIHdlJ3JlIGdvaW5nIHRvIGF2b2lkIGhhdmluZyB0d28gd2F5cyB0 byB3cmFwIGtleXMsIHRoaXMgbmVlZHMgdG8gYmUgcGFydCBvZiBKV0UvSldLLg0KDQotLVJpY2hh cmQNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgLS0gTWlrZQ0K --_000_255B9BB34FB7D647A506DC292726F6E1150B7865C8WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx IDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46 MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU3NzIwNzEyNjsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6Mzk0NzEyODg4IDIwMTkxNjQzMSAy MDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQzMSAyMDE5MTY0NDEgMjAxOTE2NDQzIDIwMTkxNjQz MSAyMDE5MTY0NDEgMjAxOTE2NDQzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo5NTEwODQzMDA7DQoJbXNvLWxp c3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjAyNjExOTAyIC05NDk5 OTQzMzQgMjAxOTE2NDE5IDIwMTkxNjQyMSAyMDE5MTY0MTcgMjAxOTE2NDE5IDIwMTkxNjQyMSAy MDE5MTY0MTcgMjAxOTE2NDE5IDIwMTkxNjQyMTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxl dmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxNDMx ODU3MjgwOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczot MTY5NDA1NDQ4MCAyMDE5MTY0MzEgMjAxOTE2NDQxIDIwMTkxNjQ0MyAyMDE5MTY0MzEgMjAxOTE2 NDQxIDIwMTkxNjQ0MyAyMDE5MTY0MzEgMjAxOTE2NDQxIDIwMTkxNjQ0Mzt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3Qt aWQ6MjEyOTkzNTY3MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6Mzc2MzYwNDIgMjAxOTE2NDMxIDIwMTkxNjQ0MSAyMDE5MTY0NDMgMjAxOTE2NDMxIDIw MTkxNjQ0MSAyMDE5MTY0NDMgMjAxOTE2NDMxIDIwMTkxNjQ0MSAyMDE5MTY0NDM7fQ0KQGxpc3Qg bDM6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPuKAnEEgVW5pZmllZCBUaGVvcnkg b2YgSk9TRSBLZXlz4oCdICZsdDtodHRwOi8vd3d3Lmlwdi5zeC9pZXRmODYvam9zZS1rZXlzLnBk ZiZndDsgbG9va3MgcXVpdGUgZ29vZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IGxvb2tzIGxpa2Ug YSBrZXkgaXMgYSBKU09OIG9iamVjdCB3aXRoIGFueSBudW1iZXIgb2YgbmFtZS92YWx1ZSBwYWly cy4gRm9yIHNvbWUgbmFtZXMsIHRoZSB2YWx1ZSBpcyBhIGJhc2U2NFt1cmxdLWVuY29kaW5nIG9m IGJpbmFyeSBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VG8gd3JhcCBhIGtleSwgaXRzIG5hbWUv dmFsdWUgcGFpcnMgYXJlIGRpdmlkZWQgaW50byAzIGdyb3Vwczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMyBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4xLjxzcGFuIHN0eWxlPSdm b250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+bm9uLWNvbmZpZGVudGlhbCBuYW1lL3ZhbHVlIHBhaXJzPG86cD48L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb0xpc3RQYXJhZ3JhcGggc3R5bGU9J3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMnPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+Mi48c3BhbiBzdHlsZT0n Zm9udDo3LjBwdCAiVGltZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPmNvbmZpZGVudGlhbCBub24tYmluYXJ5IG5hbWUvdmFsdWUgcGFpcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTGlzdFBhcmFncmFwaCBzdHlsZT0ndGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHlsZT0nbXNvLWxpc3Q6SWdub3JlJz4zLjxzcGFu IHN0eWxlPSdmb250OjcuMHB0ICJUaW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+Y29uZmlkZW50aWFsIGJpbmFyeSBuYW1lL3ZhbHVlIHBhaXJzPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGUgZmlyc3QgZ3JvdXAgYXJlIHB1dCBpbnRvIHRoZSDigJxrYXTigJ0g KGtleSBhdHRyaWJ1dGVzPykgZmllbGQgb2YgdGhlIG91dHB1dC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlRoZSBzZWNvbmQgZ3JvdXAg4oCUIGlmIGl0cyBub3QgZW1wdHkg4oCUIGJlY29tZXMgdGhlIGZp cnN0IGJpbmFyeSBzZWdtZW50IG9mIHRoZSBwbGFpbnRleHQgKGFzIGEgVVRGLTgtZW5jb2RlZCBK U09OIG9iamVjdCkuIOKAnHdq4oCdOnRydWUgaW4gdGhlIG91dHB1dCBpbmRpY2F0ZXMgdGhlIHNl Y29uZCBncm91cCBpcyBwcmVzZW50LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHRoaXJkIGdyb3Vw IChpbiBvcmRlcikgYmVjb21lIHN1YnNlcXVlbnQgYmluYXJ5IHNlZ21lbnRzIG9mIHRoZSBwbGFp bnRleHQuIFRoZSBuYW1lcyBpbiB0aGUgdGhpcmQgZ3JvdXAgKGFuZCB0aGVpciBvcmRlcikgaXMg ZGV0ZXJtaW5lZCBieSB0aGUgdHlwZSBvZiB0aGUga2V5IGJlaW5nIHdyYXBwZWQgKOKAnGt0eeKA nSBhdHRyaWJ1dGUpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIHBsYWludGV4dCBpcyB3cmFwcGVk IChlbmNyeXB0ZWQpLCB0aGVuIGJhc2U2NHVybC1lbmNvZGVkIHRvIGdpdmUgdGhlIOKAnHdr4oCd IGF0dHJpYnV0ZSBpbiB0aGUgb3V0cHV0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PlExLiBUaGUgZXhhbXBsZXMgb2Ygd3JhcHBpbmcgYW4gUlNBIGtleSBpbmNsdWRlIOKAnGTigJ06 4oCmIGluIOKAnGthdOKAnS4gSSBhc3N1bWUgdGhpcyBpcyBhIHR5cG8uIOKAnGthdOKAnSB3b3Vs ZCBpbmNsdWRlIOKAnG7igJ0gYW5kIOKAnGXigJ0sIGJ1dCDigJxk4oCdICh0aGUgcHJpdmF0ZSBl eHBvbmVudCkgd291bGQgYWx3YXlzIGJlIGVuY3J5cHRlZCBhbmQgaGVuY2UgYmUgaW5zaWRlIOKA nHdr4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UTIuIERvZXMga2V5IHdyYXBwaW5nIGdpdmUgaW50 ZWdyaXR5IHByb3RlY3Rpb24gdGhhdCB5b3UgbWlnaHQgd2FudCBmb3IgbmFtZS92YWx1ZSBwYWly cyBldmVuIHdoZW4gdGhleSBhcmUgbm90IGNvbmZpZGVudGlhbC4gRm9yIGluc3RhbmNlLCBjb3Vs ZCBpdCBiZSB1c2VmdWwgdG8gaW5jbHVkZSwgc2F5LCDigJxl4oCdIGluc2lkZSDigJx3a+KAnSBp bnN0ZWFkIG9mIHdpdGhpbiDigJxrYXTigJ0/IERvIHJlY2lwaWVudHMgbmVlZCB0byBjaGVjayBi b3RoIHRoZSBmaXJzdCBiaW5hcnkgc2VnbWVudCBhbmQg4oCca2F04oCdIHdoZW4gbG9va2luZyBm b3IgYW55IGF0dHJpYnV0ZSBub3QgZXhwbGljaXRseSBsaXN0ZWQgaW4gdGhlIOKAnGVuY29kaW5n IHJ1bGVz4oCdPyBEb2VzIHRoZSBmaXJzdCBiaW5hcnkgc2VnbWVudCB0YWtlIHByZWNlZGVuY2Ug b3ZlciDigJxrYXTigJ0/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5RMy4gU2hvdWxkIOKAnGt0eeKAnSAo a2V5IHR5cGUpIGFwcGVhciB3aXRoaW4g4oCca2F04oCdPyBUaGUgZXhhbXBsZXMgc2hvdyBpdCBh cyBhIHRvcC1sZXZlbCBhdHRyaWJ1dGUgaW5zdGVhZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkE0LiBU aGUgc3ltbWV0cmljIGtleSBleGFtcGxlcyBkb27igJl0IGluY2x1ZGUgYSBrZXkgdHlwZSAo4oCc a3R54oCdKS4gSXMgaXQgaW1wbGllZCBieSBzb21ldGhpbmcgYXQgYSBoaWdoZXIgbGV2ZWwgKGVn IGEgSldFKSwgb3IgaXMgdGhlcmUgYSBkZWZhdWx0IHZhbHVlIG1lYW5pbmcg4oCcYSBzaGFyZWQg c3ltbWV0cmljIHNlY3JldCwgd2l0aCBubyBzcGVjaWZpYyBhc3NvY2lhdGVkIGNyeXB0byBhbGdv cml0aG3igJ0/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5RNS4gVXNpbmcgYSBWQVJJTlQgKHZhcmlhYmxl LWxlbmd0aCBpbnRlZ2VyKSBpbnN0ZWFkIG9mIDIgYnl0ZXMgd291bGQgYmUgYmV0dGVyIGZvciBl bmNvZGluZyB0aGUgbGVuZ3RoIG9mIGJpbmFyeSBzZWdtZW50cy4gMiBieXRlcyAoNjQgS0IgbWF4 KSBtaWdodCBiZSB0b28gc21hbGwsIHBhcnRpY3VsYXJseSBpZiB0aGUgYmluYXJ5IGVuY29kaW5n IGlzIHVzZWQgZm9yIGFsbCBKT1NFIG1lc3NhZ2VzIChlZyBKV0UpIG5vdCBqdXN0IGtleXMuPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+ PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1ib3VuY2Vz QGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2Yg PC9iPlJpY2hhcmQgQmFybmVzPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIDExIE1hcmNoIDIwMTMg NjoyOSBBTTxicj48Yj5Ubzo8L2I+IE1pa2UgSm9uZXM8YnI+PGI+Q2M6PC9iPiBMZWlmIEpvaGFu c3Nvbjsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3NlXSBBIFVuaWZp ZWQgVGhlb3J5IG9mIEpPU0UgS2V5czxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+U28gaXQgc2VlbXMgdG8gbWUgdGhhdCB0aGUgZ3JvdXAgaGFzIHRocmVlIHF1ZXN0aW9u cyB0byBhbnN3ZXIgd2hlbiBpdCBjb21lcyB0byB3cmFwcGVkIGtleXM6PG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+UTEoRW5jcnlwdGlvbik6IFdoYXQgbWVjaGFuaXNtIHdp bGwgYmUgdXNlZCB0byBlbmNyeXB0IGtleSBtYXRlcmlhbCwgcG9zc2libHkgY29udGFpbmluZyBh dHRyaWJ1dGVzPyAmbmJzcDs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4mbmJzcDsgJm5ic3A7IEFuc3dlciAxLkE6IEpXRTxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgQW5zd2VyIDEuQjogS2V5IHdyYXAs IGRlcml2ZWQgZnJvbSBKV0U8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5R MihQYWNraW5nKTogSG93IHNob3VsZCB0aGUgd3JhcHBlZCBrZXkrYXR0cmlidXRlcyBiZSBleHBy ZXNzZWQ/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 ICZuYnNwOyBBbnN3ZXIgMi5BOiBKU09OIGZvcm1hdCAobm90IHBhY2tlZCk8bzpwPjwvbzpwPjwv cD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgJm5ic3A7IEFuc3dlciAyLkI6 IEpTT04sIHdpdGggYmluYXJ5IHBhcnRzIGV4cHJlc3NlZCBkaXJlY3RseSZuYnNwOzxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkpXRS13aXRoaW4tSldLIHJlcHJlc2VudHMg YW5zd2VyIDEuQSAvIDIuQS4gJm5ic3A7VGhlIHNvbHV0aW9uIHByb3Bvc2VkIGluIG15IFVuaWZp ZWQgVGhlb3J5IGlzIDEuQiAvIDIuQi4gJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+Rm9yIGNvbnRleHQsIEknbSB3b3JraW5nIGZyb20gYSBmZXcgcHJpbmNpcGxl cyBoZXJlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIFdl IHNob3VsZCBub3QgZGVmaW5lIG11bHRpcGxlIHdheXMgdG8gd3JhcCBzeW1tZXRyaWMga2V5czxv OnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIFdlIHNob3VsZCBu b3QgZG8gdGhpbmdzIHRoYXQgd291bGQgcHJlY2x1ZGUgYWNjcmVkaXRhdGlvbiB1bmRlciBtYWpv ciBzZWN1cml0eSBzdGFuZGFyZHMgKGUuZy4sIEZJUFMpPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+LS0gV2Ugc2hvdWxkIGNob29zZSBlbmNvZGluZ3MgdGhhdCBt aW5pbWl6ZSB0aGUgc2l6ZSBvdmVyaGVhZCBpbXBvc2VkIGJ5IHRoZSBlbmNvZGluZzxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHdlIGFncmVlIG9uIHRoZXNl IHByaW5jaXBsZXMsIHRoZW4gdGhlIGFuc3dlcnMgdG8gdGhlIGFib3ZlIHF1ZXN0aW9ucyBzZWVt IHByZXR0eSBjbGVhci48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5JdCBz ZWVtcyB0byBtZSB0aGF0IFN0ZXZlJ3MgcG9pbnQgb24gUXVlc3Rpb24gMSBwcmV0dHkgbXVjaCBk ZWNpZGVzIHRoZSBxdWVzdGlvbiBmb3IgQi4gJm5ic3A7SWYgd2Ugd2FudCBzeXN0ZW1zIHVzaW5n IEpPU0UgdG8gaGF2ZSBhbnkgaG9wZSBvZiBnZXR0aW5nIGFjY3JlZGl0YXRpb24gKGUuZy4sIHVu ZGVyIEZJUFMpLCB0aGVuIHRoZXkgd2lsbCBoYXZlIHRvIHVzZSBzdGFuZGFyZCBtZWNoYW5pc21z IGZvciBwcm90ZWN0aW5nIGtleXMsIGV2ZW4gaWYgdGhvc2Uga2V5cyBhcmUgJm5ic3A7cGFja2Fn ZWQgd2l0aCBvdGhlciBhdHRyaWJ1dGVzLiAmbmJzcDtNaWtlJ3MgbWVzc2FnZSBtaXNzZXMgdGhl IHBvaW50IHRoYXQgdGhlIGtleSB3cmFwIGFsZ29yaXRobSBpc24ndCBhY3R1YWxseSBiZWluZyB1 c2VkIHRvIHByb3RlY3QgdGhlIGtleSBpdHNlbGYgLS0gZm9yIHRoYXQgeW91IHdvdWxkIHVzZSBh IG5vcm1hbCwgY29udGVudC1vcmllbnRlZCBlbmNyeXB0aW9uIGFsZ29yaXRobSwgaW4gY29udHJh dmVudGlvbiBvZiB0aGUgRklQUyByZXF1aXJlbWVudHMuPG86cD48L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+UXVlc3Rpb24gMiBpcyBtb3N0bHkgYSBxdWVzdGlvbiBvZiBiYWNrd2Fy ZCBjb21wYXRpYmlsaXR5IGFuZCBlZmZpY2llbmN5LiAmbmJzcDtJZiB3ZSB3YW50IHRvIGhhdmUg YW55IGhvcGUgb2YgYmVpbmcgYmFja3dhcmQtY29tcGF0aWJsZSB3aXRoIEpXRSBrZXkgd3JhcHBp bmcgLS0gdGhhdCBpcywgYXZvaWRpbmcgaGF2aW5nIHR3byB3YXlzIHRvIGRvIHRoZSBzYW1lIHRo aW5nIC0tIHRoZW4gd2UgbmVlZCBhIHdheSB0byBoYW5kbGUgdGhlIG9jdGV0cyBvZiBhIGtleSBk aXJlY3RseSwgYXMgb3Bwb3NlZCB0byBiYXNlNjQtZW5jb2RlZCB3aXRoaW4gYSBKU09OIG9iamVj dC4gJm5ic3A7VGhhdCB3b3VsZCBiZSBvcHRpb24gMi5CLjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPlRoZXJlIGFyZSBhbHNvIGNvbXBhY3RuZXNzIGFyZ3VtZW50cyBmb3Ig MS5CIGFuZCAyLkIuICZuYnNwO0lmIHlvdSBkbyAxLkEsIHRoZW4gaW4gYWRkaXRpb24gdG8gdGhl IGhlYWRlciwgeW91IGhhdmUgdG8gY2FycnkgYSBzZXBhcmF0ZSBDTUssIElWLCBhbmQgTUFDIHZh bHVlLiAmbmJzcDtJZiB5b3UncmUgdXNpbmcgQUVTLUdDTSB3aXRoIGEgMTI4LWJpdCBrZXksIHRo YXQncyBhIHRvdGFsIG9mIDQ0IG9jdGV0cyAoMTYgQ01LLCAxNiBNQUMsIDEyIElWKS4gJm5ic3A7 SW4gY29udHJhc3QsIGlmIHlvdSBqdXN0IGRvIEFFUyBrZXkgd3JhcCwgdGhlIHdyYXBwaW5nIGFs Z29yaXRobSBhZGRzIGEgbWF4aW11bSBvZiAxNiBvY3RldHMgdG8gdGhlIG9iamVjdC4gJm5ic3A7 VGhlIGRpZmZlcmVuY2UgaW4gY2FzZSAyIGlzIGV2ZW4gZ3JlYXRlciwgYmVjYXVzZSB5b3UncmUg dGFsa2luZyBhYm91dCBkb3VibGUtYmFzZTY0IGVuY29kaW5nLCB3aGljaCBlbnRhaWxzIGEgcGVu YWx0eSBvZiAzMCUgb2YgdGhlIHBheWxvYWQuICZuYnNwO0lmIHlvdSdyZSBwcm90ZWN0aW5nIGFu IEFFUyBrZXksIHRoaXMgbWlnaHQgb25seSBiZSBhIGZldyBvY3RldHMsIGJ1dCBpZiB5b3UncmUg cHJvdGVjdGluZyBhIDIwNDgtYml0IFJTQSBrZXksIHRoZW4geW91J3JlIHRhbGtpbmcgaHVuZHJl ZHMgb2Ygb2N0ZXRzLiAmbmJzcDtTbyBpZiB5b3UgY2FyZSBhYm91dCBjb21wYWN0bmVzcywgMS5C IGFuZCAyLkIgbWFrZSBhIGxvdCBtb3JlIHNlbnNlLjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPlRvIHJlc3BvbmQgdG8gTWlrZSdzIHNwZWNpZmljIHBvaW50czo8bzpwPjwv bzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv cD48L2Rpdj48ZGl2PjxkaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPknigJlsbCBub3RlIHRoYXQgaW4g SlNPTiBXZWIgRW5jcnlwdGlvbiwgd2UgYXJlIGFscmVhZHkgdXNpbmcgc3RhbmRhcmQgbWV0aG9k cyBmb3IgZW5jcnlwdGluZyBrZXkgdmFsdWVzIGZvciB0aGUgQ29udGVudCBNYXN0ZXIgS2V5IOKA kyBzcGVjaWZpY2FsbHkgQUVTIEtleSBXcmFwLCBSU0EgUEtDUyAjMSAxLjUsIGFuZCBSU0EgT0FF UCAocGx1cyBzdXBwb3J0aW5nIEVDREgtRVMga2V5IGFncmVlbWVudCkuPC9zcGFuPjxzcGFuIGxh bmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjwvYmxvY2txdW90ZT48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5Ib3dldmVyLCB0aGUgYWN0dWFsIGtleSB5b3UncmUgd3JhcHBpbmcg aXMgc3RpbGwgcHJvdGVjdGVkIHdpdGggYSBjb250ZW50LW9yaWVudGVkIGFsZ29yaXRobS4gJm5i c3A7U28geW91J3JlIHN0aWxsIHZpb2xhdGluZyB0aGUgRklQUyByZXF1aXJlbWVudHMuPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9k aXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGNtJz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPldoYXQgd2XigJlyZSB0YWxraW5nIGFib3V0IGhlcmUsIGhv d2V2ZXIsIGlzIGVuY3J5cHRpbmcgcG90ZW50aWFsbHkgbW9yZSB0aGFuIGp1c3Qga2V5IHZhbHVl cyDigJMgaW4gdGhpcyBjYXNlLCBrZXkgdmFsdWVzIHdpdGggYXNzb2NpYXRlZCBrZXkgdXNlIGlu Zm9ybWF0aW9uLCBhbGdvcml0aG0gaW5mb3JtYXRpb24sIGtleSBJRCBpbmZvcm1hdGlvbiwgYW5k IHBvdGVudGlhbGx5IG90aGVyIGF0dHJpYnV0ZXMuJm5ic3A7IEFzIHN1Y2gsIHVzaW5nIHRoZSBK V0sgSlNPTiByZXByZXNlbnRhdGlvbiBvZiB0aGlzIGluZm9ybWF0aW9uIGFzIHRoZSBwYXlsb2Fk IG9mIGEgc3RhbmRhcmQgSldFIGVuY3J5cHRpb24gc2VlbXMgbGlrZSB0aGUgb2J2aW91cyBzb2x1 dGlvbiwgd2hpY2ggZG9lc27igJl0IHJlcXVpcmUgaW52ZW50aW5nIGFueXRoaW5nIHdlIGRvbuKA mXQgYWxyZWFkeSBoYXZlLjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+QWJzb2x1dGVs eSBhZ3JlZSB0aGF0IEpTT04gaXMgdGhlIHJpZ2h0IHJlcHJlc2VudGF0aW9uLiAmbmJzcDtCdXQg dGhlIGtleSBpcyBzdGlsbCBpbmNsdWRlZCBpbiB0aGF0IHJlcHJlc2VudGF0aW9uLCBzbyB5b3Ug bmVlZCB0byBhcHBseSBrZXkgd3JhcHBpbmcgYWxnb3JpdGhtcyB0byBpdC4gJm5ic3A7QW5kLCBh cyBkaXNjdXNzZWQgYWJvdmUsIGl0J3MgYSBsb3QgbW9yZSBlZmZpY2llbnQgaWYgeW91IHBhY2sg dGhlIEpTT04gc28gdGhhdCB0aGUgYmluYXJ5IGlzbid0IGRvdWJsZS1lbmNvZGVkLjxvOnA+PC9v OnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOzxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3RlIHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSc+PGRp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5kcmFmdC1taWxsZXItam9zZS1qd2UtcHJvdGVjdGVkLWp3ayBhbHJlYWR5IGRlc2NyaWJl cyBkb2luZyB0aGF0LiZuYnNwOyBJIGJlbGlldmUgdGhhdCB3ZSBzaG91bGQgYWRvcHQgdGhpcyBh cyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQgYXMgc29vbiBhcyB0aGUgcmVjaGFydGVyaW5nIGlz IGNvbXBsZXRlLjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhhdCBkcmFmdCBoYXMg c29tZSBleGNlbGxlbnQgc3VnZ2VzdGlvbnMgZm9yIHBhc3N3b3JkLWJhc2VkIGtleSB3cmFwcGlu Zy4gJm5ic3A7V2Ugc2hvdWxkIGluY29ycG9yYXRlIHRoYXQgaW50byB3aGF0ZXZlciBzb2x1dGlv biB3ZSBjb21lIHVwIHdpdGguICZuYnNwO0J1dCBmb3IgdGhlIHJlYXNvbnMgZGlzY3Vzc2VkIGFi b3ZlLCBpdCdzIHdyb25nIGluIHVzaW5nIEpXSyBmb3IgdGhlIGVuY2Fwc3VsYXRpb24uPG86cD48 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBhbHNvIGRpc2FncmVlIHRoYXQgd2Ug bmVlZCBhIHNlcGFyYXRlIGRvY3VtZW50IGZvciB0aGlzLiAmbmJzcDtJZiB3ZSdyZSBnb2luZyB0 byBhdm9pZCBoYXZpbmcgdHdvIHdheXMgdG8gd3JhcCBrZXlzLCB0aGlzIG5lZWRzIHRvIGJlIHBh cnQgb2YgSldFL0pXSy48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLVJp Y2hhcmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjE2LjhwdCc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2NvbG9y OiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150B7865C8WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Mon Mar 11 19:48:13 2013 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 E960C21F88E8 for ; Mon, 11 Mar 2013 19:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 d9cqAtwOITff for ; Mon, 11 Mar 2013 19:48:13 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 30C8F21F87B1 for ; Mon, 11 Mar 2013 19:48:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,827,1355058000"; d="scan'208,217";a="118584610" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 12 Mar 2013 13:48:08 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="120270219" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccni.tcif.telstra.com.au with ESMTP; 12 Mar 2013 13:48:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 12 Mar 2013 13:48:08 +1100 From: "Manger, James H" To: Tim Bray , Karen ODonoghue Date: Tue, 12 Mar 2013 13:48:07 +1100 Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4ewu3OxYs3UBa/Rsup629DaiYmfwABuoEA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B786643@WSMSG3153V.srv.dir.telstra.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B786643WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: jose Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 02:48:14 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B786643WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWxsIGFkZCBzb21lIGNoZWVycyDigJQgdGhpcyBkb2VzIGxvb2sgbGlrZSBzdWJzdGFudGlh bCBwcm9ncmVzcy4NCg0KSSBhc3N1bWUgdGhlIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg4oCc YXB14oCdIGV0YyB0aGF0IHNvbWV0aW1lcyBtdXN0IGJlIHVuZGVyc3Rvb2QsIGFuZCBhdCBvdGhl ciB0aW1lcyBtdXN0IGJlIGlnbm9yZWQgKGRlcGVuZGluZyBvbiDigJxhbGfigJ0gb3Ig4oCcZW5j 4oCdIHZhbHVlKSB3b3VsZCBOT1QgYmUgbGlzdGVkIGluIHRoZSDigJxjcml04oCdIGZpZWxkIGFz IHRoZXkgYXJlIGRlZmluZWQgaW4gdGhlIOKAnGJhc2Ugc3BlY3PigJ0uDQoNCkJlaW5nIGluIHRo ZSDigJxiYXNlIHNwZWNz4oCdIGlzIHRoZSByaWdodCBjcml0ZXJpYSBmb3Igd2hldGhlciBhIGZp ZWxkIHNob3VsZCBiZSBsaXN0ZWQgaW4g4oCcY3JpdOKAnSBhcyBsb25nIGFzIOKAnGJhc2Ugc3Bl Y3PigJ0gbWVhbnM6IOKAnGJhc2Ugc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBwYXJ0aWN1bGFyIOKA nGFsZ+KAnS/igJ1lbmPigJ0gdmFsdWVz4oCdLiBJdCBzaG91bGRu4oCZdCBtZWFuIChhbmQgZG9l c27igJl0IGhhdmUgdG8gbWVhbikgdGhlIGJhc2Ugc3BlYyBmb3IgdGhlIHdob2xlIEpPU0Ugc3lz dGVtLg0KDQpQLlMuIOKAnG1ldGHigJ0gbWlnaHQgYmUgYSBuaWNlciBsYWJlbCB0aGFuIOKAnGFz ZOKAnS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaW0gQnJheQ0KU2Vu dDogVHVlc2RheSwgMTIgTWFyY2ggMjAxMyAxMjo0MyBQTQ0KVG86IEthcmVuIE9Eb25vZ2h1ZQ0K Q2M6IGpvc2UNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFk ZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KQ3VlIHdpbGQgY2hlZXJzIGZyb20gdGhlIHBlYW51dCBn YWxsZXJ5IHdoZXJlIG5vbi1jcnlwdG9ncmFwaGVycyBzaXQuICBNdXN0SWdub3JlIGlzIGluZmlu aXRlbHkgbW9yZSByb2J1c3QgYW5kIG9wZW4tZW5kZWQgdGhhbiBNdXN0VW5kZXJzdGFuZC4gIC1U DQoNCk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDU6MzEgUE0sIEthcmVuIE8nRG9ub2dodWUgPG9k b25vZ2h1ZUBpc29jLm9yZzxtYWlsdG86b2Rvbm9naHVlQGlzb2Mub3JnPj4gd3JvdGU6DQoNCkZv bGtzLA0KDQpBIHNpZGUgbWVldGluZyB3YXMgaGVsZCBTdW5kYXkgd2l0aCBhIG51bWJlciBvZiBq b3NlIHdvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnRzIHRvIHRyeSB0byByZXNvbHZlIHRoZSBvcGVu IGlzc3VlIHJlbGF0ZWQgdG8gaGVhZGVyIGNyaXRpY2FsaXR5LiBUaGUgZm9sbG93aW5nIGFyZSB0 aGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMgZnJvbSB0aGUgbWVldGluZy4gUG9pbnQgNSBvZiB0aGUg cHJvcG9zZWQgcmVzb2x1dGlvbiBiZWxvdyBpcyBhY3R1YWxseSBpbmRlcGVuZGVudCBvZiB0aGUg b3RoZXIgNCBwb2ludHMsIGFuZCBjb3VsZCBiZSBjb25zaWRlcmVkIHNlcGFyYXRlbHkuIFRoaXMg d2lsbCBhbGwgYmUgZGlzY3Vzc2VkIGluIFdlZG5lc2RheSdzIG1lZXRpbmcuDQoNCkluIGFkZGl0 aW9uIHRvIHRoZSB0ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBhZ3JlZW1lbnQgdG8gcmVwbGFj ZSB0aGUgInVuZGVyc3RhbmQiIHRleHQgd2l0aCBzb21ldGhpbmcgYSBiaXQgbW9yZSBleHBsaWNp dCBsaWtlICJtdXN0IHByb2Nlc3MiLiBIb3dldmVyLCB0aGF0IHRleHQgaGFzIG5vdCBiZWVuIHJv bGxlZCBpbnRvIHRoZSBzdW1tYXJ5IHRleHQgYmVsb3cgeWV0Lg0KDQpUaGFuayB5b3UgdG8gSmlt IFNjaGFhZCwgTWlrZSBKb25lcywgSm9obiBCcmFkbGV5LCBOYXQgU2FraW11cmEsIE1hcnRpbiBU aG9tYXMsIEVyaWMgUmVzY29ybGEsIE1hdHQgTWlsbGVyLCBhbmQgUmljaGFyZCBCYXJuZXMgZm9y IHlvdXIgZWZmb3J0cyAoYW5kIG15IGFwb2xvZ2llcyBpZiBJIG1pc3NlZCBzb21lb25lKS4NCg0K UmVnYXJkcywNCkthcmVuDQoNCjE6ICBDaGFuZ2UgdGhlIGxhbmd1YWdlIOKAnEFkZGl0aW9uYWwg bWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUgSldLLiAgSWYgcHJlc2VudCwgdGhleSBNVVNU IGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRoZW0u4oCdIHRvIOKAnEFk ZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUgSldLLiAgSWYgbm90IHVuZGVy c3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIGVuY291bnRlcmluZyB0aGVtLCB0aGV5IE1VU1QgYmUg aWdub3JlZC7igJ0gIChBbmQgbWFrZSB0aGUgc2FtZSBjaGFuZ2UgZm9yIEpXSyBTZXQgYXMgd2Vs bC4pDQoNCjI6ICBDaGFyYWN0ZXJpemUgYWxsIGV4aXN0aW5nIEpXUyBhbmQgSldFIGhlYWRlciBm aWVsZHMgYXMgZWl0aGVyIG11c3QgYmUgdW5kZXJzdG9vZCBvciBtYXkgYmUgaWdub3JlZC4gIOKA nGFsZ+KAnSwg4oCcZW5j4oCdLCBhbmQg4oCcemlw4oCdIG11c3QgYmUgdW5kZXJzdG9vZC4gIOKA nGtpZOKAnSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKAnHg1dOKAnSwg4oCcandr4oCdLCDigJxq a3XigJ0sIOKAnHR5cOKAnSwgYW5kIOKAnGN0eeKAnSBjYW4gYmUgaWdub3JlZCBiZWNhdXNlIHdo aWxlIG5vdCB1c2luZyB0aGVtIG1heSByZXN1bHQgaW4gdGhlIGluYWJpbGl0eSB0byBwcm9jZXNz IHNvbWUgc2lnbmF0dXJlcyBvciBlbmNyeXB0ZWQgY29udGVudCwgdGhpcyB3aWxsIG5vdCByZXN1 bHQgaW4gYSBzZWN1cml0eSB2aW9sYXRpb24g4oCTIGp1c3QgZGVncmFkZWQgZnVuY3Rpb25hbGl0 eS4gIE90aGVyIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg4oCcYXB14oCdLCDigJxhcHbigJ0s IOKAnGVwdeKAnSwgYW5kIOKAnGVwduKAnSBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIHVzZWQgd2hl biDigJxhbGfigJ0gb3Ig4oCcZW5j4oCdIHZhbHVlcyByZXF1aXJpbmcgdGhlbSBhcmUgdXNlZCwg YW5kIG90aGVyd2lzZSB0aGV5IG1heSBiZSBpZ25vcmVkLg0KDQozLiAgRGVmaW5lIGEgbmV3IGhl YWRlciBmaWVsZCB0aGF0IGxpc3RzIHdoaWNoIGFkZGl0aW9uYWwgZmllbGRzIG5vdCBkZWZpbmVk IGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zIG11c3QgYmUgdW5kZXJzdG9vZCBhbmQgYWN0ZWQg dXBvbiB3aGVuIHByZXNlbnQuICBGb3IgaW5zdGFuY2UsIGFuIGV4cGlyYXRpb24tdGltZSBleHRl bnNpb24gZmllbGQgY291bGQgYmUgbWFya2VkIGFzIG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0 ZWQtdXBvbi4gIE9uZSBwb3NzaWJsZSBuYW1lIGZvciB0aGlzIHdvdWxkIGJlIOKAnGNyaXTigJ0g KGNyaXRpY2FsKS4gIEFuIGV4YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGEgaHlwb3RoZXRpY2FsIOKA nGV4cOKAnSAoZXhwaXJhdGlvbi10aW1lKSBmaWVsZCBpczoNCg0KICB7ImFsZyI6IkVTMjU2IiwN CiAgICJjcml0IjpbImV4cCJdLA0KICAgImV4cOKAnToxMzYzMjg0MDAwDQogIH0NCg0KNC4gIEFs bCBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgbm90IGRlZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lm aWNhdGlvbnMgYW5kIG5vdCBjb250YWluZWQgaW4gdGhlIOKAnGNyaXTigJ0gbGlzdCBNVVNUIGJl IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuDQoNCjUuICBEZWZpbmUgYSBuZXcgaGVhZGVyIGZp ZWxkIOKAnGFzZOKAnSAoYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YSkgd2hvc2UgdmFsdWUgaXMg YSBKU09OIHN0cnVjdHVyZSB3aG9zZSBjb250ZW50cyBhcmUgb3BhcXVlIHRvIGFuZCBpZ25vcmVk IGJ5IEpXUyBhbmQgSldFIGltcGxlbWVudGF0aW9ucyBidXQgZm9yIHdoaWNoIGl0cyBjb250ZW50 cyBNVVNUIGJlIHByb3ZpZGVkIHRvIGFwcGxpY2F0aW9ucyB1c2luZyBKV1Mgb3IgSldFLCBwcm92 aWRlZCB0aGF0IHRoZSBzaWduYXR1cmUvTUFDIHZhbGlkYXRpb24gb3IgZGVjcnlwdGlvbiBvcGVy YXRpb24gc3VjY2VlZHMuICBUaGUgaW50ZW5kZWQgdXNlIG9mIHRoaXMgZmllbGQgaXMgdG8gaGF2 ZSBhIHN0YW5kYXJkIHBsYWNlIHRvIHByb3ZpZGUgYXBwbGljYXRpb24tc3BlY2lmaWMgbWV0YWRh dGEgYWJvdXQgdGhlIHBheWxvYWQgb3IgcGxhaW50ZXh0Lg0KDQoNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3Nl QGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B786643WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPknigJlsbCBhZGQgc29tZSBjaGVl cnMg4oCUIHRoaXMgZG9lcyBsb29rIGxpa2Ugc3Vic3RhbnRpYWwgcHJvZ3Jlc3MuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JIGFzc3VtZSB0aGUgZmllbGRzIHN1Y2ggYXMg4oCcZXBr4oCdLCDigJxhcHXi gJ0gZXRjIHRoYXQgc29tZXRpbWVzIG11c3QgYmUgdW5kZXJzdG9vZCwgYW5kIGF0IG90aGVyIHRp bWVzIG11c3QgYmUgaWdub3JlZCAoZGVwZW5kaW5nIG9uIOKAnGFsZ+KAnSBvciDigJxlbmPigJ0g dmFsdWUpIHdvdWxkIE5PVCBiZSBsaXN0ZWQgaW4gdGhlIOKAnGNyaXTigJ0gZmllbGQgYXMgdGhl eSBhcmUgZGVmaW5lZCBpbiB0aGUg4oCcYmFzZSBzcGVjc+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PkJlaW5nIGluIHRoZSDigJxiYXNlIHNwZWNz4oCdIGlzIHRoZSByaWdodCBjcml0ZXJpYSBmb3Ig d2hldGhlciBhIGZpZWxkIHNob3VsZCBiZSBsaXN0ZWQgaW4g4oCcY3JpdOKAnSBhcyBsb25nIGFz IOKAnGJhc2Ugc3BlY3PigJ0gbWVhbnM6IOKAnGJhc2Ugc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBw YXJ0aWN1bGFyIOKAnGFsZ+KAnS/igJ1lbmPigJ0gdmFsdWVz4oCdLiBJdCBzaG91bGRu4oCZdCBt ZWFuIChhbmQgZG9lc27igJl0IGhhdmUgdG8gbWVhbikgdGhlIGJhc2Ugc3BlYyBmb3IgdGhlIHdo b2xlIEpPU0Ugc3lzdGVtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UC5TLiDigJxtZXRh4oCdIG1pZ2h0 IGJlIGEgbmljZXIgbGFiZWwgdGhhbiDigJxhc2TigJ0uPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxv OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9 TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0 Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+VGltIEJyYXk8YnI+PGI+U2VudDo8L2I+IFR1ZXNk YXksIDEyIE1hcmNoIDIwMTMgMTI6NDMgUE08YnI+PGI+VG86PC9iPiBLYXJlbiBPRG9ub2dodWU8 YnI+PGI+Q2M6PC9iPiBqb3NlPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIFByb3Bvc2Vk IHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5DdWUgd2lsZCBjaGVlcnMgZnJvbSB0aGUgcGVhbnV0IGdh bGxlcnkgd2hlcmUgbm9uLWNyeXB0b2dyYXBoZXJzIHNpdC4mbmJzcDsgTXVzdElnbm9yZSBpcyBp bmZpbml0ZWx5IG1vcmUgcm9idXN0IGFuZCBvcGVuLWVuZGVkIHRoYW4gTXVzdFVuZGVyc3RhbmQu Jm5ic3A7IC1UPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD5PbiBNb24sIE1hciAxMSwgMjAxMyBhdCA1OjMxIFBNLCBLYXJlbiBPJ0Rv bm9naHVlICZsdDs8YSBocmVmPSJtYWlsdG86b2Rvbm9naHVlQGlzb2Mub3JnIiB0YXJnZXQ9Il9i bGFuayI+b2Rvbm9naHVlQGlzb2Mub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PGJyPkZvbGtzLDxvOnA+PC9vOnA+PC9wPjxkaXY+PGRpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxicj5B IHNpZGUgbWVldGluZyB3YXMgaGVsZCBTdW5kYXkgd2l0aCBhIG51bWJlciBvZiBqb3NlIHdvcmtp bmcgZ3JvdXAgcGFydGljaXBhbnRzIHRvIHRyeSB0byByZXNvbHZlIHRoZSBvcGVuIGlzc3VlIHJl bGF0ZWQgdG8gaGVhZGVyIGNyaXRpY2FsaXR5LiBUaGUgZm9sbG93aW5nIGFyZSB0aGUgcHJvcG9z ZWQgcmVzb2x1dGlvbnMgZnJvbSB0aGUgbWVldGluZy4gUG9pbnQgNSBvZiB0aGUgcHJvcG9zZWQg cmVzb2x1dGlvbiBiZWxvdyBpcyBhY3R1YWxseSBpbmRlcGVuZGVudCBvZiB0aGUgb3RoZXIgNCBw b2ludHMsIGFuZCBjb3VsZCBiZSBjb25zaWRlcmVkIHNlcGFyYXRlbHkuIFRoaXMgd2lsbCBhbGwg YmUgZGlzY3Vzc2VkIGluIFdlZG5lc2RheSdzIG1lZXRpbmcuIDxicj48YnI+SW4gYWRkaXRpb24g dG8gdGhlIHRleHQgYmVsb3csIHRoZXJlIHdhcyBzb21lIGFncmVlbWVudCB0byByZXBsYWNlIHRo ZSAmcXVvdDt1bmRlcnN0YW5kJnF1b3Q7IHRleHQgd2l0aCBzb21ldGhpbmcgYSBiaXQgbW9yZSBl eHBsaWNpdCBsaWtlICZxdW90O211c3QgcHJvY2VzcyZxdW90Oy4gSG93ZXZlciwgdGhhdCB0ZXh0 IGhhcyBub3QgYmVlbiByb2xsZWQgaW50byB0aGUgc3VtbWFyeSB0ZXh0IGJlbG93IHlldC4gPGJy Pjxicj5UaGFuayB5b3UgdG8gSmltIFNjaGFhZCwgTWlrZSBKb25lcywgSm9obiBCcmFkbGV5LCBO YXQgU2FraW11cmEsIE1hcnRpbiBUaG9tYXMsIEVyaWMgUmVzY29ybGEsIE1hdHQgTWlsbGVyLCBh bmQgUmljaGFyZCBCYXJuZXMgZm9yIHlvdXIgZWZmb3J0cyAoYW5kIG15IGFwb2xvZ2llcyBpZiBJ IG1pc3NlZCBzb21lb25lKS4gPGJyPjxicj5SZWdhcmRzLCA8YnI+S2FyZW48YnI+PGJyPjE6Jm5i c3A7IENoYW5nZSB0aGUgbGFuZ3VhZ2Ug4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBiZSBwcmVz ZW50IGluIHRoZSBKV0suICZuYnNwO0lmIHByZXNlbnQsIHRoZXkgTVVTVCBiZSB1bmRlcnN0b29k IGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtLuKAnSB0byDigJxBZGRpdGlvbmFsIG1lbWJl cnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gJm5ic3A7SWYgbm90IHVuZGVyc3Rvb2QgYnkg aW1wbGVtZW50YXRpb25zIGVuY291bnRlcmluZyB0aGVtLCB0aGV5IE1VU1QgYmUgaWdub3JlZC7i gJ0mbmJzcDsgKEFuZCBtYWtlIHRoZSBzYW1lIGNoYW5nZSBmb3IgSldLIFNldCBhcyB3ZWxsLik8 YnI+PGJyPjI6Jm5ic3A7IENoYXJhY3Rlcml6ZSBhbGwgZXhpc3RpbmcgSldTIGFuZCBKV0UgaGVh ZGVyIGZpZWxkcyBhcyBlaXRoZXIgbXVzdCBiZSB1bmRlcnN0b29kIG9yIG1heSBiZSBpZ25vcmVk LiZuYnNwOyDigJxhbGfigJ0sIOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnSBtdXN0IGJlIHVuZGVy c3Rvb2QuJm5ic3A7IOKAnGtpZOKAnSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKAnHg1dOKAnSwg 4oCcandr4oCdLCDigJxqa3XigJ0sIOKAnHR5cOKAnSwgYW5kIOKAnGN0eeKAnSBjYW4gYmUgaWdu b3JlZCBiZWNhdXNlIHdoaWxlIG5vdCB1c2luZyB0aGVtIG1heSByZXN1bHQgaW4gdGhlIGluYWJp bGl0eSB0byBwcm9jZXNzIHNvbWUgc2lnbmF0dXJlcyBvciBlbmNyeXB0ZWQgY29udGVudCwgdGhp cyB3aWxsIG5vdCByZXN1bHQgaW4gYSBzZWN1cml0eSB2aW9sYXRpb24g4oCTIGp1c3QgZGVncmFk ZWQgZnVuY3Rpb25hbGl0eS4mbmJzcDsgT3RoZXIgZmllbGRzIHN1Y2ggYXMg4oCcZXBr4oCdLCDi gJxhcHXigJ0sIOKAnGFwduKAnSwg4oCcZXB14oCdLCBhbmQg4oCcZXB24oCdIG11c3QgYmUgdW5k ZXJzdG9vZCBhbmQgdXNlZCB3aGVuIOKAnGFsZ+KAnSBvciDigJxlbmPigJ0gdmFsdWVzIHJlcXVp cmluZyB0aGVtIGFyZSB1c2VkLCBhbmQgb3RoZXJ3aXNlIHRoZXkgbWF5IGJlIGlnbm9yZWQuPGJy Pjxicj4zLiZuYnNwOyBEZWZpbmUgYSBuZXcgaGVhZGVyIGZpZWxkIHRoYXQgbGlzdHMgd2hpY2gg YWRkaXRpb25hbCBmaWVsZHMgbm90IGRlZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMg bXVzdCBiZSB1bmRlcnN0b29kIGFuZCBhY3RlZCB1cG9uIHdoZW4gcHJlc2VudC4mbmJzcDsgRm9y IGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRpbWUgZXh0ZW5zaW9uIGZpZWxkIGNvdWxkIGJlIG1h cmtlZCBhcyBtdXN0LWJlLXVuZGVyc3Rvb2QtYW5kLWFjdGVkLXVwb24uJm5ic3A7IE9uZSBwb3Nz aWJsZSBuYW1lIGZvciB0aGlzIHdvdWxkIGJlIOKAnGNyaXTigJ0gKGNyaXRpY2FsKS4mbmJzcDsg QW4gZXhhbXBsZSB1c2UsIGFsb25nIHdpdGggYSBoeXBvdGhldGljYWwg4oCcZXhw4oCdIChleHBp cmF0aW9uLXRpbWUpIGZpZWxkIGlzOjxicj48YnI+Jm5ic3A7IHsmcXVvdDthbGcmcXVvdDs6JnF1 b3Q7RVMyNTYmcXVvdDssPGJyPiZuYnNwOyZuYnNwOyAmcXVvdDtjcml0JnF1b3Q7OlsmcXVvdDtl eHAmcXVvdDtdLDxicj4mbmJzcDsmbmJzcDsgJnF1b3Q7ZXhw4oCdOjEzNjMyODQwMDA8YnI+Jm5i c3A7IH08YnI+PGJyPjQuJm5ic3A7IEFsbCBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgbm90IGRl ZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMgYW5kIG5vdCBjb250YWluZWQgaW4gdGhl IOKAnGNyaXTigJ0gbGlzdCBNVVNUIGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuPGJyPjxi cj41LiZuYnNwOyBEZWZpbmUgYSBuZXcgaGVhZGVyIGZpZWxkIOKAnGFzZOKAnSAoYXBwbGljYXRp b24tc3BlY2lmaWMgZGF0YSkgd2hvc2UgdmFsdWUgaXMgYSBKU09OIHN0cnVjdHVyZSB3aG9zZSBj b250ZW50cyBhcmUgb3BhcXVlIHRvIGFuZCBpZ25vcmVkIGJ5IEpXUyBhbmQgSldFIGltcGxlbWVu dGF0aW9ucyBidXQgZm9yIHdoaWNoIGl0cyBjb250ZW50cyBNVVNUIGJlIHByb3ZpZGVkIHRvIGFw cGxpY2F0aW9ucyB1c2luZyBKV1Mgb3IgSldFLCBwcm92aWRlZCB0aGF0IHRoZSBzaWduYXR1cmUv TUFDIHZhbGlkYXRpb24gb3IgZGVjcnlwdGlvbiBvcGVyYXRpb24gc3VjY2VlZHMuJm5ic3A7IFRo ZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBmaWVsZCBpcyB0byBoYXZlIGEgc3RhbmRhcmQgcGxhY2Ug dG8gcHJvdmlkZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBtZXRhZGF0YSBhYm91dCB0aGUgcGF5bG9h ZCBvciBwbGFpbnRleHQuPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0 b206MTIuMHB0Jz48YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+am9zZSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5v cmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5Pjwv aHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150B786643WSMSG3153Vsrv_-- From ve7jtb@ve7jtb.com Mon Mar 11 20:01:28 2013 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 61EC921F8517 for ; Mon, 11 Mar 2013 20:01:28 -0700 (PDT) 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 dzJY7kyKJrlJ for ; Mon, 11 Mar 2013 20:01:27 -0700 (PDT) Received: from mail-ye0-f182.google.com (mail-ye0-f182.google.com [209.85.213.182]) by ietfa.amsl.com (Postfix) with ESMTP id DCDF321F8510 for ; Mon, 11 Mar 2013 20:01:26 -0700 (PDT) Received: by mail-ye0-f182.google.com with SMTP id r9so765040yen.27 for ; Mon, 11 Mar 2013 20:01:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=wgZ5ZWcT4dcnkSxwscTholm3ROW7TZvMAYO6vzegsx4=; b=GPKi7E/8kx+vQZL/0+92E8YBW1nTPLy8JaKoxEnawPy88unhTO2SwCpNm9VF8q0cGx reBKd6fFQaIHgD72o9KjDojq2n+ZfSD+ya0eqSvu8rBZbSjq3TM3Wg+hpCQCte8kr/mg yiEwGvoyKwqAwIuw66TO6A3QqRUi+QN8yKDENCOFn5w5xXiQQ2ctWK1PtKfMKddMulOG 3A1rZlky3crhl/Wn3fMrE9fZ+9+6L56uZW8a73cDlQxuszcyY8aNNEtNSSdGwKf6kwnG E7a3ndpXkALyZi+NrOxF7xVuidOO5gMzWHiGVK9yyslQhAcw8z3245j1ITbuPNx8bPZw mOfQ== X-Received: by 10.236.146.39 with SMTP id q27mr7972050yhj.203.1363057285916; Mon, 11 Mar 2013 20:01:25 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id k45sm27572619yhd.2.2013.03.11.20.01.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 20:01:24 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_29AC7FA9-1E71-4B95-850C-2E7EE54CAD10"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B786643@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Mar 2013 23:01:07 -0400 Message-Id: <1D3CF454-0536-4D5D-90DF-938C73EB6BF7@ve7jtb.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> <255B9BB34FB7D647A506DC292726F6E1150B786643@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmdwVlD/LTv31GzFvsdDvpBounGguKeiNdPdsUM6B0ctYyl4H5u217ksGo/8lV5wlT6R94n Cc: Tim Bray , jose , Karen ODonoghue Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 03:01:28 -0000 --Apple-Mail=_29AC7FA9-1E71-4B95-850C-2E7EE54CAD10 Content-Type: multipart/alternative; boundary="Apple-Mail=_6013E19B-04EA-4795-96F4-E21031F36395" --Apple-Mail=_6013E19B-04EA-4795-96F4-E21031F36395 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 2013-03-11, at 10:48 PM, "Manger, James H" = wrote: > I=92ll add some cheers =97 this does look like substantial progress. > =20 > I assume the fields such as =93epk=94, =93apu=94 etc that sometimes = must be understood, and at other times must be ignored (depending on = =93alg=94 or =93enc=94 value) would NOT be listed in the =93crit=94 = field as they are defined in the =93base specs=94. > =20 Correct > Being in the =93base specs=94 is the right criteria for whether a = field should be listed in =93crit=94 as long as =93base specs=94 means: = =93base specifications for the particular =93alg=94/=94enc=94 values=94. = It shouldn=92t mean (and doesn=92t have to mean) the base spec for the = whole JOSE system. > =20 Crit is only for extensions, it is up to the extension definition to = decide if the field needs to be in crit. > P.S. =93meta=94 might be a nicer label than =93asd=94. I don't have any particular attachment to the name. Some places things = like this are called associated data, though not the places normal = people go I grant you. =20 Meta-data about the payload is what it is, The current practice is to = use three character names. I am fine with met or meta (I suspect that = if you are throwing crap into the envelope the single character won't = kill anyone. James if you like the solution and want it to be meta I will back you on = it :) John B. > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Tim Bray > Sent: Tuesday, 12 March 2013 12:43 PM > To: Karen ODonoghue > Cc: jose > Subject: Re: [jose] Proposed resolution of header criticality issue > =20 > Cue wild cheers from the peanut gallery where non-cryptographers sit. = MustIgnore is infinitely more robust and open-ended than MustUnderstand. = -T > =20 >=20 > On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue = wrote: >=20 > Folks, >=20 > A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting.=20 >=20 > In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet.=20 >=20 > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, = Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your = efforts (and my apologies if I missed someone).=20 >=20 > Regards,=20 > Karen >=20 > 1: Change the language =93Additional members MAY be present in the = JWK. If present, they MUST be understood by implementations using = them.=94 to =93Additional members MAY be present in the JWK. If not = understood by implementations encountering them, they MUST be ignored.=94 = (And make the same change for JWK Set as well.) >=20 > 2: Characterize all existing JWS and JWE header fields as either must = be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 = must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94= , =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not = using them may result in the inability to process some signatures or = encrypted content, this will not result in a security violation =96 just = degraded functionality. Other fields such as =93epk=94, =93apu=94, = =93apv=94, =93epu=94, and =93epv=94 must be understood and used when = =93alg=94 or =93enc=94 values requiring them are used, and otherwise = they may be ignored. >=20 > 3. Define a new header field that lists which additional fields not = defined in the base specifications must be understood and acted upon = when present. For instance, an expiration-time extension field could be = marked as must-be-understood-and-acted-upon. One possible name for this = would be =93crit=94 (critical). An example use, along with a = hypothetical =93exp=94 (expiration-time) field is: >=20 > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } >=20 > 4. All additional header fields not defined in the base = specifications and not contained in the =93crit=94 list MUST be ignored = if not understood. >=20 > 5. Define a new header field =93asd=94 (application-specific data) = whose value is a JSON structure whose contents are opaque to and ignored = by JWS and JWE implementations but for which its contents MUST be = provided to applications using JWS or JWE, provided that the = signature/MAC validation or decryption operation succeeds. The intended = use of this field is to have a standard place to provide = application-specific metadata about the payload or plaintext. >=20 > =20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_6013E19B-04EA-4795-96F4-E21031F36395 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On 2013-03-11, at = 10:48 PM, "Manger, James H" <James.H.Manger@team.telstr= a.com> wrote:

I=92ll add some cheers =97= this does look like substantial progress.
 
I assume the fields such = as =93epk=94, =93apu=94 etc that sometimes must be understood, and at = other times must be ignored (depending on =93alg=94 or =93enc=94 value) = would NOT be listed in the =93crit=94 field as they are defined in the = =93base specs=94.
Being in the =93base = specs=94 is the right criteria for whether a field should be listed in = =93crit=94 as long as =93base specs=94 means: =93base specifications for = the particular =93alg=94/=94enc=94 values=94. It shouldn=92t mean (and = doesn=92t have to mean) the base spec for the whole JOSE = system.
P.S. =93meta=94 might be = a nicer label than = =93asd=94.

I don't = have any particular attachment to the name.   Some places things = like this are called associated data, though not the places normal = people go I grant you.  
Meta-data about the payload is = what it is,  The current practice is to use three character names. =   I am fine with met or meta (I suspect that if you are throwing = crap into the envelope the single character won't kill = anyone.

James if you like the solution and want = it to be meta I will back you on it :)

John = B.

 
--
James = Manger
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Tim = Bray
Sent: Tuesday, 12 March 2013 = 12:43 PM
To: Karen = ODonoghue
Cc: jose
Subject: Re: [jose] Proposed = resolution of header criticality = issue
Cue wild = cheers from the peanut gallery where non-cryptographers sit.  = MustIgnore is infinitely more robust and open-ended than = MustUnderstand.  -T

 

On = Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <odonoghue@isoc.org> = wrote:

A side meeting was held Sunday with a number of = jose working group participants to try to resolve the open issue related = to header criticality. The following are the proposed resolutions from = the meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting. 

In addition to the = text below, there was some agreement to replace the "understand" text = with something a bit more explicit like "must process". However, that = text has not been rolled into the summary text below yet. 

Thank you to Jim = Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric = Rescorla, Matt Miller, and Richard Barnes for your efforts (and my = apologies if I missed someone). 

Regards, 
Karen

1:  = Change the language =93Additional members MAY be present in the JWK. =  If present, they MUST be understood by implementations using = them.=94 to =93Additional members MAY be present in the JWK.  If = not understood by implementations encountering them, they MUST be = ignored.=94  (And make the same change for JWK Set as = well.)

2:  Characterize all existing JWS and JWE header = fields as either must be understood or may be ignored.  =93alg=94, = =93enc=94, and =93zip=94 must be understood.  =93kid=94, =93x5u=94, = =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can = be ignored because while not using them may result in the inability to = process some signatures or encrypted content, this will not result in a = security violation =96 just degraded functionality.  Other fields = such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must = be understood and used when =93alg=94 or =93enc=94 values requiring them = are used, and otherwise they may be ignored.

3.  Define a = new header field that lists which additional fields not defined in the = base specifications must be understood and acted upon when = present.  For instance, an expiration-time extension field could be = marked as must-be-understood-and-acted-upon.  One possible name for = this would be =93crit=94 (critical).  An example use, along with a = hypothetical =93exp=94 (expiration-time) field is:

  = {"alg":"ES256",
   "crit":["exp"],
   = "exp=94:1363284000
  }

4.  All additional header = fields not defined in the base specifications and not contained in the = =93crit=94 list MUST be ignored if not understood.

5.  = Define a new header field =93asd=94 (application-specific data) whose = value is a JSON structure whose contents are opaque to and ignored by = JWS and JWE implementations but for which its contents MUST be provided = to applications using JWS or JWE, provided that the signature/MAC = validation or decryption operation succeeds.  The intended use of = this field is to have a standard place to provide application-specific = metadata about the payload or plaintext.

 
 

jose@ietf.org
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose


= --Apple-Mail=_6013E19B-04EA-4795-96F4-E21031F36395-- --Apple-Mail=_29AC7FA9-1E71-4B95-850C-2E7EE54CAD10 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMDMwMTA3WjAjBgkqhkiG9w0BCQQxFgQU20F35qFp Rw/h0Df3LbtUTmvT2cYwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAdNV3Y+632X7HcF6fSD6L0MGn83B7F1FoPcXNeW4N d64rjoA5fm5TLMfWAKyvPak7OqSpjFAmgt4AgdFujNpRmhSHw/wUhTn65ibv5jFmylkX3p/J9Kp8 bg6x2LXAn4VZecyR52f3TbhU/8J4kVvz8Ixx+KV7vXhhK2C/WmQaJD2jsx49DWHeOQPlQaxaV2pB Ef9GaxgW1Su6dMUADEhd32DKYcqz5zhna8l3rg8E80smWE72foBwL58OZyYCxgz7dZ07VU8oQ4PM 6QiMSDRt8qrzM5ALEpDki2JJashTSLv6uk5FkXgZJ3ajVhB1eOVjGYPXXQ+IKs6i68DnyZZxpQAA AAAAAA== --Apple-Mail=_29AC7FA9-1E71-4B95-850C-2E7EE54CAD10-- From rlb@ipv.sx Mon Mar 11 21:59:02 2013 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 CC08C21F8440 for ; Mon, 11 Mar 2013 21:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.331 X-Spam-Level: X-Spam-Status: No, score=-1.331 tagged_above=-999 required=5 tests=[AWL=-0.906, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 4zl1aVwm0sg8 for ; Mon, 11 Mar 2013 21:58:58 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1065921F8431 for ; Mon, 11 Mar 2013 21:58:57 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id ef5so4161998obb.11 for ; Mon, 11 Mar 2013 21:58:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=6EGXmXF3VkA6vRja/6mKX1No0zQb4hOxK/3M7OMe+KA=; b=ioPAqG7rBY106PrsIkOJr3c9DWzEdfkIJNpdqDf45Q4xX7hYIme28w+vhjuUmszk4R f2CZvrZMvvR8HIl+DivoJVTWkZnfrRVwojNs5C6gsSIpfIHa8Gcz0B5dtYxiV1eQIvcc 60CG1fjf2smePBx/BsD2B8l/b7o3K8FGLLSyIxAgk8Japoc+J9oLXHKNkTK+RHLSw6ZG mGshhB+n0XuRKdidRta7T+Acr8+OWVUjpNK/gnR/LxQBFEKw7ONFMeH3Ky1qzfEcF8BV MFeHtK5mz5xW3DxQOmAstMAwh5rNBG5syUP98HA+GgcVvbXnrIaJdkEcFEwPqnD0hehn aQWg== MIME-Version: 1.0 X-Received: by 10.182.8.70 with SMTP id p6mr10804220oba.90.1363064337260; Mon, 11 Mar 2013 21:58:57 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 11 Mar 2013 21:58:57 -0700 (PDT) X-Originating-IP: [128.89.253.235] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 12 Mar 2013 00:58:57 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d0444ea41a0fa4b04d7b32550 X-Gm-Message-State: ALoCoQlaSdT9Xe0CXQJ1+gwppn5mojT34AlIANwnWXJf+jRJG5xQNzWbVhMFRSIIBCpyFR8Vad++ Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 12 Mar 2013 04:59:02 -0000 --f46d0444ea41a0fa4b04d7b32550 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi James, Thanks for the excellent summary of this approach. You said it much better than I did. Answers to your questions inline below. On Mon, Mar 11, 2013 at 10:30 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > =93A Unified Theory of JOSE Keys=94 > looks quite good.**** > > ** ** > > It looks like a key is a JSON object with any number of name/value pairs. > For some names, the value is a base64[url]-encoding of binary data.**** > > ** ** > > To wrap a key, its name/value pairs are divided into 3 groups:**** > > **1. **non-confidential name/value pairs**** > > **2. **confidential non-binary name/value pairs**** > > **3. **confidential binary name/value pairs**** > > ** ** > > The first group are put into the =93kat=94 (key attributes?) field of the > output.**** > > ** ** > > The second group =97 if its not empty =97 becomes the first binary segmen= t of > the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the outp= ut > indicates the second group is present.**** > > ** ** > > The third group (in order) become subsequent binary segments of the > plaintext. The names in the third group (and their order) is determined b= y > the type of the key being wrapped (=93kty=94 attribute).**** > > ** ** > > The plaintext is wrapped (encrypted), then base64url-encoded to give the > =93wk=94 attribute in the output.**** > > ** ** > > ** ** > > Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat=94.= I assume > this is a typo. =93kat=94 would include =93n=94 and =93e=94, but =93d=94 = (the private > exponent) would always be encrypted and hence be inside =93wk=94. > > Yes, that is a typo. Fixed in my local copy. > Q2. Does key wrapping give integrity protection that you might want for > name/value pairs even when they are not confidential. For instance, could > it be useful to include, say, =93e=94 inside =93wk=94 instead of within = =93kat=94? Do > recipients need to check both the first binary segment and =93kat=94 when > looking for any attribute not explicitly listed in the =93encoding rules= =94? > Does the first binary segment take precedence over =93kat=94? > This proposal does not allow for attributes that are integrity-protected but not confidentiality-protected. They get both services or neither. Off the top of my head, I can't think of a simple way to do this with standard key-wrapping techniques. You have correctly guessed my intent for decoding: I was thinking that the recipient would first decode two dictionaries, the one from "kat", and the one from "wk". It would then merge them by inserting the fields from "wk" into the "kat" object, overwriting if necessary. So protected fields ("wk") would take precedence over unprotected fields ("kat"). > Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples sho= w it as a > top-level attribute instead. > I'm a little split on this. The point of "kty" is to indicate how the recipient should reconstruct a JSON object out of the "wk" value. As a processing rule, it seems to make sense at the top level, but it also needs to be added to the final unwrapped key object (like the fields in "kat"). Note that there's no ambiguity about the type of the wrapped key, because the presence of "alg" signifies that wrapping has been applied. So I don't think it matters much one way or the other. > A4. The symmetric key examples don=92t include a key type (=93kty=94). Is= it > implied by something at a higher level (eg a JWE), or is there a default > value meaning =93a shared symmetric secret, with no specific associated > crypto algorithm=94? > In the spirit of trying to produce JWE as a degenerate case, I was thinking that an absent "kty" value would indicate a symmetric key. This sort of makes sense, given that the point of the "kty" in this case is to tell you what the Encoding Rules are for "wk"; an absent "kty" basically means there's no internal structure (modulo "wj"), which is the same as a symmetric key would have. Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be > better for encoding the length of binary segments. 2 bytes (64 KB max) > might be too small, particularly if the binary encoding is used for all > JOSE messages (eg JWE) not just keys. > That would be fine. Pick your favorite binary integer format :) I was just trying to be simple for this initial proposal. I would note that a fixed-length integer is easier to deal with in some languages. E.g., in JavaScript, you can write 1-, 2-, or 4-octet unsigned integers using a DataView over an ArrayBuffer. Maybe you could do something really bad, like use the first bit of the first octet to indicate whether the number is 2 or 4 bytes. Cheers, --Richard > **** > > ** ** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, 11 March 2013 6:29 AM > *To:* Mike Jones > *Cc:* Leif Johansson; jose@ietf.org > > *Subject:* Re: [jose] A Unified Theory of JOSE Keys**** > > ** ** > > So it seems to me that the group has three questions to answer when it > comes to wrapped keys:**** > > ** ** > > Q1(Encryption): What mechanism will be used to encrypt key material, > possibly containing attributes? **** > > Answer 1.A: JWE**** > > Answer 1.B: Key wrap, derived from JWE**** > > ** ** > > Q2(Packing): How should the wrapped key+attributes be expressed?**** > > Answer 2.A: JSON format (not packed)**** > > Answer 2.B: JSON, with binary parts expressed directly **** > > ** ** > > JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in my > Unified Theory is 1.B / 2.B. **** > > ** ** > > For context, I'm working from a few principles here:**** > > -- We should not define multiple ways to wrap symmetric keys**** > > -- We should not do things that would preclude accreditation under major > security standards (e.g., FIPS)**** > > -- We should choose encodings that minimize the size overhead imposed by > the encoding**** > > If we agree on these principles, then the answers to the above questions > seem pretty clear.**** > > ** ** > > It seems to me that Steve's point on Question 1 pretty much decides the > question for B. If we want systems using JOSE to have any hope of gettin= g > accreditation (e.g., under FIPS), then they will have to use standard > mechanisms for protecting keys, even if those keys are packaged with oth= er > attributes. Mike's message misses the point that the key wrap algorithm > isn't actually being used to protect the key itself -- for that you would > use a normal, content-oriented encryption algorithm, in contravention of > the FIPS requirements.**** > > ** ** > > Question 2 is mostly a question of backward compatibility and efficiency. > If we want to have any hope of being backward-compatible with JWE key > wrapping -- that is, avoiding having two ways to do the same thing -- the= n > we need a way to handle the octets of a key directly, as opposed to > base64-encoded within a JSON object. That would be option 2.B.**** > > ** ** > > There are also compactness arguments for 1.B and 2.B. If you do 1.A, the= n > in addition to the header, you have to carry a separate CMK, IV, and MAC > value. If you're using AES-GCM with a 128-bit key, that's a total of 44 > octets (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key wrap= , > the wrapping algorithm adds a maximum of 16 octets to the object. The > difference in case 2 is even greater, because you're talking about > double-base64 encoding, which entails a penalty of 30% of the payload. I= f > you're protecting an AES key, this might only be a few octets, but if > you're protecting a 2048-bit RSA key, then you're talking hundreds of > octets. So if you care about compactness, 1.B and 2.B make a lot more > sense.**** > > ** ** > > To respond to Mike's specific points:**** > > ** ** > > I=92ll note that in JSON Web Encryption, we are already using standard > methods for encrypting key values for the Content Master Key =96 specific= ally > AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key > agreement).**** > > ** ** > > However, the actual key you're wrapping is still protected with a > content-oriented algorithm. So you're still violating the FIPS > requirements.**** > > **** > > ** ** > > What we=92re talking about here, however, is encrypting potentially more > than just key values =96 in this case, key values with associated key use > information, algorithm information, key ID information, and potentially > other attributes. As such, using the JWK JSON representation of this > information as the payload of a standard JWE encryption seems like the > obvious solution, which doesn=92t require inventing anything we don=92t a= lready > have.**** > > ** ** > > Absolutely agree that JSON is the right representation. But the key is > still included in that representation, so you need to apply key wrapping > algorithms to it. And, as discussed above, it's a lot more efficient if > you pack the JSON so that the binary isn't double-encoded.**** > > **** > > draft-miller-jose-jwe-protected-jwk already describes doing that. I > believe that we should adopt this as a working group document as soon as > the rechartering is complete.**** > > ** ** > > That draft has some excellent suggestions for password-based key wrapping= . > We should incorporate that into whatever solution we come up with. But > for the reasons discussed above, it's wrong in using JWK for the > encapsulation.**** > > ** ** > > I also disagree that we need a separate document for this. If we're goin= g > to avoid having two ways to wrap keys, this needs to be part of JWE/JWK.*= * > ** > > ** ** > > --Richard**** > > ** ** > > -- Mike**** > > --f46d0444ea41a0fa4b04d7b32550 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi James,

Thanks for the excellent summary of this appro= ach. =A0You said it much better than I did. =A0Answers to your questions in= line below.

On Mon, Mar 11, 2013 at 10:30= PM, Manger, James H <James.H.Manger@team.telstra.com>= ; wrote:

=93A Unified Theor= y of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite = good.

=A0<= /p>

It looks like a key is= a JSON object with any number of name/value pairs. For some names, the val= ue is a base64[url]-encoding of binary data.

=A0<= /p>

To wrap a key, its nam= e/value pairs are divided into 3 groups:

1.=A0=A0=A0=A0=A0=A0 non-confidential name/value pairs

2.=A0=A0=A0=A0=A0=A0 confidential non-binary name/value pairs<= /u>

3.=A0=A0=A0=A0=A0=A0 confidential binary name/value pairs<= /span>

=A0<= /p>

The first group are pu= t into the =93kat=94 (key attributes?) field of the output.

=A0<= /p>

The second group =97 i= f its not empty =97 becomes the first binary segment of the plaintext (as a= UTF-8-encoded JSON object). =93wj=94:true in the output indicates the seco= nd group is present.

=A0<= /p>

The third group (in or= der) become subsequent binary segments of the plaintext. The names in the t= hird group (and their order) is determined by the type of the key being wra= pped (=93kty=94 attribute).

=A0<= /p>

The plaintext is wrapp= ed (encrypted), then base64url-encoded to give the =93wk=94 attribute in th= e output.

=A0<= /p>

=A0

Q1. The examples of wrapp= ing an RSA key include =93d=94:=85 in =93kat=94. I assume this is a typo. = =93kat=94 would include =93n=94 and =93e=94, but =93d=94 (the private expon= ent) would always be encrypted and hence be inside =93wk=94.


Yes, that is a typo. =A0Fixed in my local copy.
=A0

Q2. = Does key wrapping give integrity protection that you might want for name/va= lue pairs even when they are not confidential. For instance, could it be us= eful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? = Do recipients need to check both the first binary segment and =93kat=94 whe= n looking for any attribute not explicitly listed in the =93encoding rules= =94? Does the first binary segment take precedence over =93kat=94?


This proposal does not allow for att= ributes that are integrity-protected but not confidentiality-protected. =A0= They get both services or neither. =A0Off the top of my head, I can't t= hink of a simple way to do this with standard key-wrapping techniques.

You have correctly guessed my intent for decoding: I wa= s thinking that the recipient would first decode two dictionaries, the one = from "kat", and the one from "wk". =A0It would then mer= ge them by inserting the fields from "wk" into the "kat"= ; object, overwriting if necessary. =A0So protected fields ("wk")= would take precedence over unprotected fields ("kat").

=A0=A0

Q3. Should =93kty=94 (key type) appear within = =93kat=94? The examples show it as a top-level attribute instead.


I'm a little split on this. =A0The point of "k= ty" is to indicate how the recipient should reconstruct a JSON object = out of the "wk" value. =A0As a processing rule, it seems to make = sense at the top level, but it also needs to be added to the final unwrappe= d key object (like the fields in "kat"). =A0Note that there's= no ambiguity about the type of the wrapped key, because the presence of &q= uot;alg" signifies that wrapping has been applied. =A0So I don't t= hink it matters much one way or the other.

=A0

A4. The symmetric key examples don=92t include a key type (=93kt= y=94). Is it implied by something at a higher level (eg a JWE), or is there= a default value meaning =93a shared symmetric secret, with no specific ass= ociated crypto algorithm=94?


In the spirit of trying to produce J= WE as a degenerate case, I was thinking that an absent "kty" valu= e would indicate a symmetric key. =A0This sort of makes sense, given that t= he point of the "kty" in this case is to tell you what the Encodi= ng Rules are for "wk"; an absent "kty" basically means = there's no internal structure (modulo "wj"), which is the sam= e as a symmetric key would have.
=A0=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Q5. Using a VARINT (variable-length integer) inst= ead of 2 bytes would be better for encoding the length of binary segments. = 2 bytes (64 KB max) might be too small, particularly if the binary encoding= is used for all JOSE messages (eg JWE) not just keys.


That would be fine. =A0Pick your fav= orite binary integer format :) =A0I was just trying to be simple for this i= nitial proposal. =A0

I would note that a fixed-len= gth integer is easier to deal with in some languages. =A0E.g., in JavaScrip= t, you can write 1-, 2-, or 4-octet unsigned integers using a DataView over= an ArrayBuffer. =A0Maybe you could do something really bad, like use the f= irst bit of the first octet to indicate whether the number is 2 or 4 bytes.=

Cheers,
--Richard

=A0

=

=A0<= /p>

=A0<= /p>

--

James Manger

=A0=

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] <= b>On Behalf Of Richard Barnes
Sent: Monday, 11 March 2013 6:29 AM
To: Mike Jones
C= c: Leif Johansson; j= ose@ietf.org


Subject: Re: [jose]= A Unified Theory of JOSE Keys

=A0

So it seems to me that the group has three questions to ans= wer when it comes to wrapped keys:

=A0

Q1(Encryption): What mechanism will be used to encrypt key material= , possibly containing attributes? =A0

=A0 =A0 Answer 1.A: JWE

= =A0 =A0 Answer 1.B: Key wrap, derived from JWE

=

=A0

Q2(Packing): How should the wrapped key+attributes be expressed?<= u>

=A0 =A0 Answer 2.A: JSON format (not pack= ed)

=A0 =A0 Answer 2.B: = JSON, with binary parts expressed directly=A0

<= p class=3D"MsoNormal"> =A0

JWE-within-JWK repre= sents answer 1.A / 2.A. =A0The solution proposed in my Unified Theory is 1.= B / 2.B. =A0

=A0<= u>

For context, I'm working from a few p= rinciples here:

-- We sh= ould not define multiple ways to wrap symmetric keys

-- We should not do things that would preclude = accreditation under major security standards (e.g., FIPS)

=

-- We should choose encodings that minimi= ze the size overhead imposed by the encoding

If we agree on these principles, then the= answers to the above questions seem pretty clear.

<= div>

=A0

It seems to me that Steve's point on Question 1 pretty much decides the= question for B. =A0If we want systems using JOSE to have any hope of getti= ng accreditation (e.g., under FIPS), then they will have to use standard me= chanisms for protecting keys, even if those keys are =A0packaged with other= attributes. =A0Mike's message misses the point that the key wrap algor= ithm isn't actually being used to protect the key itself -- for that yo= u would use a normal, content-oriented encryption algorithm, in contraventi= on of the FIPS requirements.

=A0

Question 2 is mostly a question of backward compatibility an= d efficiency. =A0If we want to have any hope of being backward-compatible w= ith JWE key wrapping -- that is, avoiding having two ways to do the same th= ing -- then we need a way to handle the octets of a key directly, as oppose= d to base64-encoded within a JSON object. =A0That would be option 2.B.

=A0

There are also compactness arguments for 1.B and 2.B. =A0If = you do 1.A, then in addition to the header, you have to carry a separate CM= K, IV, and MAC value. =A0If you're using AES-GCM with a 128-bit key, th= at's a total of 44 octets (16 CMK, 16 MAC, 12 IV). =A0In contrast, if y= ou just do AES key wrap, the wrapping algorithm adds a maximum of 16 octets= to the object. =A0The difference in case 2 is even greater, because you= 9;re talking about double-base64 encoding, which entails a penalty of 30% o= f the payload. =A0If you're protecting an AES key, this might only be a= few octets, but if you're protecting a 2048-bit RSA key, then you'= re talking hundreds of octets. =A0So if you care about compactness, 1.B and= 2.B make a lot more sense.

=A0

To respond to Mike's specific points:

<= /div>

=A0

= I=92ll note that in JSON Web Encryption, we are already using standard meth= ods for encrypting key values for the Content Master Key =96 specifically A= ES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agr= eement).

=A0

<= /div>

However, the actual key you're wrappin= g is still protected with a content-oriented algorithm. =A0So you're st= ill violating the FIPS requirements.

=A0

=A0

= What we=92re talking about here, however, is encrypting potentially more th= an just key values =96 in this case, key values with associated key use inf= ormation, algorithm information, key ID information, and potentially other = attributes.=A0 As such, using the JWK JSON representation of this informati= on as the payload of a standard JWE encryption seems like the obvious solut= ion, which doesn=92t require inventing anything we don=92t already have.

=A0

<= /div>

Absolutely agree that JSON is the right re= presentation. =A0But the key is still included in that representation, so y= ou need to apply key wrapping algorithms to it. =A0And, as discussed above,= it's a lot more efficient if you pack the JSON so that the binary isn&= #39;t double-encoded.

=A0=A0<= u>

= draft-miller-jose-jwe-protected-jwk already describes doing that.=A0 I beli= eve that we should adopt this as a working group document as soon as the re= chartering is complete.

=A0

<= /div>

That draft has some excellent suggestions = for password-based key wrapping. =A0We should incorporate that into whateve= r solution we come up with. =A0But for the reasons discussed above, it'= s wrong in using JWK for the encapsulation.

=A0

I also disagree that we need a separate document for this. = =A0If we're going to avoid having two ways to wrap keys, this needs to = be part of JWE/JWK.

=A0

--Richard

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike

<= /div>
--f46d0444ea41a0fa4b04d7b32550-- From rlb@ipv.sx Mon Mar 11 22:01:43 2013 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 C99F621F85B2 for ; Mon, 11 Mar 2013 22:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.596, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 aEmGzvwA3eoH for ; Mon, 11 Mar 2013 22:01:41 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id D5C8321F8596 for ; Mon, 11 Mar 2013 22:01:37 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so5381629oag.12 for ; Mon, 11 Mar 2013 22:01:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=+YOdAwQoBr21IK1OP2q3MPidlWlvOccHu8WJ+zfCh1M=; b=R6hVc39o2g0anwe+uqlabrSuu6jC9+MWYoHn53sk0lxi55bg3X2Z1kaCRWyDlQ+AfW ckuwGz+mmPQlYC4D31WVdiF9YwSvXiLOVIp2TlTr0+RHOgVpVble7OnTLNqMsj/jSml+ 5uPZkz1yljrIUVC3YB0CEvl4WFeTvmmKXYp/NNvpzgnYbLi9x39gJXEeAZSc0bQz/5BP CeiRY5qA6DYGM+U+NtwowWytAxcyrGogCtt2cL/lHY1O3k6UuELkX57xb/prV1TS8uyy NjH/FtqcICES4E7ND98rWVg03tgvbNNTFQJWC/JJ2jzgaST5LWsUyLwKJw7iD7hvkf77 eD6g== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr11182892oec.116.1363064497368; Mon, 11 Mar 2013 22:01:37 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 11 Mar 2013 22:01:37 -0700 (PDT) X-Originating-IP: [128.89.253.235] In-Reply-To: <1D3CF454-0536-4D5D-90DF-938C73EB6BF7@ve7jtb.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> <255B9BB34FB7D647A506DC292726F6E1150B786643@WSMSG3153V.srv.dir.telstra.com> <1D3CF454-0536-4D5D-90DF-938C73EB6BF7@ve7jtb.com> Date: Tue, 12 Mar 2013 01:01:37 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=bcaec5523bb62c06ba04d7b32ff0 X-Gm-Message-State: ALoCoQl+cBLtd+2+hvN8hXA0Sgddh2dGtg2wS6LPN03fUupp6lRBbgvHbWbOmZmeYwbm9whv6iIZ Cc: Tim Bray , "Manger, James H" , Karen ODonoghue , jose Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 05:01:43 -0000 --bcaec5523bb62c06ba04d7b32ff0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 to cheers. I already high-fived Mike in person. FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I don't think it's relevant to the criticality discussion, and it's just not needed. --Richard On Mon, Mar 11, 2013 at 11:01 PM, John Bradley wrote: > > On 2013-03-11, at 10:48 PM, "Manger, James H" < > James.H.Manger@team.telstra.com> wrote: > > I=92ll add some cheers =97 this does look like substantial progress.**** > > I assume the fields such as =93epk=94, =93apu=94 etc that sometimes must = be > understood, and at other times must be ignored (depending on =93alg=94 or= =93enc=94 > value) would NOT be listed in the =93crit=94 field as they are defined in= the > =93base specs=94.**** > > > Correct > > Being in the =93base specs=94 is the right criteria for whether a field s= hould > be listed in =93crit=94 as long as =93base specs=94 means: =93base specif= ications for > the particular =93alg=94/=94enc=94 values=94. It shouldn=92t mean (and do= esn=92t have to > mean) the base spec for the whole JOSE system.**** > > > > Crit is only for extensions, it is up to the extension definition to > decide if the field needs to be in crit. > > > P.S. =93meta=94 might be a nicer label than =93asd=94. > > > I don't have any particular attachment to the name. Some places things > like this are called associated data, though not the places normal people > go I grant you. > Meta-data about the payload is what it is, The current practice is to us= e > three character names. I am fine with met or meta (I suspect that if yo= u > are throwing crap into the envelope the single character won't kill anyon= e. > > James if you like the solution and want it to be meta I will back you on > it :) > > John B. > > **** > > --**** > James Manger**** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf O= f > *Tim Bray > *Sent:* Tuesday, 12 March 2013 12:43 PM > *To:* Karen ODonoghue > *Cc:* jose > *Subject:* Re: [jose] Proposed resolution of header criticality issue**** > ** ** > Cue wild cheers from the peanut gallery where non-cryptographers sit. > MustIgnore is infinitely more robust and open-ended than MustUnderstand. = -T > **** > > ** ** > On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue > wrote:**** > > Folks,**** > > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the meeting. > Point 5 of the proposed resolution below is actually independent of the > other 4 points, and could be considered separately. This will all be > discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must process". > However, that text has not been rolled into the summary text below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the JWK. = If > present, they MUST be understood by implementations using them.=94 to > =93Additional members MAY be present in the JWK. If not understood by > implementations encountering them, they MUST be ignored.=94 (And make th= e > same change for JWK Set as well.) > > 2: Characterize all existing JWS and JWE header fields as either must be > understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 must b= e understood. > =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ= =94, and =93cty=94 can be ignored > because while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as =93epk= =94, > =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be understood and use= d when =93alg=94 or > =93enc=94 values requiring them are used, and otherwise they may be ignor= ed. > > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon when > present. For instance, an expiration-time extension field could be marke= d > as must-be-understood-and-acted-upon. One possible name for this would b= e > =93crit=94 (critical). An example use, along with a hypothetical =93exp= =94 > (expiration-time) field is: > > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } > > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not understoo= d. > > 5. Define a new header field =93asd=94 (application-specific data) whose > value is a JSON structure whose contents are opaque to and ignored by JWS > and JWE implementations but for which its contents MUST be provided to > applications using JWS or JWE, provided that the signature/MAC validation > or decryption operation succeeds. The intended use of this field is to > have a standard place to provide application-specific metadata about the > payload or plaintext.**** > ** ** > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > ** ** > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec5523bb62c06ba04d7b32ff0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 to cheers. =A0I already high-fived Mike in person.

FW= IW, my preference would be to get rid of "asd" or "meta"= ; (part 5). =A0I don't think it's relevant to the criticality discu= ssion, and it's just not needed. =A0

--Richard



On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@= ve7jtb.com> wrote:

On 2013-03-11, at 10:48 PM, "Manger, James H&q= uot; <James.H.Manger@team.telstra.com> wrote:

I=92ll add some cheers =97 this does lo= ok like substantial progress.
=A0
I assume the fields such as =93epk=94, =93apu=94 etc that sometimes= must be understood, and at other times must be ignored (depending on =93al= g=94 or =93enc=94 value) would NOT be listed in the =93crit=94 field as the= y are defined in the =93base specs=94.
=A0
Correct

Being in the =93base specs=94 is the ri= ght criteria for whether a field should be listed in =93crit=94 as long as = =93base specs=94 means: =93base specifications for the particular =93alg=94= /=94enc=94 values=94. It shouldn=92t mean (and doesn=92t have to mean) the = base spec for the whole JOSE system.
=A0

Crit is only for extensions, it is up to the extension defi= nition to decide if the field needs to be in crit.


P.S. =93meta=94 might be a nicer label = than =93asd=94.

I don't have any particul= ar attachment to the name. =A0 Some places things like this are called asso= ciated data, though not the places normal people go I grant you. =A0
<= div> Meta-data about the payload is what it is, =A0The current practice is to us= e three character names. =A0 I am fine with met or meta (I suspect that if = you are throwing crap into the envelope the single character won't kill= anyone.

James if you like the solution and want it to be meta I= will back you on it :)

John B.

=A0
--
James Manger
=A0
<= div style=3D"border-style:solid none none;border-top-width:1pt;border-top-c= olor:rgb(181,196,223);padding:3pt 0cm 0cm">
From:=A0jose-bounces@ietf.org [mail= to:jose-bounces@ietf.org]=A0O= n Behalf Of=A0Tim Bray
Sent:=A0Tuesday, 12 March 2013 12:43 PM
To:=A0Karen ODonoghue
Cc:=A0jose
Subje= ct:=A0Re: [jose] Proposed resolution of header criticality= issue
=A0
Cue wild cheers from the peanut gallery where non-cryptographers sit.=A0 Mu= stIgnore is infinitely more robust and open-ended than MustUnderstand.=A0 -= T

=A0

On Mon, Mar 11, 2013 at 5:= 31 PM, Karen O'Donoghue <odonoghue@iso= c.org> wrote:

Folks,


A side meeting was held Sunday with a number of jose working group part= icipants to try to resolve the open issue related to header criticality. Th= e following are the proposed resolutions from the meeting. Point 5 of the p= roposed resolution below is actually independent of the other 4 points, and= could be considered separately. This will all be discussed in Wednesday= 9;s meeting.=A0

In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "m= ust process". However, that text has not been rolled into the summary = text below yet.=A0

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin= Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (a= nd my apologies if I missed someone).=A0

Regards,= =A0
Karen

1:=A0 Change the language =93Additional members MAY be present= in the JWK. =A0If present, they MUST be understood by implementations usin= g them.=94 to =93Additional members MAY be present in the JWK. =A0If not un= derstood by implementations encountering them, they MUST be ignored.=94=A0 = (And make the same change for JWK Set as well.)

2:=A0 Characterize all existing JWS and JWE header fields as either mus= t be understood or may be ignored.=A0 =93alg=94, =93enc=94, and =93zip=94 m= ust be understood.=A0 =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94= , =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not usin= g them may result in the inability to process some signatures or encrypted = content, this will not result in a security violation =96 just degraded fun= ctionality.=A0 Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu= =94, and =93epv=94 must be understood and used when =93alg=94 or =93enc=94 = values requiring them are used, and otherwise they may be ignored.

3.=A0 Define a new header field that lists which additional fields not = defined in the base specifications must be understood and acted upon when p= resent.=A0 For instance, an expiration-time extension field could be marked= as must-be-understood-and-acted-upon.=A0 One possible name for this would = be =93crit=94 (critical).=A0 An example use, along with a hypothetical =93e= xp=94 (expiration-time) field is:

=A0 {"alg":"ES256",
=A0=A0 "crit":[&qu= ot;exp"],
=A0=A0 "exp=94:1363284000
=A0 }

4.=A0 All = additional header fields not defined in the base specifications and not con= tained in the =93crit=94 list MUST be ignored if not understood.

5.=A0 Define a new header field =93asd=94 (application-specific data) w= hose value is a JSON structure whose contents are opaque to and ignored by = JWS and JWE implementations but for which its contents MUST be provided to = applications using JWS or JWE, provided that the signature/MAC validation o= r decryption operation succeeds.=A0 The intended use of this field is to ha= ve a standard place to provide application-specific metadata about the payl= oad or plaintext.

=A0
=A0


_____= __________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman= /listinfo/jose

=A0
__________________________________= _____________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=


______________________________= _________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec5523bb62c06ba04d7b32ff0-- From dick.hardt@gmail.com Mon Mar 11 22:26:12 2013 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 3346521F8654 for ; Mon, 11 Mar 2013 22:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3 X-Spam-Level: X-Spam-Status: No, score=-3 tagged_above=-999 required=5 tests=[AWL=0.599, 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 niEpkkp8z3eb for ; Mon, 11 Mar 2013 22:26:11 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 721AD21F8623 for ; Mon, 11 Mar 2013 22:26:11 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4588353pbb.18 for ; Mon, 11 Mar 2013 22:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=6+JSMXFcwXwaWzfCcgjKZoAf3Z8i2ny9fuaZ9ORjc/w=; b=jXuHWvv5XqD/infSqas5HCe3U2tFlYRacnOQvihJG4MCQdQRUpJEy+Jz0iBFiKoGHH knKL1JU3wg66C7o0WUdfZjk8VKarRfat+5D9rkPxTMuUPFEPEW+BNbDA2auNLuGF33mv bxmdis3S2/RzmEYcslzEihLyG+t7kEZpuG/1YbQDmZSZELJlUOo5XJBCJQYngCEJ9kD+ +73PiPZHr0l/hKfMqZG7D7CgxAtCIuUuV9Qlgf0npqgM+Rn8iv1Eba4qMfRzMHXiUoUK Q5vfb+sLqi/v3RhqZ9q79rvGnrS2LoWCUuNYutuYkfKBD2yjeLPZlQRVdsI3aACJihyX 32XQ== X-Received: by 10.68.10.227 with SMTP id l3mr34767534pbb.100.1363065971179; Mon, 11 Mar 2013 22:26:11 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hu2sm23393222pbc.38.2013.03.11.22.26.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 22:26:08 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <513E774C.6090605@isoc.org> Date: Mon, 11 Mar 2013 22:26:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0B6EA527-9DE6-4708-A48D-9D2660951F84@gmail.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> To: odonoghue@isoc.org X-Mailer: Apple Mail (2.1499) Cc: jose@ietf.org Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 05:26:12 -0000 On Mar 11, 2013, at 5:31 PM, Karen O'Donoghue = wrote: >=20 > Folks, >=20 > A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting.=20 >=20 > In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet.=20 >=20 > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, = Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your = efforts (and my apologies if I missed someone).=20 >=20 > Regards,=20 > Karen >=20 > 1: Change the language =93Additional members MAY be present in the = JWK. If present, they MUST be understood by implementations using = them.=94 to =93Additional members MAY be present in the JWK. If not = understood by implementations encountering them, they MUST be ignored.=94 = (And make the same change for JWK Set as well.) Yeah! Implementing MUST understand was going to be non-trivial. >=20 > 2: Characterize all existing JWS and JWE header fields as either must = be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 = must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94= , =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not = using them may result in the inability to process some signatures or = encrypted content, this will not result in a security violation =96 just = degraded functionality. Other fields such as =93epk=94, =93apu=94, = =93apv=94, =93epu=94, and =93epv=94 must be understood and used when = =93alg=94 or =93enc=94 values requiring them are used, and otherwise = they may be ignored. Why must "zip" be understood? Is there a security issue here or just = degraded performance? In my current implementations, "zip" does not help = me enough to bother with the added complexity and I have not implemented = support. -- Dick From James.H.Manger@team.telstra.com Mon Mar 11 23:08:44 2013 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 66BAE21F870E for ; Mon, 11 Mar 2013 23:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.658 X-Spam-Level: X-Spam-Status: No, score=-0.658 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 Glx98dgzDwTC for ; Mon, 11 Mar 2013 23:08:43 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6EF21F868F for ; Mon, 11 Mar 2013 23:08:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,827,1355058000"; d="scan'208";a="122611201" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 17:08:38 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="169454424" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcavi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 17:08:38 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Tue, 12 Mar 2013 17:08:38 +1100 From: "Manger, James H" To: Dick Hardt Date: Tue, 12 Mar 2013 17:08:36 +1100 Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4e4jYqjHuJ8pwtRhKhYPClWZMiPwABJ8Fw Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B786C1F@WSMSG3153V.srv.dir.telstra.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> <0B6EA527-9DE6-4708-A48D-9D2660951F84@gmail.com> In-Reply-To: <0B6EA527-9DE6-4708-A48D-9D2660951F84@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 06:08:44 -0000 PiBXaHkgbXVzdCAiemlwIiBiZSB1bmRlcnN0b29kPyBJcyB0aGVyZSBhIHNlY3VyaXR5IGlzc3Vl IGhlcmUgb3IganVzdA0KPiBkZWdyYWRlZCBwZXJmb3JtYW5jZT8gSW4gbXkgY3VycmVudCBpbXBs ZW1lbnRhdGlvbnMsICJ6aXAiIGRvZXMgbm90DQo+IGhlbHAgbWUgZW5vdWdoIHRvIGJvdGhlciB3 aXRoIHRoZSBhZGRlZCBjb21wbGV4aXR5IGFuZCBJIGhhdmUgbm90DQo+IGltcGxlbWVudGVkIHN1 cHBvcnQuDQo+IA0KPiAtLSBEaWNrDQoNCllvdSBkb24ndCB3YW50IHRvIHRyeSB0byBpbnRlcnBy ZXQgY29tcHJlc3NlZCBkYXRhIGFzIHBsYWluIHRleHQuIFRoYXQgY291bGQgYmUgYSBzZWN1cml0 eSBwcm9ibGVtLiBBIHRyaWNreSBwZXJzb24gbWlnaHQgYmUgYWJsZSB0byBjcmVhdGUsIHNheSwg YSB2YWxpZCBKU09OIHZhbHVlIFggdGhhdCBjb21wcmVzc2VzIHRvIFkgdGhhdCBpcyBhbHNvIHZh bGlkIEpTT04uIElmIHlvdSBpZ25vcmUgInppcCIgeW91IGdldCBKT1NFLXZlcmlmaWVkIFk7IGlm IHlvdSBwcm9jZXNzICJ6aXAiIHlvdSBnZXQgSk9TRS12ZXJpZmllZCBYLg0KDQpZb3UgbWlnaHQg bm90IGhhdmUgdG8gaW1wbGVtZW50ICJ6aXAiICh0aGF0IGlzIGEgc2VwYXJhdGUgTVRJIGRpc2N1 c3Npb24pLCBidXQgeW91ciByZWNpcGllbnQgY29kZSBhdCBsZWFzdCBuZWVkcyB0byBub3RpY2Ug d2hlbiAiemlwIiBpcyBwcmVzZW50IGFuZCB0aHJvdyBhbiBlcnJvciAoaW5zdGVhZCBvZiBtaXNp bnRlcnByZXRpbmcgdGhlIGNvbXByZXNzZWQgY29udGVudCkuDQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg== From dick.hardt@gmail.com Mon Mar 11 23:38:41 2013 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 AD6CA21F8718 for ; Mon, 11 Mar 2013 23:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[AWL=-1.424, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 5vZLTnUXEp7G for ; Mon, 11 Mar 2013 23:38:41 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 2334721F86C2 for ; Mon, 11 Mar 2013 23:38:41 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so5953213iea.12 for ; Mon, 11 Mar 2013 23:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=XrFkqAPWzc00z2w056CFvEKK/+7/ndNjjaT/fELUEaY=; b=BRTroyz2CKUbB2Mnu7rveJ8LEtMG4nUFt2Atuv/naK+mZGtRUqPG8yXjix+b/kUT7N 6nnjCkZHhToXi/lvrdJq2q3HB5C8c9Ryz+nkUGaCI7228U6nHewwQiy4prXZgbpx1yUH E6ddeHNyErZ2KkDfghLtjXpN+ONacc8kz7koefFE2UJd7l8U6L256cR+fao8iOmrKQPY fB/sNqSOlFiDe4qg5P8XKA5Nhp9s69craKMK6jJKGP1BQXnDMipL1ojTG+4yUH74TcxH 7cSnYYbNZMUkFbL1w1kPV2ogMkqqPm0Z9E9bLkCuz69Se1hjZgzWUp5gt7Xgs7gP0zBT pPCQ== X-Received: by 10.50.1.198 with SMTP id 6mr10470566igo.0.1363070320808; Mon, 11 Mar 2013 23:38:40 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ew5sm19554249igc.2.2013.03.11.23.38.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 11 Mar 2013 23:38:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B786C1F@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 11 Mar 2013 23:38:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6497528B-758E-4060-B884-29ECFB1DD34E@gmail.com> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> <0B6EA527-9DE6-4708-A48D-9D2660951F84@gmail.com> <255B9BB34FB7D647A506DC292726F6E1150B786C1F@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1499) Cc: jose@ietf.org Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 06:38:41 -0000 Thanks for the clear explanation James.=20 On Mar 11, 2013, at 11:08 PM, "Manger, James H" = wrote: >> Why must "zip" be understood? Is there a security issue here or just >> degraded performance? In my current implementations, "zip" does not >> help me enough to bother with the added complexity and I have not >> implemented support. >>=20 >> -- Dick >=20 > You don't want to try to interpret compressed data as plain text. That = could be a security problem. A tricky person might be able to create, = say, a valid JSON value X that compresses to Y that is also valid JSON. = If you ignore "zip" you get JOSE-verified Y; if you process "zip" you = get JOSE-verified X. >=20 > You might not have to implement "zip" (that is a separate MTI = discussion), but your recipient code at least needs to notice when "zip" = is present and throw an error (instead of misinterpreting the compressed = content). >=20 > -- > James Manger From vladimir@nimbusds.com Mon Mar 11 23:44:54 2013 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 6E01E21F8739 for ; Mon, 11 Mar 2013 23:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 ZFhf-u3zPey5 for ; Mon, 11 Mar 2013 23:44:52 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 3DCF021F8518 for ; Mon, 11 Mar 2013 23:44:52 -0700 (PDT) Received: (qmail 9858 invoked from network); 12 Mar 2013 06:44:50 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 12 Mar 2013 06:44:49 -0000 Received: (qmail 7210 invoked by uid 99); 12 Mar 2013 06:44:49 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.83.232 User-Agent: Workspace Webmail 5.6.33 Message-Id: <20130311234447.cc40c4f3d92d2001859047cd8cabb9ab.64d2aabe52.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Mon, 11 Mar 2013 23:44:47 -0700 Mime-Version: 1.0 Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 06:44:55 -0000 How about "crt" instead of "crit", to fit the three-letter convention=0Afor= naming fields?=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.c= om : vladimir@nimbusds.com=0A=0A=0A-------- Original Message --------=0ASub= ject: [jose] Proposed resolution of header criticality issue=0AFrom: Karen = O'Donoghue =0ADate: Tue, March 12, 2013 12:31 am=0ATo: = jose@ietf.org=0A=0A =0A Folks,=0A =0A A side meeting was held Sunday with= a number of jose working group=0Aparticipants to try to resolve the open i= ssue related to header=0Acriticality. The following are the proposed resolu= tions from the=0Ameeting. Point 5 of the proposed resolution below is actua= lly=0Aindependent of the other 4 points, and could be considered separately= .=0AThis will all be discussed in Wednesday's meeting. =0A =0A In addition = to the text below, there was some agreement to replace the=0A"understand" t= ext with something a bit more explicit like "must=0Aprocess". However, that= text has not been rolled into the summary text=0Abelow yet. =0A =0A Thank = you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin=0AThomas,= Eric Rescorla, Matt Miller, and Richard Barnes for your efforts=0A(and my = apologies if I missed someone). =0A =0A Regards, =0A Karen=0A =0A 1: Chang= e the language =E2=80=9CAdditional members MAY be present in the=0AJWK. If= present, they MUST be understood by implementations using=0Athem.=E2=80=9D= to =E2=80=9CAdditional members MAY be present in the JWK. If not=0Aunders= tood by implementations encountering them, they MUST be=0Aignored.=E2=80=9D= (And make the same change for JWK Set as well.)=0A =0A 2: Characterize a= ll existing JWS and JWE header fields as either must=0Abe understood or may= be ignored. =E2=80=9Calg=E2=80=9D, =E2=80=9Cenc=E2=80=9D, and =E2=80=9Czi= p=E2=80=9D=0Amust be understood. =E2=80=9Ckid=E2=80=9D, =E2=80=9Cx5u=E2=80= =9D, =E2=80=9Cx5c=E2=80=9D, =E2=80=9Cx5t=E2=80=9D,=0A=E2=80=9Cjwk=E2=80=9D,= =E2=80=9Cjku=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, and =E2=80=9Ccty=E2=80=9D ca= n be ignored because=0Awhile not using them may result in the inability to = process some=0Asignatures or encrypted content, this will not result in a s= ecurity=0Aviolation =E2=80=93 just degraded functionality. Other fields su= ch as=0A=E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2=80=9D, =E2=80=9Capv=E2=80=9D= , =E2=80=9Cepu=E2=80=9D, and =E2=80=9Cepv=E2=80=9D must be=0Aunderstood and= used when =E2=80=9Calg=E2=80=9D or =E2=80=9Cenc=E2=80=9D values requiring = them=0Aare used, and otherwise they may be ignored.=0A =0A 3. Define a new= header field that lists which additional fields not=0Adefined in the base = specifications must be understood and acted upon=0Awhen present. For insta= nce, an expiration-time extension field could be=0Amarked as must-be-unders= tood-and-acted-upon. One possible name for this=0Awould be =E2=80=9Ccrit= =E2=80=9D (critical). An example use, along with a=0Ahypothetical =E2=80= =9Cexp=E2=80=9D (expiration-time) field is:=0A =0A {"alg":"ES256",=0A = "crit":["exp"],=0A "exp=E2=80=9D:1363284000=0A }=0A =0A 4. All additi= onal header fields not defined in the base specifications=0Aand not contain= ed in the =E2=80=9Ccrit=E2=80=9D list MUST be ignored if not=0Aunderstood.= =0A =0A 5. Define a new header field =E2=80=9Casd=E2=80=9D (application-sp= ecific data)=0Awhose value is a JSON structure whose contents are opaque to= and ignored=0Aby JWS and JWE implementations but for which its contents MU= ST be=0Aprovided to applications using JWS or JWE, provided that the=0Asign= ature/MAC validation or decryption operation succeeds. The intended=0Ause = of this field is to have a standard place to provide=0Aapplication-specific= metadata about the payload or plaintext.=0A =0A =0A=0A=0A =0A=0A _________= ______________________________________=0Ajose mailing list=0Ajose@ietf.org= =0Ahttps://www.ietf.org/mailman/listinfo/jose From James.H.Manger@team.telstra.com Tue Mar 12 00:41:26 2013 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 880FF21F858C for ; Tue, 12 Mar 2013 00:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 kgzg6XWKcyhJ for ; Tue, 12 Mar 2013 00:41:25 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 8E85B21F85B1 for ; Tue, 12 Mar 2013 00:41:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,829,1355058000"; d="scan'208,217";a="123424679" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipocvi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 18:41:22 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="117777929" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipcbvi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 18:41:22 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Tue, 12 Mar 2013 18:41:22 +1100 From: "Manger, James H" To: Richard Barnes Date: Tue, 12 Mar 2013 18:41:20 +1100 Thread-Topic: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter Thread-Index: Ac4cCm6ySBoYnLhLTWGJmr/Tk3H/UgC5QjLQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B786D22@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B786D22WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 12 Mar 2013 07:41:26 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B786D22WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KVmVyaWZ5aW5nIGEgSldTIHNpZ25hdHVyZSB3aXRoIGEgcmF3IHB1YmxpYyBr ZXkgaW4gdGhlIEpXUyBwcm92aWRlcyBhbG1vc3Qgbm8gdXNlZnVsIHNlY3VyaXR5IHByb3BlcnR5 LiBUbyBiZSB1c2VmdWwgeW91IG5lZWQgdG8gY29uZmlybSB0aGUgYXV0aGVudGljaXR5IG9mIHRo ZSBwdWJsaWMga2V5IGZyb20gc29tZSBvdGhlciBzb3VyY2UuIEdlbmVyYWxseSB0aGUg4oCcb3Ro ZXIgc291cmNl4oCdIHRoYXQgcHJvdmlkZXMgdGhlIGF1dGhlbnRpY2l0eSBjYW4gcHJvdmlkZSB0 aGUgYWN0dWFsIHB1YmxpYyBrZXkgYXMgd2VsbC4NCg0KVGhlIOKAnGRhbmdlcuKAnSBvZiBpbmNs dWRpbmcgYSByYXcgcHVibGljIGtleSBpcyB0aGF0IHNpbGx5IGNvZGUgdmVyaWZpZXMgdGhlIG1h dGhzIHRoZW4gYXV0b21hdGljYWxseSDigJx0cnVzdHPigJ0gdGhlIG1lc3NhZ2UuIEl0IGlzIG9u bHkgYSBzbWFsbCBkYW5nZXIuIEkgYW0gd2lsbGluZyB0byBpZ25vcmUgdGhlIGRhbmdlciwgYnV0 IG9ubHkgaWYgdGhlcmUgaXMgcmVhbCB2YWx1ZSBpbiBpbmNsdWRpbmcgdGhlIHJhdyBwdWJsaWMg a2V5LiBQZXJoYXBzIERBTkUgKGtleSBpbiBETlMgcHJvdGVjdGVkIGJ5IEROU1NFQykgaXMgYW4g ZXhhbXBsZSBvZiBhIG1lY2hhbmlzbSB0aGF0IGNhbiBjb25maXJtIHRoZSBhdXRoZW50aWNpdHkg b2YgYSBoYXNoIG9mIGEga2V5IHdpdGhvdXQgcHJvdmlkaW5nIHRoZSBhY3R1YWwga2V5LiBUaG91 Z2ggd291bGRu4oCZdCBpdCBiZSBiZXR0ZXIgdG8gZ2V0IHRoZSBmdWxsIGtleSBmcm9tIERBTkUg b25jZSwgYW5kIG9ubHkgc2VuZCBhIGtleSBpZCBpbiBldmVyeSBKT1NFIG1lc3NhZ2U/DQoNClRo ZSBjbG9zZXN0IGFuYWxvZ3kgd2l0aCBjZXJ0cyBpcyB3aGV0aGVyIG9yIG5vdCB0byBpbmNsdWRl IHRoZSBzZWxmLXNpZ25lZCByb290IGNlcnQgYXQgdGhlIGVuZCBvZiBhIGNlcnQgY2hhaW4gaW4g dGhlIG1lc3NhZ2UuIEl0IHNob3VsZG7igJl0IGJlIHNlbnQuIEl0IG9mdGVuIGlzLiBUaGF0IGhh c27igJl0IGNhdXNlZCB0aGUgc2t5IHRvIGZhbGwgaW4sIHRob3VnaCBpdCB3YXN0ZXMgYSBzbWFs bCAobm9uLXRyaXZpYWw/PykgcG9ydGlvbiBvZiBUTFMgdHJhZmZpYy4NCg0KLS0NCkphbWVzIE1h bmdlcg0KDQpGcm9tOiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYuc3hdDQpTZW50OiBT YXR1cmRheSwgOSBNYXJjaCAyMDEzIDE6MzcgQU0NClRvOiBNYW5nZXIsIEphbWVzIEgNCkNjOiBQ ZWNrLCBNaWNoYWVsIEE7IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9zZV0gZHJhZnQt aWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wOCAiandrIiBoZWFkZXIgcGFyYW1ldGVyDQoN Ck9uIFdlZCwgTWFyIDYsIDIwMTMgYXQgMTA6NTUgUE0sIE1hbmdlciwgSmFtZXMgSCA8SmFtZXMu SC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxz dHJhLmNvbT4+IHdyb3RlOg0KSSBhZ3JlZSwgTWljaGFlbC4gQSByYXcgcHVibGljIGtleSBpbiBh IEpXUyBpcyBpbnZpdGluZyBkYW5nZXJvdXMgY29kZS4NCg0KQ291bGQgeW91IGJlIGEgbGl0dGxl IG1vcmUgcHJlY2lzZSBoZXJlPyAgV2hhdCdzIHRoZSBkYW5nZXI/DQoNClRoZSBvbmx5IGRpZmZl cmVuY2UgYmV0d2VlbiBhIGtleSBhbmQgYSBjZXJ0IGlzIHRoYXQgdGhlIGNlcnQgcHJvdmlkZXMg dGhlIHJlY2lwaWVudCB3aXRoIHNvbWUgYXR0cmlidXRlcyB0aGF0IGdvIGFsb25nIHdpdGggdGhl IGtleSAoc2lnbmVkIHVuZGVyIHNvbWUgYXV0aG9yaXR5KSAtLSBhc3N1bWluZyB0aGUgcmVjaXBp ZW50IHN1cHBvcnRzIFguNTA5IGFuZCBoYXMgYW4gYXBwcm9wcmlhdGUgdHJ1c3QgYW5jaG9yLiAg U28gdGhlIG9ubHkgZGFuZ2VyIGlzIHRoYXQgdGhlIHJlY2lwaWVudCBtaWdodCBub3QgY2hlY2sg dGhlIGF0dHJpYnV0ZXMgYmVmb3JlIGFjY2VwdGluZyB0aGUgc2lnbmF0dXJlLg0KDQpUaGlzIGlz IGEgY29tcGxldGVseSBzZXBhcmF0ZSBxdWVzdGlvbiBmcm9tIHdoZXRoZXIgdGhlIHNpZ25hdHVy ZSBpcyB2YWxpZCwgaW4gYSBjcnlwdG9sb2dpY2FsIC8gbWF0aGVtYXRpY2FsIHNlbnNlLiAgQW5k IHRoZSBhbnN3ZXIgeW91J3JlIGltcGx5aW5nICh0aGF0IG5vdCBjaGVja2luZyBhdHRyaWJ1dGVz IGlzIGRhbmdlcm91cykgaXMgY2xlYXJseSBub3QgdHJ1ZSBpbiBhbGwgY2FzZXMuICBGb3IgZXhh bXBsZSwgaW4gUEdQLCB5b3UndmUgdmFsaWRhdGVkIHRoZSBwdWJsaWMga2V5IHRocm91Z2ggc29t ZSBvdXQtb2YtYmFuZCBjaGFubmVsLCBhbmQgeW91IHJlYWxseSBkbyBqdXN0IG5lZWQgdGhlIGtl eSBoZXJlLg0KDQpKT1NFIHNob3VsZCBzdGljayB0byBjcnlwdG8sIGFuZCBzdGF5IGF3YXkgZnJv bSBwb2xpY3kuICBUbyBkbyBvdGhlcndpc2Ugd291bGQgY3V0IG9mZiB1c2UgY2FzZXMgdW5uZWNl c3NhcmlsaXkuDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1i b3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFBlY2ssIE1pY2hhZWwgQQ0KU2VudDogVGh1 cnNkYXksIDcgTWFyY2ggMjAxMyA2OjIxIEFNDQpUbzogUmljaGFyZCBCYXJuZXMNCg0KQ2M6IGpv c2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdIGRy YWZ0LWlldGYtam9zZS1qc29uLXdlYi1zaWduYXR1cmUtMDggImp3ayIgaGVhZGVyIHBhcmFtZXRl cg0KDQpJbiB0aGUgY2FzZSBvZiBKV1MsIGl0IGxvb2tzIGxpa2Ugd2l0aCB0aGUg4oCcandr4oCd IGhlYWRlciBwYXJhbWV0ZXIsIHRoZSBzaWduZWQgbWVzc2FnZSBpdHNlbGYgY2FuIGNvbnRhaW4g dGhlIHJhdyBwdWJsaWMga2V5IHRvIGJlIHVzZWQgdG8gdmVyaWZ5IGl0Lg0KTXkgY29uY2VybiBp cyB0aGF0IHRoZSB2ZXJpZmllciB3aWxsIGdyYWIgYW5kIHVzZSB0aGUgcHVibGljIGtleSB3aXRo b3V0IGVuc3VyaW5nIGl0cyBhdXRoZW50aWNpdHkuDQpUaGlzIHdvdWxkIGJlIGFuYWxvZ291cyB0 byBhdXRvbWF0aWNhbGx5IHRydXN0aW5nIGEgc2VsZi1zaWduZWQgWC41MDkgY2VydGlmaWNhdGUu DQpUaGVyZSBzaG91bGQgYXQgbGVhc3QgYmUgc29tZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyBs YW5ndWFnZSB0aGF0IHdoZW4g4oCcandr4oCdIGlzIHVzZWQgdGhlIHZlcmlmaWVyIG5lZWRzIHRv IHVzZSBvdXQgb2YgYmFuZHMgbWVhbnMgdG8gYXNzdXJlIHRoYXQgdGhlIHByb3ZpZGVkIHB1Ymxp YyBrZXkgaXMgdHJ1c3RlZC4NCg0KQ01TIFNpZ25lZERhdGEgZG9lcyBub3QgY29udGFpbiB0aGUg cmF3IHB1YmxpYyBrZXkgdXNlZCB0byBzaWduIHRoZSBtZXNzYWdlIGl0c2VsZi4NCkl0IGNvbnRh aW5zIGEgU2lnbmVySWRlbnRpZmllciB0byByZWZlcmVuY2UgdGhlIHB1YmxpYyBrZXkgYW5kIG9w dGlvbmFsbHkgY29udGFpbnMgY2VydGlmaWNhdGVzICh3aGljaCB3b3VsZCBjb252ZXkgdGhlIHB1 YmxpYyBrZXksIGJ1dCBhbG9uZyB3aXRoIHByb29mIHRoYXQgaXQgc2hvdWxkIGJlIHRydXN0ZWQp Lg0KDQpSYXRoZXIgdGhhbiBkaXJlY3RseSBpbmNsdWRpbmcgdGhlIOKAnHJhd+KAnSBwdWJsaWMg a2V5LCBKV1MgcHJvdmlkZXMgbG90cyBvZiBvdGhlciBzYWZlciBoZWFkZXIgcGFyYW1ldGVycyB0 byByZWZlcmVuY2UgdGhlIHB1YmxpYyBrZXkuDQoNCk9uIFdlZCwgTWFyIDYsIDIwMTMgYXQgMTI6 MjggUE0sIFBlY2ssIE1pY2hhZWwgQSA8bXBlY2tAbWl0cmUub3JnPG1haWx0bzptcGVja0BtaXRy ZS5vcmc+PiB3cm90ZToNCldoYXQgaXMgdGhlIHVzZSBjYXNlIGZvciB0aGUgImp3ayIgKEpTT04g V2ViIEtleSkgSGVhZGVyIFBhcmFtZXRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjEuMyBvZiBk cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA4Pw0KDQpJdCBzZWVtcyB1bnNhZmUg Zm9yIGEgc2lnbmF0dXJlIHRvIHByb3ZpZGUsIHVuYXV0aGVudGljYXRlZCAobm90IGluIGEgc2ln bmVkIGNlcnRpZmljYXRlIG9yIHByb3RlY3RlZCBieSBvdGhlciBtZWFucyksIHRoZSBwdWJsaWMg a2V5IHRvIGJlIHVzZWQgdG8gdmVyaWZ5IGl0c2VsZi4NCkkgd291bGQgdGhpbmsgdGhpcyBmaWVs ZCBtYWtlcyBpdCB0b28gZWFzeSBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGRvIHRoZSB3cm9uZyB0 aGluZy4NCg0KVGhhbmtzLA0KTWlrZQ0KDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B786D22WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9 cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPlJpY2hhcmQsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5WZXJpZnlpbmcgYSBK V1Mgc2lnbmF0dXJlIHdpdGggYSByYXcgcHVibGljIGtleSBpbiB0aGUgSldTIHByb3ZpZGVzIGFs bW9zdCBubyB1c2VmdWwgc2VjdXJpdHkgcHJvcGVydHkuIFRvIGJlIHVzZWZ1bCB5b3UgbmVlZCB0 byBjb25maXJtIHRoZSBhdXRoZW50aWNpdHkgb2YgdGhlIHB1YmxpYyBrZXkgZnJvbSBzb21lIG90 aGVyIHNvdXJjZS4gR2VuZXJhbGx5IHRoZSDigJxvdGhlciBzb3VyY2XigJ0gdGhhdCBwcm92aWRl cyB0aGUgYXV0aGVudGljaXR5IGNhbiBwcm92aWRlIHRoZSBhY3R1YWwgcHVibGljIGtleSBhcyB3 ZWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIOKAnGRhbmdlcuKAnSBvZiBpbmNsdWRpbmcgYSBy YXcgcHVibGljIGtleSBpcyB0aGF0IHNpbGx5IGNvZGUgdmVyaWZpZXMgdGhlIG1hdGhzIHRoZW4g YXV0b21hdGljYWxseSDigJx0cnVzdHPigJ0gdGhlIG1lc3NhZ2UuIEl0IGlzIG9ubHkgYSBzbWFs bCBkYW5nZXIuIEkgYW0gd2lsbGluZyB0byBpZ25vcmUgdGhlIGRhbmdlciwgYnV0IG9ubHkgaWYg dGhlcmUgaXMgcmVhbCB2YWx1ZSBpbiBpbmNsdWRpbmcgdGhlIHJhdyBwdWJsaWMga2V5LiBQZXJo YXBzIERBTkUgKGtleSBpbiBETlMgcHJvdGVjdGVkIGJ5IEROU1NFQykgaXMgYW4gZXhhbXBsZSBv ZiBhIG1lY2hhbmlzbSB0aGF0IGNhbiBjb25maXJtIHRoZSBhdXRoZW50aWNpdHkgb2YgYSBoYXNo IG9mIGEga2V5IHdpdGhvdXQgcHJvdmlkaW5nIHRoZSBhY3R1YWwga2V5LiBUaG91Z2ggd291bGRu 4oCZdCBpdCBiZSBiZXR0ZXIgdG8gZ2V0IHRoZSBmdWxsIGtleSBmcm9tIERBTkUgb25jZSwgYW5k IG9ubHkgc2VuZCBhIGtleSBpZCBpbiBldmVyeSBKT1NFIG1lc3NhZ2U/PG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5UaGUgY2xvc2VzdCBhbmFsb2d5IHdpdGggY2VydHMgaXMgd2hldGhlciBvciBub3QgdG8g aW5jbHVkZSB0aGUgc2VsZi1zaWduZWQgcm9vdCBjZXJ0IGF0IHRoZSBlbmQgb2YgYSBjZXJ0IGNo YWluIGluIHRoZSBtZXNzYWdlLiBJdCBzaG91bGRu4oCZdCBiZSBzZW50LiBJdCBvZnRlbiBpcy4g VGhhdCBoYXNu4oCZdCBjYXVzZWQgdGhlIHNreSB0byBmYWxsIGluLCB0aG91Z2ggaXQgd2FzdGVz IGEgc21hbGwgKG5vbi10cml2aWFsPz8pIHBvcnRpb24gb2YgVExTIHRyYWZmaWMuPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiInPiBSaWNoYXJkIEJhcm5lcyBbbWFpbHRvOnJsYkBpcHYu c3hdIDxicj48Yj5TZW50OjwvYj4gU2F0dXJkYXksIDkgTWFyY2ggMjAxMyAxOjM3IEFNPGJyPjxi PlRvOjwvYj4gTWFuZ2VyLCBKYW1lcyBIPGJyPjxiPkNjOjwvYj4gUGVjaywgTWljaGFlbCBBOyBq b3NlQGlldGYub3JnPGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIGRyYWZ0LWlldGYtam9z ZS1qc29uLXdlYi1zaWduYXR1cmUtMDggJnF1b3Q7andrJnF1b3Q7IGhlYWRlciBwYXJhbWV0ZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5PbiBXZWQsIE1hciA2LCAyMDEzIGF0 IDEwOjU1IFBNLCBNYW5nZXIsIEphbWVzIEggJmx0OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5ILk1h bmdlckB0ZWFtLnRlbHN0cmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFtZXMuSC5NYW5nZXJAdGVh bS50ZWxzdHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxkaXY+PGJsb2NrcXVv dGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Jz48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBhZ3Jl ZSwgTWljaGFlbC4gQSByYXcgcHVibGljIGtleSBpbiBhIEpXUyBpcyBpbnZpdGluZyBkYW5nZXJv dXMgY29kZS48L3NwYW4+PG86cD48L286cD48L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPkNvdWxkIHlvdSBiZSBhIGxpdHRsZSBtb3JlIHByZWNpc2UgaGVyZT8gJm5ic3A7 V2hhdCdzIHRoZSBkYW5nZXI/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ VGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIGEga2V5IGFuZCBhIGNlcnQgaXMgdGhhdCB0aGUg Y2VydCBwcm92aWRlcyB0aGUgcmVjaXBpZW50IHdpdGggc29tZSBhdHRyaWJ1dGVzIHRoYXQgZ28g YWxvbmcgd2l0aCB0aGUga2V5IChzaWduZWQgdW5kZXIgc29tZSBhdXRob3JpdHkpIC0tIGFzc3Vt aW5nIHRoZSByZWNpcGllbnQgc3VwcG9ydHMgWC41MDkgYW5kIGhhcyBhbiBhcHByb3ByaWF0ZSB0 cnVzdCBhbmNob3IuICZuYnNwO1NvIHRoZSBvbmx5IGRhbmdlciBpcyB0aGF0IHRoZSByZWNpcGll bnQgbWlnaHQgbm90IGNoZWNrIHRoZSBhdHRyaWJ1dGVzIGJlZm9yZSBhY2NlcHRpbmcgdGhlIHNp Z25hdHVyZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5UaGlzIGlzIGEg Y29tcGxldGVseSBzZXBhcmF0ZSBxdWVzdGlvbiBmcm9tIHdoZXRoZXIgdGhlIHNpZ25hdHVyZSBp cyB2YWxpZCwgaW4gYSBjcnlwdG9sb2dpY2FsIC8gbWF0aGVtYXRpY2FsIHNlbnNlLiAmbmJzcDtB bmQgdGhlIGFuc3dlciB5b3UncmUgaW1wbHlpbmcgKHRoYXQgbm90IGNoZWNraW5nIGF0dHJpYnV0 ZXMgaXMgZGFuZ2Vyb3VzKSBpcyBjbGVhcmx5IG5vdCB0cnVlIGluIGFsbCBjYXNlcy4gJm5ic3A7 Rm9yIGV4YW1wbGUsIGluIFBHUCwgeW91J3ZlIHZhbGlkYXRlZCB0aGUgcHVibGljIGtleSB0aHJv dWdoIHNvbWUgb3V0LW9mLWJhbmQgY2hhbm5lbCwgYW5kIHlvdSByZWFsbHkgZG8ganVzdCBuZWVk IHRoZSBrZXkgaGVyZS48bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5KT1NF IHNob3VsZCBzdGljayB0byBjcnlwdG8sIGFuZCBzdGF5IGF3YXkgZnJvbSBwb2xpY3kuICZuYnNw O1RvIGRvIG90aGVyd2lzZSB3b3VsZCBjdXQgb2ZmIHVzZSBjYXNlcyB1bm5lY2Vzc2FyaWxpeS48 bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwv bzpwPjwvcD48L2Rpdj48YmxvY2txdW90ZSBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20nPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2 PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdp bi1sZWZ0OjUuMjVwdCc+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+IDxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmpvc2UtYm91bmNl c0BpZXRmLm9yZzwvYT5dIDxiPk9uIEJlaGFsZiBPZiA8L2I+UGVjaywgTWljaGFlbCBBPGJyPjxi PlNlbnQ6PC9iPiBUaHVyc2RheSwgNyBNYXJjaCAyMDEzIDY6MjEgQU08YnI+PGI+VG86PC9iPiBS aWNoYXJkIEJhcm5lczwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxicj48Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbam9z ZV0gZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLXNpZ25hdHVyZS0wOCAmcXVvdDtqd2smcXVvdDsg aGVhZGVyIHBhcmFtZXRlcjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxk aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SW4gdGhlIGNh c2Ugb2YgSldTLCBpdCBsb29rcyBsaWtlIHdpdGggdGhlIOKAnGp3a+KAnSBoZWFkZXIgcGFyYW1l dGVyLCB0aGUgc2lnbmVkIG1lc3NhZ2UgaXRzZWxmIGNhbiBjb250YWluIHRoZSByYXcgcHVibGlj IGtleSB0byBiZSB1c2VkIHRvIHZlcmlmeSBpdC48L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk15IGNvbmNl cm4gaXMgdGhhdCB0aGUgdmVyaWZpZXIgd2lsbCBncmFiIGFuZCB1c2UgdGhlIHB1YmxpYyBrZXkg d2l0aG91dCBlbnN1cmluZyBpdHMgYXV0aGVudGljaXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhp cyB3b3VsZCBiZSBhbmFsb2dvdXMgdG8gYXV0b21hdGljYWxseSB0cnVzdGluZyBhIHNlbGYtc2ln bmVkIFguNTA5IGNlcnRpZmljYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlcmUgc2hvdWxkIGF0 IGxlYXN0IGJlIHNvbWUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgbGFuZ3VhZ2UgdGhhdCB3aGVu IOKAnGp3a+KAnSBpcyB1c2VkIHRoZSB2ZXJpZmllciBuZWVkcyB0byB1c2Ugb3V0IG9mIGJhbmRz IG1lYW5zIHRvIGFzc3VyZSB0aGF0IHRoZSBwcm92aWRlZCBwdWJsaWMga2V5IGlzIHRydXN0ZWQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNNUyBTaWduZWRE YXRhIGRvZXMgbm90IGNvbnRhaW4gdGhlIHJhdyBwdWJsaWMga2V5IHVzZWQgdG8gc2lnbiB0aGUg bWVzc2FnZSBpdHNlbGYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBz dHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8n PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JdCBjb250YWlucyBhIFNpZ25lcklk ZW50aWZpZXIgdG8gcmVmZXJlbmNlIHRoZSBwdWJsaWMga2V5IGFuZCBvcHRpb25hbGx5IGNvbnRh aW5zIGNlcnRpZmljYXRlcyAod2hpY2ggd291bGQgY29udmV5IHRoZSBwdWJsaWMga2V5LCBidXQg YWxvbmcgd2l0aCBwcm9vZiB0aGF0IGl0IHNob3VsZCBiZSB0cnVzdGVkKS48L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UmF0aGVyIHRoYW4gZGlyZWN0bHkgaW5j bHVkaW5nIHRoZSDigJxyYXfigJ0gcHVibGljIGtleSwgSldTIHByb3ZpZGVzIGxvdHMgb2Ygb3Ro ZXIgc2FmZXIgaGVhZGVyIHBhcmFtZXRlcnMgdG8gcmVmZXJlbmNlIHRoZSBwdWJsaWMga2V5Ljwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjIyLjA1 cHQnPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byc+PHNwYW4gbGFuZz1FTi1VUz5PbiBXZWQsIE1hciA2LCAyMDEzIGF0IDEyOjI4IFBNLCBQ ZWNrLCBNaWNoYWVsIEEgJmx0OzxhIGhyZWY9Im1haWx0bzptcGVja0BtaXRyZS5vcmciIHRhcmdl dD0iX2JsYW5rIj5tcGVja0BtaXRyZS5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoyNy4zcHQnPjxzcGFuIGxhbmc9 RU4tVVM+V2hhdCBpcyB0aGUgdXNlIGNhc2UgZm9yIHRoZSAmcXVvdDtqd2smcXVvdDsgKEpTT04g V2ViIEtleSkgSGVhZGVyIFBhcmFtZXRlciBkZXNjcmliZWQgaW4gc2VjdGlvbiA0LjEuMyBvZiBk cmFmdC1pZXRmLWpvc2UtanNvbi13ZWItc2lnbmF0dXJlLTA4Pzxicj48YnI+SXQgc2VlbXMgdW5z YWZlIGZvciBhIHNpZ25hdHVyZSB0byBwcm92aWRlLCB1bmF1dGhlbnRpY2F0ZWQgKG5vdCBpbiBh IHNpZ25lZCBjZXJ0aWZpY2F0ZSBvciBwcm90ZWN0ZWQgYnkgb3RoZXIgbWVhbnMpLCB0aGUgcHVi bGljIGtleSB0byBiZSB1c2VkIHRvIHZlcmlmeSBpdHNlbGYuPGJyPkkgd291bGQgdGhpbmsgdGhp cyBmaWVsZCBtYWtlcyBpdCB0b28gZWFzeSBmb3IgaW1wbGVtZW50YXRpb25zIHRvIGRvIHRoZSB3 cm9uZyB0aGluZy48YnI+PGJyPlRoYW5rcyw8YnI+TWlrZTxicj48YnI+PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYmxvY2tx dW90ZT48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150B786D22WSMSG3153Vsrv_-- From djc.ochtman@gmail.com Tue Mar 12 02:48:32 2013 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 D8D9521F88F7 for ; Tue, 12 Mar 2013 02:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 rYA-hk1IN1QX for ; Tue, 12 Mar 2013 02:48:32 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3DF21F88C0 for ; Tue, 12 Mar 2013 02:48:32 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so5549972oag.10 for ; Tue, 12 Mar 2013 02:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Txvq4LipkZRH4AQAu8NaHuVF3M4MdxbmoAEnaLhRhGE=; b=jI4p/e2d1ZVvFsOddfEWeZy2WkRC7Rr7r7r+UTveQ9RGFHQ1hq/jx6iOdi9APFB5JW tzYltLOPIKE0Dw14ERFH+vfZvLA4BQfbRCBsqyiqop5rQSvj1By7rZie3sHpkbmceQzs glbQoVQwNYpQbuTGawV+jkRUW45nVccM+gyPM/pcNxh0iFGVcgxTS2Tztbn9lXDfPTqC lr/cSueGRWh1h2i2uFW4uog5u+pixqrViFaBxkovzsUI1ddEfDsUPgBE3ghuw734G0hV juOWFcCHMR7BbZdzYegkezVfcj9O52ovWYnH9ccP8jUbCimRb1oWVbHLMyBgF339vVPF 7Yzw== X-Received: by 10.182.12.6 with SMTP id u6mr11325992obb.3.1363081711938; Tue, 12 Mar 2013 02:48:31 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.76.8.2 with HTTP; Tue, 12 Mar 2013 02:48:10 -0700 (PDT) In-Reply-To: <513E774C.6090605@isoc.org> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> From: Dirkjan Ochtman Date: Tue, 12 Mar 2013 10:48:10 +0100 X-Google-Sender-Auth: MqmwQcZ7ny3lvdlMd9HRU8keaXw Message-ID: To: odonoghue@isoc.org Content-Type: text/plain; charset=UTF-8 Cc: "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 09:48:33 -0000 On Tue, Mar 12, 2013 at 1:31 AM, Karen O'Donoghue wrote: > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header criticality. > The following are the proposed resolutions from the meeting. Point 5 of the > proposed resolution below is actually independent of the other 4 points, and > could be considered separately. This will all be discussed in Wednesday's > meeting. This looks like a great improvement. Cheers, Dirkjan From rlb@ipv.sx Tue Mar 12 05:12:01 2013 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 3534421F89E2 for ; Tue, 12 Mar 2013 05:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 DPdJar0sDHs4 for ; Tue, 12 Mar 2013 05:11:59 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10C1821F89E1 for ; Tue, 12 Mar 2013 05:11:59 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so5666005oag.17 for ; Tue, 12 Mar 2013 05:11:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=JC41NvBqnpfE44geIkkRxdBM5ZW/GEo6qGfSCPU6100=; b=Cdo9Tc8pMINavTOUTWSUshnEemoEvtUHUoj1rPvpqcpBFXUATZzqA4okbZQbyE5zFZ +4r9HgqNXtIP0lvj9pza1xyw8oaM9n9qxzJV+bmdX0kwR/TdEn+pIJ4k1zSaw6RZVlTa 8YV3r+5lhXIZtDVtSRFGMJrr/LSBTZAz3l88WwZPUWPAKLHp9MScsGGXqGTDqMp/5NPT PqXeMZdl9yIf58b7/kMiVms3vHDIfIFKbhXycaEqHO+LWb/6fj02RhdLSxtdVqeIDK4U UjxmiEs9BCS7iaRiWuXGPet4/6/dDg6kpH08o5DMvs1sbK+pTd5pygKYLP8IoEw/f0ZH 0ACA== MIME-Version: 1.0 X-Received: by 10.60.171.102 with SMTP id at6mr12160188oec.60.1363090318641; Tue, 12 Mar 2013 05:11:58 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 05:11:58 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:b46a:6672:197f:e937] In-Reply-To: <20130311234447.cc40c4f3d92d2001859047cd8cabb9ab.64d2aabe52.wbe@email07.europe.secureserver.net> References: <20130311234447.cc40c4f3d92d2001859047cd8cabb9ab.64d2aabe52.wbe@email07.europe.secureserver.net> Date: Tue, 12 Mar 2013 08:11:58 -0400 Message-ID: From: Richard Barnes To: "Vladimir Dzhuvinov / NimbusDS" Content-Type: multipart/alternative; boundary=bcaec54ee0943d630404d7b932a5 X-Gm-Message-State: ALoCoQl+ZYwuO8Tz4b+/ZKMlUdPBLJYbJtOPWo+RfdXoLCxQSJwSDLbUhJYsnUGRe/3I1S8YzRsp Cc: jose@ietf.org Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 12:12:01 -0000 --bcaec54ee0943d630404d7b932a5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I really hope you're not using char[4] for field names :) On Tue, Mar 12, 2013 at 2:44 AM, Vladimir Dzhuvinov / NimbusDS < vladimir@nimbusds.com> wrote: > How about "crt" instead of "crit", to fit the three-letter convention > for naming fields? > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > -------- Original Message -------- > Subject: [jose] Proposed resolution of header criticality issue > From: Karen O'Donoghue > Date: Tue, March 12, 2013 12:31 am > To: jose@ietf.org > > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the > meeting. Point 5 of the proposed resolution below is actually > independent of the other 4 points, and could be considered separately. > This will all be discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must > process". However, that text has not been rolled into the summary text > below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the > JWK. If present, they MUST be understood by implementations using > them.=94 to =93Additional members MAY be present in the JWK. If not > understood by implementations encountering them, they MUST be > ignored.=94 (And make the same change for JWK Set as well.) > > 2: Characterize all existing JWS and JWE header fields as either must > be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 > must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, > =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because > while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as > =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be > understood and used when =93alg=94 or =93enc=94 values requiring them > are used, and otherwise they may be ignored. > > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon > when present. For instance, an expiration-time extension field could be > marked as must-be-understood-and-acted-upon. One possible name for this > would be =93crit=94 (critical). An example use, along with a > hypothetical =93exp=94 (expiration-time) field is: > > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } > > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not > understood. > > 5. Define a new header field =93asd=94 (application-specific data) > whose value is a JSON structure whose contents are opaque to and ignored > by JWS and JWE implementations but for which its contents MUST be > provided to applications using JWS or JWE, provided that the > signature/MAC validation or decryption operation succeeds. The intended > use of this field is to have a standard place to provide > application-specific metadata about the payload or plaintext. > > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --bcaec54ee0943d630404d7b932a5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I really hope you're not using char[4] for field names :)


<= div class=3D"gmail_quote">On Tue, Mar 12, 2013 at 2:44 AM, Vladimir Dzhuvin= ov / NimbusDS <vladimir@nimbusds.com> wrote:
How about "crt" instead of "c= rit", to fit the three-letter convention
for naming fields?

Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com : vladimir@ni= mbusds.com


-------- Original Message --------
Subject: [jose] Proposed resolution of header criticality issue
From: Karen O'Donoghue <odonog= hue@isoc.org>
Date: Tue, March 12, 2013 12:31 am
To: jose@ietf.org


=A0Folks,

=A0A side meeting was held Sunday with a number of jose working group
participants to try to resolve the open issue related to header
criticality. The following are the proposed resolutions from the
meeting. Point 5 of the proposed resolution below is actually
independent of the other 4 points, and could be considered separately.
This will all be discussed in Wednesday's meeting.

=A0In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "m= ust
process". However, that text has not been rolled into the summary text=
below yet.

=A0Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin<= br> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts
(and my apologies if I missed someone).

=A0Regards,
=A0Karen

=A01: =A0Change the language =93Additional members MAY be present in the JWK. =A0If present, they MUST be understood by implementations using
them.=94 to =93Additional members MAY be present in the JWK. =A0If not
understood by implementations encountering them, they MUST be
ignored.=94 =A0(And make the same change for JWK Set as well.)

=A02: =A0Characterize all existing JWS= and JWE header fields as either must
be understood or may be ignored. =A0=93alg=94, =93enc=94, and =93zip=94
must be understood. =A0=93kid=94, =93x5u=94, =93x5c=94, =93x5t=94,
=93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because
while not using them may result in the inability to process some
signatures or encrypted content, this will not result in a security
violation =96 just degraded functionality. =A0Other fields such as
=93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be
understood and used when =93alg=94 or =93enc=94 values requiring them
are used, and otherwise they may be ignored.

=A03. =A0Define a new header field that list= s which additional fields not
defined in the base specifications must be understood and acted upon
when present. =A0For instance, an expiration-time extension field could be<= br> marked as must-be-understood-and-acted-upon. =A0One possible name for this<= br> would be =93crit=94 (critical). =A0An example use, along with a
hypothetical =93exp=94 (expiration-time) field is:

=A0 =A0{"alg":"ES256",
=A0 =A0 "crit":["exp"],
=A0 =A0 "exp=94:1363284000
=A0 =A0}

=A04. =A0All additional header fields not defined in the base specification= s
and not contained in the =93crit=94 list MUST be ignored if not
understood.

=A05. =A0Define a new header field =93asd=94 (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be
provided to applications using JWS or JWE, provided that the
signature/MAC validation or decryption operation succeeds. =A0The intended<= br> use of this field is to have a standard place to provide
application-specific metadata about the payload or plaintext.






=A0__________________________= _____________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--bcaec54ee0943d630404d7b932a5-- From rlb@ipv.sx Tue Mar 12 05:15:09 2013 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 A6DBF21F8A08 for ; Tue, 12 Mar 2013 05:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 tmBcBUFWVJcs for ; Tue, 12 Mar 2013 05:15:08 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 98B2A21F89CB for ; Tue, 12 Mar 2013 05:15:08 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so4388656obq.21 for ; Tue, 12 Mar 2013 05:15:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jkyJ3tc6Y9wbm7pKllL5dZ6g4VH5do9Eo/ElhdyLpuk=; b=Ux5x+mLqXUnzlu8P4tTszStlzyauwyTcud7DiZdixMvFLA/ONTGZkV/N5nlnMULjqo c0LaRQ7H9sASUzcQLr37TgVofq5Qbr8A+z6VTsSMXipGk8z8JZSYBtiUcc2f8rEX48jZ DlUEZcDq8ya+Wj2f2VAtvlxU5Kw9OKxRHnb4Q8T9YKztKHxAaUxe5adYJPE6eOZtuhwv A6soUM2pdV81d2ws0CHHKRvu9ycIC/mkUt+TMT2q6PH4vxgolxuje6VC0nJYoprTeaIj RvcXxZTLUZ3DiEK1jISrQch43gHSQbCvUl3kFQDUEmdqfX9inXORVE9mQUSkd9xNYYw8 XSYA== MIME-Version: 1.0 X-Received: by 10.182.132.43 with SMTP id or11mr11702249obb.67.1363090508125; Tue, 12 Mar 2013 05:15:08 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 05:15:08 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:b46a:6672:197f:e937] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B786D22@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B786D22@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 12 Mar 2013 08:15:08 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=14dae93a0c1788af3d04d7b93d70 X-Gm-Message-State: ALoCoQmubMrxindyZxLAWOh69k2juuEkF73he/Ysec4tXx111XFC907VNHGB+qq2fpTlTndpv3Sp Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 12 Mar 2013 12:15:09 -0000 --14dae93a0c1788af3d04d7b93d70 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess I regard the ability to operate with bare public keys as a feature, not a bug. There are many, many ways to authenticate keys, ranging from X.509 with detailed certificate profiles to pre-shared key fingerprints. Having bare public keys lets us address all of these use cases. --Richard On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > Richard,**** > > ** ** > > Verifying a JWS signature with a raw public key in the JWS provides almos= t > no useful security property. To be useful you need to confirm the > authenticity of the public key from some other source. Generally the =93o= ther > source=94 that provides the authenticity can provide the actual public ke= y as > well.**** > > ** ** > > The =93danger=94 of including a raw public key is that silly code verifie= s the > maths then automatically =93trusts=94 the message. It is only a small dan= ger. I > am willing to ignore the danger, but only if there is real value in > including the raw public key. Perhaps DANE (key in DNS protected by DNSSE= C) > is an example of a mechanism that can confirm the authenticity of a hash = of > a key without providing the actual key. Though wouldn=92t it be better to= get > the full key from DANE once, and only send a key id in every JOSE message= ? > **** > > ** ** > > The closest analogy with certs is whether or not to include the > self-signed root cert at the end of a cert chain in the message. It > shouldn=92t be sent. It often is. That hasn=92t caused the sky to fall in= , > though it wastes a small (non-trivial??) portion of TLS traffic.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Saturday, 9 March 2013 1:37 AM > *To:* Manger, James H > *Cc:* Peck, Michael A; jose@ietf.org > > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > ** ** > > On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > I agree, Michael. A raw public key in a JWS is inviting dangerous code.**= * > * > > ** ** > > Could you be a little more precise here? What's the danger?**** > > ** ** > > The only difference between a key and a cert is that the cert provides th= e > recipient with some attributes that go along with the key (signed under > some authority) -- assuming the recipient supports X.509 and has an > appropriate trust anchor. So the only danger is that the recipient might > not check the attributes before accepting the signature.**** > > ** ** > > This is a completely separate question from whether the signature is > valid, in a cryptological / mathematical sense. And the answer you're > implying (that not checking attributes is dangerous) is clearly not true = in > all cases. For example, in PGP, you've validated the public key through > some out-of-band channel, and you really do just need the key here.**** > > ** ** > > JOSE should stick to crypto, and stay away from policy. To do otherwise > would cut off use cases unnecessariliy.**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Peck, Michael A > > *Sent:* Thursday, 7 March 2013 6:21 AM > *To:* Richard Barnes > **** > > > *Cc:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > **** > > In the case of JWS, it looks like with the =93jwk=94 header parameter, th= e > signed message itself can contain the raw public key to be used to verify > it.**** > > My concern is that the verifier will grab and use the public key without > ensuring its authenticity.**** > > This would be analogous to automatically trusting a self-signed X.509 > certificate.**** > > There should at least be some Security Considerations language that when > =93jwk=94 is used the verifier needs to use out of bands means to assure = that > the provided public key is trusted.**** > > **** > > CMS SignedData does not contain the raw public key used to sign the > message itself.**** > > It contains a SignerIdentifier to reference the public key and optionally > contains certificates (which would convey the public key, but along with > proof that it should be trusted).**** > > **** > > Rather than directly including the =93raw=94 public key, JWS provides lot= s of > other safer header parameters to reference the public key.**** > > **** > > On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A wrote:= * > *** > > What is the use case for the "jwk" (JSON Web Key) Header Parameter > described in section 4.1.3 of draft-ietf-jose-json-web-signature-08? > > It seems unsafe for a signature to provide, unauthenticated (not in a > signed certificate or protected by other means), the public key to be use= d > to verify itself. > I would think this field makes it too easy for implementations to do the > wrong thing. > > Thanks, > Mike > > **** > > ** ** > --14dae93a0c1788af3d04d7b93d70 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I guess I regard the ability to operate with bare public keys as a feature,= not a bug. =A0There are many, many ways to authenticate keys, ranging from= X.509 with detailed certificate profiles to pre-shared key fingerprints. = =A0Having bare public keys lets us address all of these use cases.

--Richard



On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H <= James.H.Manger@team.telstra.com> wrote:

Richard,

=A0<= /p>

Verifying a JWS signat= ure with a raw public key in the JWS provides almost no useful security pro= perty. To be useful you need to confirm the authenticity of the public key = from some other source. Generally the =93other source=94 that provides the = authenticity can provide the actual public key as well.

=A0<= /p>

The =93danger=94 of in= cluding a raw public key is that silly code verifies the maths then automat= ically =93trusts=94 the message. It is only a small danger. I am willing to= ignore the danger, but only if there is real value in including the raw pu= blic key. Perhaps DANE (key in DNS protected by DNSSEC) is an example of a = mechanism that can confirm the authenticity of a hash of a key without prov= iding the actual key. Though wouldn=92t it be better to get the full key fr= om DANE once, and only send a key id in every JOSE message?

=A0<= /p>

The closest analogy wi= th certs is whether or not to include the self-signed root cert at the end = of a cert chain in the message. It shouldn=92t be sent. It often is. That h= asn=92t caused the sky to fall in, though it wastes a small (non-trivial??)= portion of TLS traffic.

=A0<= /p>

--

James Manger

=A0=

From: Richard Barnes [mailto:rlb@ipv.sx]
Sent: Saturday, 9 March 2013 1:37 AM
To: Manger, James HCc: Peck, Michael A; jose@ietf.org


Subject: Re:= [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parame= ter

=A0

On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H <James.H.Manger@te= am.telstra.com> wrote:

=

I agree, Michael. A = raw public key in a JWS is inviting dangerous code.

=A0

<= div>

Could you be a little more precise here? =A0What= 's the danger?

=A0

The only difference between a key and a c= ert is that the cert provides the recipient with some attributes that go al= ong with the key (signed under some authority) -- assuming the recipient su= pports X.509 and has an appropriate trust anchor. =A0So the only danger is = that the recipient might not check the attributes before accepting the sign= ature.

=A0

This is a completely separate question from whether the sign= ature is valid, in a cryptological / mathematical sense. =A0And the answer = you're implying (that not checking attributes is dangerous) is clearly = not true in all cases. =A0For example, in PGP, you've validated the pub= lic key through some out-of-band channel, and you really do just need the k= ey here.

=A0

JOSE should stick to crypto, and stay away from policy. =A0T= o do otherwise would cut off use cases unnecessariliy.

=A0

From: jose-bounces@ietf.org = [mailto:jose-bou= nces@ietf.org] On Behalf Of Peck, Michael A


Sent: Thursday, 7 March 2013 6:21 AM
To:= Richard Barnes

<= p class=3D"MsoNormal">
Cc: jose@ietf.org
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

=

=A0

In the case of JWS, it looks like= with the =93jwk=94 header parameter, the signed message itself can contain= the raw public key to be used to verify it.

My concern= is that the verifier will grab and use the public key without ensuring its= authenticity.

This would= be analogous to automatically trusting a self-signed X.509 certificate.

There shou= ld at least be some Security Considerations language that when =93jwk=94 is= used the verifier needs to use out of bands means to assure that the provi= ded public key is trusted.

=A0=

CMS SignedData does not contain the raw public key used to sign the= message itself.

It contain= s a SignerIdentifier to reference the public key and optionally contains ce= rtificates (which would convey the public key, but along with proof that it= should be trusted).

=A0=

Rather than directly including the =93raw=94 public key, JWS provid= es lots of other safer header parameters to reference the public key.

=A0

On Wed, Mar 6, 2013 a= t 12:28 PM, Peck, Michael A <mpeck@mitre.org> wrote:

Wh= at is the use case for the "jwk" (JSON Web Key) Header Parameter = described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?
It seems unsafe for a signature to provide, unauthenticated (not in a sign= ed certificate or protected by other means), the public key to be used to v= erify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike

=A0


--14dae93a0c1788af3d04d7b93d70-- From James.H.Manger@team.telstra.com Tue Mar 12 05:18:11 2013 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 7937621F8A11 for ; Tue, 12 Mar 2013 05:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[AWL=1.162, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 iwYUYuj1b7yB for ; Tue, 12 Mar 2013 05:18:10 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id CC1CD21F8A08 for ; Tue, 12 Mar 2013 05:18:09 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,830,1355058000"; d="scan'208";a="122653771" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipoavi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 23:18:09 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="117871768" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcbvi.tcif.telstra.com.au with ESMTP; 12 Mar 2013 23:18:09 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Tue, 12 Mar 2013 23:18:07 +1100 From: "Manger, James H" To: "vladimir@nimbusds.com" , "jose@ietf.org" Date: Tue, 12 Mar 2013 23:18:07 +1100 Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4e7R9H1kqa+ob2SUSyRmT72Gsc4AALohOP Message-ID: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 12:18:11 -0000 TmFoLCAiY3J0IiBzb3VuZHMgdG9vIG11Y2ggbGlrZSBhIGNlcnRpZmljYXRlLiAqLmNydCBpcyBh IGNvbW1vbiBmaWxlIGV4dGVuc2lvbiBmb3IgY2VydHMuDQoNCkhvdyBhYm91dCAiISIgPw0KDQot LQ0KSmFtZXMgTWFuZ2VyDQoNCi0tLS0tIFJlcGx5IG1lc3NhZ2UgLS0tLS0NCkZyb206ICJWbGFk aW1pciBEemh1dmlub3YgLyBOaW1idXNEUyIgPHZsYWRpbWlyQG5pbWJ1c2RzLmNvbT4NCkRhdGU6 IFR1ZSwgTWFyIDEyLCAyMDEzIDU6NDUgcG0NClN1YmplY3Q6IFtqb3NlXSBQcm9wb3NlZCByZXNv bHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KVG86ICJqb3NlQGlldGYub3JnIiA8 am9zZUBpZXRmLm9yZz4NCg0KSG93IGFib3V0ICJjcnQiIGluc3RlYWQgb2YgImNyaXQiLCB0byBm aXQgdGhlIHRocmVlLWxldHRlciBjb252ZW50aW9uDQpmb3IgbmFtaW5nIGZpZWxkcz8NCg0KVmxh ZGltaXINCg0KLS0NClZsYWRpbWlyIER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb208aHR0cDov L3d3dy5OaW1idXNEUy5jb20+IDogdmxhZGltaXJAbmltYnVzZHMuY29tDQoNCg0KLS0tLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0KU3ViamVjdDogW2pvc2VdIFByb3Bvc2VkIHJlc29s dXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlDQpGcm9tOiBLYXJlbiBPJ0Rvbm9naHVl IDxvZG9ub2dodWVAaXNvYy5vcmc+DQpEYXRlOiBUdWUsIE1hcmNoIDEyLCAyMDEzIDEyOjMxIGFt DQpUbzogam9zZUBpZXRmLm9yZw0KDQoNCiBGb2xrcywNCg0KIEEgc2lkZSBtZWV0aW5nIHdhcyBo ZWxkIFN1bmRheSB3aXRoIGEgbnVtYmVyIG9mIGpvc2Ugd29ya2luZyBncm91cA0KcGFydGljaXBh bnRzIHRvIHRyeSB0byByZXNvbHZlIHRoZSBvcGVuIGlzc3VlIHJlbGF0ZWQgdG8gaGVhZGVyDQpj cml0aWNhbGl0eS4gVGhlIGZvbGxvd2luZyBhcmUgdGhlIHByb3Bvc2VkIHJlc29sdXRpb25zIGZy b20gdGhlDQptZWV0aW5nLiBQb2ludCA1IG9mIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uIGJlbG93 IGlzIGFjdHVhbGx5DQppbmRlcGVuZGVudCBvZiB0aGUgb3RoZXIgNCBwb2ludHMsIGFuZCBjb3Vs ZCBiZSBjb25zaWRlcmVkIHNlcGFyYXRlbHkuDQpUaGlzIHdpbGwgYWxsIGJlIGRpc2N1c3NlZCBp biBXZWRuZXNkYXkncyBtZWV0aW5nLg0KDQogSW4gYWRkaXRpb24gdG8gdGhlIHRleHQgYmVsb3cs IHRoZXJlIHdhcyBzb21lIGFncmVlbWVudCB0byByZXBsYWNlIHRoZQ0KInVuZGVyc3RhbmQiIHRl eHQgd2l0aCBzb21ldGhpbmcgYSBiaXQgbW9yZSBleHBsaWNpdCBsaWtlICJtdXN0DQpwcm9jZXNz Ii4gSG93ZXZlciwgdGhhdCB0ZXh0IGhhcyBub3QgYmVlbiByb2xsZWQgaW50byB0aGUgc3VtbWFy eSB0ZXh0DQpiZWxvdyB5ZXQuDQoNCiBUaGFuayB5b3UgdG8gSmltIFNjaGFhZCwgTWlrZSBKb25l cywgSm9obiBCcmFkbGV5LCBOYXQgU2FraW11cmEsIE1hcnRpbg0KVGhvbWFzLCBFcmljIFJlc2Nv cmxhLCBNYXR0IE1pbGxlciwgYW5kIFJpY2hhcmQgQmFybmVzIGZvciB5b3VyIGVmZm9ydHMNCihh bmQgbXkgYXBvbG9naWVzIGlmIEkgbWlzc2VkIHNvbWVvbmUpLg0KDQogUmVnYXJkcywNCiBLYXJl bg0KDQogMTogIENoYW5nZSB0aGUgbGFuZ3VhZ2Ug4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBi ZSBwcmVzZW50IGluIHRoZQ0KSldLLiAgSWYgcHJlc2VudCwgdGhleSBNVVNUIGJlIHVuZGVyc3Rv b2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nDQp0aGVtLuKAnSB0byDigJxBZGRpdGlvbmFsIG1l bWJlcnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gIElmIG5vdA0KdW5kZXJzdG9vZCBieSBp bXBsZW1lbnRhdGlvbnMgZW5jb3VudGVyaW5nIHRoZW0sIHRoZXkgTVVTVCBiZQ0KaWdub3JlZC7i gJ0gIChBbmQgbWFrZSB0aGUgc2FtZSBjaGFuZ2UgZm9yIEpXSyBTZXQgYXMgd2VsbC4pDQoNCiAy OiAgQ2hhcmFjdGVyaXplIGFsbCBleGlzdGluZyBKV1MgYW5kIEpXRSBoZWFkZXIgZmllbGRzIGFz IGVpdGhlciBtdXN0DQpiZSB1bmRlcnN0b29kIG9yIG1heSBiZSBpZ25vcmVkLiAg4oCcYWxn4oCd LCDigJxlbmPigJ0sIGFuZCDigJx6aXDigJ0NCm11c3QgYmUgdW5kZXJzdG9vZC4gIOKAnGtpZOKA nSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKAnHg1dOKAnSwNCuKAnGp3a+KAnSwg4oCcamt14oCd LCDigJx0eXDigJ0sIGFuZCDigJxjdHnigJ0gY2FuIGJlIGlnbm9yZWQgYmVjYXVzZQ0Kd2hpbGUg bm90IHVzaW5nIHRoZW0gbWF5IHJlc3VsdCBpbiB0aGUgaW5hYmlsaXR5IHRvIHByb2Nlc3Mgc29t ZQ0Kc2lnbmF0dXJlcyBvciBlbmNyeXB0ZWQgY29udGVudCwgdGhpcyB3aWxsIG5vdCByZXN1bHQg aW4gYSBzZWN1cml0eQ0KdmlvbGF0aW9uIOKAkyBqdXN0IGRlZ3JhZGVkIGZ1bmN0aW9uYWxpdHku ICBPdGhlciBmaWVsZHMgc3VjaCBhcw0K4oCcZXBr4oCdLCDigJxhcHXigJ0sIOKAnGFwduKAnSwg 4oCcZXB14oCdLCBhbmQg4oCcZXB24oCdIG11c3QgYmUNCnVuZGVyc3Rvb2QgYW5kIHVzZWQgd2hl biDigJxhbGfigJ0gb3Ig4oCcZW5j4oCdIHZhbHVlcyByZXF1aXJpbmcgdGhlbQ0KYXJlIHVzZWQs IGFuZCBvdGhlcndpc2UgdGhleSBtYXkgYmUgaWdub3JlZC4NCg0KIDMuICBEZWZpbmUgYSBuZXcg aGVhZGVyIGZpZWxkIHRoYXQgbGlzdHMgd2hpY2ggYWRkaXRpb25hbCBmaWVsZHMgbm90DQpkZWZp bmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zIG11c3QgYmUgdW5kZXJzdG9vZCBhbmQgYWN0 ZWQgdXBvbg0Kd2hlbiBwcmVzZW50LiAgRm9yIGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRpbWUg ZXh0ZW5zaW9uIGZpZWxkIGNvdWxkIGJlDQptYXJrZWQgYXMgbXVzdC1iZS11bmRlcnN0b29kLWFu ZC1hY3RlZC11cG9uLiAgT25lIHBvc3NpYmxlIG5hbWUgZm9yIHRoaXMNCndvdWxkIGJlIOKAnGNy aXTigJ0gKGNyaXRpY2FsKS4gIEFuIGV4YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGENCmh5cG90aGV0 aWNhbCDigJxleHDigJ0gKGV4cGlyYXRpb24tdGltZSkgZmllbGQgaXM6DQoNCiAgIHsiYWxnIjoi RVMyNTYiLA0KICAgICJjcml0IjpbImV4cCJdLA0KICAgICJleHDigJ06MTM2MzI4NDAwMA0KICAg fQ0KDQogNC4gIEFsbCBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgbm90IGRlZmluZWQgaW4gdGhl IGJhc2Ugc3BlY2lmaWNhdGlvbnMNCmFuZCBub3QgY29udGFpbmVkIGluIHRoZSDigJxjcml04oCd IGxpc3QgTVVTVCBiZSBpZ25vcmVkIGlmIG5vdA0KdW5kZXJzdG9vZC4NCg0KIDUuICBEZWZpbmUg YSBuZXcgaGVhZGVyIGZpZWxkIOKAnGFzZOKAnSAoYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YSkN Cndob3NlIHZhbHVlIGlzIGEgSlNPTiBzdHJ1Y3R1cmUgd2hvc2UgY29udGVudHMgYXJlIG9wYXF1 ZSB0byBhbmQgaWdub3JlZA0KYnkgSldTIGFuZCBKV0UgaW1wbGVtZW50YXRpb25zIGJ1dCBmb3Ig d2hpY2ggaXRzIGNvbnRlbnRzIE1VU1QgYmUNCnByb3ZpZGVkIHRvIGFwcGxpY2F0aW9ucyB1c2lu ZyBKV1Mgb3IgSldFLCBwcm92aWRlZCB0aGF0IHRoZQ0Kc2lnbmF0dXJlL01BQyB2YWxpZGF0aW9u IG9yIGRlY3J5cHRpb24gb3BlcmF0aW9uIHN1Y2NlZWRzLiAgVGhlIGludGVuZGVkDQp1c2Ugb2Yg dGhpcyBmaWVsZCBpcyB0byBoYXZlIGEgc3RhbmRhcmQgcGxhY2UgdG8gcHJvdmlkZQ0KYXBwbGlj YXRpb24tc3BlY2lmaWMgbWV0YWRhdGEgYWJvdXQgdGhlIHBheWxvYWQgb3IgcGxhaW50ZXh0Lg0K DQoNCg0KDQoNCg0KIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmcNCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0K From vladimir@nimbusds.com Tue Mar 12 05:58:38 2013 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 13CAC21F8AAD for ; Tue, 12 Mar 2013 05:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2] 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 7xobyvih0Uqg for ; Tue, 12 Mar 2013 05:58:36 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 2DC8E21F8A38 for ; Tue, 12 Mar 2013 05:58:35 -0700 (PDT) Received: (qmail 15908 invoked from network); 12 Mar 2013 12:58:34 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 12 Mar 2013 12:58:32 -0000 Received: (qmail 424 invoked by uid 99); 12 Mar 2013 12:58:32 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.241.63 User-Agent: Workspace Webmail 5.6.33 Message-Id: <20130312055831.cc40c4f3d92d2001859047cd8cabb9ab.21dc242763.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "jose@ietf.org" Date: Tue, 12 Mar 2013 05:58:31 -0700 Mime-Version: 1.0 Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 12:58:38 -0000 You're right James, "crt" can be confused. I find "!" a good candidate.=0AO= ther three-letter abbreviations that come to mind are "ctc" and "ctl".=0A= =0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimb= usds.com=0A=0A=0A=0A=0A-------- Original Message --------=0ASubject: Re: [j= ose] Proposed resolution of header criticality issue=0AFrom: "Manger, James= H" =0ADate: Tue, March 12, 2013 12:18 pm= =0ATo: "vladimir@nimbusds.com" , "jose@ietf.org"=0A<= jose@ietf.org>=0A=0ANah, "crt" sounds too much like a certificate. *.crt is= a common file=0Aextension for certs.=0A=0AHow about "!" ?=0A=0A--=0AJames = Manger=0A=0A----- Reply message -----=0AFrom: "Vladimir Dzhuvinov / NimbusD= S" =0ADate: Tue, Mar 12, 2013 5:45 pm=0ASubject: [jo= se] Proposed resolution of header criticality issue=0ATo: "jose@ietf.org" <= jose@ietf.org>=0A=0AHow about "crt" instead of "crit", to fit the three-let= ter convention=0Afor naming fields?=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvi= nov : www.NimbusDS.com :=0Avladimir@nimbusds.com= =0A=0A=0A-------- Original Message --------=0ASubject: [jose] Proposed reso= lution of header criticality issue=0AFrom: Karen O'Donoghue =0ADate: Tue, March 12, 2013 12:31 am=0ATo: jose@ietf.org=0A=0A=0A Fol= ks,=0A=0A A side meeting was held Sunday with a number of jose working grou= p=0Aparticipants to try to resolve the open issue related to header=0Acriti= cality. The following are the proposed resolutions from the=0Ameeting. Poin= t 5 of the proposed resolution below is actually=0Aindependent of the other= 4 points, and could be considered separately.=0AThis will all be discussed= in Wednesday's meeting.=0A=0A In addition to the text below, there was som= e agreement to replace the=0A"understand" text with something a bit more ex= plicit like "must=0Aprocess". However, that text has not been rolled into t= he summary text=0Abelow yet.=0A=0A Thank you to Jim Schaad, Mike Jones, Joh= n Bradley, Nat Sakimura, Martin=0AThomas, Eric Rescorla, Matt Miller, and R= ichard Barnes for your efforts=0A(and my apologies if I missed someone).=0A= =0A Regards,=0A Karen=0A=0A 1: Change the language =E2=80=9CAdditional memb= ers MAY be present in the=0AJWK. If present, they MUST be understood by imp= lementations using=0Athem.=E2=80=9D to =E2=80=9CAdditional members MAY be p= resent in the JWK. If not=0Aunderstood by implementations encountering them= , they MUST be=0Aignored.=E2=80=9D (And make the same change for JWK Set as= well.)=0A=0A 2: Characterize all existing JWS and JWE header fields as eit= her must=0Abe understood or may be ignored. =E2=80=9Calg=E2=80=9D, =E2=80= =9Cenc=E2=80=9D, and =E2=80=9Czip=E2=80=9D=0Amust be understood. =E2=80=9Ck= id=E2=80=9D, =E2=80=9Cx5u=E2=80=9D, =E2=80=9Cx5c=E2=80=9D, =E2=80=9Cx5t=E2= =80=9D,=0A=E2=80=9Cjwk=E2=80=9D, =E2=80=9Cjku=E2=80=9D, =E2=80=9Ctyp=E2=80= =9D, and =E2=80=9Ccty=E2=80=9D can be ignored because=0Awhile not using the= m may result in the inability to process some=0Asignatures or encrypted con= tent, this will not result in a security=0Aviolation =E2=80=93 just degrade= d functionality. Other fields such as=0A=E2=80=9Cepk=E2=80=9D, =E2=80=9Capu= =E2=80=9D, =E2=80=9Capv=E2=80=9D, =E2=80=9Cepu=E2=80=9D, and =E2=80=9Cepv= =E2=80=9D must be=0Aunderstood and used when =E2=80=9Calg=E2=80=9D or =E2= =80=9Cenc=E2=80=9D values requiring them=0Aare used, and otherwise they may= be ignored.=0A=0A 3. Define a new header field that lists which additional= fields not=0Adefined in the base specifications must be understood and act= ed upon=0Awhen present. For instance, an expiration-time extension field co= uld be=0Amarked as must-be-understood-and-acted-upon. One possible name for= this=0Awould be =E2=80=9Ccrit=E2=80=9D (critical). An example use, along w= ith a=0Ahypothetical =E2=80=9Cexp=E2=80=9D (expiration-time) field is:=0A= =0A {"alg":"ES256",=0A "crit":["exp"],=0A "exp=E2=80=9D:1363284000=0A }=0A= =0A 4. All additional header fields not defined in the base specifications= =0Aand not contained in the =E2=80=9Ccrit=E2=80=9D list MUST be ignored if = not=0Aunderstood.=0A=0A 5. Define a new header field =E2=80=9Casd=E2=80=9D = (application-specific data)=0Awhose value is a JSON structure whose content= s are opaque to and ignored=0Aby JWS and JWE implementations but for which = its contents MUST be=0Aprovided to applications using JWS or JWE, provided = that the=0Asignature/MAC validation or decryption operation succeeds. The i= ntended=0Ause of this field is to have a standard place to provide=0Aapplic= ation-specific metadata about the payload or plaintext.=0A=0A=0A=0A=0A=0A= =0A _______________________________________________=0Ajose mailing list=0Aj= ose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose=0A_______________= ________________________________=0Ajose mailing list=0Ajose@ietf.org=0Ahttp= s://www.ietf.org/mailman/listinfo/jose From rlb@ipv.sx Tue Mar 12 05:59:40 2013 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 E9FF121F84CD for ; Tue, 12 Mar 2013 05:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[AWL=2.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 lkr4WtcDtRfa for ; Tue, 12 Mar 2013 05:59:39 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id D861921F84CA for ; Tue, 12 Mar 2013 05:59:38 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so5718785oag.10 for ; Tue, 12 Mar 2013 05:59:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=MyO4NPSUzWvSslbpKfQuxEsGP4rSQmIG6xVS8y3J3bo=; b=JcrJ3zyGjB0oI+WvRqOBIWV/ojxU0+OV7UeYt6VseaIIm9V8tItCKF4v31xU3SDYrW mJLsSh3OZH4jI4NySGs2mbt2oUisx0xradiqfqGJD+NN+Dnm5NB0w5bTdU6j2vccflIZ 3GTR3Xg7WwubMoCPJOdTX1bQkydfG5dW11q0yvWBF2dBeK26JQewTtbLFckRMlJtRTIy nheR/Z6nhqqyl9fH+TySW9tTUlu0lK3Op5HQq1274gFB5F9ZKCG5VeGU1QlCm7ajML9w 1EEsfvBdlcwiHW8zcU75LhcvzvsuFtThYVqgyKjgTkkHDJ0M3CV+w0v0k0Xd8sQtFOho YfgQ== MIME-Version: 1.0 X-Received: by 10.182.245.33 with SMTP id xl1mr11746171obc.91.1363093178371; Tue, 12 Mar 2013 05:59:38 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 05:59:38 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: <20130312055831.cc40c4f3d92d2001859047cd8cabb9ab.21dc242763.wbe@email07.europe.secureserver.net> References: <20130312055831.cc40c4f3d92d2001859047cd8cabb9ab.21dc242763.wbe@email07.europe.secureserver.net> Date: Tue, 12 Mar 2013 08:59:38 -0400 Message-ID: From: Richard Barnes To: "Vladimir Dzhuvinov / NimbusDS" Content-Type: multipart/alternative; boundary=14dae93a19a3b1628504d7b9dca9 X-Gm-Message-State: ALoCoQluvj2ihR8nufx1MZIsclDF5shMOzaWQ/O33oaBSi5kswovq10SDY9qbxxoCLnLPGhgsDQ2 Cc: "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 12:59:40 -0000 --14dae93a19a3b1628504d7b9dca9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think we can spare the extra character for "crit". That is the least costly part of this proposal. On Tue, Mar 12, 2013 at 8:58 AM, Vladimir Dzhuvinov / NimbusDS < vladimir@nimbusds.com> wrote: > You're right James, "crt" can be confused. I find "!" a good candidate. > Other three-letter abbreviations that come to mind are "ctc" and "ctl". > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > > > -------- Original Message -------- > Subject: Re: [jose] Proposed resolution of header criticality issue > From: "Manger, James H" > Date: Tue, March 12, 2013 12:18 pm > To: "vladimir@nimbusds.com" , "jose@ietf.org" > > > Nah, "crt" sounds too much like a certificate. *.crt is a common file > extension for certs. > > How about "!" ? > > -- > James Manger > > ----- Reply message ----- > From: "Vladimir Dzhuvinov / NimbusDS" > Date: Tue, Mar 12, 2013 5:45 pm > Subject: [jose] Proposed resolution of header criticality issue > To: "jose@ietf.org" > > How about "crt" instead of "crit", to fit the three-letter convention > for naming fields? > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : > vladimir@nimbusds.com > > > -------- Original Message -------- > Subject: [jose] Proposed resolution of header criticality issue > From: Karen O'Donoghue > Date: Tue, March 12, 2013 12:31 am > To: jose@ietf.org > > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the > meeting. Point 5 of the proposed resolution below is actually > independent of the other 4 points, and could be considered separately. > This will all be discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must > process". However, that text has not been rolled into the summary text > below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the > JWK. If present, they MUST be understood by implementations using > them.=94 to =93Additional members MAY be present in the JWK. If not > understood by implementations encountering them, they MUST be > ignored.=94 (And make the same change for JWK Set as well.) > > 2: Characterize all existing JWS and JWE header fields as either must > be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 > must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, > =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because > while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as > =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be > understood and used when =93alg=94 or =93enc=94 values requiring them > are used, and otherwise they may be ignored. > > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon > when present. For instance, an expiration-time extension field could be > marked as must-be-understood-and-acted-upon. One possible name for this > would be =93crit=94 (critical). An example use, along with a > hypothetical =93exp=94 (expiration-time) field is: > > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } > > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not > understood. > > 5. Define a new header field =93asd=94 (application-specific data) > whose value is a JSON structure whose contents are opaque to and ignored > by JWS and JWE implementations but for which its contents MUST be > provided to applications using JWS or JWE, provided that the > signature/MAC validation or decryption operation succeeds. The intended > use of this field is to have a standard place to provide > application-specific metadata about the payload or plaintext. > > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --14dae93a19a3b1628504d7b9dca9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think we can spare the extra character for "crit". =A0That is t= he least costly part of this proposal.


On Tue, Mar 12, 2013 at 8:58 AM, Vladimir Dzhuvinov / NimbusDS <vla= dimir@nimbusds.com> wrote:
You're right James, "crt" can = be confused. I find "!" a good candidate.
Other three-letter abbreviations that come to mind are "ctc" and = "ctl".

Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com : vladimir@ni= mbusds.com




-------- Original Message --------
Subject: Re: [jose] Proposed resolution of header criticality issue
From: "Manger, James H" <James.H.Manger@team.telstra.com>
Date: Tue, March 12, 2013 12:18 pm
To: "vladimir@nimbusds.com" <vladimir@nimbusds.com<= /a>>, "jose@ietf.org"
<jose@ietf.org>

Nah, "crt" sounds too much like a certificate. *.crt is a common = file
extension for certs.

How about "!" ?

--
James Manger

----- Reply message -----
From: "Vladimir Dzhuvinov / NimbusDS" <vladimir@nimbusds.com>
Date: Tue, Mar 12, 2013 5:45 pm
Subject: [jose] Proposed resolution of header criticality issue
To: "jose@ietf.org" <jose@ietf.org>

How about "crt" instead of "crit", to fit the three-let= ter convention
for naming fields?

Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com<http://www.NimbusDS.com> :
vladimir@nimbusds.com


-------- Original Message --------
Subject: [jose] Proposed resolution of header criticality issue
From: Karen O'Donoghue <odonog= hue@isoc.org>
Date: Tue, March 12, 2013 12:31 am
To: jose@ietf.org


=A0Folks,

=A0A side meeting was held Sunday with a number of jose working group
participants to try to resolve the open issue related to header
criticality. The following are the proposed resolutions from the
meeting. Point 5 of the proposed resolution below is actually
independent of the other 4 points, and could be considered separately.
This will all be discussed in Wednesday's meeting.

=A0In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "m= ust
process". However, that text has not been rolled into the summary text=
below yet.

=A0Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin<= br> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts
(and my apologies if I missed someone).

=A0Regards,
=A0Karen

=A01: Change the language =93Additional members MAY be present in the
JWK. If present, they MUST be understood by implementations using
them.=94 to =93Additional members MAY be present in the JWK. If not
understood by implementations encountering them, they MUST be
ignored.=94 (And make the same change for JWK Set as well.)

=A02: Characterize all existing JWS and JWE header fields as either must be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94
must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94,
=93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because
while not using them may result in the inability to process some
signatures or encrypted content, this will not result in a security
violation =96 just degraded functionality. Other fields such as
=93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be
understood and used when =93alg=94 or =93enc=94 values requiring them
are used, and otherwise they may be ignored.

=A03. Define a new header field that lists which additional fields not
defined in the base specifications must be understood and acted upon
when present. For instance, an expiration-time extension field could be
marked as must-be-understood-and-acted-upon. One possible name for this
would be =93crit=94 (critical). An example use, along with a
hypothetical =93exp=94 (expiration-time) field is:

=A0{"alg":"ES256",
=A0"crit":["exp"],
=A0"exp=94:1363284000
=A0}

=A04. All additional header fields not defined in the base specifications and not contained in the =93crit=94 list MUST be ignored if not
understood.

=A05. Define a new header field =93asd=94 (application-specific data)
whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be
provided to applications using JWS or JWE, provided that the
signature/MAC validation or decryption operation succeeds. The intended
use of this field is to have a standard place to provide
application-specific metadata about the payload or plaintext.






=A0_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--14dae93a19a3b1628504d7b9dca9-- From Michael.Jones@microsoft.com Tue Mar 12 06:04:05 2013 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 0D4DD21F8A55 for ; Tue, 12 Mar 2013 06:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.598 X-Spam-Level: X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001] 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 w8ufvWQUy+QJ for ; Tue, 12 Mar 2013 06:04:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0236.outbound.protection.outlook.com [207.46.163.236]) by ietfa.amsl.com (Postfix) with ESMTP id B887721F8A47 for ; Tue, 12 Mar 2013 06:04:03 -0700 (PDT) Received: from BL2FFO11FD017.protection.gbl (10.173.161.200) by BL2FFO11HUB021.protection.gbl (10.173.161.45) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 13:04:01 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 13:04:00 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 13:03:11 +0000 From: Mike Jones To: "vladimir@nimbusds.com" , "jose@ietf.org" , James H Manger Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4fIfMKmB8jo/KiwU+B27AulrV5NQ== Date: Tue, 12 Mar 2013 13:03:11 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F8E97@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674F8E97TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(189002)(199002)(56776001)(69226001)(47976001)(49866001)(65816001)(512874001)(47736001)(15202345001)(59766001)(55846006)(77982001)(16236675001)(51856001)(56816002)(74662001)(47446002)(33656001)(54356001)(50986001)(15974865001)(5343655001)(44976002)(53806001)(63696002)(79102001)(76482001)(54316002)(74502001)(20776003)(31966008)(16406001)(4396001)(5343635001)(80022001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB021; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:04:05 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674F8E97TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBraW5kIG9mIGxpa2UgdGhlIOKAnCHigJ0gc3VnZ2VzdGlvbi4gIEphbWVzIGlzIHJpZ2h0IC0g SSBkaWRu4oCZdCBjaG9vc2UgdGhlIG5hbWUg4oCcY3J04oCdIGJlY2FzZSBpdCBtZWFucyDigJxj ZXJ0aWZpY2F0ZeKAnSB0byB0b28gbWFueSBwZW9wbGUuDQoNCkNoZWVycywNCi0tIE1pa2UNCg0K RnJvbTogTWFuZ2VyLCBKYW1lcyBIDQpTZW50OiDigI5NYXJjaOKAjiDigI4xMuKAjiwg4oCOMjAx MyDigI414oCOOuKAjjE44oCOIOKAjkFNDQpUbzogdmxhZGltaXJAbmltYnVzZHMuY29tLCBqb3Nl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVh ZGVyIGNyaXRpY2FsaXR5IGlzc3VlDQoNCk5haCwgImNydCIgc291bmRzIHRvbyBtdWNoIGxpa2Ug YSBjZXJ0aWZpY2F0ZS4gKi5jcnQgaXMgYSBjb21tb24gZmlsZSBleHRlbnNpb24gZm9yIGNlcnRz Lg0KDQpIb3cgYWJvdXQgIiEiID8NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQotLS0tLSBSZXBseSBt ZXNzYWdlIC0tLS0tDQpGcm9tOiAiVmxhZGltaXIgRHpodXZpbm92IC8gTmltYnVzRFMiIDx2bGFk aW1pckBuaW1idXNkcy5jb20+DQpEYXRlOiBUdWUsIE1hciAxMiwgMjAxMyA1OjQ1IHBtDQpTdWJq ZWN0OiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNz dWUNClRvOiAiam9zZUBpZXRmLm9yZyIgPGpvc2VAaWV0Zi5vcmc+DQoNCkhvdyBhYm91dCAiY3J0 IiBpbnN0ZWFkIG9mICJjcml0IiwgdG8gZml0IHRoZSB0aHJlZS1sZXR0ZXIgY29udmVudGlvbg0K Zm9yIG5hbWluZyBmaWVsZHM/DQoNClZsYWRpbWlyDQoNCi0tDQpWbGFkaW1pciBEemh1dmlub3Yg OiB3d3cuTmltYnVzRFMuY29tPGh0dHA6Ly93d3cuTmltYnVzRFMuY29tPiA6IHZsYWRpbWlyQG5p bWJ1c2RzLmNvbQ0KDQoNCi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NClN1Ympl Y3Q6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1 ZQ0KRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPg0KRGF0ZTogVHVl LCBNYXJjaCAxMiwgMjAxMyAxMjozMSBhbQ0KVG86IGpvc2VAaWV0Zi5vcmcNCg0KDQogRm9sa3Ms DQoNCiBBIHNpZGUgbWVldGluZyB3YXMgaGVsZCBTdW5kYXkgd2l0aCBhIG51bWJlciBvZiBqb3Nl IHdvcmtpbmcgZ3JvdXANCnBhcnRpY2lwYW50cyB0byB0cnkgdG8gcmVzb2x2ZSB0aGUgb3BlbiBp c3N1ZSByZWxhdGVkIHRvIGhlYWRlcg0KY3JpdGljYWxpdHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRo ZSBwcm9wb3NlZCByZXNvbHV0aW9ucyBmcm9tIHRoZQ0KbWVldGluZy4gUG9pbnQgNSBvZiB0aGUg cHJvcG9zZWQgcmVzb2x1dGlvbiBiZWxvdyBpcyBhY3R1YWxseQ0KaW5kZXBlbmRlbnQgb2YgdGhl IG90aGVyIDQgcG9pbnRzLCBhbmQgY291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5Lg0KVGhp cyB3aWxsIGFsbCBiZSBkaXNjdXNzZWQgaW4gV2VkbmVzZGF5J3MgbWVldGluZy4NCg0KIEluIGFk ZGl0aW9uIHRvIHRoZSB0ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBhZ3JlZW1lbnQgdG8gcmVw bGFjZSB0aGUNCiJ1bmRlcnN0YW5kIiB0ZXh0IHdpdGggc29tZXRoaW5nIGEgYml0IG1vcmUgZXhw bGljaXQgbGlrZSAibXVzdA0KcHJvY2VzcyIuIEhvd2V2ZXIsIHRoYXQgdGV4dCBoYXMgbm90IGJl ZW4gcm9sbGVkIGludG8gdGhlIHN1bW1hcnkgdGV4dA0KYmVsb3cgeWV0Lg0KDQogVGhhbmsgeW91 IHRvIEppbSBTY2hhYWQsIE1pa2UgSm9uZXMsIEpvaG4gQnJhZGxleSwgTmF0IFNha2ltdXJhLCBN YXJ0aW4NClRob21hcywgRXJpYyBSZXNjb3JsYSwgTWF0dCBNaWxsZXIsIGFuZCBSaWNoYXJkIEJh cm5lcyBmb3IgeW91ciBlZmZvcnRzDQooYW5kIG15IGFwb2xvZ2llcyBpZiBJIG1pc3NlZCBzb21l b25lKS4NCg0KIFJlZ2FyZHMsDQogS2FyZW4NCg0KIDE6ICBDaGFuZ2UgdGhlIGxhbmd1YWdlIOKA nEFkZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUNCkpXSy4gIElmIHByZXNl bnQsIHRoZXkgTVVTVCBiZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZw0KdGhl bS7igJ0gdG8g4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBiZSBwcmVzZW50IGluIHRoZSBKV0su ICBJZiBub3QNCnVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIGVuY291bnRlcmluZyB0aGVt LCB0aGV5IE1VU1QgYmUNCmlnbm9yZWQu4oCdICAoQW5kIG1ha2UgdGhlIHNhbWUgY2hhbmdlIGZv ciBKV0sgU2V0IGFzIHdlbGwuKQ0KDQogMjogIENoYXJhY3Rlcml6ZSBhbGwgZXhpc3RpbmcgSldT IGFuZCBKV0UgaGVhZGVyIGZpZWxkcyBhcyBlaXRoZXIgbXVzdA0KYmUgdW5kZXJzdG9vZCBvciBt YXkgYmUgaWdub3JlZC4gIOKAnGFsZ+KAnSwg4oCcZW5j4oCdLCBhbmQg4oCcemlw4oCdDQptdXN0 IGJlIHVuZGVyc3Rvb2QuICDigJxraWTigJ0sIOKAnHg1deKAnSwg4oCceDVj4oCdLCDigJx4NXTi gJ0sDQrigJxqd2vigJ0sIOKAnGprdeKAnSwg4oCcdHlw4oCdLCBhbmQg4oCcY3R54oCdIGNhbiBi ZSBpZ25vcmVkIGJlY2F1c2UNCndoaWxlIG5vdCB1c2luZyB0aGVtIG1heSByZXN1bHQgaW4gdGhl IGluYWJpbGl0eSB0byBwcm9jZXNzIHNvbWUNCnNpZ25hdHVyZXMgb3IgZW5jcnlwdGVkIGNvbnRl bnQsIHRoaXMgd2lsbCBub3QgcmVzdWx0IGluIGEgc2VjdXJpdHkNCnZpb2xhdGlvbiDigJMganVz dCBkZWdyYWRlZCBmdW5jdGlvbmFsaXR5LiAgT3RoZXIgZmllbGRzIHN1Y2ggYXMNCuKAnGVwa+KA nSwg4oCcYXB14oCdLCDigJxhcHbigJ0sIOKAnGVwdeKAnSwgYW5kIOKAnGVwduKAnSBtdXN0IGJl DQp1bmRlcnN0b29kIGFuZCB1c2VkIHdoZW4g4oCcYWxn4oCdIG9yIOKAnGVuY+KAnSB2YWx1ZXMg cmVxdWlyaW5nIHRoZW0NCmFyZSB1c2VkLCBhbmQgb3RoZXJ3aXNlIHRoZXkgbWF5IGJlIGlnbm9y ZWQuDQoNCiAzLiAgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCB0aGF0IGxpc3RzIHdoaWNoIGFk ZGl0aW9uYWwgZmllbGRzIG5vdA0KZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucyBt dXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVwb24NCndoZW4gcHJlc2VudC4gIEZvciBpbnN0 YW5jZSwgYW4gZXhwaXJhdGlvbi10aW1lIGV4dGVuc2lvbiBmaWVsZCBjb3VsZCBiZQ0KbWFya2Vk IGFzIG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0ZWQtdXBvbi4gIE9uZSBwb3NzaWJsZSBuYW1l IGZvciB0aGlzDQp3b3VsZCBiZSDigJxjcml04oCdIChjcml0aWNhbCkuICBBbiBleGFtcGxlIHVz ZSwgYWxvbmcgd2l0aCBhDQpoeXBvdGhldGljYWwg4oCcZXhw4oCdIChleHBpcmF0aW9uLXRpbWUp IGZpZWxkIGlzOg0KDQogICB7ImFsZyI6IkVTMjU2IiwNCiAgICAiY3JpdCI6WyJleHAiXSwNCiAg ICAiZXhw4oCdOjEzNjMyODQwMDANCiAgIH0NCg0KIDQuICBBbGwgYWRkaXRpb25hbCBoZWFkZXIg ZmllbGRzIG5vdCBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zDQphbmQgbm90IGNv bnRhaW5lZCBpbiB0aGUg4oCcY3JpdOKAnSBsaXN0IE1VU1QgYmUgaWdub3JlZCBpZiBub3QNCnVu ZGVyc3Rvb2QuDQoNCiA1LiAgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCDigJxhc2TigJ0gKGFw cGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpDQp3aG9zZSB2YWx1ZSBpcyBhIEpTT04gc3RydWN0dXJl IHdob3NlIGNvbnRlbnRzIGFyZSBvcGFxdWUgdG8gYW5kIGlnbm9yZWQNCmJ5IEpXUyBhbmQgSldF IGltcGxlbWVudGF0aW9ucyBidXQgZm9yIHdoaWNoIGl0cyBjb250ZW50cyBNVVNUIGJlDQpwcm92 aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNpbmcgSldTIG9yIEpXRSwgcHJvdmlkZWQgdGhhdCB0aGUN CnNpZ25hdHVyZS9NQUMgdmFsaWRhdGlvbiBvciBkZWNyeXB0aW9uIG9wZXJhdGlvbiBzdWNjZWVk cy4gIFRoZSBpbnRlbmRlZA0KdXNlIG9mIHRoaXMgZmllbGQgaXMgdG8gaGF2ZSBhIHN0YW5kYXJk IHBsYWNlIHRvIHByb3ZpZGUNCmFwcGxpY2F0aW9uLXNwZWNpZmljIG1ldGFkYXRhIGFib3V0IHRo ZSBwYXlsb2FkIG9yIHBsYWludGV4dC4NCg0KDQoNCg0KDQoNCiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0 Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBs aXN0DQpqb3NlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2pvc2UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpq b3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlDQo= --_000_4E1F6AAD24975D4BA5B1680429673943674F8E97TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <9ABA76D184409D44BC01DF9D02121963@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2Pkkga2luZCBvZiBsaWtlIHRoZSZuYnNwO+KAnCHigJ0gc3Vn Z2VzdGlvbi4mbmJzcDsgSmFtZXMgaXMgcmlnaHQgLSBJIGRpZG7igJl0IGNob29zZSB0aGUgbmFt ZSZuYnNwO+KAnGNydOKAnSBiZWNhc2UgaXQgbWVhbnMmbmJzcDvigJxjZXJ0aWZpY2F0ZeKAnSB0 byB0b28gbWFueSBwZW9wbGUuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5DaGVlcnMs PC9kaXY+DQo8ZGl2Pi0tIE1pa2U8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6 IDJweDsgYm9yZGVyLXRvcC1zdHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4m bmJzcDtNYW5nZXIsIEphbWVzIEg8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+Jm5ic3A74oCO TWFyY2jigI4g4oCOMTLigI4sIOKAjjIwMTMg4oCONeKAjjrigI4xOOKAjiDigI5BTTxicj4NCjxz dHJvbmc+VG86PC9zdHJvbmc+Jm5ic3A7dmxhZGltaXJAbmltYnVzZHMuY29tLCBqb3NlQGlldGYu b3JnPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1JlOiBbam9zZV0gUHJvcG9z ZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWU8YnI+DQo8L2Rpdj4NCjxk aXY+Jm5ic3A7PC9kaXY+DQpOYWgsICZxdW90O2NydCZxdW90OyBzb3VuZHMgdG9vIG11Y2ggbGlr ZSBhIGNlcnRpZmljYXRlLiAqLmNydCBpcyBhIGNvbW1vbiBmaWxlIGV4dGVuc2lvbiBmb3IgY2Vy dHMuPGJyPg0KPGJyPg0KSG93IGFib3V0ICZxdW90OyEmcXVvdDsgPzxicj4NCjxicj4NCi0tPGJy Pg0KSmFtZXMgTWFuZ2VyPGJyPg0KPGJyPg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4N CkZyb206ICZxdW90O1ZsYWRpbWlyIER6aHV2aW5vdiAvIE5pbWJ1c0RTJnF1b3Q7ICZsdDt2bGFk aW1pckBuaW1idXNkcy5jb20mZ3Q7PGJyPg0KRGF0ZTogVHVlLCBNYXIgMTIsIDIwMTMgNTo0NSBw bTxicj4NClN1YmplY3Q6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0 aWNhbGl0eSBpc3N1ZTxicj4NClRvOiAmcXVvdDtqb3NlQGlldGYub3JnJnF1b3Q7ICZsdDtqb3Nl QGlldGYub3JnJmd0Ozxicj4NCjxicj4NCkhvdyBhYm91dCAmcXVvdDtjcnQmcXVvdDsgaW5zdGVh ZCBvZiAmcXVvdDtjcml0JnF1b3Q7LCB0byBmaXQgdGhlIHRocmVlLWxldHRlciBjb252ZW50aW9u PGJyPg0KZm9yIG5hbWluZyBmaWVsZHM/PGJyPg0KPGJyPg0KVmxhZGltaXI8YnI+DQo8YnI+DQot LTxicj4NClZsYWRpbWlyIER6aHV2aW5vdiA6IHd3dy5OaW1idXNEUy5jb20mbHQ7aHR0cDovL3d3 dy5OaW1idXNEUy5jb20mZ3Q7IDogdmxhZGltaXJAbmltYnVzZHMuY29tPGJyPg0KPGJyPg0KPGJy Pg0KLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLTxicj4NClN1YmplY3Q6IFtqb3Nl XSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZTxicj4NCkZy b206IEthcmVuIE8nRG9ub2dodWUgJmx0O29kb25vZ2h1ZUBpc29jLm9yZyZndDs8YnI+DQpEYXRl OiBUdWUsIE1hcmNoIDEyLCAyMDEzIDEyOjMxIGFtPGJyPg0KVG86IGpvc2VAaWV0Zi5vcmc8YnI+ DQo8YnI+DQo8YnI+DQombmJzcDtGb2xrcyw8YnI+DQo8YnI+DQombmJzcDtBIHNpZGUgbWVldGlu ZyB3YXMgaGVsZCBTdW5kYXkgd2l0aCBhIG51bWJlciBvZiBqb3NlIHdvcmtpbmcgZ3JvdXA8YnI+ DQpwYXJ0aWNpcGFudHMgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIG9wZW4gaXNzdWUgcmVsYXRlZCB0 byBoZWFkZXI8YnI+DQpjcml0aWNhbGl0eS4gVGhlIGZvbGxvd2luZyBhcmUgdGhlIHByb3Bvc2Vk IHJlc29sdXRpb25zIGZyb20gdGhlPGJyPg0KbWVldGluZy4gUG9pbnQgNSBvZiB0aGUgcHJvcG9z ZWQgcmVzb2x1dGlvbiBiZWxvdyBpcyBhY3R1YWxseTxicj4NCmluZGVwZW5kZW50IG9mIHRoZSBv dGhlciA0IHBvaW50cywgYW5kIGNvdWxkIGJlIGNvbnNpZGVyZWQgc2VwYXJhdGVseS48YnI+DQpU aGlzIHdpbGwgYWxsIGJlIGRpc2N1c3NlZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLjxicj4NCjxi cj4NCiZuYnNwO0luIGFkZGl0aW9uIHRvIHRoZSB0ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBh Z3JlZW1lbnQgdG8gcmVwbGFjZSB0aGU8YnI+DQomcXVvdDt1bmRlcnN0YW5kJnF1b3Q7IHRleHQg d2l0aCBzb21ldGhpbmcgYSBiaXQgbW9yZSBleHBsaWNpdCBsaWtlICZxdW90O211c3Q8YnI+DQpw cm9jZXNzJnF1b3Q7LiBIb3dldmVyLCB0aGF0IHRleHQgaGFzIG5vdCBiZWVuIHJvbGxlZCBpbnRv IHRoZSBzdW1tYXJ5IHRleHQ8YnI+DQpiZWxvdyB5ZXQuPGJyPg0KPGJyPg0KJm5ic3A7VGhhbmsg eW91IHRvIEppbSBTY2hhYWQsIE1pa2UgSm9uZXMsIEpvaG4gQnJhZGxleSwgTmF0IFNha2ltdXJh LCBNYXJ0aW48YnI+DQpUaG9tYXMsIEVyaWMgUmVzY29ybGEsIE1hdHQgTWlsbGVyLCBhbmQgUmlj aGFyZCBCYXJuZXMgZm9yIHlvdXIgZWZmb3J0czxicj4NCihhbmQgbXkgYXBvbG9naWVzIGlmIEkg bWlzc2VkIHNvbWVvbmUpLjxicj4NCjxicj4NCiZuYnNwO1JlZ2FyZHMsPGJyPg0KJm5ic3A7S2Fy ZW48YnI+DQo8YnI+DQombmJzcDsxOiZuYnNwOyBDaGFuZ2UgdGhlIGxhbmd1YWdlIOKAnEFkZGl0 aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGU8YnI+DQpKV0suJm5ic3A7IElmIHBy ZXNlbnQsIHRoZXkgTVVTVCBiZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZzxi cj4NCnRoZW0u4oCdIHRvIOKAnEFkZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0 aGUgSldLLiZuYnNwOyBJZiBub3Q8YnI+DQp1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyBl bmNvdW50ZXJpbmcgdGhlbSwgdGhleSBNVVNUIGJlPGJyPg0KaWdub3JlZC7igJ0mbmJzcDsgKEFu ZCBtYWtlIHRoZSBzYW1lIGNoYW5nZSBmb3IgSldLIFNldCBhcyB3ZWxsLik8YnI+DQo8YnI+DQom bmJzcDsyOiZuYnNwOyBDaGFyYWN0ZXJpemUgYWxsIGV4aXN0aW5nIEpXUyBhbmQgSldFIGhlYWRl ciBmaWVsZHMgYXMgZWl0aGVyIG11c3Q8YnI+DQpiZSB1bmRlcnN0b29kIG9yIG1heSBiZSBpZ25v cmVkLiZuYnNwOyDigJxhbGfigJ0sIOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnTxicj4NCm11c3Qg YmUgdW5kZXJzdG9vZC4mbmJzcDsg4oCca2lk4oCdLCDigJx4NXXigJ0sIOKAnHg1Y+KAnSwg4oCc eDV04oCdLDxicj4NCuKAnGp3a+KAnSwg4oCcamt14oCdLCDigJx0eXDigJ0sIGFuZCDigJxjdHni gJ0gY2FuIGJlIGlnbm9yZWQgYmVjYXVzZTxicj4NCndoaWxlIG5vdCB1c2luZyB0aGVtIG1heSBy ZXN1bHQgaW4gdGhlIGluYWJpbGl0eSB0byBwcm9jZXNzIHNvbWU8YnI+DQpzaWduYXR1cmVzIG9y IGVuY3J5cHRlZCBjb250ZW50LCB0aGlzIHdpbGwgbm90IHJlc3VsdCBpbiBhIHNlY3VyaXR5PGJy Pg0KdmlvbGF0aW9uIOKAkyBqdXN0IGRlZ3JhZGVkIGZ1bmN0aW9uYWxpdHkuJm5ic3A7IE90aGVy IGZpZWxkcyBzdWNoIGFzPGJyPg0K4oCcZXBr4oCdLCDigJxhcHXigJ0sIOKAnGFwduKAnSwg4oCc ZXB14oCdLCBhbmQg4oCcZXB24oCdIG11c3QgYmU8YnI+DQp1bmRlcnN0b29kIGFuZCB1c2VkIHdo ZW4g4oCcYWxn4oCdIG9yIOKAnGVuY+KAnSB2YWx1ZXMgcmVxdWlyaW5nIHRoZW08YnI+DQphcmUg dXNlZCwgYW5kIG90aGVyd2lzZSB0aGV5IG1heSBiZSBpZ25vcmVkLjxicj4NCjxicj4NCiZuYnNw OzMuJm5ic3A7IERlZmluZSBhIG5ldyBoZWFkZXIgZmllbGQgdGhhdCBsaXN0cyB3aGljaCBhZGRp dGlvbmFsIGZpZWxkcyBub3Q8YnI+DQpkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25z IG11c3QgYmUgdW5kZXJzdG9vZCBhbmQgYWN0ZWQgdXBvbjxicj4NCndoZW4gcHJlc2VudC4mbmJz cDsgRm9yIGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRpbWUgZXh0ZW5zaW9uIGZpZWxkIGNvdWxk IGJlPGJyPg0KbWFya2VkIGFzIG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0ZWQtdXBvbi4mbmJz cDsgT25lIHBvc3NpYmxlIG5hbWUgZm9yIHRoaXM8YnI+DQp3b3VsZCBiZSDigJxjcml04oCdIChj cml0aWNhbCkuJm5ic3A7IEFuIGV4YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGE8YnI+DQpoeXBvdGhl dGljYWwg4oCcZXhw4oCdIChleHBpcmF0aW9uLXRpbWUpIGZpZWxkIGlzOjxicj4NCjxicj4NCiZu YnNwOyZuYnNwOyB7JnF1b3Q7YWxnJnF1b3Q7OiZxdW90O0VTMjU2JnF1b3Q7LDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyAmcXVvdDtjcml0JnF1b3Q7OlsmcXVvdDtleHAmcXVvdDtdLDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAmcXVvdDtleHDigJ06MTM2MzI4NDAwMDxicj4NCiZuYnNwOyZuYnNw OyB9PGJyPg0KPGJyPg0KJm5ic3A7NC4mbmJzcDsgQWxsIGFkZGl0aW9uYWwgaGVhZGVyIGZpZWxk cyBub3QgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9uczxicj4NCmFuZCBub3QgY29u dGFpbmVkIGluIHRoZSDigJxjcml04oCdIGxpc3QgTVVTVCBiZSBpZ25vcmVkIGlmIG5vdDxicj4N CnVuZGVyc3Rvb2QuPGJyPg0KPGJyPg0KJm5ic3A7NS4mbmJzcDsgRGVmaW5lIGEgbmV3IGhlYWRl ciBmaWVsZCDigJxhc2TigJ0gKGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpPGJyPg0Kd2hvc2Ug dmFsdWUgaXMgYSBKU09OIHN0cnVjdHVyZSB3aG9zZSBjb250ZW50cyBhcmUgb3BhcXVlIHRvIGFu ZCBpZ25vcmVkPGJyPg0KYnkgSldTIGFuZCBKV0UgaW1wbGVtZW50YXRpb25zIGJ1dCBmb3Igd2hp Y2ggaXRzIGNvbnRlbnRzIE1VU1QgYmU8YnI+DQpwcm92aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNp bmcgSldTIG9yIEpXRSwgcHJvdmlkZWQgdGhhdCB0aGU8YnI+DQpzaWduYXR1cmUvTUFDIHZhbGlk YXRpb24gb3IgZGVjcnlwdGlvbiBvcGVyYXRpb24gc3VjY2VlZHMuJm5ic3A7IFRoZSBpbnRlbmRl ZDxicj4NCnVzZSBvZiB0aGlzIGZpZWxkIGlzIHRvIGhhdmUgYSBzdGFuZGFyZCBwbGFjZSB0byBw cm92aWRlPGJyPg0KYXBwbGljYXRpb24tc3BlY2lmaWMgbWV0YWRhdGEgYWJvdXQgdGhlIHBheWxv YWQgb3IgcGxhaW50ZXh0Ljxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjxicj4N CiZuYnNwO19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0Kam9zZSBtYWlsaW5nIGxpc3Q8YnI+DQpqb3NlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCmpv c2VAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pv c2U8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0Kam9zZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTxicj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943674F8E97TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 06:07:45 2013 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 BCC1121F8A2A for ; Tue, 12 Mar 2013 06:07:45 -0700 (PDT) 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=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Nxb70tOWsYif for ; Tue, 12 Mar 2013 06:07:44 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 64AF121F8A5F for ; Tue, 12 Mar 2013 06:07:44 -0700 (PDT) Received: from BL2FFO11FD007.protection.gbl (10.173.161.202) by BL2FFO11HUB019.protection.gbl (10.173.160.111) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 13:07:42 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD007.mail.protection.outlook.com (10.173.161.3) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 13:07:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 13:06:17 +0000 From: Mike Jones To: John Bradley , Richard Barnes Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4fImHPmB8jo/KiwU+B27AulrV5NQ== Date: Tue, 12 Mar 2013 13:06:17 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674F918BTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(24454001)(377424002)(512874001)(16406001)(16236675001)(55846006)(69226001)(56776001)(20776003)(54356001)(59766001)(50986001)(4396001)(5343635001)(47976001)(49866001)(54316002)(76482001)(46102001)(80022001)(33656001)(5343655001)(56816002)(63696002)(44976002)(74662001)(31966008)(47446002)(53806001)(65816001)(77982001)(79102001)(51856001)(74502001)(47736001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB019; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: James H Manger , Tim Bray , jose , Karen O'Donoghue Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:07:45 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674F918BTK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gd2l0aCBSaWNoYXJkIG9uIHRoaXMuICBUaGUgYXBwbGljYXRpb24tc3BlY2lmaWMtZGF0 YS9tZXRhIGZpZWxkIGlzbuKAmXQgbmVlZGVkLg0KDQotLSBNaWtlDQoNCkZyb206IFJpY2hhcmQg QmFybmVzDQpTZW50OiDigI5NYXJjaOKAjiDigI4xMeKAjiwg4oCOMjAxMyDigI4xMOKAjjrigI4w MuKAjiDigI5QTQ0KVG86IEpvaG4gQnJhZGxleQ0KQ0M6IFRpbSBCcmF5LCBNYW5nZXIsIEphbWVz IEgsIEthcmVuIE9Eb25vZ2h1ZSwgam9zZQ0KU3ViamVjdDogUmU6IFtqb3NlXSBQcm9wb3NlZCBy ZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KDQorMSB0byBjaGVlcnMuICBJ IGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi4NCg0KRldJVywgbXkgcHJlZmVyZW5j ZSB3b3VsZCBiZSB0byBnZXQgcmlkIG9mICJhc2QiIG9yICJtZXRhIiAocGFydCA1KS4gIEkgZG9u J3QgdGhpbmsgaXQncyByZWxldmFudCB0byB0aGUgY3JpdGljYWxpdHkgZGlzY3Vzc2lvbiwgYW5k IGl0J3MganVzdCBub3QgbmVlZGVkLg0KDQotLVJpY2hhcmQNCg0KDQoNCk9uIE1vbiwgTWFyIDEx LCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPG1haWx0 bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpPbiAyMDEzLTAzLTExLCBhdCAxMDo0OCBQ TSwgIk1hbmdlciwgSmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208bWFp bHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCg0KSeKAmWxsIGFk ZCBzb21lIGNoZWVycyDigJQgdGhpcyBkb2VzIGxvb2sgbGlrZSBzdWJzdGFudGlhbCBwcm9ncmVz cy4NCg0KSSBhc3N1bWUgdGhlIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg4oCcYXB14oCdIGV0 YyB0aGF0IHNvbWV0aW1lcyBtdXN0IGJlIHVuZGVyc3Rvb2QsIGFuZCBhdCBvdGhlciB0aW1lcyBt dXN0IGJlIGlnbm9yZWQgKGRlcGVuZGluZyBvbiDigJxhbGfigJ0gb3Ig4oCcZW5j4oCdIHZhbHVl KSB3b3VsZCBOT1QgYmUgbGlzdGVkIGluIHRoZSDigJxjcml04oCdIGZpZWxkIGFzIHRoZXkgYXJl IGRlZmluZWQgaW4gdGhlIOKAnGJhc2Ugc3BlY3PigJ0uDQoNCkNvcnJlY3QNCg0KQmVpbmcgaW4g dGhlIOKAnGJhc2Ugc3BlY3PigJ0gaXMgdGhlIHJpZ2h0IGNyaXRlcmlhIGZvciB3aGV0aGVyIGEg ZmllbGQgc2hvdWxkIGJlIGxpc3RlZCBpbiDigJxjcml04oCdIGFzIGxvbmcgYXMg4oCcYmFzZSBz cGVjc+KAnSBtZWFuczog4oCcYmFzZSBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIHBhcnRpY3VsYXIg 4oCcYWxn4oCdL+KAnWVuY+KAnSB2YWx1ZXPigJ0uIEl0IHNob3VsZG7igJl0IG1lYW4gKGFuZCBk b2VzbuKAmXQgaGF2ZSB0byBtZWFuKSB0aGUgYmFzZSBzcGVjIGZvciB0aGUgd2hvbGUgSk9TRSBz eXN0ZW0uDQoNCg0KQ3JpdCBpcyBvbmx5IGZvciBleHRlbnNpb25zLCBpdCBpcyB1cCB0byB0aGUg ZXh0ZW5zaW9uIGRlZmluaXRpb24gdG8gZGVjaWRlIGlmIHRoZSBmaWVsZCBuZWVkcyB0byBiZSBp biBjcml0Lg0KDQoNClAuUy4g4oCcbWV0YeKAnSBtaWdodCBiZSBhIG5pY2VyIGxhYmVsIHRoYW4g 4oCcYXNk4oCdLg0KDQpJIGRvbid0IGhhdmUgYW55IHBhcnRpY3VsYXIgYXR0YWNobWVudCB0byB0 aGUgbmFtZS4gICBTb21lIHBsYWNlcyB0aGluZ3MgbGlrZSB0aGlzIGFyZSBjYWxsZWQgYXNzb2Np YXRlZCBkYXRhLCB0aG91Z2ggbm90IHRoZSBwbGFjZXMgbm9ybWFsIHBlb3BsZSBnbyBJIGdyYW50 IHlvdS4NCk1ldGEtZGF0YSBhYm91dCB0aGUgcGF5bG9hZCBpcyB3aGF0IGl0IGlzLCAgVGhlIGN1 cnJlbnQgcHJhY3RpY2UgaXMgdG8gdXNlIHRocmVlIGNoYXJhY3RlciBuYW1lcy4gICBJIGFtIGZp bmUgd2l0aCBtZXQgb3IgbWV0YSAoSSBzdXNwZWN0IHRoYXQgaWYgeW91IGFyZSB0aHJvd2luZyBj cmFwIGludG8gdGhlIGVudmVsb3BlIHRoZSBzaW5nbGUgY2hhcmFjdGVyIHdvbid0IGtpbGwgYW55 b25lLg0KDQpKYW1lcyBpZiB5b3UgbGlrZSB0aGUgc29sdXRpb24gYW5kIHdhbnQgaXQgdG8gYmUg bWV0YSBJIHdpbGwgYmFjayB5b3Ugb24gaXQgOikNCg0KSm9obiBCLg0KDQoNCi0tDQpKYW1lcyBN YW5nZXINCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmc+IFttYWlsdG86am9zZS08bWFpbHRvOmpvc2UtPmJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOmJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGltIEJyYXkNClNlbnQ6IFR1ZXNk YXksIDEyIE1hcmNoIDIwMTMgMTI6NDMgUE0NClRvOiBLYXJlbiBPRG9ub2dodWUNCkNjOiBqb3Nl DQpTdWJqZWN0OiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRp Y2FsaXR5IGlzc3VlDQoNCkN1ZSB3aWxkIGNoZWVycyBmcm9tIHRoZSBwZWFudXQgZ2FsbGVyeSB3 aGVyZSBub24tY3J5cHRvZ3JhcGhlcnMgc2l0LiAgTXVzdElnbm9yZSBpcyBpbmZpbml0ZWx5IG1v cmUgcm9idXN0IGFuZCBvcGVuLWVuZGVkIHRoYW4gTXVzdFVuZGVyc3RhbmQuICAtVA0KDQpPbiBN b24sIE1hciAxMSwgMjAxMyBhdCA1OjMxIFBNLCBLYXJlbiBPJ0Rvbm9naHVlIDxvZG9ub2dodWVA aXNvYy5vcmc8bWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZz4+IHdyb3RlOg0KDQpGb2xrcywNCg0K QSBzaWRlIG1lZXRpbmcgd2FzIGhlbGQgU3VuZGF5IHdpdGggYSBudW1iZXIgb2Ygam9zZSB3b3Jr aW5nIGdyb3VwIHBhcnRpY2lwYW50cyB0byB0cnkgdG8gcmVzb2x2ZSB0aGUgb3BlbiBpc3N1ZSBy ZWxhdGVkIHRvIGhlYWRlciBjcml0aWNhbGl0eS4gVGhlIGZvbGxvd2luZyBhcmUgdGhlIHByb3Bv c2VkIHJlc29sdXRpb25zIGZyb20gdGhlIG1lZXRpbmcuIFBvaW50IDUgb2YgdGhlIHByb3Bvc2Vk IHJlc29sdXRpb24gYmVsb3cgaXMgYWN0dWFsbHkgaW5kZXBlbmRlbnQgb2YgdGhlIG90aGVyIDQg cG9pbnRzLCBhbmQgY291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5LiBUaGlzIHdpbGwgYWxs IGJlIGRpc2N1c3NlZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLg0KDQpJbiBhZGRpdGlvbiB0byB0 aGUgdGV4dCBiZWxvdywgdGhlcmUgd2FzIHNvbWUgYWdyZWVtZW50IHRvIHJlcGxhY2UgdGhlICJ1 bmRlcnN0YW5kIiB0ZXh0IHdpdGggc29tZXRoaW5nIGEgYml0IG1vcmUgZXhwbGljaXQgbGlrZSAi bXVzdCBwcm9jZXNzIi4gSG93ZXZlciwgdGhhdCB0ZXh0IGhhcyBub3QgYmVlbiByb2xsZWQgaW50 byB0aGUgc3VtbWFyeSB0ZXh0IGJlbG93IHlldC4NCg0KVGhhbmsgeW91IHRvIEppbSBTY2hhYWQs IE1pa2UgSm9uZXMsIEpvaG4gQnJhZGxleSwgTmF0IFNha2ltdXJhLCBNYXJ0aW4gVGhvbWFzLCBF cmljIFJlc2NvcmxhLCBNYXR0IE1pbGxlciwgYW5kIFJpY2hhcmQgQmFybmVzIGZvciB5b3VyIGVm Zm9ydHMgKGFuZCBteSBhcG9sb2dpZXMgaWYgSSBtaXNzZWQgc29tZW9uZSkuDQoNClJlZ2FyZHMs DQpLYXJlbg0KDQoxOiAgQ2hhbmdlIHRoZSBsYW5ndWFnZSDigJxBZGRpdGlvbmFsIG1lbWJlcnMg TUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gIElmIHByZXNlbnQsIHRoZXkgTVVTVCBiZSB1bmRl cnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtLuKAnSB0byDigJxBZGRpdGlvbmFs IG1lbWJlcnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gIElmIG5vdCB1bmRlcnN0b29kIGJ5 IGltcGxlbWVudGF0aW9ucyBlbmNvdW50ZXJpbmcgdGhlbSwgdGhleSBNVVNUIGJlIGlnbm9yZWQu 4oCdICAoQW5kIG1ha2UgdGhlIHNhbWUgY2hhbmdlIGZvciBKV0sgU2V0IGFzIHdlbGwuKQ0KDQoy OiAgQ2hhcmFjdGVyaXplIGFsbCBleGlzdGluZyBKV1MgYW5kIEpXRSBoZWFkZXIgZmllbGRzIGFz IGVpdGhlciBtdXN0IGJlIHVuZGVyc3Rvb2Qgb3IgbWF5IGJlIGlnbm9yZWQuICDigJxhbGfigJ0s IOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnSBtdXN0IGJlIHVuZGVyc3Rvb2QuICDigJxraWTigJ0s IOKAnHg1deKAnSwg4oCceDVj4oCdLCDigJx4NXTigJ0sIOKAnGp3a+KAnSwg4oCcamt14oCdLCDi gJx0eXDigJ0sIGFuZCDigJxjdHnigJ0gY2FuIGJlIGlnbm9yZWQgYmVjYXVzZSB3aGlsZSBub3Qg dXNpbmcgdGhlbSBtYXkgcmVzdWx0IGluIHRoZSBpbmFiaWxpdHkgdG8gcHJvY2VzcyBzb21lIHNp Z25hdHVyZXMgb3IgZW5jcnlwdGVkIGNvbnRlbnQsIHRoaXMgd2lsbCBub3QgcmVzdWx0IGluIGEg c2VjdXJpdHkgdmlvbGF0aW9uIOKAkyBqdXN0IGRlZ3JhZGVkIGZ1bmN0aW9uYWxpdHkuICBPdGhl ciBmaWVsZHMgc3VjaCBhcyDigJxlcGvigJ0sIOKAnGFwdeKAnSwg4oCcYXB24oCdLCDigJxlcHXi gJ0sIGFuZCDigJxlcHbigJ0gbXVzdCBiZSB1bmRlcnN0b29kIGFuZCB1c2VkIHdoZW4g4oCcYWxn 4oCdIG9yIOKAnGVuY+KAnSB2YWx1ZXMgcmVxdWlyaW5nIHRoZW0gYXJlIHVzZWQsIGFuZCBvdGhl cndpc2UgdGhleSBtYXkgYmUgaWdub3JlZC4NCg0KMy4gIERlZmluZSBhIG5ldyBoZWFkZXIgZmll bGQgdGhhdCBsaXN0cyB3aGljaCBhZGRpdGlvbmFsIGZpZWxkcyBub3QgZGVmaW5lZCBpbiB0aGUg YmFzZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVwb24gd2hl biBwcmVzZW50LiAgRm9yIGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRpbWUgZXh0ZW5zaW9uIGZp ZWxkIGNvdWxkIGJlIG1hcmtlZCBhcyBtdXN0LWJlLXVuZGVyc3Rvb2QtYW5kLWFjdGVkLXVwb24u ICBPbmUgcG9zc2libGUgbmFtZSBmb3IgdGhpcyB3b3VsZCBiZSDigJxjcml04oCdIChjcml0aWNh bCkuICBBbiBleGFtcGxlIHVzZSwgYWxvbmcgd2l0aCBhIGh5cG90aGV0aWNhbCDigJxleHDigJ0g KGV4cGlyYXRpb24tdGltZSkgZmllbGQgaXM6DQoNCiAgeyJhbGciOiJFUzI1NiIsDQogICAiY3Jp dCI6WyJleHAiXSwNCiAgICJleHDigJ06MTM2MzI4NDAwMA0KICB9DQoNCjQuICBBbGwgYWRkaXRp b25hbCBoZWFkZXIgZmllbGRzIG5vdCBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25z IGFuZCBub3QgY29udGFpbmVkIGluIHRoZSDigJxjcml04oCdIGxpc3QgTVVTVCBiZSBpZ25vcmVk IGlmIG5vdCB1bmRlcnN0b29kLg0KDQo1LiAgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCDigJxh c2TigJ0gKGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpIHdob3NlIHZhbHVlIGlzIGEgSlNPTiBz dHJ1Y3R1cmUgd2hvc2UgY29udGVudHMgYXJlIG9wYXF1ZSB0byBhbmQgaWdub3JlZCBieSBKV1Mg YW5kIEpXRSBpbXBsZW1lbnRhdGlvbnMgYnV0IGZvciB3aGljaCBpdHMgY29udGVudHMgTVVTVCBi ZSBwcm92aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNpbmcgSldTIG9yIEpXRSwgcHJvdmlkZWQgdGhh dCB0aGUgc2lnbmF0dXJlL01BQyB2YWxpZGF0aW9uIG9yIGRlY3J5cHRpb24gb3BlcmF0aW9uIHN1 Y2NlZWRzLiAgVGhlIGludGVuZGVkIHVzZSBvZiB0aGlzIGZpZWxkIGlzIHRvIGhhdmUgYSBzdGFu ZGFyZCBwbGFjZSB0byBwcm92aWRlIGFwcGxpY2F0aW9uLXNwZWNpZmljIG1ldGFkYXRhIGFib3V0 IHRoZSBwYXlsb2FkIG9yIHBsYWludGV4dC4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9y ZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vam9zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5n IGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQo= --_000_4E1F6AAD24975D4BA5B1680429673943674F918BTK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <771D218A0287034DA4F43F8698A457AD@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2PknigJltIHdpdGggUmljaGFyZCBvbiB0aGlzLiZuYnNwOyBU aGUmbmJzcDthcHBsaWNhdGlvbi1zcGVjaWZpYy1kYXRhL21ldGEgZmllbGQgaXNu4oCZdCBuZWVk ZWQuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4tLSBNaWtlPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRvcC1jb2xvcjogcmdiKDIyOSwgMjI5LCAy MjkpOyBib3JkZXItdG9wLXdpZHRoOiAycHg7IGJvcmRlci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8 c3Ryb25nPkZyb206PC9zdHJvbmc+Jm5ic3A7UmljaGFyZCBCYXJuZXM8YnI+DQo8c3Ryb25nPlNl bnQ6PC9zdHJvbmc+Jm5ic3A74oCOTWFyY2jigI4g4oCOMTHigI4sIOKAjjIwMTMg4oCOMTDigI46 4oCOMDLigI4g4oCOUE08YnI+DQo8c3Ryb25nPlRvOjwvc3Ryb25nPiZuYnNwO0pvaG4gQnJhZGxl eTxicj4NCjxzdHJvbmc+Q0M6PC9zdHJvbmc+Jm5ic3A7VGltIEJyYXksIE1hbmdlciwgSmFtZXMg SCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZu YnNwO1JlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkg aXNzdWU8YnI+DQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQomIzQzOzEgdG8gY2hlZXJzLiAm bmJzcDtJIGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2PkZXSVcsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gZ2V0IHJpZCBvZiAmcXVv dDthc2QmcXVvdDsgb3IgJnF1b3Q7bWV0YSZxdW90OyAocGFydCA1KS4gJm5ic3A7SSBkb24ndCB0 aGluayBpdCdzIHJlbGV2YW50IHRvIHRoZSBjcml0aWNhbGl0eSBkaXNjdXNzaW9uLCBhbmQgaXQn cyBqdXN0IG5vdCBuZWVkZWQuICZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LS1SaWNoYXJkPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8YnI+DQo8ZGl2 IGNsYXNzPSJnbWFpbF9xdW90ZSI+T24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgMTE6MDEgUE0sIEpv aG4gQnJhZGxleSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFpbHRvOnZlN2p0YkB2 ZTdqdGIuY29tIj52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8 YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHggMHB4 IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQsIDIw NCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNvbGlk OyI+DQo8ZGl2IHN0eWxlPSItbXMtd29yZC13cmFwOiBicmVhay13b3JkOyI+PGJyPg0KPGRpdj4N CjxkaXYgY2xhc3M9ImltIj4NCjxkaXY+T24gMjAxMy0wMy0xMSwgYXQgMTA6NDggUE0sICZxdW90 O01hbmdlciwgSmFtZXMgSCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkphbWVzLkguTWFuZ2Vy QHRlYW0udGVsc3RyYS5jb20iPkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb208L2E+Jmd0 OyB3cm90ZTo8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlPg0KPGRpdiBsYW5nPSJFTi1BVSIgc3R5 bGU9InRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVudDogMHB4OyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsiPg0KPGRp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNl cmlmOyBmb250LXNpemU6IDExcHQ7Ij5J4oCZbGwgYWRkIHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRv ZXMgbG9vayBsaWtlIHN1YnN0YW50aWFsIHByb2dyZXNzLjx1PjwvdT48dT48L3U+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6 IDExcHQ7Ij5JIGFzc3VtZSB0aGUgZmllbGRzIHN1Y2ggYXMg4oCcZXBr4oCdLCDigJxhcHXigJ0g ZXRjIHRoYXQgc29tZXRpbWVzIG11c3QgYmUgdW5kZXJzdG9vZCwgYW5kIGF0IG90aGVyIHRpbWVz IG11c3QgYmUgaWdub3JlZCAoZGVwZW5kaW5nIG9uIOKAnGFsZ+KAnSBvciDigJxlbmPigJ0gdmFs dWUpIHdvdWxkIE5PVCBiZSBsaXN0ZWQNCiBpbiB0aGUg4oCcY3JpdOKAnSBmaWVsZCBhcyB0aGV5 IGFyZSBkZWZpbmVkIGluIHRoZSDigJxiYXNlIHNwZWNz4oCdLjx1PjwvdT48dT48L3U+PC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCkNvcnJlY3Q8L2Rpdj4NCjxkaXY+DQo8ZGl2 IGNsYXNzPSJpbSI+PGJyPg0KPGJsb2NrcXVvdGU+DQo8ZGl2IGxhbmc9IkVOLUFVIiBzdHlsZT0i dGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0i Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7 IGZvbnQtc2l6ZTogMTFwdDsiPkJlaW5nIGluIHRoZSDigJxiYXNlIHNwZWNz4oCdIGlzIHRoZSBy aWdodCBjcml0ZXJpYSBmb3Igd2hldGhlciBhIGZpZWxkIHNob3VsZCBiZSBsaXN0ZWQgaW4g4oCc Y3JpdOKAnSBhcyBsb25nIGFzIOKAnGJhc2Ugc3BlY3PigJ0gbWVhbnM6IOKAnGJhc2Ugc3BlY2lm aWNhdGlvbnMgZm9yIHRoZSBwYXJ0aWN1bGFyIOKAnGFsZ+KAnS/igJ1lbmPigJ0NCiB2YWx1ZXPi gJ0uIEl0IHNob3VsZG7igJl0IG1lYW4gKGFuZCBkb2VzbuKAmXQgaGF2ZSB0byBtZWFuKSB0aGUg YmFzZSBzcGVjIGZvciB0aGUgd2hvbGUgSk9TRSBzeXN0ZW0uPHU+PC91Pjx1PjwvdT48L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTogJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxzcGFu IHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCkNyaXQgaXMg b25seSBmb3IgZXh0ZW5zaW9ucywgaXQgaXMgdXAgdG8gdGhlIGV4dGVuc2lvbiBkZWZpbml0aW9u IHRvIGRlY2lkZSBpZiB0aGUgZmllbGQgbmVlZHMgdG8gYmUgaW4gY3JpdC48L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaW0iPjxicj4NCjxibG9ja3F1b3RlPg0K PGRpdiBsYW5nPSJFTi1BVSIgc3R5bGU9InRleHQtdHJhbnNmb3JtOiBub25lOyB0ZXh0LWluZGVu dDogMHB4OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgd2hpdGUt c3BhY2U6IG5vcm1hbDsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7 IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6 ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogQ2FsaWJyaSxzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7Ij5QLlMuIOKAnG1ldGHi gJ0gbWlnaHQgYmUgYSBuaWNlciBsYWJlbCB0aGFuIOKAnGFzZOKAnS48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0K SSBkb24ndCBoYXZlIGFueSBwYXJ0aWN1bGFyIGF0dGFjaG1lbnQgdG8gdGhlIG5hbWUuICZuYnNw OyBTb21lIHBsYWNlcyB0aGluZ3MgbGlrZSB0aGlzIGFyZSBjYWxsZWQgYXNzb2NpYXRlZCBkYXRh LCB0aG91Z2ggbm90IHRoZSBwbGFjZXMgbm9ybWFsIHBlb3BsZSBnbyBJIGdyYW50IHlvdS4gJm5i c3A7PC9kaXY+DQo8ZGl2Pk1ldGEtZGF0YSBhYm91dCB0aGUgcGF5bG9hZCBpcyB3aGF0IGl0IGlz LCAmbmJzcDtUaGUgY3VycmVudCBwcmFjdGljZSBpcyB0byB1c2UgdGhyZWUgY2hhcmFjdGVyIG5h bWVzLiAmbmJzcDsgSSBhbSBmaW5lIHdpdGggbWV0IG9yIG1ldGEgKEkgc3VzcGVjdCB0aGF0IGlm IHlvdSBhcmUgdGhyb3dpbmcgY3JhcCBpbnRvIHRoZSBlbnZlbG9wZSB0aGUgc2luZ2xlIGNoYXJh Y3RlciB3b24ndCBraWxsIGFueW9uZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkph bWVzIGlmIHlvdSBsaWtlIHRoZSBzb2x1dGlvbiBhbmQgd2FudCBpdCB0byBiZSBtZXRhIEkgd2ls bCBiYWNrIHlvdSBvbiBpdCA6KTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Sm9obiBC LjwvZGl2Pg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1Ij4NCjxkaXY+PGJyPg0KPGJsb2NrcXVvdGU+ DQo8ZGl2IGxhbmc9IkVOLUFVIiBzdHlsZT0idGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5k ZW50OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBw dDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1z aXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1m YW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0 OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSxzYW5zLXNlcmlm OyBmb250LXNpemU6IDExcHQ7Ij4tLTx1PjwvdT48dT48L3U+PC9zcGFuPjwvZGl2Pg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTFwdDsiPkphbWVzIE1hbmdlcjx1PjwvdT48dT48L3U+PC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8c3BhbiBzdHlsZT0iY29s b3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci1z dHlsZTogbm9uZSBub25lIG5vbmUgc29saWQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDRwdDsgYm9y ZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAxLjVwdDsiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBwYWRkaW5nOiAzcHQg MGNtIDBjbTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3JkZXItdG9w LXdpZHRoOiAxcHQ7Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFt aWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsi Pg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogVGFob21hLHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMHB0 OyI+PHNwYW4+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86am9z ZS0iPmpvc2UtPC9hPjxhIGhyZWY9Im1haWx0bzpib3VuY2VzQGlldGYub3JnIj5ib3VuY2VzQGll dGYub3JnPC9hPl08c3Bhbj4mbmJzcDs8L3NwYW4+PGI+T24NCiBCZWhhbGYgT2Y8c3Bhbj4mbmJz cDs8L3NwYW4+PC9iPlRpbSBCcmF5PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4+Jm5ic3A7PC9zcGFu PlR1ZXNkYXksIDEyIE1hcmNoIDIwMTMgMTI6NDMgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4+Jm5i c3A7PC9zcGFuPkthcmVuIE9Eb25vZ2h1ZTxicj4NCjxiPkNjOjwvYj48c3Bhbj4mbmJzcDs8L3Nw YW4+am9zZTxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuPiZuYnNwOzwvc3Bhbj5SZTogW2pvc2Vd IFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPHU+PC91Pjx1 PjwvdT48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJp ZjsgZm9udC1zaXplOiAxMnB0OyI+DQo8dT48L3U+Jm5ic3A7PHU+PC91PjwvZGl2Pg0KPGRpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KQ3VlIHdpbGQgY2hl ZXJzIGZyb20gdGhlIHBlYW51dCBnYWxsZXJ5IHdoZXJlIG5vbi1jcnlwdG9ncmFwaGVycyBzaXQu Jm5ic3A7IE11c3RJZ25vcmUgaXMgaW5maW5pdGVseSBtb3JlIHJvYnVzdCBhbmQgb3Blbi1lbmRl ZCB0aGFuIE11c3RVbmRlcnN0YW5kLiZuYnNwOyAtVDx1PjwvdT48dT48L3U+PC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDEy cHQ7IGZvbnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQt c2l6ZTogMTJwdDsiPg0KPHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+DQpPbiBNb24sIE1hciAxMSwgMjAxMyBh dCA1OjMxIFBNLCBLYXJlbiBPJ0Rvbm9naHVlICZsdDs8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsg dGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJtYWlsdG86b2Rvbm9naHVlQGlzb2Mu b3JnIj5vZG9ub2dodWVAaXNvYy5vcmc8L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91PjwvZGl2 Pg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiAm cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTogMTJwdDsiPg0KPGJy Pg0KRm9sa3MsPHU+PC91Pjx1PjwvdT48L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxicj4NCkEg c2lkZSBtZWV0aW5nIHdhcyBoZWxkIFN1bmRheSB3aXRoIGEgbnVtYmVyIG9mIGpvc2Ugd29ya2lu ZyBncm91cCBwYXJ0aWNpcGFudHMgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIG9wZW4gaXNzdWUgcmVs YXRlZCB0byBoZWFkZXIgY3JpdGljYWxpdHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBwcm9wb3Nl ZCByZXNvbHV0aW9ucyBmcm9tIHRoZSBtZWV0aW5nLiBQb2ludCA1IG9mIHRoZSBwcm9wb3NlZCBy ZXNvbHV0aW9uIGJlbG93IGlzIGFjdHVhbGx5DQogaW5kZXBlbmRlbnQgb2YgdGhlIG90aGVyIDQg cG9pbnRzLCBhbmQgY291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5LiBUaGlzIHdpbGwgYWxs IGJlIGRpc2N1c3NlZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLjxzcGFuPiZuYnNwOzwvc3Bhbj48 YnI+DQo8YnI+DQpJbiBhZGRpdGlvbiB0byB0aGUgdGV4dCBiZWxvdywgdGhlcmUgd2FzIHNvbWUg YWdyZWVtZW50IHRvIHJlcGxhY2UgdGhlICZxdW90O3VuZGVyc3RhbmQmcXVvdDsgdGV4dCB3aXRo IHNvbWV0aGluZyBhIGJpdCBtb3JlIGV4cGxpY2l0IGxpa2UgJnF1b3Q7bXVzdCBwcm9jZXNzJnF1 b3Q7LiBIb3dldmVyLCB0aGF0IHRleHQgaGFzIG5vdCBiZWVuIHJvbGxlZCBpbnRvIHRoZSBzdW1t YXJ5IHRleHQgYmVsb3cgeWV0LjxzcGFuPiZuYnNwOzwvc3Bhbj48YnI+DQo8YnI+DQpUaGFuayB5 b3UgdG8gSmltIFNjaGFhZCwgTWlrZSBKb25lcywgSm9obiBCcmFkbGV5LCBOYXQgU2FraW11cmEs IE1hcnRpbiBUaG9tYXMsIEVyaWMgUmVzY29ybGEsIE1hdHQgTWlsbGVyLCBhbmQgUmljaGFyZCBC YXJuZXMgZm9yIHlvdXIgZWZmb3J0cyAoYW5kIG15IGFwb2xvZ2llcyBpZiBJIG1pc3NlZCBzb21l b25lKS48c3Bhbj4mbmJzcDs8L3NwYW4+PGJyPg0KPGJyPg0KUmVnYXJkcyw8c3Bhbj4mbmJzcDs8 L3NwYW4+PGJyPg0KS2FyZW48YnI+DQo8YnI+DQoxOiZuYnNwOyBDaGFuZ2UgdGhlIGxhbmd1YWdl IOKAnEFkZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUgSldLLiAmbmJzcDtJ ZiBwcmVzZW50LCB0aGV5IE1VU1QgYmUgdW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgdXNp bmcgdGhlbS7igJ0gdG8g4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBiZSBwcmVzZW50IGluIHRo ZSBKV0suICZuYnNwO0lmIG5vdCB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyBlbmNvdW50 ZXJpbmcgdGhlbSwgdGhleSBNVVNUDQogYmUgaWdub3JlZC7igJ0mbmJzcDsgKEFuZCBtYWtlIHRo ZSBzYW1lIGNoYW5nZSBmb3IgSldLIFNldCBhcyB3ZWxsLik8YnI+DQo8YnI+DQoyOiZuYnNwOyBD aGFyYWN0ZXJpemUgYWxsIGV4aXN0aW5nIEpXUyBhbmQgSldFIGhlYWRlciBmaWVsZHMgYXMgZWl0 aGVyIG11c3QgYmUgdW5kZXJzdG9vZCBvciBtYXkgYmUgaWdub3JlZC4mbmJzcDsg4oCcYWxn4oCd LCDigJxlbmPigJ0sIGFuZCDigJx6aXDigJ0gbXVzdCBiZSB1bmRlcnN0b29kLiZuYnNwOyDigJxr aWTigJ0sIOKAnHg1deKAnSwg4oCceDVj4oCdLCDigJx4NXTigJ0sIOKAnGp3a+KAnSwg4oCcamt1 4oCdLCDigJx0eXDigJ0sIGFuZCDigJxjdHnigJ0gY2FuIGJlIGlnbm9yZWQgYmVjYXVzZSB3aGls ZSBub3QgdXNpbmcgdGhlbSBtYXkNCiByZXN1bHQgaW4gdGhlIGluYWJpbGl0eSB0byBwcm9jZXNz IHNvbWUgc2lnbmF0dXJlcyBvciBlbmNyeXB0ZWQgY29udGVudCwgdGhpcyB3aWxsIG5vdCByZXN1 bHQgaW4gYSBzZWN1cml0eSB2aW9sYXRpb24g4oCTIGp1c3QgZGVncmFkZWQgZnVuY3Rpb25hbGl0 eS4mbmJzcDsgT3RoZXIgZmllbGRzIHN1Y2ggYXMg4oCcZXBr4oCdLCDigJxhcHXigJ0sIOKAnGFw duKAnSwg4oCcZXB14oCdLCBhbmQg4oCcZXB24oCdIG11c3QgYmUgdW5kZXJzdG9vZCBhbmQgdXNl ZCB3aGVuIOKAnGFsZ+KAnSBvciDigJxlbmPigJ0NCiB2YWx1ZXMgcmVxdWlyaW5nIHRoZW0gYXJl IHVzZWQsIGFuZCBvdGhlcndpc2UgdGhleSBtYXkgYmUgaWdub3JlZC48YnI+DQo8YnI+DQozLiZu YnNwOyBEZWZpbmUgYSBuZXcgaGVhZGVyIGZpZWxkIHRoYXQgbGlzdHMgd2hpY2ggYWRkaXRpb25h bCBmaWVsZHMgbm90IGRlZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMgbXVzdCBiZSB1 bmRlcnN0b29kIGFuZCBhY3RlZCB1cG9uIHdoZW4gcHJlc2VudC4mbmJzcDsgRm9yIGluc3RhbmNl LCBhbiBleHBpcmF0aW9uLXRpbWUgZXh0ZW5zaW9uIGZpZWxkIGNvdWxkIGJlIG1hcmtlZCBhcyBt dXN0LWJlLXVuZGVyc3Rvb2QtYW5kLWFjdGVkLXVwb24uJm5ic3A7DQogT25lIHBvc3NpYmxlIG5h bWUgZm9yIHRoaXMgd291bGQgYmUg4oCcY3JpdOKAnSAoY3JpdGljYWwpLiZuYnNwOyBBbiBleGFt cGxlIHVzZSwgYWxvbmcgd2l0aCBhIGh5cG90aGV0aWNhbCDigJxleHDigJ0gKGV4cGlyYXRpb24t dGltZSkgZmllbGQgaXM6PGJyPg0KPGJyPg0KJm5ic3A7IHsmcXVvdDthbGcmcXVvdDs6JnF1b3Q7 RVMyNTYmcXVvdDssPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O2NyaXQmcXVvdDs6WyZxdW90O2V4 cCZxdW90O10sPGJyPg0KJm5ic3A7Jm5ic3A7ICZxdW90O2V4cOKAnToxMzYzMjg0MDAwPGJyPg0K Jm5ic3A7IH08YnI+DQo8YnI+DQo0LiZuYnNwOyBBbGwgYWRkaXRpb25hbCBoZWFkZXIgZmllbGRz IG5vdCBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zIGFuZCBub3QgY29udGFpbmVk IGluIHRoZSDigJxjcml04oCdIGxpc3QgTVVTVCBiZSBpZ25vcmVkIGlmIG5vdCB1bmRlcnN0b29k Ljxicj4NCjxicj4NCjUuJm5ic3A7IERlZmluZSBhIG5ldyBoZWFkZXIgZmllbGQg4oCcYXNk4oCd IChhcHBsaWNhdGlvbi1zcGVjaWZpYyBkYXRhKSB3aG9zZSB2YWx1ZSBpcyBhIEpTT04gc3RydWN0 dXJlIHdob3NlIGNvbnRlbnRzIGFyZSBvcGFxdWUgdG8gYW5kIGlnbm9yZWQgYnkgSldTIGFuZCBK V0UgaW1wbGVtZW50YXRpb25zIGJ1dCBmb3Igd2hpY2ggaXRzIGNvbnRlbnRzIE1VU1QgYmUgcHJv dmlkZWQgdG8gYXBwbGljYXRpb25zIHVzaW5nIEpXUyBvciBKV0UsIHByb3ZpZGVkIHRoYXQNCiB0 aGUgc2lnbmF0dXJlL01BQyB2YWxpZGF0aW9uIG9yIGRlY3J5cHRpb24gb3BlcmF0aW9uIHN1Y2Nl ZWRzLiZuYnNwOyBUaGUgaW50ZW5kZWQgdXNlIG9mIHRoaXMgZmllbGQgaXMgdG8gaGF2ZSBhIHN0 YW5kYXJkIHBsYWNlIHRvIHByb3ZpZGUgYXBwbGljYXRpb24tc3BlY2lmaWMgbWV0YWRhdGEgYWJv dXQgdGhlIHBheWxvYWQgb3IgcGxhaW50ZXh0Ljx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTogJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjx1PjwvdT4mbmJzcDs8 dT48L3U+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZv bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7IGZvbnQtc2l6ZTog MTJwdDsiPg0KPHU+PC91PiZuYnNwOzx1PjwvdT48L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250LWZhbWlseTogJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOyBmb250LXNpemU6IDEycHQ7Ij4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kam9zZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9u OiB1bmRlcmxpbmU7IiBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwv YT48YnI+DQo8YSBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiPmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1p bHk6ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZjsgZm9udC1zaXplOiAxMnB0OyI+ DQo8dT48L3U+Jm5ic3A7PHU+PC91PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vam9zZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPC9hPjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmci Pmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2pvc2U8L2E+PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B1680429673943674F918BTK5EX14MBXC283r_-- From bcampbell@pingidentity.com Tue Mar 12 06:08:10 2013 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 5E5C121F8A80 for ; Tue, 12 Mar 2013 06:08:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.538 X-Spam-Level: X-Spam-Status: No, score=-6.538 tagged_above=-999 required=5 tests=[AWL=1.438, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 J1-gthBAc9gc for ; Tue, 12 Mar 2013 06:08:09 -0700 (PDT) Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 00C2821F8A2A for ; Tue, 12 Mar 2013 06:08:08 -0700 (PDT) Received: from mail-ob0-f197.google.com ([209.85.214.197]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKUT8ouDAg6oHz9H/uhZ11BqkpCnrehcho@postini.com; Tue, 12 Mar 2013 06:08:09 PDT Received: by mail-ob0-f197.google.com with SMTP id ta14so23185255obb.4 for ; Tue, 12 Mar 2013 06:08:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=jWXUY+MgsrkEaLF+m8OK+qmWDLi85bbpqdYsihZ58hM=; b=IQA7l0OXuPDuhrRVeaudaj+IvSApHkDLPji44EnDG1SV3Q1+53YwvvWN0EhuuxJlM7 jFtg8PZn8tVOoqhZZ3IWAV4LgJ5vlY8EwkIS3i7tiAKb783TzBlyby9V7ztGn3I0cga0 LfU60N7Zuxzw23JoK+BquulE2p5FDlYRoPYaBjTleJ68b2DdcqpuwdYsVPsAje2GwpMo WZ5mU3fhfyHv4fgQPS43YbXxPO7q6fTUdM0XKqa2bqWAHoQ6sQ+iyVebc0/CrQVXED+Q u9oesfpBj/ROpaOiGST18KIOyB0m1f6ZdJDEr/FRPVwRJ+QNJyR06Akc4abgx9MmZgEl xR7w== X-Received: by 10.50.37.236 with SMTP id b12mr11512730igk.42.1363093685232; Tue, 12 Mar 2013 06:08:05 -0700 (PDT) X-Received: by 10.50.37.236 with SMTP id b12mr11512716igk.42.1363093685088; Tue, 12 Mar 2013 06:08:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 12 Mar 2013 06:07:34 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F8E97@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674F8E97@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Tue, 12 Mar 2013 09:07:34 -0400 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=f46d044788d9e5502c04d7b9faf3 X-Gm-Message-State: ALoCoQnvdRv8MUCHOOB1EvayhRNDF1rA4SSOwOBK++/hQ4PtXm+0hMFcpudpasgQ518PKNV8CJoHiN3vc7nfo+aag4dlAcU1TpG+j9/6MEkMxs2XSWhacBFVC6gxA1rkfdn0RXCh00gH Cc: James H Manger , "jose@ietf.org" , "vladimir@nimbusds.com" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:08:10 -0000 --f46d044788d9e5502c04d7b9faf3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable "!" is the nicest color for this particular bike-shed that has been proposed thus far. On Tue, Mar 12, 2013 at 9:03 AM, Mike Jones wr= ote: > I kind of like the =93!=94 suggestion. James is right - I didn=92t choo= se the > name =93crt=94 becase it means =93certificate=94 to too many people. > > Cheers, > -- Mike > > *From:* Manger, James H > *Sent:* March 12, 2013 5:18 AM > *To:* vladimir@nimbusds.com, jose@ietf.org > > *Subject:* Re: [jose] Proposed resolution of header criticality issue > > Nah, "crt" sounds too much like a certificate. *.crt is a common file > extension for certs. > > How about "!" ? > > -- > James Manger > > ----- Reply message ----- > From: "Vladimir Dzhuvinov / NimbusDS" > Date: Tue, Mar 12, 2013 5:45 pm > Subject: [jose] Proposed resolution of header criticality issue > To: "jose@ietf.org" > > How about "crt" instead of "crit", to fit the three-letter convention > for naming fields? > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : > vladimir@nimbusds.com > > > -------- Original Message -------- > Subject: [jose] Proposed resolution of header criticality issue > From: Karen O'Donoghue > Date: Tue, March 12, 2013 12:31 am > To: jose@ietf.org > > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the > meeting. Point 5 of the proposed resolution below is actually > independent of the other 4 points, and could be considered separately. > This will all be discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must > process". However, that text has not been rolled into the summary text > below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the > JWK. If present, they MUST be understood by implementations using > them.=94 to =93Additional members MAY be present in the JWK. If not > understood by implementations encountering them, they MUST be > ignored.=94 (And make the same change for JWK Set as well.) > > 2: Characterize all existing JWS and JWE header fields as either must > be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 > must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, > =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because > while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as > =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be > understood and used when =93alg=94 or =93enc=94 values requiring them > are used, and otherwise they may be ignored. > > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon > when present. For instance, an expiration-time extension field could be > marked as must-be-understood-and-acted-upon. One possible name for this > would be =93crit=94 (critical). An example use, along with a > hypothetical =93exp=94 (expiration-time) field is: > > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } > > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not > understood. > > 5. Define a new header field =93asd=94 (application-specific data) > whose value is a JSON structure whose contents are opaque to and ignored > by JWS and JWE implementations but for which its contents MUST be > provided to applications using JWS or JWE, provided that the > signature/MAC validation or decryption operation succeeds. The intended > use of this field is to have a standard place to provide > application-specific metadata about the payload or plaintext. > > > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d044788d9e5502c04d7b9faf3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
"!" is the nicest color for this particular bike= -shed that has been proposed thus far.
=

On Tue, Mar 12, 2013 at 9:03 AM, Mike Jo= nes <Michael.Jones@microsoft.com> wrote:
I kind of like the=A0=93!=94 suggestion.=A0 James is right - I didn=92= t choose the name=A0=93crt=94 becase it means=A0=93certificate=94 to too ma= ny people.
=A0
Cheers,
-- Mike
=A0
From:=A0Manger, James H
Sent:=A0March 12, 2013 5:18 AM
To:=A0vladimir@nimbusds.com, jose@ietf.org

Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
Nah, "crt" sounds too much like a certificate. *.crt is a common = file extension for certs.

How about "!" ?

--
James Manger

----- Reply message -----
From: "Vladimir Dzhuvinov / NimbusDS" <vladimir@nimbusds.com>
Date: Tue, Mar 12, 2013 5:45 pm
Subject: [jose] Proposed resolution of header criticality issue
To: "jose@ietf.org<= /a>" <jose@ietf.= org>

How about "crt" instead of "crit", to fit the three-let= ter convention
for naming fields?

Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com<http://www.NimbusDS.com> : vladimir@nimbusds.com


-------- Original Message --------
Subject: [jose] Proposed resolution of header criticality issue
From: Karen O'Donoghue <odonoghue@isoc.org>
Date: Tue, March 12, 2013 12:31 am
To: jose@ietf.org

=A0Folks,

=A0A side meeting was held Sunday with a number of jose working group
participants to try to resolve the open issue related to header
criticality. The following are the proposed resolutions from the
meeting. Point 5 of the proposed resolution below is actually
independent of the other 4 points, and could be considered separately.
This will all be discussed in Wednesday's meeting.

=A0In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "m= ust
process". However, that text has not been rolled into the summary text=
below yet.

=A0Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin<= br> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts
(and my apologies if I missed someone).

=A0Regards,
=A0Karen

=A01:=A0 Change the language =93Additional members MAY be present in the JWK.=A0 If present, they MUST be understood by implementations using
them.=94 to =93Additional members MAY be present in the JWK.=A0 If not
understood by implementations encountering them, they MUST be
ignored.=94=A0 (And make the same change for JWK Set as well.)

=A02:=A0 Characterize all existing JWS and JWE header fields as either must=
be understood or may be ignored.=A0 =93alg=94, =93enc=94, and =93zip=94
must be understood.=A0 =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94,
=93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because
while not using them may result in the inability to process some
signatures or encrypted content, this will not result in a security
violation =96 just degraded functionality.=A0 Other fields such as
=93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be
understood and used when =93alg=94 or =93enc=94 values requiring them
are used, and otherwise they may be ignored.

=A03.=A0 Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon
when present.=A0 For instance, an expiration-time extension field could be<= br> marked as must-be-understood-and-acted-upon.=A0 One possible name for this<= br> would be =93crit=94 (critical).=A0 An example use, along with a
hypothetical =93exp=94 (expiration-time) field is:

=A0=A0 {"alg":"ES256",
=A0=A0=A0 "crit":["exp"],
=A0=A0=A0 "exp=94:1363284000
=A0=A0 }

=A04.=A0 All additional header fields not defined in the base specification= s
and not contained in the =93crit=94 list MUST be ignored if not
understood.

=A05.=A0 Define a new header field =93asd=94 (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be
provided to applications using JWS or JWE, provided that the
signature/MAC validation or decryption operation succeeds.=A0 The intended<= br> use of this field is to have a standard place to provide
application-specific metadata about the payload or plaintext.






=A0_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d044788d9e5502c04d7b9faf3-- From ve7jtb@ve7jtb.com Tue Mar 12 06:14:44 2013 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 8E18821F85ED for ; Tue, 12 Mar 2013 06:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=-0.698, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 2f42nroHd+QJ for ; Tue, 12 Mar 2013 06:14:43 -0700 (PDT) Received: from mail-gh0-f173.google.com (mail-gh0-f173.google.com [209.85.160.173]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC2821F8525 for ; Tue, 12 Mar 2013 06:14:42 -0700 (PDT) Received: by mail-gh0-f173.google.com with SMTP id g2so788971ghb.32 for ; Tue, 12 Mar 2013 06:14:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=DlHWT9ZERp6SqIHNOmE/lGDSC3crAw+3hjx+wfBo9cI=; b=fY5x9UQY/e19+Q63m5NQU8yqiXr1xvwnsaNztcBe42fjwWU7NoNwGH4A2Mv7fR0TIR z02wUmNvAyY33rVes4myuJ07C9hNZUXT/6rp8eyYcU1wBNwMAWW+dGsIXLg3JoEENWoi Kk8NUR9oAezU95xvTaDqe/pljJvHIDG3zMD+zurBjlbzTJ1wtetGyPkKbK0r7TKRZ3Xv 6JdMqReUMMNcoyfBsg/QEyjJdea+fWZ7LuguhHTsAirTGryEaHK3Y3sFsjkJrAzJ4qU6 a8UiocfxkciDoechBjtjjFf5vbLoOc2gDFCKlxobTKgHFtaeWAWs4SYadSH8iVet1+aC E/XA== X-Received: by 10.236.116.67 with SMTP id f43mr8927257yhh.3.1363094082013; Tue, 12 Mar 2013 06:14:42 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id e8sm29452069yhh.16.2013.03.12.06.14.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 06:14:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1B1334B4-16AC-4284-A8B7-773CF480C1C9"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 09:14:36 -0400 Message-Id: <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmaa/wxzZA0zK2XlYl/9/i0pDt98Rb5iybQ+4JK18zkSYIVnvkbWjHryN5ccokzD/XzMM0D Cc: Richard Barnes , James H Manger , Tim Bray , jose , Karen O'Donoghue Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:14:44 -0000 --Apple-Mail=_1B1334B4-16AC-4284-A8B7-773CF480C1C9 Content-Type: multipart/alternative; boundary="Apple-Mail=_B1906FCB-A48B-4C33-B09D-1C1F9EAE1305" --Apple-Mail=_B1906FCB-A48B-4C33-B09D-1C1F9EAE1305 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am OK with getting rid of it if we make it clear that claims from the = envelope will not be passed on to applications. If we don't do that we will compromise interoperability between = libraries. Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body = in some way. I just want it one way or the other. John B. On 2013-03-12, at 9:06 AM, Mike Jones = wrote: > I=E2=80=99m with Richard on this. The application-specific-data/meta = field isn=E2=80=99t needed. > =20 > -- Mike > =20 > From: Richard Barnes > Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E11=E2=80=8E, =E2=80=8E2013 = =E2=80=8E10=E2=80=8E:=E2=80=8E02=E2=80=8E =E2=80=8EPM > To: John Bradley > CC: Tim Bray, Manger, James H, Karen ODonoghue, jose > Subject: Re: [jose] Proposed resolution of header criticality issue > =20 > +1 to cheers. I already high-fived Mike in person. >=20 > FWIW, my preference would be to get rid of "asd" or "meta" (part 5). = I don't think it's relevant to the criticality discussion, and it's just = not needed. =20 >=20 > --Richard >=20 >=20 >=20 > On Mon, Mar 11, 2013 at 11:01 PM, John Bradley = wrote: >=20 > On 2013-03-11, at 10:48 PM, "Manger, James H" = wrote: >=20 > I=E2=80=99ll add some cheers =E2=80=94 this does look like substantial = progress. > =20 > I assume the fields such as =E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2=80=9D= etc that sometimes must be understood, and at other times must be = ignored (depending on =E2=80=9Calg=E2=80=9D or =E2=80=9Cenc=E2=80=9D = value) would NOT be listed in the =E2=80=9Ccrit=E2=80=9D field as they = are defined in the =E2=80=9Cbase specs=E2=80=9D. > =20 > Correct >=20 > Being in the =E2=80=9Cbase specs=E2=80=9D is the right criteria for = whether a field should be listed in =E2=80=9Ccrit=E2=80=9D as long as = =E2=80=9Cbase specs=E2=80=9D means: =E2=80=9Cbase specifications for the = particular =E2=80=9Calg=E2=80=9D/=E2=80=9Denc=E2=80=9D values=E2=80=9D. = It shouldn=E2=80=99t mean (and doesn=E2=80=99t have to mean) the base = spec for the whole JOSE system. > =20 >=20 > Crit is only for extensions, it is up to the extension definition to = decide if the field needs to be in crit. >=20 >=20 > P.S. =E2=80=9Cmeta=E2=80=9D might be a nicer label than =E2=80=9Casd=E2=80= =9D. >=20 > I don't have any particular attachment to the name. Some places = things like this are called associated data, though not the places = normal people go I grant you. =20 > Meta-data about the payload is what it is, The current practice is to = use three character names. I am fine with met or meta (I suspect that = if you are throwing crap into the envelope the single character won't = kill anyone. >=20 > James if you like the solution and want it to be meta I will back you = on it :) >=20 > John B. >=20 > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Tim Bray > Sent: Tuesday, 12 March 2013 12:43 PM > To: Karen ODonoghue > Cc: jose > Subject: Re: [jose] Proposed resolution of header criticality issue > =20 > Cue wild cheers from the peanut gallery where non-cryptographers sit. = MustIgnore is infinitely more robust and open-ended than MustUnderstand. = -T > =20 >=20 > On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue = wrote: >=20 > Folks, >=20 > A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting.=20 >=20 > In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet.=20 >=20 > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, = Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your = efforts (and my apologies if I missed someone).=20 >=20 > Regards,=20 > Karen >=20 > 1: Change the language =E2=80=9CAdditional members MAY be present in = the JWK. If present, they MUST be understood by implementations using = them.=E2=80=9D to =E2=80=9CAdditional members MAY be present in the JWK. = If not understood by implementations encountering them, they MUST be = ignored.=E2=80=9D (And make the same change for JWK Set as well.) >=20 > 2: Characterize all existing JWS and JWE header fields as either must = be understood or may be ignored. =E2=80=9Calg=E2=80=9D, =E2=80=9Cenc=E2=80= =9D, and =E2=80=9Czip=E2=80=9D must be understood. =E2=80=9Ckid=E2=80=9D,= =E2=80=9Cx5u=E2=80=9D, =E2=80=9Cx5c=E2=80=9D, =E2=80=9Cx5t=E2=80=9D, = =E2=80=9Cjwk=E2=80=9D, =E2=80=9Cjku=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, and = =E2=80=9Ccty=E2=80=9D can be ignored because while not using them may = result in the inability to process some signatures or encrypted content, = this will not result in a security violation =E2=80=93 just degraded = functionality. Other fields such as =E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2= =80=9D, =E2=80=9Capv=E2=80=9D, =E2=80=9Cepu=E2=80=9D, and =E2=80=9Cepv=E2=80= =9D must be understood and used when =E2=80=9Calg=E2=80=9D or =E2=80=9Cenc= =E2=80=9D values requiring them are used, and otherwise they may be = ignored. >=20 > 3. Define a new header field that lists which additional fields not = defined in the base specifications must be understood and acted upon = when present. For instance, an expiration-time extension field could be = marked as must-be-understood-and-acted-upon. One possible name for this = would be =E2=80=9Ccrit=E2=80=9D (critical). An example use, along with = a hypothetical =E2=80=9Cexp=E2=80=9D (expiration-time) field is: >=20 > {"alg":"ES256", > "crit":["exp"], > "exp=E2=80=9D:1363284000 > } >=20 > 4. All additional header fields not defined in the base = specifications and not contained in the =E2=80=9Ccrit=E2=80=9D list MUST = be ignored if not understood. >=20 > 5. Define a new header field =E2=80=9Casd=E2=80=9D = (application-specific data) whose value is a JSON structure whose = contents are opaque to and ignored by JWS and JWE implementations but = for which its contents MUST be provided to applications using JWS or = JWE, provided that the signature/MAC validation or decryption operation = succeeds. The intended use of this field is to have a standard place to = provide application-specific metadata about the payload or plaintext. >=20 > =20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 --Apple-Mail=_B1906FCB-A48B-4C33-B09D-1C1F9EAE1305 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I am = OK with getting rid of it if we make it clear that claims from the = envelope will not be passed on to applications.

If we = don't do that we will compromise interoperability between libraries. =   Envelope is for JOSE only and not made available, that makes = things like timestamps and other things that the application layer needs = to interpret can't go in the envelope they need to be in the body in = some way.

I just want it one way or the = other.

John = B.


On 2013-03-12, at 9:06 AM, = Mike Jones <Michael.Jones@microsoft.com> wrote:

I=E2=80=99m with Richard on this.  = The application-specific-data/meta field isn=E2=80=99t = needed.
 
-- Mike
 
From: Richard Barnes
Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E11=E2=80=8E, = =E2=80=8E2013 =E2=80=8E10=E2=80=8E:=E2=80=8E02=E2=80=8E =E2=80=8EPM
To: John Bradley
CC: Tim Bray, Manger, James H, Karen ODonoghue, = jose
Subject: Re: [jose] Proposed resolution of header = criticality issue
 
+1 to cheers.  I already high-fived Mike in person.

FWIW, my preference would be to get rid of "asd" or "meta" (part = 5).  I don't think it's relevant to the criticality discussion, and = it's just not needed.  

--Richard



On Mon, Mar 11, 2013 at 11:01 PM, John = Bradley <ve7jtb@ve7jtb.com> = wrote:

On 2013-03-11, at 10:48 PM, "Manger, James H" <James.H.Manger@team.telstr= a.com> wrote:

I=E2=80=99ll add some cheers =E2=80=94 this does look = like substantial progress.
 
I assume the fields such as =E2=80=9Cepk=E2=80=9D, = =E2=80=9Capu=E2=80=9D etc that sometimes must be understood, and at = other times must be ignored (depending on =E2=80=9Calg=E2=80=9D or = =E2=80=9Cenc=E2=80=9D value) would NOT be listed in the =E2=80=9Ccrit=E2=80=9D field as they are defined in the =E2=80=9Cb= ase specs=E2=80=9D.
 
Correct

Being in the =E2=80=9Cbase specs=E2=80=9D is the right = criteria for whether a field should be listed in =E2=80=9Ccrit=E2=80=9D = as long as =E2=80=9Cbase specs=E2=80=9D means: =E2=80=9Cbase = specifications for the particular =E2=80=9Calg=E2=80=9D/=E2=80=9Denc=E2=80= =9D values=E2=80=9D. It shouldn=E2=80=99t mean (and doesn=E2=80=99t have to = mean) the base spec for the whole JOSE = system.
 

Crit is only for extensions, it is up to the extension definition to = decide if the field needs to be in crit.


P.S. =E2=80=9Cmeta=E2=80=9D might be a nicer label = than =E2=80=9Casd=E2=80=9D.

I don't have any particular attachment to the name.   Some places = things like this are called associated data, though not the places = normal people go I grant you.  
Meta-data about the payload is what it is,  The current = practice is to use three character names.   I am fine with met or = meta (I suspect that if you are throwing crap into the envelope the = single character won't kill anyone.

James if you like the solution and want it to be meta I will back = you on it :)

John B.

 
--
James Manger
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] <= b>On Behalf Of Tim Bray
Sent: Tuesday, 12 March 2013 12:43 PM
To: Karen ODonoghue
Cc: jose
Subject: Re: [jose] Proposed resolution of = header criticality issue
 
Cue wild cheers from the peanut gallery where non-cryptographers = sit.  MustIgnore is infinitely more robust and open-ended than = MustUnderstand.  -T

 

On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <odonoghue@isoc.org> = wrote:

Folks,


A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's = meeting. 

In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet. 

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin = Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts = (and my apologies if I missed someone). 

Regards, 
Karen

1:  Change the language =E2=80=9CAdditional members MAY be present = in the JWK.  If present, they MUST be understood by implementations = using them.=E2=80=9D to =E2=80=9CAdditional members MAY be present in = the JWK.  If not understood by implementations encountering them, = they MUST be ignored.=E2=80=9D  (And make the same change for JWK Set as = well.)

2:  Characterize all existing JWS and JWE header fields as either = must be understood or may be ignored.  =E2=80=9Calg=E2=80=9D, = =E2=80=9Cenc=E2=80=9D, and =E2=80=9Czip=E2=80=9D must be = understood.  =E2=80=9Ckid=E2=80=9D, =E2=80=9Cx5u=E2=80=9D, = =E2=80=9Cx5c=E2=80=9D, =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cjwk=E2=80=9D, = =E2=80=9Cjku=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, and =E2=80=9Ccty=E2=80=9D = can be ignored because while not using them may result in the inability to process some signatures or encrypted = content, this will not result in a security violation =E2=80=93 just = degraded functionality.  Other fields such as =E2=80=9Cepk=E2=80=9D, = =E2=80=9Capu=E2=80=9D, =E2=80=9Capv=E2=80=9D, =E2=80=9Cepu=E2=80=9D, and = =E2=80=9Cepv=E2=80=9D must be understood and used when =E2=80=9Calg=E2=80=9D= or =E2=80=9Cenc=E2=80=9D values requiring them are used, and otherwise they may be ignored.

3.  Define a new header field that lists which additional fields = not defined in the base specifications must be understood and acted upon = when present.  For instance, an expiration-time extension field = could be marked as must-be-understood-and-acted-upon.  One possible name for this would be =E2=80=9Ccrit=E2=80=9D = (critical).  An example use, along with a hypothetical =E2=80=9Cexp=E2= =80=9D (expiration-time) field is:

  {"alg":"ES256",
   "crit":["exp"],
   "exp=E2=80=9D:1363284000
  }

4.  All additional header fields not defined in the base = specifications and not contained in the =E2=80=9Ccrit=E2=80=9D list MUST = be ignored if not understood.

5.  Define a new header field =E2=80=9Casd=E2=80=9D = (application-specific data) whose value is a JSON structure whose = contents are opaque to and ignored by JWS and JWE implementations but = for which its contents MUST be provided to applications using JWS or = JWE, provided that the signature/MAC validation or decryption operation succeeds.  = The intended use of this field is to have a standard place to provide = application-specific metadata about the payload or = plaintext.

 
 


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose

 
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/m= ailman/listinfo/jose



= --Apple-Mail=_B1906FCB-A48B-4C33-B09D-1C1F9EAE1305-- --Apple-Mail=_1B1334B4-16AC-4284-A8B7-773CF480C1C9 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMTMxNDM3WjAjBgkqhkiG9w0BCQQxFgQUNfEW6i+w YVx8bX6/6sX1AFE4ksMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAKxCh93soyukc+VHn68XHbeTvPp/pgHxoePZJ9S2M DlhXs+f/mQK5Vy6nJsSqNnhke8PHvrUpImT9QbrFBYrvqiytRhmU2/b2R3pHCP+Zk2DWYdPmX3/6 P6IEMAYHdfIemBG/oddPwJJxM/NWjM5/Wlskw9vAXZUfAyQNUTW7v/XJsIe6rVvHtBKPfE0Voz2J wtSeS8m+mWVjBkn3ich+CZ66k7I7m/d6/zm2wI3ldMmL6GKH87OPFII4nbZYlxEYQHW1tySOrZp8 9Jcy8gihnMqYEg8X+GcT26wr589SgmOEcBI1IDxNJtqEk9lJzevRSLzgcFq44GBYq0Dx1qX6IwAA AAAAAA== --Apple-Mail=_1B1334B4-16AC-4284-A8B7-773CF480C1C9-- From rlb@ipv.sx Tue Mar 12 06:15:55 2013 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 926B321F896D for ; Tue, 12 Mar 2013 06:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=1.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, 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 6Q6DRrpuswtS for ; Tue, 12 Mar 2013 06:15:53 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 32B8621F87EE for ; Tue, 12 Mar 2013 06:15:53 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so5598511oag.39 for ; Tue, 12 Mar 2013 06:15:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=vAvEMlbepknG5xxQ9brLtQkugpUNswh+EAPNO4mxiY8=; b=VJXY0puwHBfu/Ks7UCrpEa5KyuHj5KyPsR6AqcxZ8192k+t+jicx4ji3dXkivFIfl/ xxSHqSkluLL3z/20FAKBHD+YH/C8PzJzMQNEbUVgvS7nXIgQcvHmZsUTO9jtlBfCHVlj JPbISGb0pxwiXKIAyUSmOTT+FW/pxfqfJbE6dVzrkEw9s8mYPYVyy4k8HZGb8u3FlOcU undZISYaG2r/s+fuCATF6pzC94h1Am+FIkxg0dAw5ZC3RsBSdqfBaXBRJbvQNqYnE8U0 0ceCfr1LbsukznIn+nn2BN4g3d/gvyelvZCvQYHfmO4whpgvhkIq++UBFfEQv6GZsSz+ HU5Q== MIME-Version: 1.0 X-Received: by 10.60.14.71 with SMTP id n7mr11783139oec.135.1363094144821; Tue, 12 Mar 2013 06:15:44 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 06:15:44 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: References: <4E1F6AAD24975D4BA5B1680429673943674F8E97@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 09:15:44 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=e89a8f2353bf4c3f5e04d7ba1654 X-Gm-Message-State: ALoCoQnbwEDEq78HsfYTG1RzyWSGbhtE14EIN6j2MasPqSXobjGtOlW9GL+o32io5bTZG83f1qvG Cc: Mike Jones , James H Manger , "jose@ietf.org" , "vladimir@nimbusds.com" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:15:55 -0000 --e89a8f2353bf4c3f5e04d7ba1654 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, "!" is really developer-hostile. For example, in JS, suppose you do the following: var json =3D '{"foo":1, "!":2}'; var x =3D JSON.parse(json); Then I can access the field in question using one syntax (x["!"]), but not the simpler one (x.foo). I would much rather have something that makes it easy to write code instead of something that minimizes octets. On Tue, Mar 12, 2013 at 9:07 AM, Brian Campbell wrote: > "!" is the nicest color for this particular bike-shed that has been > proposed thus far. > > > On Tue, Mar 12, 2013 at 9:03 AM, Mike Jones = wrote: > >> I kind of like the =93!=94 suggestion. James is right - I didn=92t cho= ose >> the name =93crt=94 becase it means =93certificate=94 to too many people. >> >> Cheers, >> -- Mike >> >> *From:* Manger, James H >> *Sent:* March 12, 2013 5:18 AM >> >> *To:* vladimir@nimbusds.com, jose@ietf.org >> >> *Subject:* Re: [jose] Proposed resolution of header criticality issue >> >> Nah, "crt" sounds too much like a certificate. *.crt is a common file >> extension for certs. >> >> How about "!" ? >> >> -- >> James Manger >> >> ----- Reply message ----- >> From: "Vladimir Dzhuvinov / NimbusDS" >> Date: Tue, Mar 12, 2013 5:45 pm >> Subject: [jose] Proposed resolution of header criticality issue >> To: "jose@ietf.org" >> >> How about "crt" instead of "crit", to fit the three-letter convention >> for naming fields? >> >> Vladimir >> >> -- >> Vladimir Dzhuvinov : www.NimbusDS.com : >> vladimir@nimbusds.com >> >> >> -------- Original Message -------- >> Subject: [jose] Proposed resolution of header criticality issue >> From: Karen O'Donoghue >> Date: Tue, March 12, 2013 12:31 am >> To: jose@ietf.org >> >> >> Folks, >> >> A side meeting was held Sunday with a number of jose working group >> participants to try to resolve the open issue related to header >> criticality. The following are the proposed resolutions from the >> meeting. Point 5 of the proposed resolution below is actually >> independent of the other 4 points, and could be considered separately. >> This will all be discussed in Wednesday's meeting. >> >> In addition to the text below, there was some agreement to replace the >> "understand" text with something a bit more explicit like "must >> process". However, that text has not been rolled into the summary text >> below yet. >> >> Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin >> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts >> (and my apologies if I missed someone). >> >> Regards, >> Karen >> >> 1: Change the language =93Additional members MAY be present in the >> JWK. If present, they MUST be understood by implementations using >> them.=94 to =93Additional members MAY be present in the JWK. If not >> understood by implementations encountering them, they MUST be >> ignored.=94 (And make the same change for JWK Set as well.) >> >> 2: Characterize all existing JWS and JWE header fields as either must >> be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 >> must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, >> =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because >> while not using them may result in the inability to process some >> signatures or encrypted content, this will not result in a security >> violation =96 just degraded functionality. Other fields such as >> =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be >> understood and used when =93alg=94 or =93enc=94 values requiring them >> are used, and otherwise they may be ignored. >> >> 3. Define a new header field that lists which additional fields not >> defined in the base specifications must be understood and acted upon >> when present. For instance, an expiration-time extension field could be >> marked as must-be-understood-and-acted-upon. One possible name for this >> would be =93crit=94 (critical). An example use, along with a >> hypothetical =93exp=94 (expiration-time) field is: >> >> {"alg":"ES256", >> "crit":["exp"], >> "exp=94:1363284000 >> } >> >> 4. All additional header fields not defined in the base specifications >> and not contained in the =93crit=94 list MUST be ignored if not >> understood. >> >> 5. Define a new header field =93asd=94 (application-specific data) >> whose value is a JSON structure whose contents are opaque to and ignored >> by JWS and JWE implementations but for which its contents MUST be >> provided to applications using JWS or JWE, provided that the >> signature/MAC validation or decryption operation succeeds. The intended >> use of this field is to have a standard place to provide >> application-specific metadata about the payload or plaintext. >> >> >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8f2353bf4c3f5e04d7ba1654 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, "!" is really developer-hostile. =A0For example, in JS,= suppose you do the following:

var json =3D '{"= foo":1, "!":2}';
var x =3D JSON.parse(json);

Then I can access the field in question using one synta= x (x["!"]), but not the simpler one (x.foo). =A0

I would much rather have something that makes it easy to write cod= e instead of something that minimizes octets.



On Tue, Mar 12, 2013= at 9:07 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
"!" is the nicest= color for this particular bike-shed that has been proposed thus far.


On Tue, Mar 12, 2013 at 9:03 AM, Mike Jones <Michael.Jones@= microsoft.com> wrote:
I kind of like the=A0=93!=94 suggestion.=A0 James is right - I didn=92= t choose the name=A0=93crt=94 becase it means=A0=93certificate=94 to too ma= ny people.
=A0
Cheers,
-- Mike
=A0
From:=A0Manger, James H
Sent:=A0March 12, 2013 5:18 AM

To:=A0vladimir@nimbusds.com, jose@ietf.org

Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
Nah, "crt" sounds too much like a certificate. *.crt is a common = file extension for certs.

How about "!" ?

--
James Manger

----- Reply message -----
From: "Vladimir Dzhuvinov / NimbusDS" <vladimir@nimbusds.com>
Date: Tue, Mar 12, 2013 5:45 pm
Subject: [jose] Proposed resolution of header criticality issue
To: "jose@ietf.org<= /a>" <jose@ietf.= org>

How about "crt" instead of "crit", to fit the three-let= ter convention
for naming fields?

Vladimir

--
Vladimir Dzhuvinov : = www.NimbusDS.com<http://www.NimbusDS.com> : vladimir@nimbusds.com


-------- Original Message --------
Subject: [jose] Proposed resolution of header criticality issue
From: Karen O'Donoghue <odonoghue@isoc.org>
Date: Tue, March 12, 2013 12:31 am
To: jose@ietf.org

=A0Folks,

=A0A side meeting was held Sunday with a number of jose working group
participants to try to resolve the open issue related to header
criticality. The following are the proposed resolutions from the
meeting. Point 5 of the proposed resolution below is actually
independent of the other 4 points, and could be considered separately.
This will all be discussed in Wednesday's meeting.

=A0In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "m= ust
process". However, that text has not been rolled into the summary text=
below yet.

=A0Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin<= br> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts
(and my apologies if I missed someone).

=A0Regards,
=A0Karen

=A01:=A0 Change the language =93Additional members MAY be present in the JWK.=A0 If present, they MUST be understood by implementations using
them.=94 to =93Additional members MAY be present in the JWK.=A0 If not
understood by implementations encountering them, they MUST be
ignored.=94=A0 (And make the same change for JWK Set as well.)

=A02:=A0 Characterize all existing JWS and JWE header fields as either must=
be understood or may be ignored.=A0 =93alg=94, =93enc=94, and =93zip=94
must be understood.=A0 =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94,
=93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored because
while not using them may result in the inability to process some
signatures or encrypted content, this will not result in a security
violation =96 just degraded functionality.=A0 Other fields such as
=93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be
understood and used when =93alg=94 or =93enc=94 values requiring them
are used, and otherwise they may be ignored.

=A03.=A0 Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon
when present.=A0 For instance, an expiration-time extension field could be<= br> marked as must-be-understood-and-acted-upon.=A0 One possible name for this<= br> would be =93crit=94 (critical).=A0 An example use, along with a
hypothetical =93exp=94 (expiration-time) field is:

=A0=A0 {"alg":"ES256",
=A0=A0=A0 "crit":["exp"],
=A0=A0=A0 "exp=94:1363284000
=A0=A0 }

=A04.=A0 All additional header fields not defined in the base specification= s
and not contained in the =93crit=94 list MUST be ignored if not
understood.

=A05.=A0 Define a new header field =93asd=94 (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be
provided to applications using JWS or JWE, provided that the
signature/MAC validation or decryption operation succeeds.=A0 The intended<= br> use of this field is to have a standard place to provide
application-specific metadata about the payload or plaintext.






=A0_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8f2353bf4c3f5e04d7ba1654-- From rlb@ipv.sx Tue Mar 12 06:25:48 2013 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 831A921F8B13 for ; Tue, 12 Mar 2013 06:25:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.838 X-Spam-Level: X-Spam-Status: No, score=-2.838 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 dN2BpK0ypq6I for ; Tue, 12 Mar 2013 06:25:47 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFF321F8ABD for ; Tue, 12 Mar 2013 06:25:43 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so5681362oag.27 for ; Tue, 12 Mar 2013 06:25:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Orisq1Xj2uWBFpAYbrumpVAuePXkAeWSY6i+TlA5gN4=; b=LpEMzZ34x2Chk2AgBiKJEnvCzk9i/ogRy5WMiWNs4TQO5gX74cS9du22bae+JuTw+/ 0LZvrNcWaFcmtIM8oco/oUg1yqk5P4OStUyYWJVykw2cWTjmxUPh/ibDnuQ+plELl1iN 1c7ahOXLxOa3jwUOXPsyN/BQ0AE7woPVes3pO595hxlTOpOT2pWgHebGfun0SyRu2Rm9 l2IL7ZV1Ejr9crm6izRrtpa/JHhpyPA/EFicxdqrrJNWA8yV+MjgWAl1OtGcDQPeGSch a+hRXbJz+f3dbjS1ZXyeZvwvIPXi4GeKvZHwBprDE/2d9tWuRb/DAj6a6cDCnvqonT8J lJnQ== MIME-Version: 1.0 X-Received: by 10.182.59.20 with SMTP id v20mr12125207obq.80.1363094742704; Tue, 12 Mar 2013 06:25:42 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 06:25:42 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> References: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> Date: Tue, 12 Mar 2013 09:25:42 -0400 Message-ID: From: Richard Barnes To: John Bradley Content-Type: multipart/alternative; boundary=14dae93a0db1ef37e804d7ba3939 X-Gm-Message-State: ALoCoQn87DmD0XOKVTvkHIToHJAhEwbz7/JwFLnEZUOPd6VJstZcrKJsqtJDQhHjyFFTK6rf2eCp Cc: James H Manger , Mike Jones , Tim Bray , jose , Karen O'Donoghue Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:25:48 -0000 --14dae93a0db1ef37e804d7ba3939 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would be fine with some implementation guidance on where to put your application-specific stuff. Suggested text: """ Applications may wish to associate information with a JOSE object, beyond the standard fields in the JOSE header. Applications SHOULD NOT use the JOSE header for application-level information, i.e., fields not directly related to cryptographic processing of the JOSE object. As an alternative, if an application wishes to have information cryptographically bound to a JOSE object, it could encapsulate the application-layer information and the JOSE object together, then apply JWS integrity protection to them. Of course, if the application does not require this cryptographic binding, then it can carry the application-layer information in other application fields alongside the JOSE object. """ It should probably go in both the JWE and JWS specs. Speaking of which, have I suggested recently that we should combine the two? Cause we should. But that's another thread... --Richard On Tue, Mar 12, 2013 at 9:14 AM, John Bradley wrote: > I am OK with getting rid of it if we make it clear that claims from the > envelope will not be passed on to applications. > > If we don't do that we will compromise interoperability between libraries= . > Envelope is for JOSE only and not made available, that makes things lik= e > timestamps and other things that the application layer needs to interpret > can't go in the envelope they need to be in the body in some way. > > I just want it one way or the other. > > John B. > > > On 2013-03-12, at 9:06 AM, Mike Jones wrote= : > > I=92m with Richard on this. The application-specific-data/meta field > isn=92t needed. > > -- Mike > > *From:* Richard Barnes > *Sent:* March 11, 2013 10:02 PM > *To:* John Bradley > *CC:* Tim Bray, Manger, James H, Karen ODonoghue, jose > *Subject:* Re: [jose] Proposed resolution of header criticality issue > > +1 to cheers. I already high-fived Mike in person. > > FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I > don't think it's relevant to the criticality discussion, and it's just no= t > needed. > > --Richard > > > > On Mon, Mar 11, 2013 at 11:01 PM, John Bradley wrote: > >> >> On 2013-03-11, at 10:48 PM, "Manger, James H" < >> James.H.Manger@team.telstra.com> wrote: >> >> I=92ll add some cheers =97 this does look like substantial progress.**= ** >> >> I assume the fields such as =93epk=94, =93apu=94 etc that sometimes mus= t be >> understood, and at other times must be ignored (depending on =93alg=94 o= r =93enc=94 >> value) would NOT be listed in the =93crit=94 field as they are defined i= n the >> =93base specs=94.**** >> >> >> Correct >> >> Being in the =93base specs=94 is the right criteria for whether a fiel= d >> should be listed in =93crit=94 as long as =93base specs=94 means: =93bas= e >> specifications for the particular =93alg=94/=94enc=94 values=94. It shou= ldn=92t mean >> (and doesn=92t have to mean) the base spec for the whole JOSE system.***= * >> >> >> >> Crit is only for extensions, it is up to the extension definition to >> decide if the field needs to be in crit. >> >> >> P.S. =93meta=94 might be a nicer label than =93asd=94. >> >> >> I don't have any particular attachment to the name. Some places >> things like this are called associated data, though not the places norma= l >> people go I grant you. >> Meta-data about the payload is what it is, The current practice is to >> use three character names. I am fine with met or meta (I suspect that = if >> you are throwing crap into the envelope the single character won't kill >> anyone. >> >> James if you like the solution and want it to be meta I will back you >> on it :) >> >> John B. >> >> **** >> >> --**** >> James Manger**** >> >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >> Behalf Of *Tim Bray >> *Sent:* Tuesday, 12 March 2013 12:43 PM >> *To:* Karen ODonoghue >> *Cc:* jose >> *Subject:* Re: [jose] Proposed resolution of header criticality issue***= * >> ** ** >> Cue wild cheers from the peanut gallery where non-cryptographers sit. >> MustIgnore is infinitely more robust and open-ended than MustUnderstand.= -T >> **** >> >> ** ** >> On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue >> wrote:**** >> >> Folks,**** >> >> >> A side meeting was held Sunday with a number of jose working group >> participants to try to resolve the open issue related to header >> criticality. The following are the proposed resolutions from the meeting= . >> Point 5 of the proposed resolution below is actually independent of the >> other 4 points, and could be considered separately. This will all be >> discussed in Wednesday's meeting. >> >> In addition to the text below, there was some agreement to replace the >> "understand" text with something a bit more explicit like "must process"= . >> However, that text has not been rolled into the summary text below yet. >> >> Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin >> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts >> (and my apologies if I missed someone). >> >> Regards, >> Karen >> >> 1: Change the language =93Additional members MAY be present in the JWK. >> If present, they MUST be understood by implementations using them.=94 t= o >> =93Additional members MAY be present in the JWK. If not understood by >> implementations encountering them, they MUST be ignored.=94 (And make t= he >> same change for JWK Set as well.) >> >> 2: Characterize all existing JWS and JWE header fields as either must b= e >> understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 must = be understood. >> =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ= =94, and =93cty=94 can be ignored >> because while not using them may result in the inability to process some >> signatures or encrypted content, this will not result in a security >> violation =96 just degraded functionality. Other fields such as =93epk= =94, >> =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be understood and us= ed when =93alg=94 or >> =93enc=94 values requiring them are used, and otherwise they may be igno= red. >> >> 3. Define a new header field that lists which additional fields not >> defined in the base specifications must be understood and acted upon whe= n >> present. For instance, an expiration-time extension field could be mark= ed >> as must-be-understood-and-acted-upon. One possible name for this would = be >> =93crit=94 (critical). An example use, along with a hypothetical =93exp= =94 >> (expiration-time) field is: >> >> {"alg":"ES256", >> "crit":["exp"], >> "exp=94:1363284000 >> } >> >> 4. All additional header fields not defined in the base specifications >> and not contained in the =93crit=94 list MUST be ignored if not understo= od. >> >> 5. Define a new header field =93asd=94 (application-specific data) whos= e >> value is a JSON structure whose contents are opaque to and ignored by JW= S >> and JWE implementations but for which its contents MUST be provided to >> applications using JWS or JWE, provided that the signature/MAC validatio= n >> or decryption operation succeeds. The intended use of this field is to >> have a standard place to provide application-specific metadata about the >> payload or plaintext.**** >> ** ** >> ** ** >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose**** >> ** ** >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > --14dae93a0db1ef37e804d7ba3939 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would be fine with some implementation guidance on where to put your appl= ication-specific stuff. =A0Suggested text:
"""
Applications may wish to associate information with a JOSE object, beyond = the standard fields in the JOSE header. =A0Applications SHOULD NOT use the = JOSE header for application-level information, i.e., fields not directly re= lated to cryptographic processing of the JOSE object. =A0As an alternative,= if an application wishes to have information cryptographically bound to a = JOSE object, it could encapsulate the application-layer information and the= JOSE object together, then apply JWS integrity protection to them. =A0Of c= ourse, if the application does not require this cryptographic binding, then= it can carry the application-layer information in other application fields= alongside the JOSE object.
"""

It should probably go in b= oth the JWE and JWS specs. =A0Speaking of which, have I suggested recently = that we should combine the two? =A0Cause we should. =A0But that's anoth= er thread...

--Richard



<= div>
On Tue, Mar 12, 2013 at 9:14 AM, John Br= adley <ve7jtb@ve7jtb.com> wrote:
I am OK = with getting rid of it if we make it clear that claims from the envelope wi= ll not be passed on to applications.

If we don't do that we will compromise interoperability = between libraries. =A0 Envelope is for JOSE only and not made available, th= at makes things like timestamps and other things that the application layer= needs to interpret can't go in the envelope they need to be in the bod= y in some way.

I just want it one way or the other.

John B.


On 2013-03-12, at 9:06 AM, Mike Jones <Michael.Jones@microsoft.com> wrote= :

I=92m with Richard on this.=A0 The=A0application-specific-data/meta fi= eld isn=92t needed.
=A0
-- Mike
=A0
From:=A0Richard Barnes
Sent:=A0March 11, 2013 10:02 PM
To:=A0John Bradley
CC:=A0Tim Bray, Manger, James H, Karen ODonoghue, jose
Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
+1 to cheers. =A0I already high-fived Mike in person.

FWIW, my preference would be to get rid of "asd" or "me= ta" (part 5). =A0I don't think it's relevant to the criticalit= y discussion, and it's just not needed. =A0

--Richard



On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <= span dir=3D"ltr"> <ve7jtb@ve7jtb.co= m> wrote:

On 2013-03-11, at 10:48 PM, "Manger, James H" <James.H.Manger@t= eam.telstra.com> wrote:

I=92ll add some cheers =97 this does look like substantial progress= .
=A0
I assume the fields such as =93epk=94, =93apu=94 etc that sometimes= must be understood, and at other times must be ignored (depending on =93al= g=94 or =93enc=94 value) would NOT be listed in the =93crit=94 field as they are defined in the =93base specs=94.
=A0
Correct

Being in the =93base specs=94 is the right criteria for whether a f= ield should be listed in =93crit=94 as long as =93base specs=94 means: =93b= ase specifications for the particular =93alg=94/=94enc=94 values=94. It shouldn=92t mean (and doesn=92t have to mean) the base spec = for the whole JOSE system.
=A0

Crit is only for extensions, it is up to the extension definition to decide= if the field needs to be in crit.


P.S. =93meta=94 might be a nicer label than =93asd=94.

I don't have any particular attachment to the name. =A0 Some places thi= ngs like this are called associated data, though not the places normal peop= le go I grant you. =A0
Meta-data about the payload is what it is, =A0The current practice is = to use three character names. =A0 I am fine with met or meta (I suspect tha= t if you are throwing crap into the envelope the single character won't= kill anyone.

James if you like the solution and want it to be meta I will back you = on it :)

John B.

=A0
--
James Manger
=A0
From:=A0jose-bounces@ietf.org [mailto:jose-bounces@ietf.org]=A0On Behalf Of=A0Tim Bray
Sent:=A0Tuesday, 12 March 2013 12:43 PM
To:=A0Karen ODonoghue
Cc:=A0jose
Subject:=A0Re: [jose] Proposed resolution of header cri= ticality issue
=A0
Cue wild cheers from the peanut gallery where non-cryptographers sit.=A0 Mu= stIgnore is infinitely more robust and open-ended than MustUnderstand.=A0 -= T

=A0

On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <odonoghue@isoc.org> wrote:

Folks,


A side meeting was held Sunday with a number of jose working group particip= ants to try to resolve the open issue related to header criticality. The fo= llowing are the proposed resolutions from the meeting. Point 5 of the propo= sed resolution below is actually independent of the other 4 points, and could be considered separately. Thi= s will all be discussed in Wednesday's meeting.=A0

In addition to the text below, there was some agreement to replace the &quo= t;understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text= below yet.=A0

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Tho= mas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and m= y apologies if I missed someone).=A0

Regards,=A0
Karen

1:=A0 Change the language =93Additional members MAY be present in the JWK. = =A0If present, they MUST be understood by implementations using them.=94 to= =93Additional members MAY be present in the JWK. =A0If not understood by i= mplementations encountering them, they MUST be ignored.=94=A0 (And make the same change for JWK Set as well.)

2:=A0 Characterize all existing JWS and JWE header fields as either must be= understood or may be ignored.=A0 =93alg=94, =93enc=94, and =93zip=94 must = be understood.=A0 =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, = =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not using = them may result in the inability to process some signatures or encrypted content, t= his will not result in a security violation =96 just degraded functionality= .=A0 Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and = =93epv=94 must be understood and used when =93alg=94 or =93enc=94 values requiring them are used, and otherwise they may be ignored.

3.=A0 Define a new header field that lists which additional fields not defi= ned in the base specifications must be understood and acted upon when prese= nt.=A0 For instance, an expiration-time extension field could be marked as = must-be-understood-and-acted-upon.=A0 One possible name for this would be =93crit=94 (critical).=A0 An example u= se, along with a hypothetical =93exp=94 (expiration-time) field is:

=A0 {"alg":"ES256",
=A0=A0 "crit":["exp"],
=A0=A0 "exp=94:1363284000
=A0 }

4.=A0 All additional header fields not defined in the base specifications a= nd not contained in the =93crit=94 list MUST be ignored if not understood.<= br>
5.=A0 Define a new header field =93asd=94 (application-specific data) whose= value is a JSON structure whose contents are opaque to and ignored by JWS = and JWE implementations but for which its contents MUST be provided to appl= ications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.=A0 The inte= nded use of this field is to have a standard place to provide application-s= pecific metadata about the payload or plaintext.

=A0
=A0


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman= /listinfo/jose

=A0
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--14dae93a0db1ef37e804d7ba3939-- From mamille2@cisco.com Tue Mar 12 06:26:11 2013 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 34F7A21F8ABD for ; Tue, 12 Mar 2013 06:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.599 X-Spam-Level: X-Spam-Status: No, score=-11.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, 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 tguMaY+un8ny for ; Tue, 12 Mar 2013 06:26:10 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E504821F8B16 for ; Tue, 12 Mar 2013 06:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10074; q=dns/txt; s=iport; t=1363094770; x=1364304370; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FF/zrR35PvqtBbq26Bbh0lqdEcVX1eV0fvm/MtQ1AhU=; b=Yi9HXDkwU8XtU/PBy9t+pAnlm5kG9HLJ+taWLFbZSaG2TlCGn3L+L1ub mLBFyYKFFiTavMp03BJG0RUARGSz/AhVC/5lN02E5HaAwPPY96m7SxOac Gz+cA7V2rocm6uOPNEr3GBSKefrFWKDnBmmOqevdzHat3OWfeINxklprM o=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAJIrP1GtJV2Y/2dsb2JhbABDxGWBShZ0gigBAQEDAQEBAUYlCwUHBAIBCA4DAwEBAQskAiULHQgBAQQOBQgGiAAGDLAjkAgXjlwGEAoGCwcEAgOCVmEDjzSBKJZwgwqBbCQY X-IronPort-AV: E=Sophos;i="4.84,830,1355097600"; d="p7s'?scan'208";a="183532917" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 12 Mar 2013 13:26:09 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2CDQ9lR013327 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 13:26:09 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 08:26:09 -0500 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4fIfMK3YjC29WFUkSdwgXH1ivMkQAKoV0AAABJBAAAAFz8AA== Date: Tue, 12 Mar 2013 13:26:09 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B1680429673943674F8E97@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.149] Content-Type: multipart/signed; boundary="Apple-Mail=_7A4537C1-061B-4DD1-9A18-00C889EDCE2C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Mike Jones , Brian Campbell , James H Manger , "jose@ietf.org" , "vladimir@nimbusds.com" Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:26:11 -0000 --Apple-Mail=_7A4537C1-061B-4DD1-9A18-00C889EDCE2C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I agree with Richard on the nice-ness test of the property identifier, = which "crit" passes. However, I also just want this bikeshed to be painted. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Mar 12, 2013, at 9:15 AM, Richard Barnes wrote: > Actually, "!" is really developer-hostile. For example, in JS, = suppose you > do the following: >=20 > var json =3D '{"foo":1, "!":2}'; > var x =3D JSON.parse(json); >=20 > Then I can access the field in question using one syntax (x["!"]), but = not > the simpler one (x.foo). >=20 > I would much rather have something that makes it easy to write code = instead > of something that minimizes octets. >=20 >=20 >=20 > On Tue, Mar 12, 2013 at 9:07 AM, Brian Campbell > wrote: >=20 >> "!" is the nicest color for this particular bike-shed that has been >> proposed thus far. >>=20 >>=20 >> On Tue, Mar 12, 2013 at 9:03 AM, Mike Jones = wrote: >>=20 >>> I kind of like the =93!=94 suggestion. James is right - I didn=92t = choose >>> the name =93crt=94 becase it means =93certificate=94 to too many = people. >>>=20 >>> Cheers, >>> -- Mike >>>=20 >>> *From:* Manger, James H >>> *Sent:* March 12, 2013 5:18 AM >>>=20 >>> *To:* vladimir@nimbusds.com, jose@ietf.org >>>=20 >>> *Subject:* Re: [jose] Proposed resolution of header criticality = issue >>>=20 >>> Nah, "crt" sounds too much like a certificate. *.crt is a common = file >>> extension for certs. >>>=20 >>> How about "!" ? >>>=20 >>> -- >>> James Manger >>>=20 >>> ----- Reply message ----- >>> From: "Vladimir Dzhuvinov / NimbusDS" >>> Date: Tue, Mar 12, 2013 5:45 pm >>> Subject: [jose] Proposed resolution of header criticality issue >>> To: "jose@ietf.org" >>>=20 >>> How about "crt" instead of "crit", to fit the three-letter = convention >>> for naming fields? >>>=20 >>> Vladimir >>>=20 >>> -- >>> Vladimir Dzhuvinov : www.NimbusDS.com : >>> vladimir@nimbusds.com >>>=20 >>>=20 >>> -------- Original Message -------- >>> Subject: [jose] Proposed resolution of header criticality issue >>> From: Karen O'Donoghue >>> Date: Tue, March 12, 2013 12:31 am >>> To: jose@ietf.org >>>=20 >>>=20 >>> Folks, >>>=20 >>> A side meeting was held Sunday with a number of jose working group >>> participants to try to resolve the open issue related to header >>> criticality. The following are the proposed resolutions from the >>> meeting. Point 5 of the proposed resolution below is actually >>> independent of the other 4 points, and could be considered = separately. >>> This will all be discussed in Wednesday's meeting. >>>=20 >>> In addition to the text below, there was some agreement to replace = the >>> "understand" text with something a bit more explicit like "must >>> process". However, that text has not been rolled into the summary = text >>> below yet. >>>=20 >>> Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, = Martin >>> Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your = efforts >>> (and my apologies if I missed someone). >>>=20 >>> Regards, >>> Karen >>>=20 >>> 1: Change the language =93Additional members MAY be present in the >>> JWK. If present, they MUST be understood by implementations using >>> them.=94 to =93Additional members MAY be present in the JWK. If not >>> understood by implementations encountering them, they MUST be >>> ignored.=94 (And make the same change for JWK Set as well.) >>>=20 >>> 2: Characterize all existing JWS and JWE header fields as either = must >>> be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 >>> must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, >>> =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored = because >>> while not using them may result in the inability to process some >>> signatures or encrypted content, this will not result in a security >>> violation =96 just degraded functionality. Other fields such as >>> =93epk=94, =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be >>> understood and used when =93alg=94 or =93enc=94 values requiring = them >>> are used, and otherwise they may be ignored. >>>=20 >>> 3. Define a new header field that lists which additional fields not >>> defined in the base specifications must be understood and acted upon >>> when present. For instance, an expiration-time extension field = could be >>> marked as must-be-understood-and-acted-upon. One possible name for = this >>> would be =93crit=94 (critical). An example use, along with a >>> hypothetical =93exp=94 (expiration-time) field is: >>>=20 >>> {"alg":"ES256", >>> "crit":["exp"], >>> "exp=94:1363284000 >>> } >>>=20 >>> 4. All additional header fields not defined in the base = specifications >>> and not contained in the =93crit=94 list MUST be ignored if not >>> understood. >>>=20 >>> 5. Define a new header field =93asd=94 (application-specific data) >>> whose value is a JSON structure whose contents are opaque to and = ignored >>> by JWS and JWE implementations but for which its contents MUST be >>> provided to applications using JWS or JWE, provided that the >>> signature/MAC validation or decryption operation succeeds. The = intended >>> use of this field is to have a standard place to provide >>> application-specific metadata about the payload or plaintext. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_7A4537C1-061B-4DD1-9A18-00C889EDCE2C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxMjEzMjYwOVowIwYJKoZIhvcNAQkEMRYEFKyCxp28SMy/qYijzs85FX6thybOMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBXvQsZyO5/5hc1aHlISVQuqw3zOT8UBU1qHVsCUZS8 6hKIR2XgTGWZu+25zbCKal3pEe9/Rl7kNFf9zEtbbeO3T+VcFIn5JrGth0v7tahAFKpkkGqtkDxU xlzAAGDrH52K+yUcjN00FUZXC8WiSmDtb+YTOT2PyDT2AeZtbTietJx0rj4/iI0TBpJq+pkV0oFS Y3/gQLq3N/9/LPZedpcz6ktLNimzm3ldtl4dfXxisNsjOiI/RzB/hTw4oZOfg6DvlCLGQqvSbCVe K3DedPFssSCsefdoMhCxEl31QRSmSgcswedNIPpg/TizzWJbAYM5Y0otzYmmH5fPYfOGGrCzAAAA AAAA --Apple-Mail=_7A4537C1-061B-4DD1-9A18-00C889EDCE2C-- From ietf@augustcellars.com Tue Mar 12 06:39:02 2013 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 BD6B621F8BCF for ; Tue, 12 Mar 2013 06:39:02 -0700 (PDT) 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 ZKj6i0dkevin for ; Tue, 12 Mar 2013 06:39:02 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3B60621F8BCE for ; Tue, 12 Mar 2013 06:39:02 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id EFD5F2C9EB for ; Tue, 12 Mar 2013 06:39:01 -0700 (PDT) From: "Jim Schaad" To: References: <01d001ce1478$1f3c9c60$5db5d520$@augustcellars.com> In-Reply-To: <01d001ce1478$1f3c9c60$5db5d520$@augustcellars.com> Date: Tue, 12 Mar 2013 09:38:28 -0400 Message-ID: <047001ce1f26$e2121fe0$a6365fa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0471_01CE1F05.5B011C20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL16gBtrNBZZcLD3XSJGrh8vMns7pZSeYyg Content-Language: en-us Subject: [jose] FW: Agenda Posted 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, 12 Mar 2013 13:39:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0471_01CE1F05.5B011C20 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0472_01CE1F05.5B011C20" ------=_NextPart_001_0472_01CE1F05.5B011C20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda has been updated. All presentations currently received have been posted. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Tuesday, February 26, 2013 6:22 PM To: jose@ietf.org Subject: [jose] Agenda Posted The first cut at the agenda for the meeting has been posted. If anything or anybody is missing please let me know. https://datatracker.ietf.org/meeting/86/agenda/jose Jim ------=_NextPart_001_0472_01CE1F05.5B011C20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda has been updated.

 

All presentations = currently received have been posted.

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Jim Schaad
Sent: Tuesday, February 26, 2013 6:22 = PM
To: jose@ietf.org
Subject: [jose] Agenda = Posted

 

<chair>

 

The first = cut at the agenda for the meeting has been posted.  If anything or = anybody is missing please let me know.

 

https://data= tracker.ietf.org/meeting/86/agenda/jose

 

Jim

 

------=_NextPart_001_0472_01CE1F05.5B011C20-- ------=_NextPart_000_0471_01CE1F05.5B011C20 Content-Type: text/plain; name="ATT00001.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ATT00001.txt" _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_0471_01CE1F05.5B011C20-- From James.H.Manger@team.telstra.com Tue Mar 12 06:40:12 2013 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 0E93821F8481 for ; Tue, 12 Mar 2013 06:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.871 X-Spam-Level: X-Spam-Status: No, score=-0.871 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 YM+bxL6QqFta for ; Tue, 12 Mar 2013 06:40:10 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 023B321F8A84 for ; Tue, 12 Mar 2013 06:39:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,830,1355058000"; d="scan'208";a="119194929" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 13 Mar 2013 00:39:58 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7011"; a="120547097" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccni.tcif.telstra.com.au with ESMTP; 13 Mar 2013 00:39:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 13 Mar 2013 00:39:58 +1100 From: "Manger, James H" To: "michael.jones@microsoft.com" , "rlb@ipv.sx" Date: Wed, 13 Mar 2013 00:39:58 +1100 Thread-Topic: [jose] Proposed resolution of header criticality issue: meta/asd Thread-Index: AQHOHycW1XUdMuaSuU6oCo6QrOPCIQ== Message-ID: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue: meta/asd 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, 12 Mar 2013 13:40:13 -0000 SSB3b3VsZCBwdXQgImN0eSIgKGNvbnRlbnQgdHlwZSkgdW5kZXIgIm1ldGEiLg0KDQpNaWtlLCBk byB5b3UgdGhpbmsgImN0eSIgaXNuJ3QgbmVlZGVkLCBvciB0aGF0IHRoZXJlIGlzIG5vIHZhbHVl IGluIHNlcGFyYXRpbmcgc3VjaCBhIGZpZWxkIGZyb20gdGhlIG90aGVycz8NCg0KLS0NCkphbWVz IE1hbmdlcg0KDQotLS0tLSBSZXBseSBtZXNzYWdlIC0tLS0tDQpGcm9tOiAiTWlrZSBKb25lcyIg PE1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4NCkRhdGU6IFdlZCwgTWFyIDEzLCAyMDEzIDEy OjA3IGFtDQpTdWJqZWN0OiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3Jp dGljYWxpdHkgaXNzdWUNClRvOiAiSm9obiBCcmFkbGV5IiA8dmU3anRiQHZlN2p0Yi5jb20+LCAi UmljaGFyZCBCYXJuZXMiIDxybGJAaXB2LnN4Pg0KQ2M6ICJUaW0gQnJheSIgPHRicmF5QHRleHR1 YWxpdHkuY29tPiwgIk1hbmdlciwgSmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3Ry YS5jb20+LCAiS2FyZW4gTyZhcG9zO0Rvbm9naHVlIiA8b2Rvbm9naHVlQGlzb2Mub3JnPiwgImpv c2UiIDxqb3NlQGlldGYub3JnPg0KDQpJ4oCZbSB3aXRoIFJpY2hhcmQgb24gdGhpcy4gIFRoZSBh cHBsaWNhdGlvbi1zcGVjaWZpYy1kYXRhL21ldGEgZmllbGQgaXNu4oCZdCBuZWVkZWQuDQoNCi0t IE1pa2UNCg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjEx4oCO LCDigI4yMDEzIOKAjjEw4oCOOuKAjjAy4oCOIOKAjlBNDQpUbzogSm9obiBCcmFkbGV5DQpDQzog VGltIEJyYXksIE1hbmdlciwgSmFtZXMgSCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlDQpTdWJqZWN0 OiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlz c3VlDQoNCisxIHRvIGNoZWVycy4gIEkgYWxyZWFkeSBoaWdoLWZpdmVkIE1pa2UgaW4gcGVyc29u Lg0KDQpGV0lXLCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGdldCByaWQgb2YgImFzZCIgb3Ig Im1ldGEiIChwYXJ0IDUpLiAgSSBkb24ndCB0aGluayBpdCdzIHJlbGV2YW50IHRvIHRoZSBjcml0 aWNhbGl0eSBkaXNjdXNzaW9uLCBhbmQgaXQncyBqdXN0IG5vdCBuZWVkZWQuDQoNCi0tUmljaGFy ZA0KDQoNCg0KT24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgMTE6MDEgUE0sIEpvaG4gQnJhZGxleSA8 dmU3anRiQHZlN2p0Yi5jb208bWFpbHRvOnZlN2p0YkB2ZTdqdGIuY29tPj4gd3JvdGU6DQoNCk9u IDIwMTMtMDMtMTEsIGF0IDEwOjQ4IFBNLCAiTWFuZ2VyLCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbTxtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bT4+IHdyb3RlOg0KDQpJ4oCZbGwgYWRkIHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRvZXMgbG9vayBs aWtlIHN1YnN0YW50aWFsIHByb2dyZXNzLg0KDQpJIGFzc3VtZSB0aGUgZmllbGRzIHN1Y2ggYXMg 4oCcZXBr4oCdLCDigJxhcHXigJ0gZXRjIHRoYXQgc29tZXRpbWVzIG11c3QgYmUgdW5kZXJzdG9v ZCwgYW5kIGF0IG90aGVyIHRpbWVzIG11c3QgYmUgaWdub3JlZCAoZGVwZW5kaW5nIG9uIOKAnGFs Z+KAnSBvciDigJxlbmPigJ0gdmFsdWUpIHdvdWxkIE5PVCBiZSBsaXN0ZWQgaW4gdGhlIOKAnGNy aXTigJ0gZmllbGQgYXMgdGhleSBhcmUgZGVmaW5lZCBpbiB0aGUg4oCcYmFzZSBzcGVjc+KAnS4N Cg0KQ29ycmVjdA0KDQpCZWluZyBpbiB0aGUg4oCcYmFzZSBzcGVjc+KAnSBpcyB0aGUgcmlnaHQg Y3JpdGVyaWEgZm9yIHdoZXRoZXIgYSBmaWVsZCBzaG91bGQgYmUgbGlzdGVkIGluIOKAnGNyaXTi gJ0gYXMgbG9uZyBhcyDigJxiYXNlIHNwZWNz4oCdIG1lYW5zOiDigJxiYXNlIHNwZWNpZmljYXRp b25zIGZvciB0aGUgcGFydGljdWxhciDigJxhbGfigJ0v4oCdZW5j4oCdIHZhbHVlc+KAnS4gSXQg c2hvdWxkbuKAmXQgbWVhbiAoYW5kIGRvZXNu4oCZdCBoYXZlIHRvIG1lYW4pIHRoZSBiYXNlIHNw ZWMgZm9yIHRoZSB3aG9sZSBKT1NFIHN5c3RlbS4NCg0KDQpDcml0IGlzIG9ubHkgZm9yIGV4dGVu c2lvbnMsIGl0IGlzIHVwIHRvIHRoZSBleHRlbnNpb24gZGVmaW5pdGlvbiB0byBkZWNpZGUgaWYg dGhlIGZpZWxkIG5lZWRzIHRvIGJlIGluIGNyaXQuDQoNCg0KUC5TLiDigJxtZXRh4oCdIG1pZ2h0 IGJlIGEgbmljZXIgbGFiZWwgdGhhbiDigJxhc2TigJ0uDQoNCkkgZG9uJ3QgaGF2ZSBhbnkgcGFy dGljdWxhciBhdHRhY2htZW50IHRvIHRoZSBuYW1lLiAgIFNvbWUgcGxhY2VzIHRoaW5ncyBsaWtl IHRoaXMgYXJlIGNhbGxlZCBhc3NvY2lhdGVkIGRhdGEsIHRob3VnaCBub3QgdGhlIHBsYWNlcyBu b3JtYWwgcGVvcGxlIGdvIEkgZ3JhbnQgeW91Lg0KTWV0YS1kYXRhIGFib3V0IHRoZSBwYXlsb2Fk IGlzIHdoYXQgaXQgaXMsICBUaGUgY3VycmVudCBwcmFjdGljZSBpcyB0byB1c2UgdGhyZWUgY2hh cmFjdGVyIG5hbWVzLiAgIEkgYW0gZmluZSB3aXRoIG1ldCBvciBtZXRhIChJIHN1c3BlY3QgdGhh dCBpZiB5b3UgYXJlIHRocm93aW5nIGNyYXAgaW50byB0aGUgZW52ZWxvcGUgdGhlIHNpbmdsZSBj aGFyYWN0ZXIgd29uJ3Qga2lsbCBhbnlvbmUuDQoNCkphbWVzIGlmIHlvdSBsaWtlIHRoZSBzb2x1 dGlvbiBhbmQgd2FudCBpdCB0byBiZSBtZXRhIEkgd2lsbCBiYWNrIHlvdSBvbiBpdCA6KQ0KDQpK b2huIEIuDQoNCg0KLS0NCkphbWVzIE1hbmdlcg0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLTxtYWlsdG86am9z ZS0+Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP ZiBUaW0gQnJheQ0KU2VudDogVHVlc2RheSwgMTIgTWFyY2ggMjAxMyAxMjo0MyBQTQ0KVG86IEth cmVuIE9Eb25vZ2h1ZQ0KQ2M6IGpvc2UNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVz b2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KQ3VlIHdpbGQgY2hlZXJzIGZy b20gdGhlIHBlYW51dCBnYWxsZXJ5IHdoZXJlIG5vbi1jcnlwdG9ncmFwaGVycyBzaXQuICBNdXN0 SWdub3JlIGlzIGluZmluaXRlbHkgbW9yZSByb2J1c3QgYW5kIG9wZW4tZW5kZWQgdGhhbiBNdXN0 VW5kZXJzdGFuZC4gIC1UDQoNCk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDU6MzEgUE0sIEthcmVu IE8nRG9ub2dodWUgPG9kb25vZ2h1ZUBpc29jLm9yZzxtYWlsdG86b2Rvbm9naHVlQGlzb2Mub3Jn Pj4gd3JvdGU6DQoNCkZvbGtzLA0KDQpBIHNpZGUgbWVldGluZyB3YXMgaGVsZCBTdW5kYXkgd2l0 aCBhIG51bWJlciBvZiBqb3NlIHdvcmtpbmcgZ3JvdXAgcGFydGljaXBhbnRzIHRvIHRyeSB0byBy ZXNvbHZlIHRoZSBvcGVuIGlzc3VlIHJlbGF0ZWQgdG8gaGVhZGVyIGNyaXRpY2FsaXR5LiBUaGUg Zm9sbG93aW5nIGFyZSB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbnMgZnJvbSB0aGUgbWVldGluZy4g UG9pbnQgNSBvZiB0aGUgcHJvcG9zZWQgcmVzb2x1dGlvbiBiZWxvdyBpcyBhY3R1YWxseSBpbmRl cGVuZGVudCBvZiB0aGUgb3RoZXIgNCBwb2ludHMsIGFuZCBjb3VsZCBiZSBjb25zaWRlcmVkIHNl cGFyYXRlbHkuIFRoaXMgd2lsbCBhbGwgYmUgZGlzY3Vzc2VkIGluIFdlZG5lc2RheSdzIG1lZXRp bmcuDQoNCkluIGFkZGl0aW9uIHRvIHRoZSB0ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBhZ3Jl ZW1lbnQgdG8gcmVwbGFjZSB0aGUgInVuZGVyc3RhbmQiIHRleHQgd2l0aCBzb21ldGhpbmcgYSBi aXQgbW9yZSBleHBsaWNpdCBsaWtlICJtdXN0IHByb2Nlc3MiLiBIb3dldmVyLCB0aGF0IHRleHQg aGFzIG5vdCBiZWVuIHJvbGxlZCBpbnRvIHRoZSBzdW1tYXJ5IHRleHQgYmVsb3cgeWV0Lg0KDQpU aGFuayB5b3UgdG8gSmltIFNjaGFhZCwgTWlrZSBKb25lcywgSm9obiBCcmFkbGV5LCBOYXQgU2Fr aW11cmEsIE1hcnRpbiBUaG9tYXMsIEVyaWMgUmVzY29ybGEsIE1hdHQgTWlsbGVyLCBhbmQgUmlj aGFyZCBCYXJuZXMgZm9yIHlvdXIgZWZmb3J0cyAoYW5kIG15IGFwb2xvZ2llcyBpZiBJIG1pc3Nl ZCBzb21lb25lKS4NCg0KUmVnYXJkcywNCkthcmVuDQoNCjE6ICBDaGFuZ2UgdGhlIGxhbmd1YWdl IOKAnEFkZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUgSldLLiAgSWYgcHJl c2VudCwgdGhleSBNVVNUIGJlIHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIHVzaW5nIHRo ZW0u4oCdIHRvIOKAnEFkZGl0aW9uYWwgbWVtYmVycyBNQVkgYmUgcHJlc2VudCBpbiB0aGUgSldL LiAgSWYgbm90IHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIGVuY291bnRlcmluZyB0aGVt LCB0aGV5IE1VU1QgYmUgaWdub3JlZC7igJ0gIChBbmQgbWFrZSB0aGUgc2FtZSBjaGFuZ2UgZm9y IEpXSyBTZXQgYXMgd2VsbC4pDQoNCjI6ICBDaGFyYWN0ZXJpemUgYWxsIGV4aXN0aW5nIEpXUyBh bmQgSldFIGhlYWRlciBmaWVsZHMgYXMgZWl0aGVyIG11c3QgYmUgdW5kZXJzdG9vZCBvciBtYXkg YmUgaWdub3JlZC4gIOKAnGFsZ+KAnSwg4oCcZW5j4oCdLCBhbmQg4oCcemlw4oCdIG11c3QgYmUg dW5kZXJzdG9vZC4gIOKAnGtpZOKAnSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKAnHg1dOKAnSwg 4oCcandr4oCdLCDigJxqa3XigJ0sIOKAnHR5cOKAnSwgYW5kIOKAnGN0eeKAnSBjYW4gYmUgaWdu b3JlZCBiZWNhdXNlIHdoaWxlIG5vdCB1c2luZyB0aGVtIG1heSByZXN1bHQgaW4gdGhlIGluYWJp bGl0eSB0byBwcm9jZXNzIHNvbWUgc2lnbmF0dXJlcyBvciBlbmNyeXB0ZWQgY29udGVudCwgdGhp cyB3aWxsIG5vdCByZXN1bHQgaW4gYSBzZWN1cml0eSB2aW9sYXRpb24g4oCTIGp1c3QgZGVncmFk ZWQgZnVuY3Rpb25hbGl0eS4gIE90aGVyIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg4oCcYXB1 4oCdLCDigJxhcHbigJ0sIOKAnGVwdeKAnSwgYW5kIOKAnGVwduKAnSBtdXN0IGJlIHVuZGVyc3Rv b2QgYW5kIHVzZWQgd2hlbiDigJxhbGfigJ0gb3Ig4oCcZW5j4oCdIHZhbHVlcyByZXF1aXJpbmcg dGhlbSBhcmUgdXNlZCwgYW5kIG90aGVyd2lzZSB0aGV5IG1heSBiZSBpZ25vcmVkLg0KDQozLiAg RGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCB0aGF0IGxpc3RzIHdoaWNoIGFkZGl0aW9uYWwgZmll bGRzIG5vdCBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zIG11c3QgYmUgdW5kZXJz dG9vZCBhbmQgYWN0ZWQgdXBvbiB3aGVuIHByZXNlbnQuICBGb3IgaW5zdGFuY2UsIGFuIGV4cGly YXRpb24tdGltZSBleHRlbnNpb24gZmllbGQgY291bGQgYmUgbWFya2VkIGFzIG11c3QtYmUtdW5k ZXJzdG9vZC1hbmQtYWN0ZWQtdXBvbi4gIE9uZSBwb3NzaWJsZSBuYW1lIGZvciB0aGlzIHdvdWxk IGJlIOKAnGNyaXTigJ0gKGNyaXRpY2FsKS4gIEFuIGV4YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGEg aHlwb3RoZXRpY2FsIOKAnGV4cOKAnSAoZXhwaXJhdGlvbi10aW1lKSBmaWVsZCBpczoNCg0KICB7 ImFsZyI6IkVTMjU2IiwNCiAgICJjcml0IjpbImV4cCJdLA0KICAgImV4cOKAnToxMzYzMjg0MDAw DQogIH0NCg0KNC4gIEFsbCBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgbm90IGRlZmluZWQgaW4g dGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMgYW5kIG5vdCBjb250YWluZWQgaW4gdGhlIOKAnGNyaXTi gJ0gbGlzdCBNVVNUIGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuDQoNCjUuICBEZWZpbmUg YSBuZXcgaGVhZGVyIGZpZWxkIOKAnGFzZOKAnSAoYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0YSkg d2hvc2UgdmFsdWUgaXMgYSBKU09OIHN0cnVjdHVyZSB3aG9zZSBjb250ZW50cyBhcmUgb3BhcXVl IHRvIGFuZCBpZ25vcmVkIGJ5IEpXUyBhbmQgSldFIGltcGxlbWVudGF0aW9ucyBidXQgZm9yIHdo aWNoIGl0cyBjb250ZW50cyBNVVNUIGJlIHByb3ZpZGVkIHRvIGFwcGxpY2F0aW9ucyB1c2luZyBK V1Mgb3IgSldFLCBwcm92aWRlZCB0aGF0IHRoZSBzaWduYXR1cmUvTUFDIHZhbGlkYXRpb24gb3Ig ZGVjcnlwdGlvbiBvcGVyYXRpb24gc3VjY2VlZHMuICBUaGUgaW50ZW5kZWQgdXNlIG9mIHRoaXMg ZmllbGQgaXMgdG8gaGF2ZSBhIHN0YW5kYXJkIHBsYWNlIHRvIHByb3ZpZGUgYXBwbGljYXRpb24t c3BlY2lmaWMgbWV0YWRhdGEgYWJvdXQgdGhlIHBheWxvYWQgb3IgcGxhaW50ZXh0Lg0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFp bGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRm Lm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQoN Cg== From ietf@augustcellars.com Tue Mar 12 06:49:54 2013 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 EB64521F89E1 for ; Tue, 12 Mar 2013 06:49:54 -0700 (PDT) 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 yKYs1V8tGk+Y for ; Tue, 12 Mar 2013 06:49:52 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B8C4F21F896D for ; Tue, 12 Mar 2013 06:49:51 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 8346A38F05; Tue, 12 Mar 2013 06:49:50 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Mike Jones'" References: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> In-Reply-To: <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> Date: Tue, 12 Mar 2013 09:49:17 -0400 Message-ID: <048401ce1f28$65152300$2f3f6900$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0485_01CE1F06.DE08B320" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKR5Ax308Vj71jVx84GjhLmrcE9EAG+veMzlwySZTA= Content-Language: en-us Cc: 'Richard Barnes' , 'Tim Bray' , 'James H Manger' , 'Karen O'Donoghue' , 'jose' Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:49:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0485_01CE1F06.DE08B320 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am not truly happy with this idea. If the application cares about who = =E2=80=9Cowns=E2=80=9D a key for a signature then it needs to somehow = get that information. That may be done by getting the way and key from = the security library and that may be done by just returning the claims = from the envelope. =20 Jim =20 =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = John Bradley Sent: Tuesday, March 12, 2013 9:15 AM To: Mike Jones Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue Subject: Re: [jose] Proposed resolution of header criticality issue =20 I am OK with getting rid of it if we make it clear that claims from the = envelope will not be passed on to applications. =20 If we don't do that we will compromise interoperability between = libraries. Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body = in some way. =20 I just want it one way or the other. =20 John B. =20 =20 On 2013-03-12, at 9:06 AM, Mike Jones = wrote: I=E2=80=99m with Richard on this. The application-specific-data/meta = field isn=E2=80=99t needed. =20 -- Mike =20 From: Richard Barnes Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E11=E2=80=8E, =E2=80=8E2013 = =E2=80=8E10=E2=80=8E:=E2=80=8E02=E2=80=8E =E2=80=8EPM To: John Bradley CC: Tim Bray, Manger, James H, Karen ODonoghue, jose Subject: Re: [jose] Proposed resolution of header criticality issue =20 +1 to cheers. I already high-fived Mike in person.=20 =20 FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I = don't think it's relevant to the criticality discussion, and it's just = not needed. =20 =20 --Richard =20 =20 On Mon, Mar 11, 2013 at 11:01 PM, John Bradley = wrote: =20 On 2013-03-11, at 10:48 PM, "Manger, James H" = wrote: =20 I=E2=80=99ll add some cheers =E2=80=94 this does look like substantial = progress. =20 I assume the fields such as =E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2=80=9D = etc that sometimes must be understood, and at other times must be = ignored (depending on =E2=80=9Calg=E2=80=9D or =E2=80=9Cenc=E2=80=9D = value) would NOT be listed in the =E2=80=9Ccrit=E2=80=9D field as they = are defined in the =E2=80=9Cbase specs=E2=80=9D. =20 Correct =20 Being in the =E2=80=9Cbase specs=E2=80=9D is the right criteria for = whether a field should be listed in =E2=80=9Ccrit=E2=80=9D as long as = =E2=80=9Cbase specs=E2=80=9D means: =E2=80=9Cbase specifications for the = particular =E2=80=9Calg=E2=80=9D/=E2=80=9Denc=E2=80=9D values=E2=80=9D. = It shouldn=E2=80=99t mean (and doesn=E2=80=99t have to mean) the base = spec for the whole JOSE system. =20 =20 Crit is only for extensions, it is up to the extension definition to = decide if the field needs to be in crit. =20 =20 P.S. =E2=80=9Cmeta=E2=80=9D might be a nicer label than = =E2=80=9Casd=E2=80=9D. =20 I don't have any particular attachment to the name. Some places things = like this are called associated data, though not the places normal = people go I grant you. =20 Meta-data about the payload is what it is, The current practice is to = use three character names. I am fine with met or meta (I suspect that = if you are throwing crap into the envelope the single character won't = kill anyone. =20 James if you like the solution and want it to be meta I will back you on = it :) =20 John B. =20 =20 -- James Manger =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Tim Bray Sent: Tuesday, 12 March 2013 12:43 PM To: Karen ODonoghue Cc: jose Subject: Re: [jose] Proposed resolution of header criticality issue =20 Cue wild cheers from the peanut gallery where non-cryptographers sit. = MustIgnore is infinitely more robust and open-ended than MustUnderstand. = -T =20 On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue < = odonoghue@isoc.org> wrote: Folks, A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting.=20 In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet.=20 Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin = Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts = (and my apologies if I missed someone).=20 Regards,=20 Karen 1: Change the language =E2=80=9CAdditional members MAY be present in = the JWK. If present, they MUST be understood by implementations using = them.=E2=80=9D to =E2=80=9CAdditional members MAY be present in the JWK. = If not understood by implementations encountering them, they MUST be = ignored.=E2=80=9D (And make the same change for JWK Set as well.) 2: Characterize all existing JWS and JWE header fields as either must = be understood or may be ignored. =E2=80=9Calg=E2=80=9D, = =E2=80=9Cenc=E2=80=9D, and =E2=80=9Czip=E2=80=9D must be understood. = =E2=80=9Ckid=E2=80=9D, =E2=80=9Cx5u=E2=80=9D, =E2=80=9Cx5c=E2=80=9D, = =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cjwk=E2=80=9D, =E2=80=9Cjku=E2=80=9D, = =E2=80=9Ctyp=E2=80=9D, and =E2=80=9Ccty=E2=80=9D can be ignored because = while not using them may result in the inability to process some = signatures or encrypted content, this will not result in a security = violation =E2=80=93 just degraded functionality. Other fields such as = =E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2=80=9D, =E2=80=9Capv=E2=80=9D, = =E2=80=9Cepu=E2=80=9D, and =E2=80=9Cepv=E2=80=9D must be understood and = used when =E2=80=9Calg=E2=80=9D or =E2=80=9Cenc=E2=80=9D values = requiring them are used, and otherwise they may be ignored. 3. Define a new header field that lists which additional fields not = defined in the base specifications must be understood and acted upon = when present. For instance, an expiration-time extension field could be = marked as must-be-understood-and-acted-upon. One possible name for this = would be =E2=80=9Ccrit=E2=80=9D (critical). An example use, along with = a hypothetical =E2=80=9Cexp=E2=80=9D (expiration-time) field is: {"alg":"ES256", "crit":["exp"], "exp=E2=80=9D:1363284000 } 4. All additional header fields not defined in the base specifications = and not contained in the =E2=80=9Ccrit=E2=80=9D list MUST be ignored if = not understood. 5. Define a new header field =E2=80=9Casd=E2=80=9D = (application-specific data) whose value is a JSON structure whose = contents are opaque to and ignored by JWS and JWE implementations but = for which its contents MUST be provided to applications using JWS or = JWE, provided that the signature/MAC validation or decryption operation = succeeds. The intended use of this field is to have a standard place to = provide application-specific metadata about the payload or plaintext. =20 =20 _______________________________________________ jose mailing list jose@ietf.org = https://www.ietf.org/mailman/listinfo/jose =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose =20 =20 ------=_NextPart_000_0485_01CE1F06.DE08B320 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I am not truly happy with this idea.=C2=A0 If the application cares = about who =E2=80=9Cowns=E2=80=9D a key for a signature then it needs to = somehow get that information.=C2=A0 That may be done by getting the way = and key from the security library and that may be done by just returning = the claims from the envelope.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = John Bradley
Sent: Tuesday, March 12, 2013 9:15 = AM
To: Mike Jones
Cc: Richard Barnes; James H = Manger; Tim Bray; jose; Karen O'Donoghue
Subject: Re: [jose] = Proposed resolution of header criticality = issue

 

I am OK with = getting rid of it if we make it clear that claims from the envelope will = not be passed on to applications.

 

If we don't do that we will compromise = interoperability between libraries.   Envelope is for JOSE only and = not made available, that makes things like timestamps and other things = that the application layer needs to interpret can't go in the envelope = they need to be in the body in some way.

 

I = just want it one way or the other.

 

John B.

 

 

On = 2013-03-12, at 9:06 AM, Mike Jones <Michael.Jones@microsoft.com> wrote:



+1 to cheers.  I = already high-fived Mike in person.

 

=

On Mon, Mar 11, 2013 at = 11:01 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

 

=

On 2013-03-11, at 10:48 PM, = "Manger, James H" <James.H.Manger@team.telst= ra.com> wrote:

 

=

I=E2=80=99ll add some cheers =E2=80=94 this does look like = substantial progress.

 

I assume the fields such as =E2=80=9Cepk=E2=80=9D, = =E2=80=9Capu=E2=80=9D etc that sometimes must be understood, and at = other times must be ignored (depending on =E2=80=9Calg=E2=80=9D or = =E2=80=9Cenc=E2=80=9D value) would NOT be listed in the = =E2=80=9Ccrit=E2=80=9D field as they are defined in the =E2=80=9Cbase = specs=E2=80=9D.

 

<= p class=3DMsoNormal>Correct

 

=

Being in the =E2=80=9Cbase specs=E2=80=9D is the right criteria for = whether a field should be listed in =E2=80=9Ccrit=E2=80=9D as long as = =E2=80=9Cbase specs=E2=80=9D means: =E2=80=9Cbase specifications for the = particular =E2=80=9Calg=E2=80=9D/=E2=80=9Denc=E2=80=9D values=E2=80=9D. = It shouldn=E2=80=99t mean (and doesn=E2=80=99t have to mean) the base = spec for the whole JOSE system.

 

 

=

Crit is only for = extensions, it is up to the extension definition to decide if the field = needs to be in crit.

 

=

 

=

P.S. =E2=80=9Cmeta=E2=80=9D might be a nicer label than = =E2=80=9Casd=E2=80=9D.

 

=

I don't have any particular = attachment to the name.   Some places things like this are called = associated data, though not the places normal people go I grant you. =  

Meta-data about the payload = is what it is,  The current practice is to use three character = names.   I am fine with met or meta (I suspect that if you are = throwing crap into the envelope the single character won't kill = anyone.

 

=

James if you like the = solution and want it to be meta I will back you on it = :)

 

=

John = B.

 

=

 

--

James Manger

 

From:=  jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf = Of Tim Bray
Sent: Tuesday, 12 March 2013 12:43 = PM
To: Karen = ODonoghue
Cc: jose
Subject: Re: [jose] = Proposed resolution of header criticality issue

 

Cue wild cheers from the peanut = gallery where non-cryptographers sit.  MustIgnore is infinitely = more robust and open-ended than MustUnderstand.  = -T

 

On Mon, Mar 11, 2013 at 5:31 PM, = Karen O'Donoghue <odonoghue@isoc.org> = wrote:


Folks,


A side meeting was held Sunday with a number of jose = working group participants to try to resolve the open issue related to = header criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting. 

In = addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like = "must process". However, that text has not been rolled into = the summary text below yet. 

Thank you to Jim Schaad, Mike = Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt = Miller, and Richard Barnes for your efforts (and my apologies if I = missed someone). 

Regards, 
Karen

1:  = Change the language =E2=80=9CAdditional members MAY be present in the = JWK.  If present, they MUST be understood by implementations using = them.=E2=80=9D to =E2=80=9CAdditional members MAY be present in the JWK. =  If not understood by implementations encountering them, they MUST = be ignored.=E2=80=9D  (And make the same change for JWK Set as = well.)

2:  Characterize all existing JWS and JWE header = fields as either must be understood or may be ignored.  = =E2=80=9Calg=E2=80=9D, =E2=80=9Cenc=E2=80=9D, and =E2=80=9Czip=E2=80=9D = must be understood.  =E2=80=9Ckid=E2=80=9D, =E2=80=9Cx5u=E2=80=9D, = =E2=80=9Cx5c=E2=80=9D, =E2=80=9Cx5t=E2=80=9D, =E2=80=9Cjwk=E2=80=9D, = =E2=80=9Cjku=E2=80=9D, =E2=80=9Ctyp=E2=80=9D, and =E2=80=9Ccty=E2=80=9D = can be ignored because while not using them may result in the inability = to process some signatures or encrypted content, this will not result in = a security violation =E2=80=93 just degraded functionality.  Other = fields such as =E2=80=9Cepk=E2=80=9D, =E2=80=9Capu=E2=80=9D, = =E2=80=9Capv=E2=80=9D, =E2=80=9Cepu=E2=80=9D, and =E2=80=9Cepv=E2=80=9D = must be understood and used when =E2=80=9Calg=E2=80=9D or = =E2=80=9Cenc=E2=80=9D values requiring them are used, and otherwise they = may be ignored.

3.  Define a new header field that lists = which additional fields not defined in the base specifications must be = understood and acted upon when present.  For instance, an = expiration-time extension field could be marked as = must-be-understood-and-acted-upon.  One possible name for this = would be =E2=80=9Ccrit=E2=80=9D (critical).  An example use, along = with a hypothetical =E2=80=9Cexp=E2=80=9D (expiration-time) field = is:

  {"alg":"ES256",
   = "crit":["exp"],
   = "exp=E2=80=9D:1363284000
  }

4.  All additional = header fields not defined in the base specifications and not contained = in the =E2=80=9Ccrit=E2=80=9D list MUST be ignored if not = understood.

5.  Define a new header field = =E2=80=9Casd=E2=80=9D (application-specific data) whose value is a JSON = structure whose contents are opaque to and ignored by JWS and JWE = implementations but for which its contents MUST be provided to = applications using JWS or JWE, provided that the signature/MAC = validation or decryption operation succeeds.  The intended use of = this field is to have a standard place to provide application-specific = metadata about the payload or = plaintext.

 

 


_______________________________________________
jose = mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= /a>

____________________________= ___________________
jose mailing list
jose@ietf.org
https://www.ietf.org/= mailman/listinfo/jose

<= p class=3DMsoNormal> 

=


________________________= _______________________
jose mailing list
jose@ietf.org
https://www.ietf.org/= mailman/listinfo/jose

 

=

 

------=_NextPart_000_0485_01CE1F06.DE08B320-- From rlb@ipv.sx Tue Mar 12 06:53:35 2013 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 812AB21F8A80 for ; Tue, 12 Mar 2013 06:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.976 X-Spam-Level: X-Spam-Status: No, score=-3.976 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 h96-j-Dc-mPx for ; Tue, 12 Mar 2013 06:53:34 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id 86FD121F89E9 for ; Tue, 12 Mar 2013 06:53:34 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id o17so5694390oag.6 for ; Tue, 12 Mar 2013 06:53:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=510PfaYFXEtnyxCfkm6YeYe6Il8fxpVBAI8D9Jhr4oE=; b=Vi8616OZRX0kJS23LDHVasa3HTDd9oE6pu218gebuxuMIZZKjwxsuWZpAWNTaH8BUJ GoJKz6/DjKz6PlXTmcPdjFqZQ5TxLP2CwZEM6CgZU5saxzzROvAzYj3ZZADT+Duw/NbJ lToh12UAX17nUT4KGHfABqFjC1csN/XvioHreK9D6gDQ81CKbzW4fLb1RBePc08XrdaE lyXbiOp6Pt7aRo0w9ncJ9EC1GWbUYIimJKkNYIXKl1xYZpFakEue119vxSgY7Gtd11AO u8nRQoXnZaYk0rGN7L0EEQxbxK5ARbspQU3me4glgSeUClD7xyKa2+xARgBcNJDP1/rs ZkhA== MIME-Version: 1.0 X-Received: by 10.60.171.50 with SMTP id ar18mr11810201oec.24.1363096414071; Tue, 12 Mar 2013 06:53:34 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 06:53:33 -0700 (PDT) X-Originating-IP: [2001:df8:0:16:9c72:6750:de2d:8ee1] In-Reply-To: <048401ce1f28$65152300$2f3f6900$@augustcellars.com> References: <4E1F6AAD24975D4BA5B1680429673943674F918B@TK5EX14MBXC283.redmond.corp.microsoft.com> <49106B45-E208-475B-9F84-CF622BA385C2@ve7jtb.com> <048401ce1f28$65152300$2f3f6900$@augustcellars.com> Date: Tue, 12 Mar 2013 09:53:33 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec550af3a8e42cf04d7ba9d1c X-Gm-Message-State: ALoCoQkcoIJm/DTojOayOczgXt5bz6jbVWVAjRmtG79XCZE4o+T6xClhkJqK6FCx/+/ZsFHEQjTm Cc: Karen O'Donoghue , Mike Jones , Tim Bray , jose , John Bradley , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 13:53:35 -0000 --bcaec550af3a8e42cf04d7ba9d1c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Note that my proposed text did not say that the libraries would not return header stuff, only that you shouldn't cram non-crypto-related things in there. On Tuesday, March 12, 2013, Jim Schaad wrote: > I am not truly happy with this idea. If the application cares about who > =93owns=94 a key for a signature then it needs to somehow get that > information. That may be done by getting the way and key from the securi= ty > library and that may be done by just returning the claims from the envelo= pe. > **** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org 'jose-bounces@ietf.org');> [mailto:jose-bounces@ietf.org] > *On Behalf Of *John Bradley > *Sent:* Tuesday, March 12, 2013 9:15 AM > *To:* Mike Jones > *Cc:* Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue > *Subject:* Re: [jose] Proposed resolution of header criticality issue**** > > ** ** > > I am OK with getting rid of it if we make it clear that claims from the > envelope will not be passed on to applications.**** > > ** ** > > If we don't do that we will compromise interoperability between libraries= . > Envelope is for JOSE only and not made available, that makes things lik= e > timestamps and other things that the application layer needs to interpret > can't go in the envelope they need to be in the body in some way.**** > > ** ** > > I just want it one way or the other.**** > > ** ** > > John B.**** > > ** ** > > ** ** > > On 2013-03-12, at 9:06 AM, Mike Jones wrote= : > **** > > > > **** > > I=92m with Richard on this. The application-specific-data/meta field isn= =92t > needed.**** > > **** > > -- Mike**** > > **** > > *From:* Richard Barnes > *Sent:* March 11, 2013 10:02 PM > *To:* John Bradley > *CC:* Tim Bray, Manger, James H, Karen ODonoghue, jose > *Subject:* Re: [jose] Proposed resolution of header criticality issue**** > > **** > > +1 to cheers. I already high-fived Mike in person. **** > > ** ** > > FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I > don't think it's relevant to the criticality discussion, and it's just no= t > needed. **** > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Mon, Mar 11, 2013 at 11:01 PM, John Bradley wrote:= * > *** > > ** ** > > On 2013-03-11, at 10:48 PM, "Manger, James H" < > James.H.Manger@team.telstra.com> wrote:**** > > ** ** > > I=92ll add some cheers =97 this does look like substant > > --bcaec550af3a8e42cf04d7ba9d1c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Note that my proposed text did not say that the libraries would not return = header stuff, only that you shouldn't cram non-crypto-related things in= there.=A0



On Tuesday, March 12, 20= 13, Jim Schaad wrote:

I am not trul= y happy with this idea.=A0 If the application cares about who =93owns=94 a = key for a signature then it needs to somehow get that information.=A0 That = may be done by getting the way and key from the security library and that m= ay be done by just returning the claims from the envelope.

=A0<= /p>

Jim

=A0<= /p>

=A0

From:= jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradl= ey
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donogh= ue
Subject: Re: [jose] Proposed resolution of header criticality = issue

=A0

I am OK with getting rid of it if we= make it clear that claims from the envelope will not be passed on to appli= cations.

=A0

If we = don't do that we will compromise interoperability between libraries. = =A0 Envelope is for JOSE only and not made available, that makes things lik= e timestamps and other things that the application layer needs to interpret= can't go in the envelope they need to be in the body in some way.

=A0

I just want it one way or = the other.

=A0

<= p>John B.

=A0

=A0

On 2013-03-12, at 9:06 AM, Mike Jones <Michael.Jones@mic= rosoft.com> wrote:



<= /p>

I=92m with Richard on this.=A0 The=A0application-specific-= data/meta field isn=92t needed.

=A0

-- Mike

=A0

From:=A0Richard Barnes
Sent:=A0March 11, 2013 10:02 PM
To:=A0John Bradley
CC:=A0Tim Bray, Manger, James H, Karen ODonoghue, jose<= br>Subject:=A0Re: [jose] Proposed resolution of header = criticality issue

=A0

+1 to cheers. =A0I already high-= fived Mike in person.

=A0

FWIW, my preference would be to g= et rid of "asd" or "meta" (part 5). =A0I don't thin= k it's relevant to the criticality discussion, and it's just not ne= eded. =A0

=A0

--Richard

=A0

=A0

On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com= > wrote:

=A0

On 2013-03-11, at 10:48 PM, "Manger, James H" <<= a>James.H.Manger@team.telstra.com> wrote:

=A0<= u>

, 'James H Manger' , 'Tim Bray' , 'jose' , 'Karen O'Donoghue' Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 14:00:03 -0000 --_000_f1586efec6de49a689fa4fa97d0b42a2BY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBhZ3JlZSwgYXMgd2hvIGlzIHRvIHNheSB3aGF0IGlzIHJlbGF0ZWQgb3Igbm90IHJl bGF0aXZlIHRvIGVudmVsb3BlIGNvbnRlbnRzDQoNClNlbnQgZnJvbSBXaW5kb3dzIE1haWwNCg0K RnJvbTogSmltIFNjaGFhZA0KU2VudDog4oCOTWFyY2jigI4g4oCOMTLigI4sIOKAjjIwMTMg4oCO NuKAjjrigI41MeKAjiDigI5BTQ0KVG86ICdKb2huIEJyYWRsZXknLCBNaWtlIEpvbmVzDQpDQzog J1JpY2hhcmQgQmFybmVzJywgJ1RpbSBCcmF5JywgJ0phbWVzIEggTWFuZ2VyJywgJ0thcmVuIE8n RG9ub2dodWUnLCAnam9zZScNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlv biBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KSSBhbSBub3QgdHJ1bHkgaGFwcHkgd2l0 aCB0aGlzIGlkZWEuICBJZiB0aGUgYXBwbGljYXRpb24gY2FyZXMgYWJvdXQgd2hvIOKAnG93bnPi gJ0gYSBrZXkgZm9yIGEgc2lnbmF0dXJlIHRoZW4gaXQgbmVlZHMgdG8gc29tZWhvdyBnZXQgdGhh dCBpbmZvcm1hdGlvbi4gIFRoYXQgbWF5IGJlIGRvbmUgYnkgZ2V0dGluZyB0aGUgd2F5IGFuZCBr ZXkgZnJvbSB0aGUgc2VjdXJpdHkgbGlicmFyeSBhbmQgdGhhdCBtYXkgYmUgZG9uZSBieSBqdXN0 IHJldHVybmluZyB0aGUgY2xhaW1zIGZyb20gdGhlIGVudmVsb3BlLg0KDQpKaW0NCg0KDQpGcm9t OiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKb2huIEJyYWRsZXkNClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDEyLCAyMDEzIDk6 MTUgQU0NClRvOiBNaWtlIEpvbmVzDQpDYzogUmljaGFyZCBCYXJuZXM7IEphbWVzIEggTWFuZ2Vy OyBUaW0gQnJheTsgam9zZTsgS2FyZW4gTydEb25vZ2h1ZQ0KU3ViamVjdDogUmU6IFtqb3NlXSBQ cm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KDQpJIGFtIE9L IHdpdGggZ2V0dGluZyByaWQgb2YgaXQgaWYgd2UgbWFrZSBpdCBjbGVhciB0aGF0IGNsYWltcyBm cm9tIHRoZSBlbnZlbG9wZSB3aWxsIG5vdCBiZSBwYXNzZWQgb24gdG8gYXBwbGljYXRpb25zLg0K DQpJZiB3ZSBkb24ndCBkbyB0aGF0IHdlIHdpbGwgY29tcHJvbWlzZSBpbnRlcm9wZXJhYmlsaXR5 IGJldHdlZW4gbGlicmFyaWVzLiAgIEVudmVsb3BlIGlzIGZvciBKT1NFIG9ubHkgYW5kIG5vdCBt YWRlIGF2YWlsYWJsZSwgdGhhdCBtYWtlcyB0aGluZ3MgbGlrZSB0aW1lc3RhbXBzIGFuZCBvdGhl ciB0aGluZ3MgdGhhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgbmVlZHMgdG8gaW50ZXJwcmV0IGNh bid0IGdvIGluIHRoZSBlbnZlbG9wZSB0aGV5IG5lZWQgdG8gYmUgaW4gdGhlIGJvZHkgaW4gc29t ZSB3YXkuDQoNCkkganVzdCB3YW50IGl0IG9uZSB3YXkgb3IgdGhlIG90aGVyLg0KDQpKb2huIEIu DQoNCg0KT24gMjAxMy0wMy0xMiwgYXQgOTowNiBBTSwgTWlrZSBKb25lcyA8TWljaGFlbC5Kb25l c0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCg0KDQpJ4oCZbSB3aXRoIFJpY2hhcmQgb24gdGhpcy4gIFRoZSBhcHBsaWNhdGlvbi1zcGVj aWZpYy1kYXRhL21ldGEgZmllbGQgaXNu4oCZdCBuZWVkZWQuDQoNCi0tIE1pa2UNCg0KRnJvbTog UmljaGFyZCBCYXJuZXMNClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjEx4oCOLCDigI4yMDEzIOKAjjEw 4oCOOuKAjjAy4oCOIOKAjlBNDQpUbzogSm9obiBCcmFkbGV5DQpDQzogVGltIEJyYXksIE1hbmdl ciwgSmFtZXMgSCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlDQpTdWJqZWN0OiBSZTogW2pvc2VdIFBy b3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlDQoNCisxIHRvIGNo ZWVycy4gIEkgYWxyZWFkeSBoaWdoLWZpdmVkIE1pa2UgaW4gcGVyc29uLg0KDQpGV0lXLCBteSBw cmVmZXJlbmNlIHdvdWxkIGJlIHRvIGdldCByaWQgb2YgImFzZCIgb3IgIm1ldGEiIChwYXJ0IDUp LiAgSSBkb24ndCB0aGluayBpdCdzIHJlbGV2YW50IHRvIHRoZSBjcml0aWNhbGl0eSBkaXNjdXNz aW9uLCBhbmQgaXQncyBqdXN0IG5vdCBuZWVkZWQuDQoNCi0tUmljaGFyZA0KDQoNCk9uIE1vbiwg TWFyIDExLCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29t PG1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbT4+IHdyb3RlOg0KDQpPbiAyMDEzLTAzLTExLCBhdCAx MDo0OCBQTSwgIk1hbmdlciwgSmFtZXMgSCIgPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCg0KSeKA mWxsIGFkZCBzb21lIGNoZWVycyDigJQgdGhpcyBkb2VzIGxvb2sgbGlrZSBzdWJzdGFudGlhbCBw cm9ncmVzcy4NCg0KSSBhc3N1bWUgdGhlIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg4oCcYXB1 4oCdIGV0YyB0aGF0IHNvbWV0aW1lcyBtdXN0IGJlIHVuZGVyc3Rvb2QsIGFuZCBhdCBvdGhlciB0 aW1lcyBtdXN0IGJlIGlnbm9yZWQgKGRlcGVuZGluZyBvbiDigJxhbGfigJ0gb3Ig4oCcZW5j4oCd IHZhbHVlKSB3b3VsZCBOT1QgYmUgbGlzdGVkIGluIHRoZSDigJxjcml04oCdIGZpZWxkIGFzIHRo ZXkgYXJlIGRlZmluZWQgaW4gdGhlIOKAnGJhc2Ugc3BlY3PigJ0uDQoNCkNvcnJlY3QNCg0KQmVp bmcgaW4gdGhlIOKAnGJhc2Ugc3BlY3PigJ0gaXMgdGhlIHJpZ2h0IGNyaXRlcmlhIGZvciB3aGV0 aGVyIGEgZmllbGQgc2hvdWxkIGJlIGxpc3RlZCBpbiDigJxjcml04oCdIGFzIGxvbmcgYXMg4oCc YmFzZSBzcGVjc+KAnSBtZWFuczog4oCcYmFzZSBzcGVjaWZpY2F0aW9ucyBmb3IgdGhlIHBhcnRp Y3VsYXIg4oCcYWxn4oCdL+KAnWVuY+KAnSB2YWx1ZXPigJ0uIEl0IHNob3VsZG7igJl0IG1lYW4g KGFuZCBkb2VzbuKAmXQgaGF2ZSB0byBtZWFuKSB0aGUgYmFzZSBzcGVjIGZvciB0aGUgd2hvbGUg Sk9TRSBzeXN0ZW0uDQoNCg0KQ3JpdCBpcyBvbmx5IGZvciBleHRlbnNpb25zLCBpdCBpcyB1cCB0 byB0aGUgZXh0ZW5zaW9uIGRlZmluaXRpb24gdG8gZGVjaWRlIGlmIHRoZSBmaWVsZCBuZWVkcyB0 byBiZSBpbiBjcml0Lg0KDQoNClAuUy4g4oCcbWV0YeKAnSBtaWdodCBiZSBhIG5pY2VyIGxhYmVs IHRoYW4g4oCcYXNk4oCdLg0KDQpJIGRvbid0IGhhdmUgYW55IHBhcnRpY3VsYXIgYXR0YWNobWVu dCB0byB0aGUgbmFtZS4gICBTb21lIHBsYWNlcyB0aGluZ3MgbGlrZSB0aGlzIGFyZSBjYWxsZWQg YXNzb2NpYXRlZCBkYXRhLCB0aG91Z2ggbm90IHRoZSBwbGFjZXMgbm9ybWFsIHBlb3BsZSBnbyBJ IGdyYW50IHlvdS4NCk1ldGEtZGF0YSBhYm91dCB0aGUgcGF5bG9hZCBpcyB3aGF0IGl0IGlzLCAg VGhlIGN1cnJlbnQgcHJhY3RpY2UgaXMgdG8gdXNlIHRocmVlIGNoYXJhY3RlciBuYW1lcy4gICBJ IGFtIGZpbmUgd2l0aCBtZXQgb3IgbWV0YSAoSSBzdXNwZWN0IHRoYXQgaWYgeW91IGFyZSB0aHJv d2luZyBjcmFwIGludG8gdGhlIGVudmVsb3BlIHRoZSBzaW5nbGUgY2hhcmFjdGVyIHdvbid0IGtp bGwgYW55b25lLg0KDQpKYW1lcyBpZiB5b3UgbGlrZSB0aGUgc29sdXRpb24gYW5kIHdhbnQgaXQg dG8gYmUgbWV0YSBJIHdpbGwgYmFjayB5b3Ugb24gaXQgOikNCg0KSm9obiBCLg0KDQoNCi0tDQpK YW1lcyBNYW5nZXINCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS08bWFpbHRvOmpvc2UtPmJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGltIEJyYXkNClNlbnQ6 IFR1ZXNkYXksIDEyIE1hcmNoIDIwMTMgMTI6NDMgUE0NClRvOiBLYXJlbiBPRG9ub2dodWUNCkNj OiBqb3NlDQpTdWJqZWN0OiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVy IGNyaXRpY2FsaXR5IGlzc3VlDQoNCkN1ZSB3aWxkIGNoZWVycyBmcm9tIHRoZSBwZWFudXQgZ2Fs bGVyeSB3aGVyZSBub24tY3J5cHRvZ3JhcGhlcnMgc2l0LiAgTXVzdElnbm9yZSBpcyBpbmZpbml0 ZWx5IG1vcmUgcm9idXN0IGFuZCBvcGVuLWVuZGVkIHRoYW4gTXVzdFVuZGVyc3RhbmQuICAtVA0K DQpPbiBNb24sIE1hciAxMSwgMjAxMyBhdCA1OjMxIFBNLCBLYXJlbiBPJ0Rvbm9naHVlIDxvZG9u b2dodWVAaXNvYy5vcmc8bWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZz4+IHdyb3RlOg0KDQpGb2xr cywNCg0KQSBzaWRlIG1lZXRpbmcgd2FzIGhlbGQgU3VuZGF5IHdpdGggYSBudW1iZXIgb2Ygam9z ZSB3b3JraW5nIGdyb3VwIHBhcnRpY2lwYW50cyB0byB0cnkgdG8gcmVzb2x2ZSB0aGUgb3BlbiBp c3N1ZSByZWxhdGVkIHRvIGhlYWRlciBjcml0aWNhbGl0eS4gVGhlIGZvbGxvd2luZyBhcmUgdGhl IHByb3Bvc2VkIHJlc29sdXRpb25zIGZyb20gdGhlIG1lZXRpbmcuIFBvaW50IDUgb2YgdGhlIHBy b3Bvc2VkIHJlc29sdXRpb24gYmVsb3cgaXMgYWN0dWFsbHkgaW5kZXBlbmRlbnQgb2YgdGhlIG90 aGVyIDQgcG9pbnRzLCBhbmQgY291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5LiBUaGlzIHdp bGwgYWxsIGJlIGRpc2N1c3NlZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLg0KDQpJbiBhZGRpdGlv biB0byB0aGUgdGV4dCBiZWxvdywgdGhlcmUgd2FzIHNvbWUgYWdyZWVtZW50IHRvIHJlcGxhY2Ug dGhlICJ1bmRlcnN0YW5kIiB0ZXh0IHdpdGggc29tZXRoaW5nIGEgYml0IG1vcmUgZXhwbGljaXQg bGlrZSAibXVzdCBwcm9jZXNzIi4gSG93ZXZlciwgdGhhdCB0ZXh0IGhhcyBub3QgYmVlbiByb2xs ZWQgaW50byB0aGUgc3VtbWFyeSB0ZXh0IGJlbG93IHlldC4NCg0KVGhhbmsgeW91IHRvIEppbSBT Y2hhYWQsIE1pa2UgSm9uZXMsIEpvaG4gQnJhZGxleSwgTmF0IFNha2ltdXJhLCBNYXJ0aW4gVGhv bWFzLCBFcmljIFJlc2NvcmxhLCBNYXR0IE1pbGxlciwgYW5kIFJpY2hhcmQgQmFybmVzIGZvciB5 b3VyIGVmZm9ydHMgKGFuZCBteSBhcG9sb2dpZXMgaWYgSSBtaXNzZWQgc29tZW9uZSkuDQoNClJl Z2FyZHMsDQpLYXJlbg0KDQoxOiAgQ2hhbmdlIHRoZSBsYW5ndWFnZSDigJxBZGRpdGlvbmFsIG1l bWJlcnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gIElmIHByZXNlbnQsIHRoZXkgTVVTVCBi ZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtLuKAnSB0byDigJxBZGRp dGlvbmFsIG1lbWJlcnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4gIElmIG5vdCB1bmRlcnN0 b29kIGJ5IGltcGxlbWVudGF0aW9ucyBlbmNvdW50ZXJpbmcgdGhlbSwgdGhleSBNVVNUIGJlIGln bm9yZWQu4oCdICAoQW5kIG1ha2UgdGhlIHNhbWUgY2hhbmdlIGZvciBKV0sgU2V0IGFzIHdlbGwu KQ0KDQoyOiAgQ2hhcmFjdGVyaXplIGFsbCBleGlzdGluZyBKV1MgYW5kIEpXRSBoZWFkZXIgZmll bGRzIGFzIGVpdGhlciBtdXN0IGJlIHVuZGVyc3Rvb2Qgb3IgbWF5IGJlIGlnbm9yZWQuICDigJxh bGfigJ0sIOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnSBtdXN0IGJlIHVuZGVyc3Rvb2QuICDigJxr aWTigJ0sIOKAnHg1deKAnSwg4oCceDVj4oCdLCDigJx4NXTigJ0sIOKAnGp3a+KAnSwg4oCcamt1 4oCdLCDigJx0eXDigJ0sIGFuZCDigJxjdHnigJ0gY2FuIGJlIGlnbm9yZWQgYmVjYXVzZSB3aGls ZSBub3QgdXNpbmcgdGhlbSBtYXkgcmVzdWx0IGluIHRoZSBpbmFiaWxpdHkgdG8gcHJvY2VzcyBz b21lIHNpZ25hdHVyZXMgb3IgZW5jcnlwdGVkIGNvbnRlbnQsIHRoaXMgd2lsbCBub3QgcmVzdWx0 IGluIGEgc2VjdXJpdHkgdmlvbGF0aW9uIOKAkyBqdXN0IGRlZ3JhZGVkIGZ1bmN0aW9uYWxpdHku ICBPdGhlciBmaWVsZHMgc3VjaCBhcyDigJxlcGvigJ0sIOKAnGFwdeKAnSwg4oCcYXB24oCdLCDi gJxlcHXigJ0sIGFuZCDigJxlcHbigJ0gbXVzdCBiZSB1bmRlcnN0b29kIGFuZCB1c2VkIHdoZW4g 4oCcYWxn4oCdIG9yIOKAnGVuY+KAnSB2YWx1ZXMgcmVxdWlyaW5nIHRoZW0gYXJlIHVzZWQsIGFu ZCBvdGhlcndpc2UgdGhleSBtYXkgYmUgaWdub3JlZC4NCg0KMy4gIERlZmluZSBhIG5ldyBoZWFk ZXIgZmllbGQgdGhhdCBsaXN0cyB3aGljaCBhZGRpdGlvbmFsIGZpZWxkcyBub3QgZGVmaW5lZCBp biB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVw b24gd2hlbiBwcmVzZW50LiAgRm9yIGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRpbWUgZXh0ZW5z aW9uIGZpZWxkIGNvdWxkIGJlIG1hcmtlZCBhcyBtdXN0LWJlLXVuZGVyc3Rvb2QtYW5kLWFjdGVk LXVwb24uICBPbmUgcG9zc2libGUgbmFtZSBmb3IgdGhpcyB3b3VsZCBiZSDigJxjcml04oCdIChj cml0aWNhbCkuICBBbiBleGFtcGxlIHVzZSwgYWxvbmcgd2l0aCBhIGh5cG90aGV0aWNhbCDigJxl eHDigJ0gKGV4cGlyYXRpb24tdGltZSkgZmllbGQgaXM6DQoNCiAgeyJhbGciOiJFUzI1NiIsDQog ICAiY3JpdCI6WyJleHAiXSwNCiAgICJleHDigJ06MTM2MzI4NDAwMA0KICB9DQoNCjQuICBBbGwg YWRkaXRpb25hbCBoZWFkZXIgZmllbGRzIG5vdCBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmlj YXRpb25zIGFuZCBub3QgY29udGFpbmVkIGluIHRoZSDigJxjcml04oCdIGxpc3QgTVVTVCBiZSBp Z25vcmVkIGlmIG5vdCB1bmRlcnN0b29kLg0KDQo1LiAgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVs ZCDigJxhc2TigJ0gKGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpIHdob3NlIHZhbHVlIGlzIGEg SlNPTiBzdHJ1Y3R1cmUgd2hvc2UgY29udGVudHMgYXJlIG9wYXF1ZSB0byBhbmQgaWdub3JlZCBi eSBKV1MgYW5kIEpXRSBpbXBsZW1lbnRhdGlvbnMgYnV0IGZvciB3aGljaCBpdHMgY29udGVudHMg TVVTVCBiZSBwcm92aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNpbmcgSldTIG9yIEpXRSwgcHJvdmlk ZWQgdGhhdCB0aGUgc2lnbmF0dXJlL01BQyB2YWxpZGF0aW9uIG9yIGRlY3J5cHRpb24gb3BlcmF0 aW9uIHN1Y2NlZWRzLiAgVGhlIGludGVuZGVkIHVzZSBvZiB0aGlzIGZpZWxkIGlzIHRvIGhhdmUg YSBzdGFuZGFyZCBwbGFjZSB0byBwcm92aWRlIGFwcGxpY2F0aW9uLXNwZWNpZmljIG1ldGFkYXRh IGFib3V0IHRoZSBwYXlsb2FkIG9yIHBsYWludGV4dC4NCg0KDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBp ZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBt YWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQo= --_000_f1586efec6de49a689fa4fa97d0b42a2BY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPjxzdHlsZT48IS0t CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwgewptYXJnaW46MGluIDBp biAwcHQ7CmZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7CmZvbnQtc2l6ZTox MnB0Owp9Ci0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjxkaXYgZGF0YS1leHRlcm5hbHN0 eWxlPSJmYWxzZSIgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmksJ1NlZ29lIFVJJyxNZWlyeW8s J01pY3Jvc29mdCBZYUhlaSBVSScsJ01pY3Jvc29mdCBKaGVuZ0hlaSBVSScsJ01hbGd1biBHb3Ro aWMnLCdLaG1lciBVSScsJ05pcm1hbGEgVUknLFR1bmdhLCdMYW8gVUknLEVicmltYSxzYW5zLXNl cmlmO2ZvbnQtc2l6ZToxNnB4OyI+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+ SSB3b3VsZCBhZ3JlZSwgYXMgd2hvIGlzIHRvIHNheSB3aGF0IGlzIHJlbGF0ZWQgb3Igbm90IHJl bGF0aXZlIHRvIGVudmVsb3BlIGNvbnRlbnRzPC9kaXY+DQo8ZGl2IGRhdGEtc2lnbmF0dXJlYmxv Y2s9InRydWUiPg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+U2VudCBmcm9tIFdpbmRvd3MgTWFp bDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRv cC1jb2xvcjogcmdiKDIyNSwgMjI1LCAyMjUpOyBib3JkZXItdG9wLXdpZHRoOiAxcHg7IGJvcmRl ci10b3Atc3R5bGU6IHNvbGlkOyI+DQo8c3Ryb25nPkZyb206PC9zdHJvbmc+Jm5ic3A7SmltIFNj aGFhZDxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9uZz4mbmJzcDvigI5NYXJjaOKAjiDigI4xMuKA jiwg4oCOMjAxMyDigI424oCOOuKAjjUx4oCOIOKAjkFNPGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9u Zz4mbmJzcDsnSm9obiBCcmFkbGV5JywgTWlrZSBKb25lczxicj4NCjxzdHJvbmc+Q0M6PC9zdHJv bmc+Jm5ic3A7J1JpY2hhcmQgQmFybmVzJywgJ1RpbSBCcmF5JywgJ0phbWVzIEggTWFuZ2VyJywg J0thcmVuIE8nRG9ub2dodWUnLCAnam9zZSc8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+ Jm5ic3A7UmU6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0 eSBpc3N1ZTxicj4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiBXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+SSBhbSBub3QgdHJ1bHkgaGFwcHkgd2l0 aCB0aGlzIGlkZWEuJm5ic3A7IElmIHRoZSBhcHBsaWNhdGlvbiBjYXJlcyBhYm91dCB3aG8g4oCc b3duc+KAnSBhIGtleSBmb3IgYSBzaWduYXR1cmUgdGhlbiBpdCBuZWVkcyB0byBzb21laG93IGdl dCB0aGF0IGluZm9ybWF0aW9uLiZuYnNwOw0KIFRoYXQgbWF5IGJlIGRvbmUgYnkgZ2V0dGluZyB0 aGUgd2F5IGFuZCBrZXkgZnJvbSB0aGUgc2VjdXJpdHkgbGlicmFyeSBhbmQgdGhhdCBtYXkgYmUg ZG9uZSBieSBqdXN0IHJldHVybmluZyB0aGUgY2xhaW1zIGZyb20gdGhlIGVudmVsb3BlLjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPHAgY2xhc3M9 IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1z aXplOiAxMXB0OyI+SmltPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOzwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyLXdpZHRoOiBtZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgYm9yZGVyLXN0 eWxlOiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWNvbG9yOiBibGFjayBibGFjayBibGFj ayBibHVlOyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUg bm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMykgYmxhY2sgYmxhY2s7IHBhZGRp bmc6IDNwdCAwaW4gMGluOyI+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiAmcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Zm9udC1zaXplOiAxMHB0OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTog MTBwdDsiPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkpvaG4gQnJhZGxleTxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBNYXJjaCAxMiwgMjAxMyA5OjE1IEFNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEpvbmVz PGJyPg0KPGI+Q2M6PC9iPiBSaWNoYXJkIEJhcm5lczsgSmFtZXMgSCBNYW5nZXI7IFRpbSBCcmF5 OyBqb3NlOyBLYXJlbiBPJ0Rvbm9naHVlPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0g UHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWU8L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBj bGFzcz0iIE1zb05vcm1hbCI+SSBhbSBPSyB3aXRoIGdldHRpbmcgcmlkIG9mIGl0IGlmIHdlIG1h a2UgaXQgY2xlYXIgdGhhdCBjbGFpbXMgZnJvbSB0aGUgZW52ZWxvcGUgd2lsbCBub3QgYmUgcGFz c2VkIG9uIHRvIGFwcGxpY2F0aW9ucy48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5JZiB3ZSBk b24ndCBkbyB0aGF0IHdlIHdpbGwgY29tcHJvbWlzZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4g bGlicmFyaWVzLiAmbmJzcDsgRW52ZWxvcGUgaXMgZm9yIEpPU0Ugb25seSBhbmQgbm90IG1hZGUg YXZhaWxhYmxlLCB0aGF0IG1ha2VzIHRoaW5ncyBsaWtlIHRpbWVzdGFtcHMgYW5kIG90aGVyIHRo aW5ncyB0aGF0IHRoZSBhcHBsaWNhdGlvbiBsYXllciBuZWVkcyB0byBpbnRlcnByZXQgY2FuJ3Qg Z28gaW4NCiB0aGUgZW52ZWxvcGUgdGhleSBuZWVkIHRvIGJlIGluIHRoZSBib2R5IGluIHNvbWUg d2F5LjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj4mbmJzcDs8L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+SSBqdXN0IHdhbnQgaXQgb25l IHdheSBvciB0aGUgb3RoZXIuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5Kb2hu IEIuPC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPiZuYnNwOzwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5PbiAyMDEzLTAzLTEyLCBhdCA5OjA2IEFNLCBN aWtlIEpvbmVzICZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVz QG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3Rl OjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxicj4NCjxicj4NCjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPkni gJltIHdpdGggUmljaGFyZCBvbiB0aGlzLiZuYnNwOyBUaGUmbmJzcDthcHBsaWNhdGlvbi1zcGVj aWZpYy1kYXRhL21ldGEgZmllbGQgaXNu4oCZdCBuZWVkZWQuPC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4t LSBNaWtlPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRl ci13aWR0aDogMS41cHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5v bmU7IGJvcmRlci1jb2xvcjogcmdiKDIyOSwgMjI5LCAyMjkpIGJsYWNrIGJsYWNrOyBwYWRkaW5n OiAwaW47Ij4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+RnJv bTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDtSaWNoYXJkIEJhcm5lczxicj4N CjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4mbmJzcDvigI5NYXJj aOKAjiDigI4xMeKAjiwg4oCOMjAxMyDigI4xMOKAjjrigI4wMuKAjiDigI5QTTxicj4NCjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Ij5Ubzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7Sm9obiBCcmFkbGV5PGJy Pg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPkNDOjwvc3Bhbj48L3N0cm9uZz4mbmJzcDtUaW0gQnJh eSwgTWFuZ2VyLCBKYW1lcyBILCBLYXJlbiBPRG9ub2dodWUsIGpvc2U8YnI+DQo8c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7OyI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7UmU6IFtqb3NlXSBQcm9w b3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZTwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4m IzQzOzEgdG8gY2hlZXJzLiAmbmJzcDtJIGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNv bi4NCjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OzsiPkZXSVcsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gZ2V0IHJpZCBv ZiAmcXVvdDthc2QmcXVvdDsgb3IgJnF1b3Q7bWV0YSZxdW90OyAocGFydCA1KS4gJm5ic3A7SSBk b24ndCB0aGluayBpdCdzIHJlbGV2YW50IHRvIHRoZSBjcml0aWNhbGl0eSBkaXNjdXNzaW9uLCBh bmQgaXQncyBqdXN0IG5vdCBuZWVkZWQuICZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+LS1SaWNo YXJkPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNw Ozwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+ T24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgMTE6MDEgUE0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgdGFi aW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86dmU3anRiQHZlN2p0Yi5jb20iPnZlN2p0YkB2ZTdqdGIu Y29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+T24gMjAxMy0wMy0xMSwgYXQgMTA6 NDggUE0sICZxdW90O01hbmdlciwgSmFtZXMgSCZxdW90OyAmbHQ7PGEgdGFiaW5kZXg9Ii0xIiBo cmVmPSJtYWlsdG86SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbSI+SmFtZXMuSC5NYW5n ZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7IG1hcmdpbi1ib3R0b206IDVwdDsiPg0K PHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1B VSIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij5J4oCZ bGwgYWRkIHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRvZXMgbG9vayBsaWtlIHN1YnN0YW50aWFsIHBy b2dyZXNzLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1BVSI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tQVUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Zm9udC1zaXplOiAxMXB0OyI+SSBhc3N1bWUgdGhlIGZpZWxkcyBzdWNoIGFzIOKAnGVwa+KAnSwg 4oCcYXB14oCdIGV0YyB0aGF0IHNvbWV0aW1lcyBtdXN0IGJlIHVuZGVyc3Rvb2QsIGFuZCBhdCBv dGhlciB0aW1lcyBtdXN0IGJlIGlnbm9yZWQgKGRlcGVuZGluZyBvbg0KIOKAnGFsZ+KAnSBvciDi gJxlbmPigJ0gdmFsdWUpIHdvdWxkIE5PVCBiZSBsaXN0ZWQgaW4gdGhlIOKAnGNyaXTigJ0gZmll bGQgYXMgdGhleSBhcmUgZGVmaW5lZCBpbiB0aGUg4oCcYmFzZSBzcGVjc+KAnS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tQVUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIj48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5Db3JyZWN0PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBt YXJnaW4tYm90dG9tOiA1cHQ7Ij4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsi PiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozsg Zm9udC1zaXplOiAxMXB0OyI+QmVpbmcgaW4gdGhlIOKAnGJhc2Ugc3BlY3PigJ0gaXMgdGhlIHJp Z2h0IGNyaXRlcmlhIGZvciB3aGV0aGVyIGEgZmllbGQgc2hvdWxkIGJlIGxpc3RlZCBpbiDigJxj cml04oCdIGFzIGxvbmcgYXMg4oCcYmFzZSBzcGVjc+KAnSBtZWFuczog4oCcYmFzZQ0KIHNwZWNp ZmljYXRpb25zIGZvciB0aGUgcGFydGljdWxhciDigJxhbGfigJ0v4oCdZW5j4oCdIHZhbHVlc+KA nS4gSXQgc2hvdWxkbuKAmXQgbWVhbiAoYW5kIGRvZXNu4oCZdCBoYXZlIHRvIG1lYW4pIHRoZSBi YXNlIHNwZWMgZm9yIHRoZSB3aG9sZSBKT1NFIHN5c3RlbS48L3NwYW4+PHNwYW4gbGFuZz0iRU4t QVUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1p bHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXpl OiAxMXB0OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIj48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Q3JpdCBpcyBvbmx5IGZvciBleHRl bnNpb25zLCBpdCBpcyB1cCB0byB0aGUgZXh0ZW5zaW9uIGRlZmluaXRpb24gdG8gZGVjaWRlIGlm IHRoZSBmaWVsZCBuZWVkcyB0byBiZSBpbiBjcml0Ljwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOiA1cHQ7 IG1hcmdpbi1ib3R0b206IDVwdDsiPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBmb250LXNpemU6IDExcHQ7Ij5QLlMuIOKAnG1ldGHigJ0gbWlnaHQgYmUgYSBuaWNlciBsYWJl bCB0aGFuIOKAnGFzZOKAnS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5JIGRvbid0IGhhdmUgYW55IHBh cnRpY3VsYXIgYXR0YWNobWVudCB0byB0aGUgbmFtZS4gJm5ic3A7IFNvbWUgcGxhY2VzIHRoaW5n cyBsaWtlIHRoaXMgYXJlIGNhbGxlZCBhc3NvY2lhdGVkIGRhdGEsIHRob3VnaCBub3QgdGhlIHBs YWNlcyBub3JtYWwgcGVvcGxlIGdvIEkgZ3JhbnQgeW91LiAmbmJzcDs8L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+TWV0YS1kYXRh IGFib3V0IHRoZSBwYXlsb2FkIGlzIHdoYXQgaXQgaXMsICZuYnNwO1RoZSBjdXJyZW50IHByYWN0 aWNlIGlzIHRvIHVzZSB0aHJlZSBjaGFyYWN0ZXIgbmFtZXMuICZuYnNwOyBJIGFtIGZpbmUgd2l0 aCBtZXQgb3IgbWV0YSAoSSBzdXNwZWN0IHRoYXQgaWYgeW91IGFyZSB0aHJvd2luZyBjcmFwIGlu dG8gdGhlIGVudmVsb3BlDQogdGhlIHNpbmdsZSBjaGFyYWN0ZXIgd29uJ3Qga2lsbCBhbnlvbmUu PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Ij5KYW1lcyBpZiB5b3UgbGlrZSB0aGUgc29sdXRpb24gYW5kIHdh bnQgaXQgdG8gYmUgbWV0YSBJIHdpbGwgYmFjayB5b3Ugb24gaXQgOik8L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsiPkpvaG4gQi48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7Ij4NCjxw IGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUi IHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFVIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPi0tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLUFV Ij48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUFVIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5 OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTog MTFwdDsiPkphbWVzIE1hbmdlcjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1BVSI+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIg c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlci13aWR0aDogbWVkaXVtIG1lZGl1bSBtZWRpdW0gMS41cHQ7IGJvcmRlci1zdHlsZTog bm9uZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1jb2xvcjogYmxhY2sgYmxhY2sgYmxhY2sgYmx1 ZTsgcGFkZGluZzogMGluIDBpbiAwaW4gNHB0OyI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy LXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7 IGJvcmRlci1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpIGJsYWNrIGJsYWNrOyBwYWRkaW5nOiAz cHQgMGluIDBpbjsiPg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 OyBmb250LXNpemU6IDEwcHQ7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiAmcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXpl OiAxMHB0OyI+Jm5ic3A7PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86am9zZS1ib3VuY2Vz QGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgdGFiaW5kZXg9 Ii0xIiBocmVmPSJtYWlsdG86am9zZS0iPmpvc2UtPC9hPjxhIHRhYmluZGV4PSItMSIgaHJlZj0i bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmciPmJvdW5jZXNAaWV0Zi5vcmc8L2E+XSZuYnNwOzxiPk9u DQogQmVoYWxmIE9mJm5ic3A7PC9iPlRpbSBCcmF5PGJyPg0KPGI+U2VudDo8L2I+Jm5ic3A7VHVl c2RheSwgMTIgTWFyY2ggMjAxMyAxMjo0MyBQTTxicj4NCjxiPlRvOjwvYj4mbmJzcDtLYXJlbiBP RG9ub2dodWU8YnI+DQo8Yj5DYzo8L2I+Jm5ic3A7am9zZTxicj4NCjxiPlN1YmplY3Q6PC9iPiZu YnNwO1JlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkg aXNzdWU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tQVUiPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUFV Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+Q3VlIHdpbGQgY2hlZXJzIGZyb20gdGhlIHBlYW51 dCBnYWxsZXJ5IHdoZXJlIG5vbi1jcnlwdG9ncmFwaGVycyBzaXQuJm5ic3A7IE11c3RJZ25vcmUg aXMgaW5maW5pdGVseSBtb3JlIHJvYnVzdCBhbmQgb3Blbi1lbmRlZCB0aGFuIE11c3RVbmRlcnN0 YW5kLiZuYnNwOyAtVDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSIgTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIGxhbmc9IkVO LUFVIj4mbmJzcDs8L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tQVUiPk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDU6MzEgUE0sIEth cmVuIE8nRG9ub2dodWUgJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOm9kb25vZ2h1 ZUBpc29jLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij5vZG9ub2dodWVAaXNvYy5v cmc8L3NwYW4+PC9hPiZndDsgd3JvdGU6PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tQVUiPjxicj4NCkZvbGtzLDwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tQVUiPjxicj4NCkEgc2lk ZSBtZWV0aW5nIHdhcyBoZWxkIFN1bmRheSB3aXRoIGEgbnVtYmVyIG9mIGpvc2Ugd29ya2luZyBn cm91cCBwYXJ0aWNpcGFudHMgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIG9wZW4gaXNzdWUgcmVsYXRl ZCB0byBoZWFkZXIgY3JpdGljYWxpdHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBwcm9wb3NlZCBy ZXNvbHV0aW9ucyBmcm9tIHRoZSBtZWV0aW5nLiBQb2ludCA1IG9mIHRoZSBwcm9wb3NlZCByZXNv bHV0aW9uIGJlbG93IGlzIGFjdHVhbGx5DQogaW5kZXBlbmRlbnQgb2YgdGhlIG90aGVyIDQgcG9p bnRzLCBhbmQgY291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5LiBUaGlzIHdpbGwgYWxsIGJl IGRpc2N1c3NlZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLiZuYnNwOzxicj4NCjxicj4NCkluIGFk ZGl0aW9uIHRvIHRoZSB0ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBhZ3JlZW1lbnQgdG8gcmVw bGFjZSB0aGUgJnF1b3Q7dW5kZXJzdGFuZCZxdW90OyB0ZXh0IHdpdGggc29tZXRoaW5nIGEgYml0 IG1vcmUgZXhwbGljaXQgbGlrZSAmcXVvdDttdXN0IHByb2Nlc3MmcXVvdDsuIEhvd2V2ZXIsIHRo YXQgdGV4dCBoYXMgbm90IGJlZW4gcm9sbGVkIGludG8gdGhlIHN1bW1hcnkgdGV4dCBiZWxvdyB5 ZXQuJm5ic3A7PGJyPg0KPGJyPg0KVGhhbmsgeW91IHRvIEppbSBTY2hhYWQsIE1pa2UgSm9uZXMs IEpvaG4gQnJhZGxleSwgTmF0IFNha2ltdXJhLCBNYXJ0aW4gVGhvbWFzLCBFcmljIFJlc2Nvcmxh LCBNYXR0IE1pbGxlciwgYW5kIFJpY2hhcmQgQmFybmVzIGZvciB5b3VyIGVmZm9ydHMgKGFuZCBt eSBhcG9sb2dpZXMgaWYgSSBtaXNzZWQgc29tZW9uZSkuJm5ic3A7PGJyPg0KPGJyPg0KUmVnYXJk cywmbmJzcDs8YnI+DQpLYXJlbjxicj4NCjxicj4NCjE6Jm5ic3A7IENoYW5nZSB0aGUgbGFuZ3Vh Z2Ug4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBiZSBwcmVzZW50IGluIHRoZSBKV0suICZuYnNw O0lmIHByZXNlbnQsIHRoZXkgTVVTVCBiZSB1bmRlcnN0b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1 c2luZyB0aGVtLuKAnSB0byDigJxBZGRpdGlvbmFsIG1lbWJlcnMgTUFZIGJlIHByZXNlbnQgaW4g dGhlIEpXSy4gJm5ic3A7SWYgbm90IHVuZGVyc3Rvb2QgYnkgaW1wbGVtZW50YXRpb25zIGVuY291 bnRlcmluZyB0aGVtLCB0aGV5IE1VU1QNCiBiZSBpZ25vcmVkLuKAnSZuYnNwOyAoQW5kIG1ha2Ug dGhlIHNhbWUgY2hhbmdlIGZvciBKV0sgU2V0IGFzIHdlbGwuKTxicj4NCjxicj4NCjI6Jm5ic3A7 IENoYXJhY3Rlcml6ZSBhbGwgZXhpc3RpbmcgSldTIGFuZCBKV0UgaGVhZGVyIGZpZWxkcyBhcyBl aXRoZXIgbXVzdCBiZSB1bmRlcnN0b29kIG9yIG1heSBiZSBpZ25vcmVkLiZuYnNwOyDigJxhbGfi gJ0sIOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnSBtdXN0IGJlIHVuZGVyc3Rvb2QuJm5ic3A7IOKA nGtpZOKAnSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKAnHg1dOKAnSwg4oCcandr4oCdLCDigJxq a3XigJ0sIOKAnHR5cOKAnSwgYW5kIOKAnGN0eeKAnSBjYW4gYmUgaWdub3JlZCBiZWNhdXNlIHdo aWxlIG5vdCB1c2luZyB0aGVtIG1heQ0KIHJlc3VsdCBpbiB0aGUgaW5hYmlsaXR5IHRvIHByb2Nl c3Mgc29tZSBzaWduYXR1cmVzIG9yIGVuY3J5cHRlZCBjb250ZW50LCB0aGlzIHdpbGwgbm90IHJl c3VsdCBpbiBhIHNlY3VyaXR5IHZpb2xhdGlvbiDigJMganVzdCBkZWdyYWRlZCBmdW5jdGlvbmFs aXR5LiZuYnNwOyBPdGhlciBmaWVsZHMgc3VjaCBhcyDigJxlcGvigJ0sIOKAnGFwdeKAnSwg4oCc YXB24oCdLCDigJxlcHXigJ0sIGFuZCDigJxlcHbigJ0gbXVzdCBiZSB1bmRlcnN0b29kIGFuZCB1 c2VkIHdoZW4g4oCcYWxn4oCdIG9yIOKAnGVuY+KAnQ0KIHZhbHVlcyByZXF1aXJpbmcgdGhlbSBh cmUgdXNlZCwgYW5kIG90aGVyd2lzZSB0aGV5IG1heSBiZSBpZ25vcmVkLjxicj4NCjxicj4NCjMu Jm5ic3A7IERlZmluZSBhIG5ldyBoZWFkZXIgZmllbGQgdGhhdCBsaXN0cyB3aGljaCBhZGRpdGlv bmFsIGZpZWxkcyBub3QgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJl IHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVwb24gd2hlbiBwcmVzZW50LiZuYnNwOyBGb3IgaW5zdGFu Y2UsIGFuIGV4cGlyYXRpb24tdGltZSBleHRlbnNpb24gZmllbGQgY291bGQgYmUgbWFya2VkIGFz IG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0ZWQtdXBvbi4mbmJzcDsNCiBPbmUgcG9zc2libGUg bmFtZSBmb3IgdGhpcyB3b3VsZCBiZSDigJxjcml04oCdIChjcml0aWNhbCkuJm5ic3A7IEFuIGV4 YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGEgaHlwb3RoZXRpY2FsIOKAnGV4cOKAnSAoZXhwaXJhdGlv bi10aW1lKSBmaWVsZCBpczo8YnI+DQo8YnI+DQombmJzcDsgeyZxdW90O2FsZyZxdW90OzomcXVv dDtFUzI1NiZxdW90Oyw8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7Y3JpdCZxdW90OzpbJnF1b3Q7 ZXhwJnF1b3Q7XSw8YnI+DQombmJzcDsmbmJzcDsgJnF1b3Q7ZXhw4oCdOjEzNjMyODQwMDA8YnI+ DQombmJzcDsgfTxicj4NCjxicj4NCjQuJm5ic3A7IEFsbCBhZGRpdGlvbmFsIGhlYWRlciBmaWVs ZHMgbm90IGRlZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMgYW5kIG5vdCBjb250YWlu ZWQgaW4gdGhlIOKAnGNyaXTigJ0gbGlzdCBNVVNUIGJlIGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rv b2QuPGJyPg0KPGJyPg0KNS4mbmJzcDsgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCDigJxhc2Ti gJ0gKGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpIHdob3NlIHZhbHVlIGlzIGEgSlNPTiBzdHJ1 Y3R1cmUgd2hvc2UgY29udGVudHMgYXJlIG9wYXF1ZSB0byBhbmQgaWdub3JlZCBieSBKV1MgYW5k IEpXRSBpbXBsZW1lbnRhdGlvbnMgYnV0IGZvciB3aGljaCBpdHMgY29udGVudHMgTVVTVCBiZSBw cm92aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNpbmcgSldTIG9yIEpXRSwgcHJvdmlkZWQgdGhhdA0K IHRoZSBzaWduYXR1cmUvTUFDIHZhbGlkYXRpb24gb3IgZGVjcnlwdGlvbiBvcGVyYXRpb24gc3Vj Y2VlZHMuJm5ic3A7IFRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBmaWVsZCBpcyB0byBoYXZlIGEg c3RhbmRhcmQgcGxhY2UgdG8gcHJvdmlkZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBtZXRhZGF0YSBh Ym91dCB0aGUgcGF5bG9hZCBvciBwbGFpbnRleHQuPC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSI+Jm5ic3A7PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLUFVIj4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSIg TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLUFV Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCmpvc2UgbWFpbGluZyBsaXN0PGJyPg0KPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86 am9zZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij5qb3NlQGlldGYub3Jn PC9zcGFuPjwvYT48YnI+DQo8YSB0YWJpbmRleD0iLTEiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam9zZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiBwdXJwbGU7Ij5o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L3NwYW4+PC9hPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tQVUiPiZuYnNwOzwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1BVSIgc3R5bGU9ImZvbnQtZmFt aWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmpvc2UgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+ am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8YSB0YWJpbmRleD0iLTEiIGhyZWY9Imh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9qb3NlPC9hPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PGJyPg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlz dDxicj4NCjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vam9zZTwvYT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDs8L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_f1586efec6de49a689fa4fa97d0b42a2BY2PR03MB041namprd03pro_-- From Michael.Jones@microsoft.com Tue Mar 12 07:01:33 2013 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 E518521F858C for ; Tue, 12 Mar 2013 07:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 PVZL28Ow6e-3 for ; Tue, 12 Mar 2013 07:01:32 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id 8189021F8526 for ; Tue, 12 Mar 2013 07:01:31 -0700 (PDT) Received: from BY2FFO11FD026.protection.gbl (10.1.15.200) by BY2FFO11HUB034.protection.gbl (10.1.14.118) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 14:01:28 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD026.mail.protection.outlook.com (10.1.15.215) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 14:01:28 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 14:00:27 +0000 From: Mike Jones To: Jim Schaad , Richard Barnes Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: Ac4fKfMLmB8jo/KiwU+B27AulrV5NQ== Date: Tue, 12 Mar 2013 14:00:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FB494@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FB494TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(189002)(199002)(377424002)(377454001)(63696002)(55846006)(47736001)(80022001)(47446002)(16406001)(33656001)(4396001)(512874001)(69226001)(76482001)(51856001)(74662001)(56776001)(59766001)(5343635001)(5343655001)(20776003)(16236675001)(50986001)(47976001)(54356001)(74502001)(49866001)(77982001)(79102001)(31966008)(44976002)(54316002)(53806001)(56816002)(65816001)(46102001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB034; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: John Bradley , Tim Bray , James H Manger , Karen O'Donoghue , jose Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 14:01:33 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FB494TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgdG8gb25seSBwdXR0aW5nIGNyeXB0by1yZWxhdGVkIHRoaW5ncyBpbiB0aGUgaGVhZGVycy4N Cg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjEy4oCOLCDigI4y MDEzIOKAjjbigI464oCONTPigI4g4oCOQU0NClRvOiBKaW0gU2NoYWFkDQpDQzogSm9obiBCcmFk bGV5LCBNaWtlIEpvbmVzLCBKYW1lcyBIIE1hbmdlciwgVGltIEJyYXksIGpvc2UsIEthcmVuIE8n RG9ub2dodWUNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFk ZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KTm90ZSB0aGF0IG15IHByb3Bvc2VkIHRleHQgZGlkIG5v dCBzYXkgdGhhdCB0aGUgbGlicmFyaWVzIHdvdWxkIG5vdCByZXR1cm4gaGVhZGVyIHN0dWZmLCBv bmx5IHRoYXQgeW91IHNob3VsZG4ndCBjcmFtIG5vbi1jcnlwdG8tcmVsYXRlZCB0aGluZ3MgaW4g dGhlcmUuDQoNCg0KDQpPbiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMywgSmltIFNjaGFhZCB3cm90 ZToNCkkgYW0gbm90IHRydWx5IGhhcHB5IHdpdGggdGhpcyBpZGVhLiAgSWYgdGhlIGFwcGxpY2F0 aW9uIGNhcmVzIGFib3V0IHdobyDigJxvd25z4oCdIGEga2V5IGZvciBhIHNpZ25hdHVyZSB0aGVu IGl0IG5lZWRzIHRvIHNvbWVob3cgZ2V0IHRoYXQgaW5mb3JtYXRpb24uICBUaGF0IG1heSBiZSBk b25lIGJ5IGdldHRpbmcgdGhlIHdheSBhbmQga2V5IGZyb20gdGhlIHNlY3VyaXR5IGxpYnJhcnkg YW5kIHRoYXQgbWF5IGJlIGRvbmUgYnkganVzdCByZXR1cm5pbmcgdGhlIGNsYWltcyBmcm9tIHRo ZSBlbnZlbG9wZS4NCg0KSmltDQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBCcmFkbGV5DQpTZW50 OiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyA5OjE1IEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6IFJp Y2hhcmQgQmFybmVzOyBKYW1lcyBIIE1hbmdlcjsgVGltIEJyYXk7IGpvc2U7IEthcmVuIE8nRG9u b2dodWUNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIg Y3JpdGljYWxpdHkgaXNzdWUNCg0KDQoNCkkgYW0gT0sgd2l0aCBnZXR0aW5nIHJpZCBvZiBpdCBp ZiB3ZSBtYWtlIGl0IGNsZWFyIHRoYXQgY2xhaW1zIGZyb20gdGhlIGVudmVsb3BlIHdpbGwgbm90 IGJlIHBhc3NlZCBvbiB0byBhcHBsaWNhdGlvbnMuDQoNCg0KDQpJZiB3ZSBkb24ndCBkbyB0aGF0 IHdlIHdpbGwgY29tcHJvbWlzZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gbGlicmFyaWVzLiAg IEVudmVsb3BlIGlzIGZvciBKT1NFIG9ubHkgYW5kIG5vdCBtYWRlIGF2YWlsYWJsZSwgdGhhdCBt YWtlcyB0aGluZ3MgbGlrZSB0aW1lc3RhbXBzIGFuZCBvdGhlciB0aGluZ3MgdGhhdCB0aGUgYXBw bGljYXRpb24gbGF5ZXIgbmVlZHMgdG8gaW50ZXJwcmV0IGNhbid0IGdvIGluIHRoZSBlbnZlbG9w ZSB0aGV5IG5lZWQgdG8gYmUgaW4gdGhlIGJvZHkgaW4gc29tZSB3YXkuDQoNCg0KDQpJIGp1c3Qg d2FudCBpdCBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCg0KDQoNCkpvaG4gQi4NCg0KDQoNCg0KDQpP biAyMDEzLTAzLTEyLCBhdCA5OjA2IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jv c29mdC5jb20+IHdyb3RlOg0KDQoNCg0KSeKAmW0gd2l0aCBSaWNoYXJkIG9uIHRoaXMuICBUaGUg YXBwbGljYXRpb24tc3BlY2lmaWMtZGF0YS9tZXRhIGZpZWxkIGlzbuKAmXQgbmVlZGVkLg0KDQoN Cg0KLS0gTWlrZQ0KDQoNCg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6IE1hcmNoIDExLCAy MDEzIDEwOjAyIFBNDQpUbzogSm9obiBCcmFkbGV5DQpDQzogVGltIEJyYXksIE1hbmdlciwgSmFt ZXMgSCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlDQpTdWJqZWN0OiBSZTogW2pvc2VdIFByb3Bvc2Vk IHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlDQoNCg0KDQorMSB0byBjaGVl cnMuICBJIGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi4NCg0KDQoNCkZXSVcsIG15 IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gZ2V0IHJpZCBvZiAiYXNkIiBvciAibWV0YSIgKHBhcnQg NSkuICBJIGRvbid0IHRoaW5rIGl0J3MgcmVsZXZhbnQgdG8gdGhlIGNyaXRpY2FsaXR5IGRpc2N1 c3Npb24sIGFuZCBpdCdzIGp1c3Qgbm90IG5lZWRlZC4NCg0KDQoNCi0tUmljaGFyZA0KDQoNCg0K DQoNCk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJyYWRsZXkgPHZlN2p0 YkB2ZTdqdGIuY29tPiB3cm90ZToNCg0KDQoNCk9uIDIwMTMtMDMtMTEsIGF0IDEwOjQ4IFBNLCAi TWFuZ2VyLCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4gd3JvdGU6 DQoNCg0KDQpJ4oCZbGwgYWRkIHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRvZXMgbG9vayBsaWtlIHN1 YnN0YW50DQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FB494TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <3194FC9A8551F345BAB5FD223930CFB9@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+JiM0Mzsx IHRvJm5ic3A7b25seSBwdXR0aW5nIGNyeXB0by1yZWxhdGVkIHRoaW5ncyBpbiB0aGUgaGVhZGVy cy48L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNvbG9y OiByZ2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDJweDsgYm9yZGVyLXRvcC1z dHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDtSaWNoYXJkIEJhcm5l czxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9uZz4mbmJzcDvigI5NYXJjaOKAjiDigI4xMuKAjiwg 4oCOMjAxMyDigI424oCOOuKAjjUz4oCOIOKAjkFNPGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4m bmJzcDtKaW0gU2NoYWFkPGJyPg0KPHN0cm9uZz5DQzo8L3N0cm9uZz4mbmJzcDtKb2huIEJyYWRs ZXksIE1pa2UgSm9uZXMsIEphbWVzIEggTWFuZ2VyLCBUaW0gQnJheSwgam9zZSwgS2FyZW4gTydE b25vZ2h1ZTxicj4NCjxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4mbmJzcDtSZTogW2pvc2VdIFBy b3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPGJyPg0KPC9kaXY+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KTm90ZSB0aGF0IG15IHByb3Bvc2VkIHRleHQgZGlkIG5vdCBz YXkgdGhhdCB0aGUgbGlicmFyaWVzIHdvdWxkIG5vdCByZXR1cm4gaGVhZGVyIHN0dWZmLCBvbmx5 IHRoYXQgeW91IHNob3VsZG4ndCBjcmFtIG5vbi1jcnlwdG8tcmVsYXRlZCB0aGluZ3MgaW4gdGhl cmUuJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48c3Bhbj48L3NwYW4+PGJyPg0KPGJy Pg0KT24gVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMsIEppbSBTY2hhYWQgd3JvdGU6PGJyPg0KPGJs b2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAw LjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQs IDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsi Pg0KPGRpdiBsYW5nPSJFTi1VUyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij5JIGFtIG5v dCB0cnVseSBoYXBweSB3aXRoIHRoaXMgaWRlYS4mbmJzcDsgSWYgdGhlIGFwcGxpY2F0aW9uIGNh cmVzIGFib3V0IHdobyDigJxvd25z4oCdIGEga2V5IGZvciBhIHNpZ25hdHVyZSB0aGVuIGl0IG5l ZWRzIHRvIHNvbWVob3cgZ2V0IHRoYXQgaW5mb3JtYXRpb24uJm5ic3A7DQogVGhhdCBtYXkgYmUg ZG9uZSBieSBnZXR0aW5nIHRoZSB3YXkgYW5kIGtleSBmcm9tIHRoZSBzZWN1cml0eSBsaWJyYXJ5 IGFuZCB0aGF0IG1heSBiZSBkb25lIGJ5IGp1c3QgcmV0dXJuaW5nIHRoZSBjbGFpbXMgZnJvbSB0 aGUgZW52ZWxvcGUuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7 Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPkpp bTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij48dT48L3U+Jm5ic3A7 PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IG1lZGl1bSBtZWRp dW0gbWVkaXVtIDEuNXB0OyBib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3Jk ZXItY29sb3I6IGJsYWNrIGJsYWNrIGJsYWNrIGJsdWU7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRw dDsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlci13aWR0aDogMXB0IG1lZGl1bSBtZWRpdW07 IGJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItY29sb3I6IHJnYigxODEsIDE5 NiwgMjIzKSBibGFjayBibGFjazsgcGFkZGluZzogM3B0IDBpbiAwaW47Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4NCjxhPmpvc2UtYm91bmNlc0BpZXRmLm9y ZzwvYT4gW21haWx0bzo8YT5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8Yj5PbiBCZWhhbGYg T2YNCjwvYj5Kb2huIEJyYWRsZXk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMTIs IDIwMTMgOToxNSBBTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4g UmljaGFyZCBCYXJuZXM7IEphbWVzIEggTWFuZ2VyOyBUaW0gQnJheTsgam9zZTsgS2FyZW4gTydE b25vZ2h1ZTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRp b24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHA+SSBhbSBPSyB3 aXRoIGdldHRpbmcgcmlkIG9mIGl0IGlmIHdlIG1ha2UgaXQgY2xlYXIgdGhhdCBjbGFpbXMgZnJv bSB0aGUgZW52ZWxvcGUgd2lsbCBub3QgYmUgcGFzc2VkIG9uIHRvIGFwcGxpY2F0aW9ucy48dT48 L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwPklmIHdlIGRvbid0IGRvIHRoYXQgd2Ugd2lsbCBjb21wcm9taXNlIGludGVy b3BlcmFiaWxpdHkgYmV0d2VlbiBsaWJyYXJpZXMuICZuYnNwOyBFbnZlbG9wZSBpcyBmb3IgSk9T RSBvbmx5IGFuZCBub3QgbWFkZSBhdmFpbGFibGUsIHRoYXQgbWFrZXMgdGhpbmdzIGxpa2UgdGlt ZXN0YW1wcyBhbmQgb3RoZXIgdGhpbmdzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIG5lZWRz IHRvIGludGVycHJldCBjYW4ndCBnbyBpbiB0aGUgZW52ZWxvcGUgdGhleQ0KIG5lZWQgdG8gYmUg aW4gdGhlIGJvZHkgaW4gc29tZSB3YXkuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPkkganVzdCB3 YW50IGl0IG9uZSB3YXkgb3IgdGhlIG90aGVyLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHA+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD5Kb2hu IEIuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cD5PbiAyMDEzLTAzLTEyLCBhdCA5OjA2IEFNLCBNaWtlIEpvbmVzICZsdDs8 YT5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPHA+PGJyPg0KPGJyPg0KPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPknigJltIHdpdGggUmljaGFyZCBvbiB0aGlz LiZuYnNwOyBUaGUmbmJzcDthcHBsaWNhdGlvbi1zcGVjaWZpYy1kYXRhL21ldGEgZmllbGQgaXNu 4oCZdCBuZWVkZWQuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Ij4mbmJzcDs8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OzsiPi0tIE1pa2U8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXdpZHRoOiAxLjVwdCBtZWRpdW0gbWVk aXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiByZ2IoMjI5 LCAyMjksIDIyOSkgYmxhY2sgYmxhY2s7IHBhZGRpbmc6IDBpbjsiPg0KPHA+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsiPkZyb206PC9zcGFuPjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7UmljaGFy ZCBCYXJuZXM8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+U2VudDo8L3NwYW4+PC9zdHJvbmc+ Jm5ic3A7TWFyY2ggMTEsIDIwMTMgMTA6MDIgUE08YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+ VG86PC9zcGFuPjwvc3Ryb25nPiZuYnNwO0pvaG4gQnJhZGxleTxicj4NCjxzdHJvbmc+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Ij5DQzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7VGltIEJyYXksIE1hbmdlciwgSmFtZXMg SCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPlN1Ympl Y3Q6PC9zcGFuPjwvc3Ryb25nPiZuYnNwO1JlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBv ZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWU8dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mIzQzOzEgdG8gY2hlZXJzLiAmbmJzcDtJIGFs cmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi4NCjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+RldJVywgbXkgcHJlZmVyZW5jZSB3 b3VsZCBiZSB0byBnZXQgcmlkIG9mICZxdW90O2FzZCZxdW90OyBvciAmcXVvdDttZXRhJnF1b3Q7 IChwYXJ0IDUpLiAmbmJzcDtJIGRvbid0IHRoaW5rIGl0J3MgcmVsZXZhbnQgdG8gdGhlIGNyaXRp Y2FsaXR5IGRpc2N1c3Npb24sIGFuZCBpdCdzIGp1c3Qgbm90IG5lZWRlZC4gJm5ic3A7PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij48dT48 L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsiPi0tUmljaGFyZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206IDEycHQ7Ij48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPk9uIE1v biwgTWFyIDExLCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJyYWRsZXkgJmx0OzxhPnZlN2p0YkB2 ZTdqdGIuY29tPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5PbiAyMDEzLTAzLTExLCBhdCAxMDo0OCBQ TSwgJnF1b3Q7TWFuZ2VyLCBKYW1lcyBIJnF1b3Q7ICZsdDs8YT5KYW1lcy5ILk1hbmdlckB0ZWFt LnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0OyBtYXJnaW4tYm90dG9tOiA1 cHQ7Ij4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tQVUiIHN0eWxlPSJjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+SeKAmWxsIGFkZCBzb21lIGNoZWVy cyDigJQgdGhpcyBkb2VzIGxvb2sgbGlrZSBzdWJzdGFudDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4E1F6AAD24975D4BA5B1680429673943674FB494TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 07:07:12 2013 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 59EBC21F8675 for ; Tue, 12 Mar 2013 07:07:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6C-JGYHMaOZg for ; Tue, 12 Mar 2013 07:07:10 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2378521F859B for ; Tue, 12 Mar 2013 07:07:09 -0700 (PDT) Received: from BL2FFO11FD016.protection.gbl (10.173.161.204) by BL2FFO11HUB006.protection.gbl (10.173.160.226) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 14:07:07 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD016.mail.protection.outlook.com (10.173.160.224) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 14:07:07 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 14:06:52 +0000 From: Mike Jones To: Richard Barnes , James H Manger Thread-Topic: [jose] Proposed resolution of header criticality issue: meta/asd Thread-Index: Ac4fKtgH1XUdMuaSuU6oCo6QrOPCIQ== Date: Tue, 12 Mar 2013 14:06:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943674FBA8E@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943674FBA8ETK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454001)(189002)(377424002)(24454001)(54316002)(51856001)(74662001)(16236675001)(44976002)(56816002)(33656001)(55846006)(80022001)(16297215001)(16406001)(59766001)(5343635001)(53806001)(56776001)(46102001)(54356001)(47736001)(47446002)(4396001)(79102001)(5343655001)(15202345001)(69226001)(47976001)(49866001)(74502001)(50986001)(63696002)(31966008)(77982001)(20776003)(76482001)(65816001)(512874001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB006; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue: meta/asd 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, 12 Mar 2013 14:07:12 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943674FBA8ETK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGNvbnRlbnQgdHlwZSBmaWVsZCBpcyB1c2VkIGFzIGlucHV0IHRvIGNyeXB0byBwcm9jZXNz aW5nIHJ1bGVzIGFuZCBpcyBub3QgbmVjZXNzYXJpbHkgYXBwbGljYXRpb24tc3BlY2lmaWMgZGF0 YS4gIEZvciBpbnN0YW5jZSwgc2VlIEpXVOKAmXMgbm9ybWF0aXZlIHVzZSBvZiB0aGUgZmllbGQg dG8gY29udmV5IHN0cnVjdHVyYWwgaW5mb3JtYXRpb24gaW4gaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vYXV0aC1qc29uLXdlYi10b2tlbi0wNiNzZWN0aW9uLTcuDQoNCkZy b206IE1hbmdlciwgSmFtZXMgSA0KU2VudDog4oCOTWFyY2jigI4g4oCOMTLigI4sIOKAjjIwMTMg 4oCONuKAjjrigI40MOKAjiDigI5BTQ0KVG86IE1pa2UgSm9uZXMsIHJsYkBpcHYuc3gNCkNDOiBq b3NlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2Yg aGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlOiBtZXRhL2FzZA0KDQpJIHdvdWxkIHB1dCAiY3R5IiAo Y29udGVudCB0eXBlKSB1bmRlciAibWV0YSIuDQoNCk1pa2UsIGRvIHlvdSB0aGluayAiY3R5IiBp c24ndCBuZWVkZWQsIG9yIHRoYXQgdGhlcmUgaXMgbm8gdmFsdWUgaW4gc2VwYXJhdGluZyBzdWNo IGEgZmllbGQgZnJvbSB0aGUgb3RoZXJzPw0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCi0tLS0tIFJl cGx5IG1lc3NhZ2UgLS0tLS0NCkZyb206ICJNaWtlIEpvbmVzIiA8TWljaGFlbC5Kb25lc0BtaWNy b3NvZnQuY29tPg0KRGF0ZTogV2VkLCBNYXIgMTMsIDIwMTMgMTI6MDcgYW0NClN1YmplY3Q6IFtq b3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KVG86 ICJKb2huIEJyYWRsZXkiIDx2ZTdqdGJAdmU3anRiLmNvbT4sICJSaWNoYXJkIEJhcm5lcyIgPHJs YkBpcHYuc3g+DQpDYzogIlRpbSBCcmF5IiA8dGJyYXlAdGV4dHVhbGl0eS5jb20+LCAiTWFuZ2Vy LCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4sICJLYXJlbiBPJmFw b3M7RG9ub2dodWUiIDxvZG9ub2dodWVAaXNvYy5vcmc+LCAiam9zZSIgPGpvc2VAaWV0Zi5vcmc+ DQoNCknigJltIHdpdGggUmljaGFyZCBvbiB0aGlzLiAgVGhlIGFwcGxpY2F0aW9uLXNwZWNpZmlj LWRhdGEvbWV0YSBmaWVsZCBpc27igJl0IG5lZWRlZC4NCg0KLS0gTWlrZQ0KDQpGcm9tOiBSaWNo YXJkIEJhcm5lcw0KU2VudDog4oCOTWFyY2jigI4g4oCOMTHigI4sIOKAjjIwMTMg4oCOMTDigI46 4oCOMDLigI4g4oCOUE0NClRvOiBKb2huIEJyYWRsZXkNCkNDOiBUaW0gQnJheSwgTWFuZ2VyLCBK YW1lcyBILCBLYXJlbiBPRG9ub2dodWUsIGpvc2UNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9z ZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KKzEgdG8gY2hlZXJz LiAgSSBhbHJlYWR5IGhpZ2gtZml2ZWQgTWlrZSBpbiBwZXJzb24uDQoNCkZXSVcsIG15IHByZWZl cmVuY2Ugd291bGQgYmUgdG8gZ2V0IHJpZCBvZiAiYXNkIiBvciAibWV0YSIgKHBhcnQgNSkuICBJ IGRvbid0IHRoaW5rIGl0J3MgcmVsZXZhbnQgdG8gdGhlIGNyaXRpY2FsaXR5IGRpc2N1c3Npb24s IGFuZCBpdCdzIGp1c3Qgbm90IG5lZWRlZC4NCg0KLS1SaWNoYXJkDQoNCg0KDQpPbiBNb24sIE1h ciAxMSwgMjAxMyBhdCAxMTowMSBQTSwgSm9obiBCcmFkbGV5IDx2ZTdqdGJAdmU3anRiLmNvbTxt YWlsdG86dmU3anRiQHZlN2p0Yi5jb20+PiB3cm90ZToNCg0KT24gMjAxMy0wMy0xMSwgYXQgMTA6 NDggUE0sICJNYW5nZXIsIEphbWVzIEgiIDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29t PG1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6DQoNCknigJls bCBhZGQgc29tZSBjaGVlcnMg4oCUIHRoaXMgZG9lcyBsb29rIGxpa2Ugc3Vic3RhbnRpYWwgcHJv Z3Jlc3MuDQoNCkkgYXNzdW1lIHRoZSBmaWVsZHMgc3VjaCBhcyDigJxlcGvigJ0sIOKAnGFwdeKA nSBldGMgdGhhdCBzb21ldGltZXMgbXVzdCBiZSB1bmRlcnN0b29kLCBhbmQgYXQgb3RoZXIgdGlt ZXMgbXVzdCBiZSBpZ25vcmVkIChkZXBlbmRpbmcgb24g4oCcYWxn4oCdIG9yIOKAnGVuY+KAnSB2 YWx1ZSkgd291bGQgTk9UIGJlIGxpc3RlZCBpbiB0aGUg4oCcY3JpdOKAnSBmaWVsZCBhcyB0aGV5 IGFyZSBkZWZpbmVkIGluIHRoZSDigJxiYXNlIHNwZWNz4oCdLg0KDQpDb3JyZWN0DQoNCkJlaW5n IGluIHRoZSDigJxiYXNlIHNwZWNz4oCdIGlzIHRoZSByaWdodCBjcml0ZXJpYSBmb3Igd2hldGhl ciBhIGZpZWxkIHNob3VsZCBiZSBsaXN0ZWQgaW4g4oCcY3JpdOKAnSBhcyBsb25nIGFzIOKAnGJh c2Ugc3BlY3PigJ0gbWVhbnM6IOKAnGJhc2Ugc3BlY2lmaWNhdGlvbnMgZm9yIHRoZSBwYXJ0aWN1 bGFyIOKAnGFsZ+KAnS/igJ1lbmPigJ0gdmFsdWVz4oCdLiBJdCBzaG91bGRu4oCZdCBtZWFuIChh bmQgZG9lc27igJl0IGhhdmUgdG8gbWVhbikgdGhlIGJhc2Ugc3BlYyBmb3IgdGhlIHdob2xlIEpP U0Ugc3lzdGVtLg0KDQoNCkNyaXQgaXMgb25seSBmb3IgZXh0ZW5zaW9ucywgaXQgaXMgdXAgdG8g dGhlIGV4dGVuc2lvbiBkZWZpbml0aW9uIHRvIGRlY2lkZSBpZiB0aGUgZmllbGQgbmVlZHMgdG8g YmUgaW4gY3JpdC4NCg0KDQpQLlMuIOKAnG1ldGHigJ0gbWlnaHQgYmUgYSBuaWNlciBsYWJlbCB0 aGFuIOKAnGFzZOKAnS4NCg0KSSBkb24ndCBoYXZlIGFueSBwYXJ0aWN1bGFyIGF0dGFjaG1lbnQg dG8gdGhlIG5hbWUuICAgU29tZSBwbGFjZXMgdGhpbmdzIGxpa2UgdGhpcyBhcmUgY2FsbGVkIGFz c29jaWF0ZWQgZGF0YSwgdGhvdWdoIG5vdCB0aGUgcGxhY2VzIG5vcm1hbCBwZW9wbGUgZ28gSSBn cmFudCB5b3UuDQpNZXRhLWRhdGEgYWJvdXQgdGhlIHBheWxvYWQgaXMgd2hhdCBpdCBpcywgIFRo ZSBjdXJyZW50IHByYWN0aWNlIGlzIHRvIHVzZSB0aHJlZSBjaGFyYWN0ZXIgbmFtZXMuICAgSSBh bSBmaW5lIHdpdGggbWV0IG9yIG1ldGEgKEkgc3VzcGVjdCB0aGF0IGlmIHlvdSBhcmUgdGhyb3dp bmcgY3JhcCBpbnRvIHRoZSBlbnZlbG9wZSB0aGUgc2luZ2xlIGNoYXJhY3RlciB3b24ndCBraWxs IGFueW9uZS4NCg0KSmFtZXMgaWYgeW91IGxpa2UgdGhlIHNvbHV0aW9uIGFuZCB3YW50IGl0IHRv IGJlIG1ldGEgSSB3aWxsIGJhY2sgeW91IG9uIGl0IDopDQoNCkpvaG4gQi4NCg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3Vu Y2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtPG1haWx0bzpqb3NlLT5ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFRpbSBCcmF5DQpTZW50OiBU dWVzZGF5LCAxMiBNYXJjaCAyMDEzIDEyOjQzIFBNDQpUbzogS2FyZW4gT0Rvbm9naHVlDQpDYzog am9zZQ0KU3ViamVjdDogUmU6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBj cml0aWNhbGl0eSBpc3N1ZQ0KDQpDdWUgd2lsZCBjaGVlcnMgZnJvbSB0aGUgcGVhbnV0IGdhbGxl cnkgd2hlcmUgbm9uLWNyeXB0b2dyYXBoZXJzIHNpdC4gIE11c3RJZ25vcmUgaXMgaW5maW5pdGVs eSBtb3JlIHJvYnVzdCBhbmQgb3Blbi1lbmRlZCB0aGFuIE11c3RVbmRlcnN0YW5kLiAgLVQNCg0K T24gTW9uLCBNYXIgMTEsIDIwMTMgYXQgNTozMSBQTSwgS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9n aHVlQGlzb2Mub3JnPG1haWx0bzpvZG9ub2dodWVAaXNvYy5vcmc+PiB3cm90ZToNCg0KRm9sa3Ms DQoNCkEgc2lkZSBtZWV0aW5nIHdhcyBoZWxkIFN1bmRheSB3aXRoIGEgbnVtYmVyIG9mIGpvc2Ug d29ya2luZyBncm91cCBwYXJ0aWNpcGFudHMgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIG9wZW4gaXNz dWUgcmVsYXRlZCB0byBoZWFkZXIgY3JpdGljYWxpdHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBw cm9wb3NlZCByZXNvbHV0aW9ucyBmcm9tIHRoZSBtZWV0aW5nLiBQb2ludCA1IG9mIHRoZSBwcm9w b3NlZCByZXNvbHV0aW9uIGJlbG93IGlzIGFjdHVhbGx5IGluZGVwZW5kZW50IG9mIHRoZSBvdGhl ciA0IHBvaW50cywgYW5kIGNvdWxkIGJlIGNvbnNpZGVyZWQgc2VwYXJhdGVseS4gVGhpcyB3aWxs IGFsbCBiZSBkaXNjdXNzZWQgaW4gV2VkbmVzZGF5J3MgbWVldGluZy4NCg0KSW4gYWRkaXRpb24g dG8gdGhlIHRleHQgYmVsb3csIHRoZXJlIHdhcyBzb21lIGFncmVlbWVudCB0byByZXBsYWNlIHRo ZSAidW5kZXJzdGFuZCIgdGV4dCB3aXRoIHNvbWV0aGluZyBhIGJpdCBtb3JlIGV4cGxpY2l0IGxp a2UgIm11c3QgcHJvY2VzcyIuIEhvd2V2ZXIsIHRoYXQgdGV4dCBoYXMgbm90IGJlZW4gcm9sbGVk IGludG8gdGhlIHN1bW1hcnkgdGV4dCBiZWxvdyB5ZXQuDQoNClRoYW5rIHlvdSB0byBKaW0gU2No YWFkLCBNaWtlIEpvbmVzLCBKb2huIEJyYWRsZXksIE5hdCBTYWtpbXVyYSwgTWFydGluIFRob21h cywgRXJpYyBSZXNjb3JsYSwgTWF0dCBNaWxsZXIsIGFuZCBSaWNoYXJkIEJhcm5lcyBmb3IgeW91 ciBlZmZvcnRzIChhbmQgbXkgYXBvbG9naWVzIGlmIEkgbWlzc2VkIHNvbWVvbmUpLg0KDQpSZWdh cmRzLA0KS2FyZW4NCg0KMTogIENoYW5nZSB0aGUgbGFuZ3VhZ2Ug4oCcQWRkaXRpb25hbCBtZW1i ZXJzIE1BWSBiZSBwcmVzZW50IGluIHRoZSBKV0suICBJZiBwcmVzZW50LCB0aGV5IE1VU1QgYmUg dW5kZXJzdG9vZCBieSBpbXBsZW1lbnRhdGlvbnMgdXNpbmcgdGhlbS7igJ0gdG8g4oCcQWRkaXRp b25hbCBtZW1iZXJzIE1BWSBiZSBwcmVzZW50IGluIHRoZSBKV0suICBJZiBub3QgdW5kZXJzdG9v ZCBieSBpbXBsZW1lbnRhdGlvbnMgZW5jb3VudGVyaW5nIHRoZW0sIHRoZXkgTVVTVCBiZSBpZ25v cmVkLuKAnSAgKEFuZCBtYWtlIHRoZSBzYW1lIGNoYW5nZSBmb3IgSldLIFNldCBhcyB3ZWxsLikN Cg0KMjogIENoYXJhY3Rlcml6ZSBhbGwgZXhpc3RpbmcgSldTIGFuZCBKV0UgaGVhZGVyIGZpZWxk cyBhcyBlaXRoZXIgbXVzdCBiZSB1bmRlcnN0b29kIG9yIG1heSBiZSBpZ25vcmVkLiAg4oCcYWxn 4oCdLCDigJxlbmPigJ0sIGFuZCDigJx6aXDigJ0gbXVzdCBiZSB1bmRlcnN0b29kLiAg4oCca2lk 4oCdLCDigJx4NXXigJ0sIOKAnHg1Y+KAnSwg4oCceDV04oCdLCDigJxqd2vigJ0sIOKAnGprdeKA nSwg4oCcdHlw4oCdLCBhbmQg4oCcY3R54oCdIGNhbiBiZSBpZ25vcmVkIGJlY2F1c2Ugd2hpbGUg bm90IHVzaW5nIHRoZW0gbWF5IHJlc3VsdCBpbiB0aGUgaW5hYmlsaXR5IHRvIHByb2Nlc3Mgc29t ZSBzaWduYXR1cmVzIG9yIGVuY3J5cHRlZCBjb250ZW50LCB0aGlzIHdpbGwgbm90IHJlc3VsdCBp biBhIHNlY3VyaXR5IHZpb2xhdGlvbiDigJMganVzdCBkZWdyYWRlZCBmdW5jdGlvbmFsaXR5LiAg T3RoZXIgZmllbGRzIHN1Y2ggYXMg4oCcZXBr4oCdLCDigJxhcHXigJ0sIOKAnGFwduKAnSwg4oCc ZXB14oCdLCBhbmQg4oCcZXB24oCdIG11c3QgYmUgdW5kZXJzdG9vZCBhbmQgdXNlZCB3aGVuIOKA nGFsZ+KAnSBvciDigJxlbmPigJ0gdmFsdWVzIHJlcXVpcmluZyB0aGVtIGFyZSB1c2VkLCBhbmQg b3RoZXJ3aXNlIHRoZXkgbWF5IGJlIGlnbm9yZWQuDQoNCjMuICBEZWZpbmUgYSBuZXcgaGVhZGVy IGZpZWxkIHRoYXQgbGlzdHMgd2hpY2ggYWRkaXRpb25hbCBmaWVsZHMgbm90IGRlZmluZWQgaW4g dGhlIGJhc2Ugc3BlY2lmaWNhdGlvbnMgbXVzdCBiZSB1bmRlcnN0b29kIGFuZCBhY3RlZCB1cG9u IHdoZW4gcHJlc2VudC4gIEZvciBpbnN0YW5jZSwgYW4gZXhwaXJhdGlvbi10aW1lIGV4dGVuc2lv biBmaWVsZCBjb3VsZCBiZSBtYXJrZWQgYXMgbXVzdC1iZS11bmRlcnN0b29kLWFuZC1hY3RlZC11 cG9uLiAgT25lIHBvc3NpYmxlIG5hbWUgZm9yIHRoaXMgd291bGQgYmUg4oCcY3JpdOKAnSAoY3Jp dGljYWwpLiAgQW4gZXhhbXBsZSB1c2UsIGFsb25nIHdpdGggYSBoeXBvdGhldGljYWwg4oCcZXhw 4oCdIChleHBpcmF0aW9uLXRpbWUpIGZpZWxkIGlzOg0KDQogIHsiYWxnIjoiRVMyNTYiLA0KICAg ImNyaXQiOlsiZXhwIl0sDQogICAiZXhw4oCdOjEzNjMyODQwMDANCiAgfQ0KDQo0LiAgQWxsIGFk ZGl0aW9uYWwgaGVhZGVyIGZpZWxkcyBub3QgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0 aW9ucyBhbmQgbm90IGNvbnRhaW5lZCBpbiB0aGUg4oCcY3JpdOKAnSBsaXN0IE1VU1QgYmUgaWdu b3JlZCBpZiBub3QgdW5kZXJzdG9vZC4NCg0KNS4gIERlZmluZSBhIG5ldyBoZWFkZXIgZmllbGQg 4oCcYXNk4oCdIChhcHBsaWNhdGlvbi1zcGVjaWZpYyBkYXRhKSB3aG9zZSB2YWx1ZSBpcyBhIEpT T04gc3RydWN0dXJlIHdob3NlIGNvbnRlbnRzIGFyZSBvcGFxdWUgdG8gYW5kIGlnbm9yZWQgYnkg SldTIGFuZCBKV0UgaW1wbGVtZW50YXRpb25zIGJ1dCBmb3Igd2hpY2ggaXRzIGNvbnRlbnRzIE1V U1QgYmUgcHJvdmlkZWQgdG8gYXBwbGljYXRpb25zIHVzaW5nIEpXUyBvciBKV0UsIHByb3ZpZGVk IHRoYXQgdGhlIHNpZ25hdHVyZS9NQUMgdmFsaWRhdGlvbiBvciBkZWNyeXB0aW9uIG9wZXJhdGlv biBzdWNjZWVkcy4gIFRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhpcyBmaWVsZCBpcyB0byBoYXZlIGEg c3RhbmRhcmQgcGxhY2UgdG8gcHJvdmlkZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBtZXRhZGF0YSBh Ym91dCB0aGUgcGF5bG9hZCBvciBwbGFpbnRleHQuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0 Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2UNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGll dGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFp bGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg0K --_000_4E1F6AAD24975D4BA5B1680429673943674FBA8ETK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: <58FBE4B29E60AC4C9A89DC7C1019BC2D@microsoft.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPGRpdiBzdHlsZT0i Zm9udC1mYW1pbHk6Q2FsaWJyaSwmcXVvdDtTZWdvZSBVSSZxdW90OyxNZWlyeW8sJnF1b3Q7TWlj cm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LCZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSBVSSZxdW90Oywm cXVvdDtNYWxndW4gR290aGljJnF1b3Q7LCZxdW90O0tobWVyIFVJJnF1b3Q7LCZxdW90O05pcm1h bGEgVUkmcXVvdDssVHVuZ2EsJnF1b3Q7TGFvIFVJJnF1b3Q7LEVicmltYSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNnB4OyI+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+VGhlIGNv bnRlbnQgdHlwZSBmaWVsZCBpcyB1c2VkIGFzJm5ic3A7aW5wdXQgdG8gY3J5cHRvIHByb2Nlc3Np bmcgcnVsZXMgYW5kIGlzIG5vdCBuZWNlc3NhcmlseSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBkYXRh LiZuYnNwOyBGb3IgaW5zdGFuY2UsIHNlZSBKV1TigJlzIG5vcm1hdGl2ZSB1c2Ugb2YgdGhlIGZp ZWxkIHRvIGNvbnZleSBzdHJ1Y3R1cmFsIGluZm9ybWF0aW9uIGluDQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpzb24td2ViLXRva2VuLTA2I3Nl Y3Rpb24tNyI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9hdXRoLWpz b24td2ViLXRva2VuLTA2I3NlY3Rpb24tNzwvYT4uPC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9t cG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNvbG9y OiByZ2IoMjI5LCAyMjksIDIyOSk7IGJvcmRlci10b3Atd2lkdGg6IDJweDsgYm9yZGVyLXRvcC1z dHlsZTogc29saWQ7IiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPg0KPHN0cm9uZz5Gcm9t Ojwvc3Ryb25nPiZuYnNwO01hbmdlciwgSmFtZXMgSDxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9u Zz4mbmJzcDvigI5NYXJjaOKAjiDigI4xMuKAjiwg4oCOMjAxMyDigI424oCOOuKAjjQw4oCOIOKA jkFNPGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4mbmJzcDtNaWtlIEpvbmVzLCBybGJAaXB2LnN4 PGJyPg0KPHN0cm9uZz5DQzo8L3N0cm9uZz4mbmJzcDtqb3NlQGlldGYub3JnPGJyPg0KPHN0cm9u Zz5TdWJqZWN0Ojwvc3Ryb25nPiZuYnNwO1JlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBv ZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWU6IG1ldGEvYXNkPGJyPg0KPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KSSB3b3VsZCBwdXQgJnF1b3Q7Y3R5JnF1b3Q7IChjb250ZW50IHR5cGUpIHVu ZGVyICZxdW90O21ldGEmcXVvdDsuPGJyPg0KPGJyPg0KTWlrZSwgZG8geW91IHRoaW5rICZxdW90 O2N0eSZxdW90OyBpc24ndCBuZWVkZWQsIG9yIHRoYXQgdGhlcmUgaXMgbm8gdmFsdWUgaW4gc2Vw YXJhdGluZyBzdWNoIGEgZmllbGQgZnJvbSB0aGUgb3RoZXJzPzxicj4NCjxicj4NCi0tPGJyPg0K SmFtZXMgTWFuZ2VyPGJyPg0KPGJyPg0KLS0tLS0gUmVwbHkgbWVzc2FnZSAtLS0tLTxicj4NCkZy b206ICZxdW90O01pa2UgSm9uZXMmcXVvdDsgJmx0O01pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNv bSZndDs8YnI+DQpEYXRlOiBXZWQsIE1hciAxMywgMjAxMyAxMjowNyBhbTxicj4NClN1YmplY3Q6 IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZTxi cj4NClRvOiAmcXVvdDtKb2huIEJyYWRsZXkmcXVvdDsgJmx0O3ZlN2p0YkB2ZTdqdGIuY29tJmd0 OywgJnF1b3Q7UmljaGFyZCBCYXJuZXMmcXVvdDsgJmx0O3JsYkBpcHYuc3gmZ3Q7PGJyPg0KQ2M6 ICZxdW90O1RpbSBCcmF5JnF1b3Q7ICZsdDt0YnJheUB0ZXh0dWFsaXR5LmNvbSZndDssICZxdW90 O01hbmdlciwgSmFtZXMgSCZxdW90OyAmbHQ7SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bSZndDssICZxdW90O0thcmVuIE8mYW1wO2Fwb3M7RG9ub2dodWUmcXVvdDsgJmx0O29kb25vZ2h1 ZUBpc29jLm9yZyZndDssICZxdW90O2pvc2UmcXVvdDsgJmx0O2pvc2VAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGJyPg0KSeKAmW0gd2l0aCBSaWNoYXJkIG9uIHRoaXMuJm5ic3A7IFRoZSBhcHBsaWNhdGlv bi1zcGVjaWZpYy1kYXRhL21ldGEgZmllbGQgaXNu4oCZdCBuZWVkZWQuPGJyPg0KPGJyPg0KLS0g TWlrZTxicj4NCjxicj4NCkZyb206IFJpY2hhcmQgQmFybmVzPGJyPg0KU2VudDog4oCOTWFyY2ji gI4g4oCOMTHigI4sIOKAjjIwMTMg4oCOMTDigI464oCOMDLigI4g4oCOUE08YnI+DQpUbzogSm9o biBCcmFkbGV5PGJyPg0KQ0M6IFRpbSBCcmF5LCBNYW5nZXIsIEphbWVzIEgsIEthcmVuIE9Eb25v Z2h1ZSwgam9zZTxicj4NClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBv ZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWU8YnI+DQo8YnI+DQomIzQzOzEgdG8gY2hlZXJzLiZu YnNwOyBJIGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi48YnI+DQo8YnI+DQpGV0lX LCBteSBwcmVmZXJlbmNlIHdvdWxkIGJlIHRvIGdldCByaWQgb2YgJnF1b3Q7YXNkJnF1b3Q7IG9y ICZxdW90O21ldGEmcXVvdDsgKHBhcnQgNSkuJm5ic3A7IEkgZG9uJ3QgdGhpbmsgaXQncyByZWxl dmFudCB0byB0aGUgY3JpdGljYWxpdHkgZGlzY3Vzc2lvbiwgYW5kIGl0J3MganVzdCBub3QgbmVl ZGVkLjxicj4NCjxicj4NCi0tUmljaGFyZDxicj4NCjxicj4NCjxicj4NCjxicj4NCk9uIE1vbiwg TWFyIDExLCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJyYWRsZXkgJmx0O3ZlN2p0YkB2ZTdqdGIu Y29tJmx0O21haWx0bzp2ZTdqdGJAdmU3anRiLmNvbSZndDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4N Ck9uIDIwMTMtMDMtMTEsIGF0IDEwOjQ4IFBNLCAmcXVvdDtNYW5nZXIsIEphbWVzIEgmcXVvdDsg Jmx0O0phbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20mbHQ7bWFpbHRvOkphbWVzLkguTWFu Z2VyQHRlYW0udGVsc3RyYS5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpJ4oCZbGwgYWRk IHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRvZXMgbG9vayBsaWtlIHN1YnN0YW50aWFsIHByb2dyZXNz Ljxicj4NCjxicj4NCkkgYXNzdW1lIHRoZSBmaWVsZHMgc3VjaCBhcyDigJxlcGvigJ0sIOKAnGFw deKAnSBldGMgdGhhdCBzb21ldGltZXMgbXVzdCBiZSB1bmRlcnN0b29kLCBhbmQgYXQgb3RoZXIg dGltZXMgbXVzdCBiZSBpZ25vcmVkIChkZXBlbmRpbmcgb24g4oCcYWxn4oCdIG9yIOKAnGVuY+KA nSB2YWx1ZSkgd291bGQgTk9UIGJlIGxpc3RlZCBpbiB0aGUg4oCcY3JpdOKAnSBmaWVsZCBhcyB0 aGV5IGFyZSBkZWZpbmVkIGluIHRoZSDigJxiYXNlIHNwZWNz4oCdLjxicj4NCjxicj4NCkNvcnJl Y3Q8YnI+DQo8YnI+DQpCZWluZyBpbiB0aGUg4oCcYmFzZSBzcGVjc+KAnSBpcyB0aGUgcmlnaHQg Y3JpdGVyaWEgZm9yIHdoZXRoZXIgYSBmaWVsZCBzaG91bGQgYmUgbGlzdGVkIGluIOKAnGNyaXTi gJ0gYXMgbG9uZyBhcyDigJxiYXNlIHNwZWNz4oCdIG1lYW5zOiDigJxiYXNlIHNwZWNpZmljYXRp b25zIGZvciB0aGUgcGFydGljdWxhciDigJxhbGfigJ0v4oCdZW5j4oCdIHZhbHVlc+KAnS4gSXQg c2hvdWxkbuKAmXQgbWVhbiAoYW5kIGRvZXNu4oCZdCBoYXZlIHRvIG1lYW4pIHRoZSBiYXNlIHNw ZWMgZm9yIHRoZSB3aG9sZQ0KIEpPU0Ugc3lzdGVtLjxicj4NCjxicj4NCjxicj4NCkNyaXQgaXMg b25seSBmb3IgZXh0ZW5zaW9ucywgaXQgaXMgdXAgdG8gdGhlIGV4dGVuc2lvbiBkZWZpbml0aW9u IHRvIGRlY2lkZSBpZiB0aGUgZmllbGQgbmVlZHMgdG8gYmUgaW4gY3JpdC48YnI+DQo8YnI+DQo8 YnI+DQpQLlMuIOKAnG1ldGHigJ0gbWlnaHQgYmUgYSBuaWNlciBsYWJlbCB0aGFuIOKAnGFzZOKA nS48YnI+DQo8YnI+DQpJIGRvbid0IGhhdmUgYW55IHBhcnRpY3VsYXIgYXR0YWNobWVudCB0byB0 aGUgbmFtZS4mbmJzcDsmbmJzcDsgU29tZSBwbGFjZXMgdGhpbmdzIGxpa2UgdGhpcyBhcmUgY2Fs bGVkIGFzc29jaWF0ZWQgZGF0YSwgdGhvdWdoIG5vdCB0aGUgcGxhY2VzIG5vcm1hbCBwZW9wbGUg Z28gSSBncmFudCB5b3UuPGJyPg0KTWV0YS1kYXRhIGFib3V0IHRoZSBwYXlsb2FkIGlzIHdoYXQg aXQgaXMsJm5ic3A7IFRoZSBjdXJyZW50IHByYWN0aWNlIGlzIHRvIHVzZSB0aHJlZSBjaGFyYWN0 ZXIgbmFtZXMuJm5ic3A7Jm5ic3A7IEkgYW0gZmluZSB3aXRoIG1ldCBvciBtZXRhIChJIHN1c3Bl Y3QgdGhhdCBpZiB5b3UgYXJlIHRocm93aW5nIGNyYXAgaW50byB0aGUgZW52ZWxvcGUgdGhlIHNp bmdsZSBjaGFyYWN0ZXIgd29uJ3Qga2lsbCBhbnlvbmUuPGJyPg0KPGJyPg0KSmFtZXMgaWYgeW91 IGxpa2UgdGhlIHNvbHV0aW9uIGFuZCB3YW50IGl0IHRvIGJlIG1ldGEgSSB3aWxsIGJhY2sgeW91 IG9uIGl0IDopPGJyPg0KPGJyPg0KSm9obiBCLjxicj4NCjxicj4NCjxicj4NCi0tPGJyPg0KSmFt ZXMgTWFuZ2VyPGJyPg0KPGJyPg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnJmx0O21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IFttYWlsdG86am9zZS0mbHQ7bWFpbHRvOmpvc2Ut Jmd0O2JvdW5jZXNAaWV0Zi5vcmcmbHQ7bWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmcmZ3Q7XSBPbiBC ZWhhbGYgT2YgVGltIEJyYXk8YnI+DQpTZW50OiBUdWVzZGF5LCAxMiBNYXJjaCAyMDEzIDEyOjQz IFBNPGJyPg0KVG86IEthcmVuIE9Eb25vZ2h1ZTxicj4NCkNjOiBqb3NlPGJyPg0KU3ViamVjdDog UmU6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1 ZTxicj4NCjxicj4NCkN1ZSB3aWxkIGNoZWVycyBmcm9tIHRoZSBwZWFudXQgZ2FsbGVyeSB3aGVy ZSBub24tY3J5cHRvZ3JhcGhlcnMgc2l0LiZuYnNwOyBNdXN0SWdub3JlIGlzIGluZmluaXRlbHkg bW9yZSByb2J1c3QgYW5kIG9wZW4tZW5kZWQgdGhhbiBNdXN0VW5kZXJzdGFuZC4mbmJzcDsgLVQ8 YnI+DQo8YnI+DQpPbiBNb24sIE1hciAxMSwgMjAxMyBhdCA1OjMxIFBNLCBLYXJlbiBPJ0Rvbm9n aHVlICZsdDtvZG9ub2dodWVAaXNvYy5vcmcmbHQ7bWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZyZn dDsmZ3Q7IHdyb3RlOjxicj4NCjxicj4NCkZvbGtzLDxicj4NCjxicj4NCkEgc2lkZSBtZWV0aW5n IHdhcyBoZWxkIFN1bmRheSB3aXRoIGEgbnVtYmVyIG9mIGpvc2Ugd29ya2luZyBncm91cCBwYXJ0 aWNpcGFudHMgdG8gdHJ5IHRvIHJlc29sdmUgdGhlIG9wZW4gaXNzdWUgcmVsYXRlZCB0byBoZWFk ZXIgY3JpdGljYWxpdHkuIFRoZSBmb2xsb3dpbmcgYXJlIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9u cyBmcm9tIHRoZSBtZWV0aW5nLiBQb2ludCA1IG9mIHRoZSBwcm9wb3NlZCByZXNvbHV0aW9uIGJl bG93IGlzIGFjdHVhbGx5DQogaW5kZXBlbmRlbnQgb2YgdGhlIG90aGVyIDQgcG9pbnRzLCBhbmQg Y291bGQgYmUgY29uc2lkZXJlZCBzZXBhcmF0ZWx5LiBUaGlzIHdpbGwgYWxsIGJlIGRpc2N1c3Nl ZCBpbiBXZWRuZXNkYXkncyBtZWV0aW5nLjxicj4NCjxicj4NCkluIGFkZGl0aW9uIHRvIHRoZSB0 ZXh0IGJlbG93LCB0aGVyZSB3YXMgc29tZSBhZ3JlZW1lbnQgdG8gcmVwbGFjZSB0aGUgJnF1b3Q7 dW5kZXJzdGFuZCZxdW90OyB0ZXh0IHdpdGggc29tZXRoaW5nIGEgYml0IG1vcmUgZXhwbGljaXQg bGlrZSAmcXVvdDttdXN0IHByb2Nlc3MmcXVvdDsuIEhvd2V2ZXIsIHRoYXQgdGV4dCBoYXMgbm90 IGJlZW4gcm9sbGVkIGludG8gdGhlIHN1bW1hcnkgdGV4dCBiZWxvdyB5ZXQuPGJyPg0KPGJyPg0K VGhhbmsgeW91IHRvIEppbSBTY2hhYWQsIE1pa2UgSm9uZXMsIEpvaG4gQnJhZGxleSwgTmF0IFNh a2ltdXJhLCBNYXJ0aW4gVGhvbWFzLCBFcmljIFJlc2NvcmxhLCBNYXR0IE1pbGxlciwgYW5kIFJp Y2hhcmQgQmFybmVzIGZvciB5b3VyIGVmZm9ydHMgKGFuZCBteSBhcG9sb2dpZXMgaWYgSSBtaXNz ZWQgc29tZW9uZSkuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpLYXJlbjxicj4NCjxicj4NCjE6 Jm5ic3A7IENoYW5nZSB0aGUgbGFuZ3VhZ2Ug4oCcQWRkaXRpb25hbCBtZW1iZXJzIE1BWSBiZSBw cmVzZW50IGluIHRoZSBKV0suJm5ic3A7IElmIHByZXNlbnQsIHRoZXkgTVVTVCBiZSB1bmRlcnN0 b29kIGJ5IGltcGxlbWVudGF0aW9ucyB1c2luZyB0aGVtLuKAnSB0byDigJxBZGRpdGlvbmFsIG1l bWJlcnMgTUFZIGJlIHByZXNlbnQgaW4gdGhlIEpXSy4mbmJzcDsgSWYgbm90IHVuZGVyc3Rvb2Qg YnkgaW1wbGVtZW50YXRpb25zIGVuY291bnRlcmluZyB0aGVtLCB0aGV5IE1VU1QNCiBiZSBpZ25v cmVkLuKAnSZuYnNwOyAoQW5kIG1ha2UgdGhlIHNhbWUgY2hhbmdlIGZvciBKV0sgU2V0IGFzIHdl bGwuKTxicj4NCjxicj4NCjI6Jm5ic3A7IENoYXJhY3Rlcml6ZSBhbGwgZXhpc3RpbmcgSldTIGFu ZCBKV0UgaGVhZGVyIGZpZWxkcyBhcyBlaXRoZXIgbXVzdCBiZSB1bmRlcnN0b29kIG9yIG1heSBi ZSBpZ25vcmVkLiZuYnNwOyDigJxhbGfigJ0sIOKAnGVuY+KAnSwgYW5kIOKAnHppcOKAnSBtdXN0 IGJlIHVuZGVyc3Rvb2QuJm5ic3A7IOKAnGtpZOKAnSwg4oCceDV14oCdLCDigJx4NWPigJ0sIOKA nHg1dOKAnSwg4oCcandr4oCdLCDigJxqa3XigJ0sIOKAnHR5cOKAnSwgYW5kIOKAnGN0eeKAnSBj YW4gYmUgaWdub3JlZCBiZWNhdXNlIHdoaWxlIG5vdCB1c2luZyB0aGVtIG1heQ0KIHJlc3VsdCBp biB0aGUgaW5hYmlsaXR5IHRvIHByb2Nlc3Mgc29tZSBzaWduYXR1cmVzIG9yIGVuY3J5cHRlZCBj b250ZW50LCB0aGlzIHdpbGwgbm90IHJlc3VsdCBpbiBhIHNlY3VyaXR5IHZpb2xhdGlvbiDigJMg anVzdCBkZWdyYWRlZCBmdW5jdGlvbmFsaXR5LiZuYnNwOyBPdGhlciBmaWVsZHMgc3VjaCBhcyDi gJxlcGvigJ0sIOKAnGFwdeKAnSwg4oCcYXB24oCdLCDigJxlcHXigJ0sIGFuZCDigJxlcHbigJ0g bXVzdCBiZSB1bmRlcnN0b29kIGFuZCB1c2VkIHdoZW4g4oCcYWxn4oCdIG9yIOKAnGVuY+KAnQ0K IHZhbHVlcyByZXF1aXJpbmcgdGhlbSBhcmUgdXNlZCwgYW5kIG90aGVyd2lzZSB0aGV5IG1heSBi ZSBpZ25vcmVkLjxicj4NCjxicj4NCjMuJm5ic3A7IERlZmluZSBhIG5ldyBoZWFkZXIgZmllbGQg dGhhdCBsaXN0cyB3aGljaCBhZGRpdGlvbmFsIGZpZWxkcyBub3QgZGVmaW5lZCBpbiB0aGUgYmFz ZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVwb24gd2hlbiBw cmVzZW50LiZuYnNwOyBGb3IgaW5zdGFuY2UsIGFuIGV4cGlyYXRpb24tdGltZSBleHRlbnNpb24g ZmllbGQgY291bGQgYmUgbWFya2VkIGFzIG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0ZWQtdXBv bi4mbmJzcDsNCiBPbmUgcG9zc2libGUgbmFtZSBmb3IgdGhpcyB3b3VsZCBiZSDigJxjcml04oCd IChjcml0aWNhbCkuJm5ic3A7IEFuIGV4YW1wbGUgdXNlLCBhbG9uZyB3aXRoIGEgaHlwb3RoZXRp Y2FsIOKAnGV4cOKAnSAoZXhwaXJhdGlvbi10aW1lKSBmaWVsZCBpczo8YnI+DQo8YnI+DQombmJz cDsgeyZxdW90O2FsZyZxdW90OzomcXVvdDtFUzI1NiZxdW90Oyw8YnI+DQombmJzcDsmbmJzcDsg JnF1b3Q7Y3JpdCZxdW90OzpbJnF1b3Q7ZXhwJnF1b3Q7XSw8YnI+DQombmJzcDsmbmJzcDsgJnF1 b3Q7ZXhw4oCdOjEzNjMyODQwMDA8YnI+DQombmJzcDsgfTxicj4NCjxicj4NCjQuJm5ic3A7IEFs bCBhZGRpdGlvbmFsIGhlYWRlciBmaWVsZHMgbm90IGRlZmluZWQgaW4gdGhlIGJhc2Ugc3BlY2lm aWNhdGlvbnMgYW5kIG5vdCBjb250YWluZWQgaW4gdGhlIOKAnGNyaXTigJ0gbGlzdCBNVVNUIGJl IGlnbm9yZWQgaWYgbm90IHVuZGVyc3Rvb2QuPGJyPg0KPGJyPg0KNS4mbmJzcDsgRGVmaW5lIGEg bmV3IGhlYWRlciBmaWVsZCDigJxhc2TigJ0gKGFwcGxpY2F0aW9uLXNwZWNpZmljIGRhdGEpIHdo b3NlIHZhbHVlIGlzIGEgSlNPTiBzdHJ1Y3R1cmUgd2hvc2UgY29udGVudHMgYXJlIG9wYXF1ZSB0 byBhbmQgaWdub3JlZCBieSBKV1MgYW5kIEpXRSBpbXBsZW1lbnRhdGlvbnMgYnV0IGZvciB3aGlj aCBpdHMgY29udGVudHMgTVVTVCBiZSBwcm92aWRlZCB0byBhcHBsaWNhdGlvbnMgdXNpbmcgSldT IG9yIEpXRSwgcHJvdmlkZWQgdGhhdA0KIHRoZSBzaWduYXR1cmUvTUFDIHZhbGlkYXRpb24gb3Ig ZGVjcnlwdGlvbiBvcGVyYXRpb24gc3VjY2VlZHMuJm5ic3A7IFRoZSBpbnRlbmRlZCB1c2Ugb2Yg dGhpcyBmaWVsZCBpcyB0byBoYXZlIGEgc3RhbmRhcmQgcGxhY2UgdG8gcHJvdmlkZSBhcHBsaWNh dGlvbi1zcGVjaWZpYyBtZXRhZGF0YSBhYm91dCB0aGUgcGF5bG9hZCBvciBwbGFpbnRleHQuPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCmpvc2VAaWV0Zi5vcmcmbHQ7 bWFpbHRvOmpvc2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9qb3NlPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4NCmpvc2VAaWV0Zi5v cmcmbHQ7bWFpbHRvOmpvc2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9qb3NlPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpqb3NlIG1haWxpbmcgbGlzdDxicj4N Cmpvc2VAaWV0Zi5vcmcmbHQ7bWFpbHRvOmpvc2VAaWV0Zi5vcmcmZ3Q7PGJyPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlPGJyPg0KPGJyPg0KPGJyPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B1680429673943674FBA8ETK5EX14MBXC283r_-- From tonynad@microsoft.com Tue Mar 12 07:07:13 2013 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 571A211E809C for ; Tue, 12 Mar 2013 07:07:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.534 X-Spam-Level: X-Spam-Status: No, score=0.534 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNRESOLVED_TEMPLATE=3.132] 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 BAVLemmpdxfE for ; Tue, 12 Mar 2013 07:07:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 5B75821F89C3 for ; Tue, 12 Mar 2013 07:07:12 -0700 (PDT) Received: from BL2FFO11FD023.protection.gbl (10.173.161.204) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 14:07:09 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 14:07:09 +0000 Received: from tx2outboundpool.messaging.microsoft.com (157.54.51.80) by mail.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Tue, 12 Mar 2013 14:06:52 +0000 Received: from mail162-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Mar 2013 14:05:11 +0000 Received: from mail162-tx2 (localhost [127.0.0.1]) by mail162-tx2-R.bigfish.com (Postfix) with ESMTP id 2982F4A0193 for ; Tue, 12 Mar 2013 14:05:11 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT001.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -18 X-BigFish: PS-18(zz98dI9371Ic89bh936eIc857hzz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kz97hz1033IL8275bh8275dh18c673hz31h2a8h668h839hd24hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail162-tx2: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT001.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail162-tx2 (localhost.localdomain [127.0.0.1]) by mail162-tx2 (MessageSwitch) id 1363097108163327_6940; Tue, 12 Mar 2013 14:05:08 +0000 (UTC) Received: from TX2EHSMHS040.bigfish.com (unknown [10.9.14.249]) by mail162-tx2.bigfish.com (Postfix) with ESMTP id 22253100090; Tue, 12 Mar 2013 14:05:08 +0000 (UTC) Received: from BL2PRD0310HT001.namprd03.prod.outlook.com (157.56.240.21) by TX2EHSMHS040.bigfish.com (10.9.99.140) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 12 Mar 2013 14:05:06 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT001.namprd03.prod.outlook.com (10.255.97.36) with Microsoft SMTP Server (TLS) id 14.16.275.5; Tue, 12 Mar 2013 14:05:06 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.620.20; Tue, 12 Mar 2013 14:05:03 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.143]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.7.89]) with mapi id 15.00.0620.020; Tue, 12 Mar 2013 14:05:03 +0000 From: Anthony Nadalin To: Jim Schaad , Richard Barnes , "Mike Jones" Thread-Topic: [jose] Proposed resolution of header criticality issue Thread-Index: AQHOHyqX0p3XkY/ZrUKl7wc3naQ6bA== Date: Tue, 12 Mar 2013 14:05:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.204] Content-Type: multipart/alternative; boundary="_000_faa9ca71018349558772a066dd9abd4dBY2PR03MB041namprd03pro_" MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEAM.TELSTRA.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%TEXTUALITY.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AUGUSTCELLARS.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IPV.SX$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VE7JTB.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC101.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC101.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(377424002)(24454001)(189002)(199002)(66066001)(16236675001)(76482001)(56776001)(20776003)(47736001)(47976001)(63696002)(5343635001)(56816002)(80022001)(33646001)(54316002)(77982001)(47446002)(50986001)(59766001)(51856001)(74502001)(65816001)(512874001)(5343655001)(69226001)(53806001)(54356001)(49866001)(1511001)(16676001)(79102001)(74662001)(31966008)(46102001)(44976002)(6806001)(4396001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB034; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: John Bradley , James H Manger , Tim Bray , jose , Karen O'Donoghue Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 14:07:13 -0000 --_000_faa9ca71018349558772a066dd9abd4dBY2PR03MB041namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 b2ggZ3JlYXQgbm93IHlvdSBhcmUgZ29pbmcgdG8gdGVsbCB1cyB3aGF0IGlzIGNyeXB0byByZWxh dGVkIGFuZCB3aGF0IGlzIG5vdCwgdGhhdCBpcyBwcmV0dHkgbXVjaCBuIGFwcGxpY2F0aW9uIGNh bGwgbm90IGEgc3BlYyBjYWxsDQoNClNlbnQgZnJvbSBXaW5kb3dzIE1haWwNCg0KRnJvbTogTWlr ZSBKb25lcw0KU2VudDog4oCOTWFyY2jigI4g4oCOMTLigI4sIOKAjjIwMTMg4oCON+KAjjrigI4w MuKAjiDigI5BTQ0KVG86IEppbSBTY2hhYWQsIFJpY2hhcmQgQmFybmVzDQpDQzogSm9obiBCcmFk bGV5LCBUaW0gQnJheSwgSmFtZXMgSCBNYW5nZXIsIEthcmVuIE8nRG9ub2dodWUsIGpvc2UNClN1 YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxp dHkgaXNzdWUNCg0KKzEgdG8gb25seSBwdXR0aW5nIGNyeXB0by1yZWxhdGVkIHRoaW5ncyBpbiB0 aGUgaGVhZGVycy4NCg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6IOKAjk1hcmNo4oCOIOKA jjEy4oCOLCDigI4yMDEzIOKAjjbigI464oCONTPigI4g4oCOQU0NClRvOiBKaW0gU2NoYWFkDQpD QzogSm9obiBCcmFkbGV5LCBNaWtlIEpvbmVzLCBKYW1lcyBIIE1hbmdlciwgVGltIEJyYXksIGpv c2UsIEthcmVuIE8nRG9ub2dodWUNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1 dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KTm90ZSB0aGF0IG15IHByb3Bvc2Vk IHRleHQgZGlkIG5vdCBzYXkgdGhhdCB0aGUgbGlicmFyaWVzIHdvdWxkIG5vdCByZXR1cm4gaGVh ZGVyIHN0dWZmLCBvbmx5IHRoYXQgeW91IHNob3VsZG4ndCBjcmFtIG5vbi1jcnlwdG8tcmVsYXRl ZCB0aGluZ3MgaW4gdGhlcmUuDQoNCg0KDQpPbiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMywgSmlt IFNjaGFhZCB3cm90ZToNCkkgYW0gbm90IHRydWx5IGhhcHB5IHdpdGggdGhpcyBpZGVhLiAgSWYg dGhlIGFwcGxpY2F0aW9uIGNhcmVzIGFib3V0IHdobyDigJxvd25z4oCdIGEga2V5IGZvciBhIHNp Z25hdHVyZSB0aGVuIGl0IG5lZWRzIHRvIHNvbWVob3cgZ2V0IHRoYXQgaW5mb3JtYXRpb24uICBU aGF0IG1heSBiZSBkb25lIGJ5IGdldHRpbmcgdGhlIHdheSBhbmQga2V5IGZyb20gdGhlIHNlY3Vy aXR5IGxpYnJhcnkgYW5kIHRoYXQgbWF5IGJlIGRvbmUgYnkganVzdCByZXR1cm5pbmcgdGhlIGNs YWltcyBmcm9tIHRoZSBlbnZlbG9wZS4NCg0KSmltDQoNCg0KRnJvbTogam9zZS1ib3VuY2VzQGll dGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBC cmFkbGV5DQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyA5OjE1IEFNDQpUbzogTWlrZSBK b25lcw0KQ2M6IFJpY2hhcmQgQmFybmVzOyBKYW1lcyBIIE1hbmdlcjsgVGltIEJyYXk7IGpvc2U7 IEthcmVuIE8nRG9ub2dodWUNClN1YmplY3Q6IFJlOiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlv biBvZiBoZWFkZXIgY3JpdGljYWxpdHkgaXNzdWUNCg0KDQoNCkkgYW0gT0sgd2l0aCBnZXR0aW5n IHJpZCBvZiBpdCBpZiB3ZSBtYWtlIGl0IGNsZWFyIHRoYXQgY2xhaW1zIGZyb20gdGhlIGVudmVs b3BlIHdpbGwgbm90IGJlIHBhc3NlZCBvbiB0byBhcHBsaWNhdGlvbnMuDQoNCg0KDQpJZiB3ZSBk b24ndCBkbyB0aGF0IHdlIHdpbGwgY29tcHJvbWlzZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4g bGlicmFyaWVzLiAgIEVudmVsb3BlIGlzIGZvciBKT1NFIG9ubHkgYW5kIG5vdCBtYWRlIGF2YWls YWJsZSwgdGhhdCBtYWtlcyB0aGluZ3MgbGlrZSB0aW1lc3RhbXBzIGFuZCBvdGhlciB0aGluZ3Mg dGhhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIgbmVlZHMgdG8gaW50ZXJwcmV0IGNhbid0IGdvIGlu IHRoZSBlbnZlbG9wZSB0aGV5IG5lZWQgdG8gYmUgaW4gdGhlIGJvZHkgaW4gc29tZSB3YXkuDQoN Cg0KDQpJIGp1c3Qgd2FudCBpdCBvbmUgd2F5IG9yIHRoZSBvdGhlci4NCg0KDQoNCkpvaG4gQi4N Cg0KDQoNCg0KDQpPbiAyMDEzLTAzLTEyLCBhdCA5OjA2IEFNLCBNaWtlIEpvbmVzIDxNaWNoYWVs LkpvbmVzQG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KDQoNCg0KSeKAmW0gd2l0aCBSaWNoYXJkIG9u IHRoaXMuICBUaGUgYXBwbGljYXRpb24tc3BlY2lmaWMtZGF0YS9tZXRhIGZpZWxkIGlzbuKAmXQg bmVlZGVkLg0KDQoNCg0KLS0gTWlrZQ0KDQoNCg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6 IE1hcmNoIDExLCAyMDEzIDEwOjAyIFBNDQpUbzogSm9obiBCcmFkbGV5DQpDQzogVGltIEJyYXks IE1hbmdlciwgSmFtZXMgSCwgS2FyZW4gT0Rvbm9naHVlLCBqb3NlDQpTdWJqZWN0OiBSZTogW2pv c2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlDQoNCg0K DQorMSB0byBjaGVlcnMuICBJIGFscmVhZHkgaGlnaC1maXZlZCBNaWtlIGluIHBlcnNvbi4NCg0K DQoNCkZXSVcsIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gZ2V0IHJpZCBvZiAiYXNkIiBvciAi bWV0YSIgKHBhcnQgNSkuICBJIGRvbid0IHRoaW5rIGl0J3MgcmVsZXZhbnQgdG8gdGhlIGNyaXRp Y2FsaXR5IGRpc2N1c3Npb24sIGFuZCBpdCdzIGp1c3Qgbm90IG5lZWRlZC4NCg0KDQoNCi0tUmlj aGFyZA0KDQoNCg0KDQoNCk9uIE1vbiwgTWFyIDExLCAyMDEzIGF0IDExOjAxIFBNLCBKb2huIEJy YWRsZXkgPHZlN2p0YkB2ZTdqdGIuY29tPiB3cm90ZToNCg0KDQoNCk9uIDIwMTMtMDMtMTEsIGF0 IDEwOjQ4IFBNLCAiTWFuZ2VyLCBKYW1lcyBIIiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJh LmNvbT4gd3JvdGU6DQoNCg0KDQpJ4oCZbGwgYWRkIHNvbWUgY2hlZXJzIOKAlCB0aGlzIGRvZXMg bG9vayBsaWtlIHN1YnN0YW50DQo= --_000_faa9ca71018349558772a066dd9abd4dBY2PR03MB041namprd03pro_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHk+DQo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLCdTZWdvZSBVSScsTWVpcnlvLCdNaWNyb3NvZnQgWWFIZWkgVUknLCdNaWNyb3Nv ZnQgSmhlbmdIZWkgVUknLCdNYWxndW4gR290aGljJywnS2htZXIgVUknLCdOaXJtYWxhIFVJJyxU dW5nYSwnTGFvIFVJJyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdj5v aCBncmVhdCBub3cgeW91IGFyZSBnb2luZyB0byB0ZWxsIHVzIHdoYXQgaXMgY3J5cHRvIHJlbGF0 ZWQgYW5kIHdoYXQgaXMgbm90LCB0aGF0IGlzIHByZXR0eSBtdWNoIG4gYXBwbGljYXRpb24gY2Fs bCBub3QgYSBzcGVjIGNhbGw8L2Rpdj4NCjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+ DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5TZW50IGZyb20gV2luZG93cyBNYWlsPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNvbG9yOiBy Z2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lkdGg6IDFweDsgYm9yZGVyLXRvcC1zdHls ZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDtNaWtlIEpvbmVzPGJyPg0K PHN0cm9uZz5TZW50Ojwvc3Ryb25nPiZuYnNwO+KAjk1hcmNo4oCOIOKAjjEy4oCOLCDigI4yMDEz IOKAjjfigI464oCOMDLigI4g4oCOQU08YnI+DQo8c3Ryb25nPlRvOjwvc3Ryb25nPiZuYnNwO0pp bSBTY2hhYWQsIFJpY2hhcmQgQmFybmVzPGJyPg0KPHN0cm9uZz5DQzo8L3N0cm9uZz4mbmJzcDtK b2huIEJyYWRsZXksIFRpbSBCcmF5LCBKYW1lcyBIIE1hbmdlciwgS2FyZW4gTydEb25vZ2h1ZSwg am9zZTxicj4NCjxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4mbmJzcDtSZTogW2pvc2VdIFByb3Bv c2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPGJyPg0KPC9kaXY+DQo8 ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksJnF1b3Q7 U2Vnb2UgVUkmcXVvdDssTWVpcnlvLCZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OywmcXVv dDtNaWNyb3NvZnQgSmhlbmdIZWkgVUkmcXVvdDssJnF1b3Q7TWFsZ3VuIEdvdGhpYyZxdW90Oywm cXVvdDtLaG1lciBVSSZxdW90OywmcXVvdDtOaXJtYWxhIFVJJnF1b3Q7LFR1bmdhLCZxdW90O0xh byBVSSZxdW90OyxFYnJpbWEsc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNnB4OyI+DQo8ZGl2PiYj NDM7MSB0byZuYnNwO29ubHkgcHV0dGluZyBjcnlwdG8tcmVsYXRlZCB0aGluZ3MgaW4gdGhlIGhl YWRlcnMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXRvcC1j b2xvcjogcmdiKDIyOSwgMjI5LCAyMjkpOyBib3JkZXItdG9wLXdpZHRoOiAycHg7IGJvcmRlci10 b3Atc3R5bGU6IHNvbGlkOyI+DQo8c3Ryb25nPkZyb206PC9zdHJvbmc+Jm5ic3A7UmljaGFyZCBC YXJuZXM8YnI+DQo8c3Ryb25nPlNlbnQ6PC9zdHJvbmc+Jm5ic3A74oCOTWFyY2jigI4g4oCOMTLi gI4sIOKAjjIwMTMg4oCONuKAjjrigI41M+KAjiDigI5BTTxicj4NCjxzdHJvbmc+VG86PC9zdHJv bmc+Jm5ic3A7SmltIFNjaGFhZDxicj4NCjxzdHJvbmc+Q0M6PC9zdHJvbmc+Jm5ic3A7Sm9obiBC cmFkbGV5LCBNaWtlIEpvbmVzLCBKYW1lcyBIIE1hbmdlciwgVGltIEJyYXksIGpvc2UsIEthcmVu IE8nRG9ub2dodWU8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+Jm5ic3A7UmU6IFtqb3Nl XSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZTxicj4NCjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCk5vdGUgdGhhdCBteSBwcm9wb3NlZCB0ZXh0IGRpZCBu b3Qgc2F5IHRoYXQgdGhlIGxpYnJhcmllcyB3b3VsZCBub3QgcmV0dXJuIGhlYWRlciBzdHVmZiwg b25seSB0aGF0IHlvdSBzaG91bGRuJ3QgY3JhbSBub24tY3J5cHRvLXJlbGF0ZWQgdGhpbmdzIGlu IHRoZXJlLiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PHNwYW4+PC9zcGFuPjxicj4N Cjxicj4NCk9uIFR1ZXNkYXksIE1hcmNoIDEyLCAyMDEzLCBKaW0gU2NoYWFkIHdyb3RlOjxicj4N CjxibG9ja3F1b3RlIGNsYXNzPSIgZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBweCAwcHgg MHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJnYigyMDQs IDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5bGU6IHNv bGlkOyI+DQo8ZGl2IGxhbmc9IkVOLVVTIj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogJnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDExcHQ7Ij5J IGFtIG5vdCB0cnVseSBoYXBweSB3aXRoIHRoaXMgaWRlYS4mbmJzcDsgSWYgdGhlIGFwcGxpY2F0 aW9uIGNhcmVzIGFib3V0IHdobyDigJxvd25z4oCdIGEga2V5IGZvciBhIHNpZ25hdHVyZSB0aGVu IGl0IG5lZWRzIHRvIHNvbWVob3cgZ2V0IHRoYXQgaW5mb3JtYXRpb24uJm5ic3A7DQogVGhhdCBt YXkgYmUgZG9uZSBieSBnZXR0aW5nIHRoZSB3YXkgYW5kIGtleSBmcm9tIHRoZSBzZWN1cml0eSBs aWJyYXJ5IGFuZCB0aGF0IG1heSBiZSBkb25lIGJ5IGp1c3QgcmV0dXJuaW5nIHRoZSBjbGFpbXMg ZnJvbSB0aGUgZW52ZWxvcGUuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1p bHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXpl OiAxMXB0OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6 ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAx MXB0OyI+SmltPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+ PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0OyI+PHU+ PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXdpZHRoOiBt ZWRpdW0gbWVkaXVtIG1lZGl1bSAxLjVwdDsgYm9yZGVyLXN0eWxlOiBub25lIG5vbmUgbm9uZSBz b2xpZDsgYm9yZGVyLWNvbG9yOiBibGFjayBibGFjayBibGFjayBibHVlOyBwYWRkaW5nOiAwaW4g MGluIDBpbiA0cHQ7Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDFwdCBtZWRp dW0gbWVkaXVtOyBib3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLWNvbG9yOiBy Z2IoMTgxLCAxOTYsIDIyMykgYmxhY2sgYmxhY2s7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyI+DQo8 cCBjbGFzcz0iIE1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMHB0OyI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPg0KPGEgdGFiaW5kZXg9 Ii0xIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIj5q b3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIEJyYWRs ZXk8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMgOToxNSBBTTxicj4N CjxiPlRvOjwvYj4gTWlrZSBKb25lczxicj4NCjxiPkNjOjwvYj4gUmljaGFyZCBCYXJuZXM7IEph bWVzIEggTWFuZ2VyOyBUaW0gQnJheTsgam9zZTsgS2FyZW4gTydEb25vZ2h1ZTxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRp Y2FsaXR5IGlzc3VlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw Pjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHA+SSBhbSBPSyB3aXRoIGdldHRpbmcgcmlkIG9m IGl0IGlmIHdlIG1ha2UgaXQgY2xlYXIgdGhhdCBjbGFpbXMgZnJvbSB0aGUgZW52ZWxvcGUgd2ls bCBub3QgYmUgcGFzc2VkIG9uIHRvIGFwcGxpY2F0aW9ucy48dT48L3U+PHU+PC91PjwvcD4NCjxk aXY+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPklmIHdl IGRvbid0IGRvIHRoYXQgd2Ugd2lsbCBjb21wcm9taXNlIGludGVyb3BlcmFiaWxpdHkgYmV0d2Vl biBsaWJyYXJpZXMuICZuYnNwOyBFbnZlbG9wZSBpcyBmb3IgSk9TRSBvbmx5IGFuZCBub3QgbWFk ZSBhdmFpbGFibGUsIHRoYXQgbWFrZXMgdGhpbmdzIGxpa2UgdGltZXN0YW1wcyBhbmQgb3RoZXIg dGhpbmdzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIGxheWVyIG5lZWRzIHRvIGludGVycHJldCBjYW4n dCBnbyBpbiB0aGUgZW52ZWxvcGUgdGhleQ0KIG5lZWQgdG8gYmUgaW4gdGhlIGJvZHkgaW4gc29t ZSB3YXkuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48dT48L3U+Jm5ic3A7 PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPkkganVzdCB3YW50IGl0IG9uZSB3YXkgb3Ig dGhlIG90aGVyLjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+PHU+PC91PiZu YnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD5Kb2huIEIuPHU+PC91Pjx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cD5PbiAy MDEzLTAzLTEyLCBhdCA5OjA2IEFNLCBNaWtlIEpvbmVzICZsdDs8YSB0YWJpbmRleD0iLTEiPk1p Y2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48L3U+PC9w Pg0KPC9kaXY+DQo8cD48YnI+DQo8YnI+DQo8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+SeKAmW0gd2l0aCBSaWNoYXJkIG9uIHRoaXMuJm5i c3A7IFRoZSZuYnNwO2FwcGxpY2F0aW9uLXNwZWNpZmljLWRhdGEvbWV0YSBmaWVsZCBpc27igJl0 IG5lZWRlZC48dT48L3U+PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OzsiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7OyI+LS0gTWlrZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItd2lkdGg6IDEuNXB0IG1lZGl1bSBtZWRpdW07 IGJvcmRlci1zdHlsZTogc29saWQgbm9uZSBub25lOyBib3JkZXItY29sb3I6IHJnYigyMjksIDIy OSwgMjI5KSBibGFjayBibGFjazsgcGFkZGluZzogMGluOyI+DQo8cD48c3Ryb25nPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7OyI+RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij4mbmJzcDtSaWNoYXJkIEJh cm5lczxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5TZW50Ojwvc3Bhbj48L3N0cm9uZz4mbmJz cDtNYXJjaCAxMSwgMjAxMyAxMDowMiBQTTxicj4NCjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5Ubzo8 L3NwYW4+PC9zdHJvbmc+Jm5ic3A7Sm9obiBCcmFkbGV5PGJyPg0KPHN0cm9uZz48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OzsiPkNDOjwvc3Bhbj48L3N0cm9uZz4mbmJzcDtUaW0gQnJheSwgTWFuZ2VyLCBKYW1lcyBILCBL YXJlbiBPRG9ub2dodWUsIGpvc2U8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+U3ViamVjdDo8 L3NwYW4+PC9zdHJvbmc+Jm5ic3A7UmU6IFtqb3NlXSBQcm9wb3NlZCByZXNvbHV0aW9uIG9mIGhl YWRlciBjcml0aWNhbGl0eSBpc3N1ZTx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPiYjNDM7MSB0byBjaGVlcnMuICZuYnNwO0kgYWxyZWFk eSBoaWdoLWZpdmVkIE1pa2UgaW4gcGVyc29uLg0KPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Ij5GV0lXLCBteSBwcmVmZXJlbmNlIHdvdWxk IGJlIHRvIGdldCByaWQgb2YgJnF1b3Q7YXNkJnF1b3Q7IG9yICZxdW90O21ldGEmcXVvdDsgKHBh cnQgNSkuICZuYnNwO0kgZG9uJ3QgdGhpbmsgaXQncyByZWxldmFudCB0byB0aGUgY3JpdGljYWxp dHkgZGlzY3Vzc2lvbiwgYW5kIGl0J3MganVzdCBub3QgbmVlZGVkLiAmbmJzcDs8dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjx1PjwvdT4m bmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+ LS1SaWNoYXJkPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHA+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMTJwdDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+T24gTW9uLCBN YXIgMTEsIDIwMTMgYXQgMTE6MDEgUE0sIEpvaG4gQnJhZGxleSAmbHQ7PGEgdGFiaW5kZXg9Ii0x Ij52ZTdqdGJAdmU3anRiLmNvbTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48L3U+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwv cD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+T24gMjAxMy0wMy0xMSwg YXQgMTA6NDggUE0sICZxdW90O01hbmdlciwgSmFtZXMgSCZxdW90OyAmbHQ7PGEgdGFiaW5kZXg9 Ii0xIj5KYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPC9hPiZndDsgd3JvdGU6PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDogNXB0OyBtYXJnaW4tYm90dG9tOiA1cHQ7Ij4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogJnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7OyI+PHU+PC91PiZu YnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFu Zz0iRU4tQVUiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6ICZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1zaXplOiAxMXB0 OyI+SeKAmWxsIGFkZCBzb21lIGNoZWVycyDigJQgdGhpcyBkb2VzIGxvb2sgbGlrZSBzdWJzdGFu dDwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_faa9ca71018349558772a066dd9abd4dBY2PR03MB041namprd03pro_-- From rlb@ipv.sx Tue Mar 12 07:30:51 2013 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 4F85B21F86D5 for ; Tue, 12 Mar 2013 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 7t2dmjVigKOP for ; Tue, 12 Mar 2013 07:30:50 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id A8A3921F84CA for ; Tue, 12 Mar 2013 07:30:49 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so5779325oag.38 for ; Tue, 12 Mar 2013 07:30:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=HrAvqixjGjm1+1hPDsbURLq0sLU7Sm3L8wlzXlH5wrw=; b=K8WkGJvRtlGu8mvk/eiWMkQ+CucLbyNsHrsoZ4ysBh7t6hpky1AlhWaoV4nFEOTCPf ovjj17tsr0Hg0psxk486IPCih4E+KOh8tp8DnSpG98TPYj6iZSAkkTS6qAdRnHq3pFMg pihzs9V3OE7/JLFCBtdto3Y87vK1TK4sMUM4OP/YGUhkIMgdE7E2kBOLsEe1RS1sUiC5 w4Y0719qEzOhTv24co/5bIF2NzpENs9OMjyKH1lEuQt+HgKSzgCBFJitgresTd6cjQJE +eZHu+/5cjfJ65LSVGeDkknDURrh/jy5dOv6zkyrcw6CQJLNY7nWbSEHyTbIUuI8GYRU uRYw== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr12074464oec.126.1363098648062; Tue, 12 Mar 2013 07:30:48 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 07:30:47 -0700 (PDT) X-Originating-IP: [128.89.254.2] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943674FBA8E@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B1680429673943674FBA8E@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 10:30:47 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec54fae48b63f0904d7bb2243 X-Gm-Message-State: ALoCoQkhlrUIiaf81cH8XWyRH3MrtxmkHjWN9QSLxlTvqPMC0QyucWtTefZTAQheyXHBjdLF//c0 Cc: James H Manger , "jose@ietf.org" Subject: Re: [jose] Proposed resolution of header criticality issue: meta/asd 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, 12 Mar 2013 14:30:51 -0000 --bcaec54fae48b63f0904d7bb2243 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's a good example of an application making a field mandatory. It doesn't have to be mandatory in the base spec. Unlike with "zip", you don't have to understand "cty" when you validate a signature or decrypt an object. So I would put it in the "MAY ignore" bin. On Tue, Mar 12, 2013 at 10:06 AM, Mike Jones w= rote: > The content type field is used as input to crypto processing rules and > is not necessarily application-specific data. For instance, see JWT=92s > normative use of the field to convey structural information in > http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-7. > > *From:* Manger, James H > *Sent:* March 12, 2013 6:40 AM > *To:* Mike Jones, rlb@ipv.sx > *CC:* jose@ietf.org > *Subject:* Re: [jose] Proposed resolution of header criticality issue: > meta/asd > > I would put "cty" (content type) under "meta". > > Mike, do you think "cty" isn't needed, or that there is no value in > separating such a field from the others? > > -- > James Manger > > ----- Reply message ----- > From: "Mike Jones" > Date: Wed, Mar 13, 2013 12:07 am > Subject: [jose] Proposed resolution of header criticality issue > To: "John Bradley" , "Richard Barnes" > Cc: "Tim Bray" , "Manger, James H" < > James.H.Manger@team.telstra.com>, "Karen O'Donoghue" < > odonoghue@isoc.org>, "jose" > > I=92m with Richard on this. The application-specific-data/meta field isn= =92t > needed. > > -- Mike > > From: Richard Barnes > Sent: March 11, 2013 10:02 PM > To: John Bradley > CC: Tim Bray, Manger, James H, Karen ODonoghue, jose > Subject: Re: [jose] Proposed resolution of header criticality issue > > +1 to cheers. I already high-fived Mike in person. > > FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I > don't think it's relevant to the criticality discussion, and it's just no= t > needed. > > --Richard > > > > On Mon, Mar 11, 2013 at 11:01 PM, John Bradley ve7jtb@ve7jtb.com>> wrote: > > On 2013-03-11, at 10:48 PM, "Manger, James H" < > James.H.Manger@team.telstra.com> > wrote: > > I=92ll add some cheers =97 this does look like substantial progress. > > I assume the fields such as =93epk=94, =93apu=94 etc that sometimes must = be > understood, and at other times must be ignored (depending on =93alg=94 or= =93enc=94 > value) would NOT be listed in the =93crit=94 field as they are defined in= the > =93base specs=94. > > Correct > > Being in the =93base specs=94 is the right criteria for whether a field s= hould > be listed in =93crit=94 as long as =93base specs=94 means: =93base specif= ications for > the particular =93alg=94/=94enc=94 values=94. It shouldn=92t mean (and do= esn=92t have to > mean) the base spec for the whole JOSE system. > > > Crit is only for extensions, it is up to the extension definition to > decide if the field needs to be in crit. > > > P.S. =93meta=94 might be a nicer label than =93asd=94. > > I don't have any particular attachment to the name. Some places things > like this are called associated data, though not the places normal people > go I grant you. > Meta-data about the payload is what it is, The current practice is to us= e > three character names. I am fine with met or meta (I suspect that if yo= u > are throwing crap into the envelope the single character won't kill anyon= e. > > James if you like the solution and want it to be meta I will back you on > it :) > > John B. > > > -- > James Manger > > From: jose-bounces@ietf.org [mailto:jose- > bounces@ietf.org] On Behalf Of Tim > Bray > Sent: Tuesday, 12 March 2013 12:43 PM > To: Karen ODonoghue > Cc: jose > Subject: Re: [jose] Proposed resolution of header criticality issue > > Cue wild cheers from the peanut gallery where non-cryptographers sit. > MustIgnore is infinitely more robust and open-ended than MustUnderstand. = -T > > On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue > wrote: > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the meeting. > Point 5 of the proposed resolution below is actually independent of the > other 4 points, and could be considered separately. This will all be > discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must process". > However, that text has not been rolled into the summary text below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the JWK. = If > present, they MUST be understood by implementations using them.=94 to > =93Additional members MAY be present in the JWK. If not understood by > implementations encountering them, they MUST be ignored.=94 (And make th= e > same change for JWK Set as well.) > > 2: Characterize all existing JWS and JWE header fields as either must be > understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 must b= e understood. > =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ= =94, and =93cty=94 can be ignored > because while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as =93epk= =94, > =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be understood and use= d when =93alg=94 or > =93enc=94 values requiring them are used, and otherwise they may be ignor= ed. > > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon when > present. For instance, an expiration-time extension field could be marke= d > as must-be-understood-and-acted-upon. One possible name for this would b= e > =93crit=94 (critical). An example use, along with a hypothetical =93exp= =94 > (expiration-time) field is: > > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } > > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not understoo= d. > > 5. Define a new header field =93asd=94 (application-specific data) whose > value is a JSON structure whose contents are opaque to and ignored by JWS > and JWE implementations but for which its contents MUST be provided to > applications using JWS or JWE, provided that the signature/MAC validation > or decryption operation succeeds. The intended use of this field is to > have a standard place to provide application-specific metadata about the > payload or plaintext. > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > --bcaec54fae48b63f0904d7bb2243 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That's a good example of an application making a field mandatory. =A0It= doesn't have to be mandatory in the base spec. =A0Unlike with "zi= p", you don't have to understand "cty" when you validate= a signature or decrypt an object.


So I would put it in the "MAY ignore" bin.


On Tue, Mar 12, 2013 at 10:06 AM, Mike = Jones <Michael.Jones@microsoft.com> wrote:
The content type field is used as=A0input to crypto processing rules a= nd is not necessarily application-specific data.=A0 For instance, see JWT= =92s normative use of the field to convey structural information in http://tools.ietf.org/html/draft-ietf-oauth-json-web-token-06#section-7= .
=A0
From:=A0Manger, James H
Sent:=A0March 12, 2013 6:40 AM
To:=A0Mike Jones, rlb@ipv.sx
CC:=A0j= ose@ietf.org
Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue: meta/asd
=A0
I would put "cty" (content type) under "meta".

Mike, do you think "cty" isn't needed, or that there is no va= lue in separating such a field from the others?

--
James Manger

----- Reply message -----
From: "Mike Jones" <Michael.Jones@microsoft.com>
Date: Wed, Mar 13, 2013 12:07 am
Subject: [jose] Proposed resolution of header criticality issue
To: "John Bradley" <ve7jtb@ve7jtb.com>, "Richard Barnes" <rlb@= ipv.sx>
Cc: "Tim Bray" <tbray@textuality.com>, "Manger, James H" <<= a href=3D"mailto:James.H.Manger@team.telstra.com" target=3D"_blank">James.H= .Manger@team.telstra.com>, "Karen O&apos;Donoghue" <= ;odonoghue@isoc.org= >, "jose" <jose@ietf.org>

I=92m with Richard on this.=A0 The application-specific-data/meta field isn= =92t needed.

-- Mike

From: Richard Barnes
Sent: March 11, 2013 10:02 PM
To: John Bradley
CC: Tim Bray, Manger, James H, Karen ODonoghue, jose
Subject: Re: [jose] Proposed resolution of header criticality issue

+1 to cheers.=A0 I already high-fived Mike in person.

FWIW, my preference would be to get rid of "asd" or "meta&qu= ot; (part 5).=A0 I don't think it's relevant to the criticality dis= cussion, and it's just not needed.

--Richard



On Mon, Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com<mailto:ve7jtb@ve7jtb.com>> wr= ote:

On 2013-03-11, at 10:48 PM, "Manger, James H" <James.H.Manger@team.t= elstra.com<mailto:James.H.Manger@team.telstra.com>> wrote:

I=92ll add some cheers =97 this does look like substantial progress.

I assume the fields such as =93epk=94, =93apu=94 etc that sometimes must be= understood, and at other times must be ignored (depending on =93alg=94 or = =93enc=94 value) would NOT be listed in the =93crit=94 field as they are de= fined in the =93base specs=94.

Correct

Being in the =93base specs=94 is the right criteria for whether a field sho= uld be listed in =93crit=94 as long as =93base specs=94 means: =93base spec= ifications for the particular =93alg=94/=94enc=94 values=94. It shouldn=92t= mean (and doesn=92t have to mean) the base spec for the whole JOSE system.


Crit is only for extensions, it is up to the extension definition to decide= if the field needs to be in crit.


P.S. =93meta=94 might be a nicer label than =93asd=94.

I don't have any particular attachment to the name.=A0=A0 Some places t= hings like this are called associated data, though not the places normal pe= ople go I grant you.
Meta-data about the payload is what it is,=A0 The current practice is to us= e three character names.=A0=A0 I am fine with met or meta (I suspect that i= f you are throwing crap into the envelope the single character won't ki= ll anyone.

James if you like the solution and want it to be meta I will back you on it= :)

John B.


--
James Manger

From: jose-bounc= es@ietf.org<mailto:jose-bounces@ietf.org> [mailto:jose-<mailto:jose->bo= unces@ietf.org<mailto:bounces@ietf.org>] On Behalf Of Tim Bray
Sent: Tuesday, 12 March 2013 12:43 PM
To: Karen ODonoghue
Cc: jose
Subject: Re: [jose] Proposed resolution of header criticality issue

Cue wild cheers from the peanut gallery where non-cryptographers sit.=A0 Mu= stIgnore is infinitely more robust and open-ended than MustUnderstand.=A0 -= T

On Mon, Mar 11, 2013 at 5:31 PM, Karen O'Donoghue <odonoghue@isoc.org<mailto:odonoghue@isoc.org= >> wrote:

Folks,

A side meeting was held Sunday with a number of jose working group particip= ants to try to resolve the open issue related to header criticality. The fo= llowing are the proposed resolutions from the meeting. Point 5 of the propo= sed resolution below is actually independent of the other 4 points, and could be considered separately. Thi= s will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the &quo= t;understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text= below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Tho= mas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and m= y apologies if I missed someone).

Regards,
Karen

1:=A0 Change the language =93Additional members MAY be present in the JWK.= =A0 If present, they MUST be understood by implementations using them.=94 t= o =93Additional members MAY be present in the JWK.=A0 If not understood by = implementations encountering them, they MUST be ignored.=94=A0 (And make the same change for JWK Set as well.)

2:=A0 Characterize all existing JWS and JWE header fields as either must be= understood or may be ignored.=A0 =93alg=94, =93enc=94, and =93zip=94 must = be understood.=A0 =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, = =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not using = them may result in the inability to process some signatures or encrypted content, t= his will not result in a security violation =96 just degraded functionality= .=A0 Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and = =93epv=94 must be understood and used when =93alg=94 or =93enc=94 values requiring them are used, and otherwise they may be ignored.

3.=A0 Define a new header field that lists which additional fields not defi= ned in the base specifications must be understood and acted upon when prese= nt.=A0 For instance, an expiration-time extension field could be marked as = must-be-understood-and-acted-upon.=A0 One possible name for this would be =93crit=94 (critical).=A0 An example u= se, along with a hypothetical =93exp=94 (expiration-time) field is:

=A0 {"alg":"ES256",
=A0=A0 "crit":["exp"],
=A0=A0 "exp=94:1363284000
=A0 }

4.=A0 All additional header fields not defined in the base specifications a= nd not contained in the =93crit=94 list MUST be ignored if not understood.<= br>
5.=A0 Define a new header field =93asd=94 (application-specific data) whose= value is a JSON structure whose contents are opaque to and ignored by JWS = and JWE implementations but for which its contents MUST be provided to appl= ications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.=A0 The inte= nded use of this field is to have a standard place to provide application-s= pecific metadata about the payload or plaintext.



_______________________________________________
jose mailing list
jose@ietf.org<mai= lto:jose@ietf.org>= ;
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org<mai= lto:jose@ietf.org>= ;
ht= tps://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org<mai= lto:jose@ietf.org>= ;
ht= tps://www.ietf.org/mailman/listinfo/jose



--bcaec54fae48b63f0904d7bb2243-- From dick.hardt@gmail.com Tue Mar 12 10:07:19 2013 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 7A9CA11E80D1 for ; Tue, 12 Mar 2013 10:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 6Io9vLjzL94Z for ; Tue, 12 Mar 2013 10:07:18 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id DE8E91F0C6D for ; Tue, 12 Mar 2013 10:07:17 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id j10so34274bkw.12 for ; Tue, 12 Mar 2013 10:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=L8DG8gs2+2y3HF2XPmgTcu+xBTTd9MqpUTvH3CZNBjA=; b=Xv3ZIhN0SrNX5zgX/iDSNtjtc/4k09Ykksq+VCebB3QzLVqZfcUyJBKdfrkMLbOb70 CefLlnYLDeYbXcw5WXrGl5KUuIg+GnIYRSbIM6GUldLSix63QnlTxR7LZup39J98n14y t8PxyHZNj2TYOd0uBFs+lzkF2UdZkBzc66UMkOZWdgUEIH5HM5cTZyh4xK5UtWJS+YrQ nryr/KrwMcxtbPg6Ljcaq6jts6TDH63XTGPkBcMyiqIIy+w9krQ5yUrDLsKOGDItOy0O yqCI4+UjYv19SBnOcEACtvjdekaM9V/yoe4fvPUFd8cICcI9DNAUHtfUUCD78Sno2s1s 2DNw== MIME-Version: 1.0 X-Received: by 10.205.114.11 with SMTP id ey11mr6468618bkc.104.1363108036924; Tue, 12 Mar 2013 10:07:16 -0700 (PDT) Received: by 10.204.37.130 with HTTP; Tue, 12 Mar 2013 10:07:16 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Mar 2013 10:07:16 -0700 Message-ID: From: Dick Hardt To: Anthony Nadalin Content-Type: multipart/alternative; boundary=bcaec5554fa055182404d7bd5276 Cc: Karen O'Donoghue , Richard Barnes , Jim Schaad , Mike Jones , Tim Bray , jose , John Bradley , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 17:07:19 -0000 --bcaec5554fa055182404d7bd5276 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Agreed. In an implementation I am working on, I need an audience signal in a JWE so that recipients of the JWE token know who can decrypt and process it. While on that topic, it seems that I can't have 'aud' in the header, so I would need to have a URI for that property such as 'aud.example.com' btw: per Richard's comment, the code to use app specific payload data is pretty ugly with jwt.['prop.example.com'] but I put all the app properties in the one object so I do jwt.['prop.example.com'].prop1 -- Dick On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin wro= te: > oh great now you are going to tell us what is crypto related and what is > not, that is pretty much n application call not a spec call > > Sent from Windows Mail > > *From:* Mike Jones > *Sent:* March 12, 2013 7:02 AM > *To:* Jim Schaad, Richard Barnes > *CC:* John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose > > *Subject:* Re: [jose] Proposed resolution of header criticality issue > > +1 to only putting crypto-related things in the headers. > > *From:* Richard Barnes > *Sent:* March 12, 2013 6:53 AM > *To:* Jim Schaad > *CC:* John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen > O'Donoghue > *Subject:* Re: [jose] Proposed resolution of header criticality issue > > Note that my proposed text did not say that the libraries would not retur= n > header stuff, only that you shouldn't cram non-crypto-related things in > there. > > > > On Tuesday, March 12, 2013, Jim Schaad wrote: > >> I am not truly happy with this idea. If the application cares about >> who =93owns=94 a key for a signature then it needs to somehow get that >> information. That may be done by getting the way and key from the secur= ity >> library and that may be done by just returning the claims from the envel= ope. >> **** >> >> ** ** >> >> Jim**** >> >> ** ** >> >> ** ** >> >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *John Bradley >> *Sent:* Tuesday, March 12, 2013 9:15 AM >> *To:* Mike Jones >> *Cc:* Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue >> *Subject:* Re: [jose] Proposed resolution of header criticality issue***= * >> >> ** ** >> >> I am OK with getting rid of it if we make it clear that claims from the >> envelope will not be passed on to applications.**** >> >> ** ** >> >> If we don't do that we will compromise interoperability between >> libraries. Envelope is for JOSE only and not made available, that make= s >> things like timestamps and other things that the application layer needs= to >> interpret can't go in the envelope they need to be in the body in some w= ay. >> **** >> >> ** ** >> >> I just want it one way or the other.**** >> >> ** ** >> >> John B.**** >> >> ** ** >> >> ** ** >> >> On 2013-03-12, at 9:06 AM, Mike Jones >> wrote:**** >> >> >> >> **** >> >> I=92m with Richard on this. The application-specific-data/meta field is= n=92t >> needed.**** >> >> **** >> >> -- Mike**** >> >> **** >> >> *From:* Richard Barnes >> *Sent:* March 11, 2013 10:02 PM >> *To:* John Bradley >> *CC:* Tim Bray, Manger, James H, Karen ODonoghue, jose >> *Subject:* Re: [jose] Proposed resolution of header criticality issue***= * >> >> **** >> >> +1 to cheers. I already high-fived Mike in person. **** >> >> ** ** >> >> FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I >> don't think it's relevant to the criticality discussion, and it's just n= ot >> needed. **** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> ** ** >> >> On Mon, Mar 11, 2013 at 11:01 PM, John Bradley wrote= : >> **** >> >> ** ** >> >> On 2013-03-11, at 10:48 PM, "Manger, James H" < >> James.H.Manger@team.telstra.com> wrote:**** >> >> ** ** >> >> I=92ll add some cheers =97 this does look like substant >> >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --=20 -- Dick --bcaec5554fa055182404d7bd5276 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Agreed.

In an implementation I am= working on, I need an audience signal in a JWE so that recipients of the J= WE token know who can decrypt and process it.

While on that topic, it seems that I can't have 'aud' in the he= ader, so I would need to have a URI for that property such as 'aud.example.com'

btw: per Richard's comment, the code to use app specific pay= load data is pretty ugly with

jwt.[= 9;prop.example.com']

but I put all the app properties in the one object so = I do

jwt.['prop.example.com'].prop1

-- Dick



On Tue, Mar 12, 2013 at 7:05 AM, Anth= ony Nadalin <tonynad@microsoft.com> wrote:
oh great now you are going to tell us what is crypto related and what = is not, that is pretty much n application call not a spec call
=A0
Sent from Windows Mail
=A0
From:=A0Mike Jones
Sent:=A0March 12, 2013 7:02 AM
To:=A0Jim Schaad, Richard Barnes
CC:=A0John Bradley, Tim Bray, James H Manger, Karen O'= Donoghue, jose

Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
+1 to=A0only putting crypto-related things in the headers.
=A0
From:=A0Richard Barnes
Sent:=A0March 12, 2013 6:53 AM
To:=A0Jim Schaad
CC:=A0John Bradley, Mike Jones, James H Manger, Tim Bray, = jose, Karen O'Donoghue
Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
Note that my proposed text did not say that the libraries would not return = header stuff, only that you shouldn't cram non-crypto-related things in= there.=A0



On Tuesday, March 12, 2013, Jim Schaad wrote:

I am not truly happy= with this idea.=A0 If the application cares about who =93owns=94 a key for= a signature then it needs to somehow get that information.=A0 That may be done by getting the way and key from the security library and = that may be done by just returning the claims from the envelope.<= /u>

=A0

Jim

=A0

=A0

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Dono= ghue
Subject: Re: [jose] Proposed resolution of header criticality issue<= u>

=A0

I am OK with getting rid of it if we make it clear that claims from the = envelope will not be passed on to applications.

=A0

If we don't do that we will compromise interoperability between libr= aries. =A0 Envelope is for JOSE only and not made available, that makes thi= ngs like timestamps and other things that the application layer needs to in= terpret can't go in the envelope they need to be in the body in some way.

=A0

I just want it one way or the other.

=A0

John B.

=A0

=A0

On 2013-03-12, at 9:06 AM, Mike Jones <Michael.Jones@microsoft.com= > wrote:



I= =92m with Richard on this.=A0 The=A0application-specific-data/meta field is= n=92t needed.

= =A0

-= - Mike

= =A0

From:=A0Richard Barnes
Sent:=A0March 11, 2013 10:02 PM
To:=A0John Bradley
CC:=A0Tim Bray, Manger, James H, Karen ODonoghue, jose<= br> Subject:=A0Re: [jose] Proposed resolution of header cri= ticality issue

= =A0

+= 1 to cheers. =A0I already high-fived Mike in person.

<= u>=A0

F= WIW, my preference would be to get rid of "asd" or "meta&quo= t; (part 5). =A0I don't think it's relevant to the criticality disc= ussion, and it's just not needed. =A0

<= u>=A0

-= -Richard

<= u>=A0

=A0

O= n Mon, Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

<= u>=A0

O= n 2013-03-11, at 10:48 PM, "Manger, James H" <James.H.Mange= r@team.telstra.com> wrote:

<= u>=A0

I=92ll add some cheers = =97 this does look like substant


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
-- Dick
--bcaec5554fa055182404d7bd5276-- From mpeck@mitre.org Tue Mar 12 11:29:24 2013 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 9EE6611E8121 for ; Tue, 12 Mar 2013 11:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.565 X-Spam-Level: X-Spam-Status: No, score=-5.565 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 iBP8J1UxaMwx for ; Tue, 12 Mar 2013 11:29:22 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB0E11E8120 for ; Tue, 12 Mar 2013 11:29:21 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D36711F09E5 for ; Tue, 12 Mar 2013 14:29:20 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BD1321F09AC for ; Tue, 12 Mar 2013 14:29:20 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 14:29:20 -0400 From: "Peck, Michael A" To: "jose@ietf.org" Thread-Topic: Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: Ac4fTKr2pTLwejeuRSCB0FriUWdwPw== Date: Tue, 12 Mar 2013 18:29:18 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09ECIMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 18:29:24 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09ECIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of C= oncat KDF on the shared secret Z established by ECDH-ES. The draft allows for an empty PartyUInfo and PartyVInfo but that may not be= allowed by NIST SP 800-56A (where the Concat KDF is defined). The current (March 2007) version of NIST SP 800-56A requires "At a minimum,= PartyUInfo shall include IDU, the identifier of party U." and an equivalen= t requirement for PartyVInfo. (Page 46 of http://csrc.nist.gov/publications= /nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf ) The August 2012 draft update to NIST SP 800-56A requires "At a minimum, Par= tyUInfo shall include IDu, an identifier for party U, as a distinct item of= information." and an equivalent requirement for PartyVInfo. (Page 59 of ht= tp://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) My i= nterpretation of this text (others may interpret it differently) is that Pa= rtyUInfo and PartyVInfo can't be empty. Instead of using the Concat KDF, a more appropriate choice may be the KDF d= escribed in NIST SP 800-56C and RFC 5869. Its requirements are not as strict. (SP 800-56C Page 13: "If the informati= on is available, Context should include the identifiers of the parties who = are deriving and/or using the derived keying material") It would look something like this: Step 1 - Randomness Extraction: Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice f= or all of the current algorithms) Step 2 - Expansion Step: Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 w= ith the same HMAC algorithm used in step 1 to produce needed keys from the = Key Derivation Key produced in step 1. The needed keys would depend on the values of alg and enc. If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key= is needed (used to decrypt the CMK, which may then need to be split into C= EK/CIK). If alg is ECDH-ES, then the needed keys depend on "enc": If enc is AES-GCM, a 128 bit key or 256 bit key is needed. If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-h= mac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it's then spli= t into two by the AEAD algorithm. If enc is one of the current CBC+HMAC options in draft-ietf-jose-json-web-a= lgorithms-08, then two keys are needed, a CEK and a CIK. Counter Mode KDF = could be invoked twice, with different labels each time, or Counter Mode KD= F could be invoked once to generate a big key which would then be split int= o the CEK and CIK. Richard has already pointed out the issues with using the Concat KDF to der= ive the CEK/CIK from the CMK. Instead, one option would be to use the Expa= nsion Step above: use the Counter Mode KDF with an HMAC to derive necessar= y keys from the CMK. Even if we use encryption algorithms that combine the encryption and integr= ity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-s= ha2-01, there will still be a need to take a smaller master key and create = the combined encryption + integrity key from it. Mike --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09ECIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-jose-json-web-algorithms-08 section 4.7.1= describes the use of Concat KDF on the shared secret Z established by ECDH= -ES.

 

The draft allows for an empty PartyUInfo and PartyVI= nfo but that may not be allowed by NIST SP 800-56A (where the Concat KDF is= defined).

The current (March 2007) version of NIST SP 800-56A = requires “At a minimum, PartyUInfo shall include IDU, the identifier of party U.” and an equivalent requirement for PartyVInfo. (Page 46 of = http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar0= 8-2007.pdf )

The August 2012 draft update to NIST SP 800-56A requ= ires “At a minimum, PartyUInfo shall include IDu, an identifier for p= arty U, as a distinct item of information.” and an equivalent require= ment for PartyVInfo. (Page 59 of http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pd= f )  My interpretation of this text (others may interpret it diffe= rently) is that PartyUInfo and PartyVInfo can’t be empty.

 

Instead of using the Concat KDF, a more appropriate = choice may be the KDF described in NIST SP 800-56C and RFC 5869.=

Its requirements are not as strict.  (SP 800-56C = Page 13: “If the information is avai= lable, Context should include the identifiers of the = parties who are deriving and/or using the derived keying material”)

 

It would look something like this:

 

Step 1 - Randomness Extraction:

Key Derivation Key :=3D HMAC(salt, Z)  &nb= sp;      (HMAC-SHA256 should suffice for all of th= e current algorithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or se= ction 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produc= e needed keys from the Key Derivation Key produced in step 1.

The needed keys would depend on the values of alg an= d enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, = a single 128 bit or 256 bit key is needed (used to decrypt the CMK, which m= ay then need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on &#= 8220;enc”:

If enc is AES-GCM, a 128 bit key or 256 bit key is n= eeded.

If enc is one of the AEAD AES-CBC algorithms in draf= t-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN = is needed as it’s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in= draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK an= d a CIK.  Counter Mode KDF could be invoked twice, with different labe= ls each time, or Counter Mode KDF could be invoked once to generate a big key which would then be split into the CEK = and CIK.

 

Richard has already pointed out the issues with usin= g the Concat KDF to derive the CEK/CIK from the CMK.  Instead, one opt= ion would be to use the Expansion Step above:  use the Counter Mode KD= F with an HMAC to derive necessary keys from the CMK. 

Even if we use encryption algorithms that combine th= e encryption and integrity key such as the CBC+HMAC algorithms in draft= -mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take a sma= ller master key and create the combined encryption + integrity key from it.

 

 

Mike

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09ECIMCMBX04MITREOR_-- From mpeck@mitre.org Tue Mar 12 11:31:58 2013 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 6967711E8164 for ; Tue, 12 Mar 2013 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.123 X-Spam-Level: X-Spam-Status: No, score=-6.123 tagged_above=-999 required=5 tests=[AWL=0.475, 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 hjDJBOwSDR8t for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4614011E8121 for ; Tue, 12 Mar 2013 11:31:45 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D1B41625025F; Tue, 12 Mar 2013 14:31:44 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id A09D81F0A69; Tue, 12 Mar 2013 14:31:44 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 14:31:44 -0400 From: "Peck, Michael A" To: Richard Barnes , "Manger, James H" Thread-Topic: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter Thread-Index: AQHOHxs/hviZSqyUCUGH4wA138tZ1ZiiYOmA Date: Tue, 12 Mar 2013 18:31:43 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC09FE@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B786D22@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09FEIMCMBX04MITREOR_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 12 Mar 2013 18:31:58 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09FEIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JWS already has several X.509 header parameters, and the "kid" header param= eter can be used anywhere those don't fit - such as to provide a fingerprin= t to identify the public key. If implementations really wanted to (though I wouldn't recommend this), the= y could stuff the raw public key itself in the "kid". Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Tuesday, March 12, 2013 8:15 AM To: Manger, James H Cc: jose@ietf.org Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header para= meter I guess I regard the ability to operate with bare public keys as a feature,= not a bug. There are many, many ways to authenticate keys, ranging from X= .509 with detailed certificate profiles to pre-shared key fingerprints. Ha= ving bare public keys lets us address all of these use cases. --Richard On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H > wrote: Richard, Verifying a JWS signature with a raw public key in the JWS provides almost = no useful security property. To be useful you need to confirm the authentic= ity of the public key from some other source. Generally the "other source" = that provides the authenticity can provide the actual public key as well. The "danger" of including a raw public key is that silly code verifies the = maths then automatically "trusts" the message. It is only a small danger. I= am willing to ignore the danger, but only if there is real value in includ= ing the raw public key. Perhaps DANE (key in DNS protected by DNSSEC) is an= example of a mechanism that can confirm the authenticity of a hash of a ke= y without providing the actual key. Though wouldn't it be better to get the= full key from DANE once, and only send a key id in every JOSE message? The closest analogy with certs is whether or not to include the self-signed= root cert at the end of a cert chain in the message. It shouldn't be sent.= It often is. That hasn't caused the sky to fall in, though it wastes a sma= ll (non-trivial??) portion of TLS traffic. -- James Manger From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Saturday, 9 March 2013 1:37 AM To: Manger, James H Cc: Peck, Michael A; jose@ietf.org Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header para= meter On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H > wrote: I agree, Michael. A raw public key in a JWS is inviting dangerous code. Could you be a little more precise here? What's the danger? The only difference between a key and a cert is that the cert provides the = recipient with some attributes that go along with the key (signed under som= e authority) -- assuming the recipient supports X.509 and has an appropriat= e trust anchor. So the only danger is that the recipient might not check t= he attributes before accepting the signature. This is a completely separate question from whether the signature is valid,= in a cryptological / mathematical sense. And the answer you're implying (= that not checking attributes is dangerous) is clearly not true in all cases= . For example, in PGP, you've validated the public key through some out-of= -band channel, and you really do just need the key here. JOSE should stick to crypto, and stay away from policy. To do otherwise wo= uld cut off use cases unnecessariliy. From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Peck, Michael A Sent: Thursday, 7 March 2013 6:21 AM To: Richard Barnes Cc: jose@ietf.org Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header para= meter In the case of JWS, it looks like with the "jwk" header parameter, the sign= ed message itself can contain the raw public key to be used to verify it. My concern is that the verifier will grab and use the public key without en= suring its authenticity. This would be analogous to automatically trusting a self-signed X.509 certi= ficate. There should at least be some Security Considerations language that when "j= wk" is used the verifier needs to use out of bands means to assure that the= provided public key is trusted. CMS SignedData does not contain the raw public key used to sign the message= itself. It contains a SignerIdentifier to reference the public key and optionally c= ontains certificates (which would convey the public key, but along with pro= of that it should be trusted). Rather than directly including the "raw" public key, JWS provides lots of o= ther safer header parameters to reference the public key. On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A > wrote: What is the use case for the "jwk" (JSON Web Key) Header Parameter describe= d in section 4.1.3 of draft-ietf-jose-json-web-signature-08? It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself. I would think this field makes it too easy for implementations to do the wr= ong thing. Thanks, Mike --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09FEIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JWS already has several X= .509 header parameters, and the “kid” header parameter can be u= sed anywhere those don’t fit – such as to provide a fingerprint= to identify the public key.

If implementations really= wanted to (though I wouldn’t recommend this), they could stuff the r= aw public key itself in the “kid”.

 <= /p>

Mike

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 8:15 AM
To: Manger, James H
Cc: jose@ietf.org
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

 

I guess I regard the ability to operate with bare pu= blic keys as a feature, not a bug.  There are many, many ways to authe= nticate keys, ranging from X.509 with detailed certificate profiles to pre-= shared key fingerprints.  Having bare public keys lets us address all of these use cases.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:

Richard,

 

Verifying a JWS signatur= e with a raw public key in the JWS provides almost no useful security property. To be useful you need to confirm the authenticity of th= e public key from some other source. Generally the “other source̶= 1; that provides the authenticity can provide the actual public key as well= .

 

The “danger”= of including a raw public key is that silly code verifies the maths then automatically “trusts” the message. It is only a small danger.= I am willing to ignore the danger, but only if there is real value in incl= uding the raw public key. Perhaps DANE (key in DNS protected by DNSSEC) is = an example of a mechanism that can confirm the authenticity of a hash of a key without providing the actual key. Though w= ouldn’t it be better to get the full key from DANE once, and only sen= d a key id in every JOSE message?

 

The closest analogy with= certs is whether or not to include the self-signed root cert at the end of a cert chain in the message. It shouldn’t be sent. It = often is. That hasn’t caused the sky to fall in, though it wastes a s= mall (non-trivial??) portion of TLS traffic.

 

--

James Manger

 

From: Richard Barnes [mailto= :rlb@ipv.sx]
Sent: Saturday, 9 March 2013 1:37 AM
To: Manger, James H
Cc: Peck, Michael A; jose@ietf.org


Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

 

On Wed, Mar 6, 2013 at 10:55 PM, Manger, Jame= s H <James.H.Manger@team.telstra.com> wrote:

I agree, Michael. A raw = public key in a JWS is inviting dangerous code.=

 

Could you be a little more precise here? &nbs= p;What's the danger?

 

The only difference between a key and a cert = is that the cert provides the recipient with some attributes that go along = with the key (signed under some authority) -- assuming the recipient supports X.509 and has an appropriate trust anch= or.  So the only danger is that the recipient might not check the attr= ibutes before accepting the signature.

 

This is a completely separate question from w= hether the signature is valid, in a cryptological / mathematical sense. &nb= sp;And the answer you're implying (that not checking attributes is dangerous) is clearly not true in all cases.  = For example, in PGP, you've validated the public key through some out-of-ba= nd channel, and you really do just need the key here.

 

JOSE should stick to crypto, and stay away fr= om policy.  To do otherwise would cut off use cases unnecessariliy.

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A<= /span>


Sent: Thursday, 7 March 2013 6:21 AM
To: Richard Barnes


Cc: jose@ietf.org=
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

 

In the case of JWS, it looks like with = the “jwk” header parameter, the signed message itself can contain the raw public key to be used to verify it.

My concern is that the verifier will gr= ab and use the public key without ensuring its authenticity.

This would be analogous to automaticall= y trusting a self-signed X.509 certificate.

There should at least be some Security = Considerations language that when “jwk” is used the verifier needs to use out of bands means to assure that the provided public key is = trusted.

 =

CMS SignedData does not contain the raw= public key used to sign the message itself.

It contains a SignerIdentifier to refer= ence the public key and optionally contains certificates (which would convey the public key, but along with proof that it should be truste= d).

 =

Rather than directly including the R= 20;raw” public key, JWS provides lots of other safer header parameter= s to reference the public key.=

 

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <mpeck@mitre.org> wrote:

What is the use case for the "jwk" (JSON Web Key) Header Paramete= r described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike

 

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC09FEIMCMBX04MITREOR_-- From rlb@ipv.sx Tue Mar 12 11:32:59 2013 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 22E7511E8121 for ; Tue, 12 Mar 2013 11:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.397, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 6vl2UEQjTOmP for ; Tue, 12 Mar 2013 11:32:58 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id DA62511E8164 for ; Tue, 12 Mar 2013 11:32:57 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l20so181575oag.23 for ; Tue, 12 Mar 2013 11:32:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TGV86IaUPrh2XV19CGrB1XCeZ4EP9JfPzLZUybP3MiI=; b=puE3DxVAeny4Kxlt9zqSSdTHNWJO7SPnprmsSOVxrPX9HtxI2MZGRMdG9lqwYXhBsG Wb6o4cMx3HoIyIrf1D6oTNaGfuP10fxnK53q6HQK0xcWnaoeLjV0e7yawIzA0BymTtN+ F+/7wKrvv3T4RD2oBlqIuc1d5AuOm7HhtVIFnufPdh4HN1neG7RmM902FpPsWSVAGvv2 2jIrrZBgtNk8qNjSrcQyvGmwC20qVSYG8PZe+8AWCij9FvzqxhXE3vmGFzyAFd6w/fIq EFQM+ABLu2wwzqDzxPAqL04Cmwnh8u5Ch7vK7vZGtEZAhgO3yXAv7XFAyC6vtTXBBTMP uUCQ== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr13404499oec.116.1363113177465; Tue, 12 Mar 2013 11:32:57 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 11:32:57 -0700 (PDT) X-Originating-IP: [128.89.253.127] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC09FE@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321E79FAA1@IMCMBX04.MITRE.ORG> <8B4C063947CD794BB6FF90C78BAE9B321E7A3558@IMCMBX04.MITRE.ORG> <255B9BB34FB7D647A506DC292726F6E1150B476F63@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B786D22@WSMSG3153V.srv.dir.telstra.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC09FE@IMCMBX04.MITRE.ORG> Date: Tue, 12 Mar 2013 14:32:57 -0400 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=bcaec5523bb6bb659704d7be841c X-Gm-Message-State: ALoCoQns02dko4EB0mBF5E2GvGV3oBIaoERB+fDBtWBEQH3bQ72udT8Vh8uZbDw4iD3EyOctuI0Z Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header parameter 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, 12 Mar 2013 18:32:59 -0000 --bcaec5523bb6bb659704d7be841c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would prefer not to encourage abuse of fields. Let's just provide a field. --Richard On Tue, Mar 12, 2013 at 2:31 PM, Peck, Michael A wrote: > JWS already has several X.509 header parameters, and the =93kid=94 heade= r > parameter can be used anywhere those don=92t fit =96 such as to provide a > fingerprint to identify the public key.**** > > If implementations really wanted to (though I wouldn=92t recommend this), > they could stuff the raw public key itself in the =93kid=94.**** > > ** ** > > Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Tuesday, March 12, 2013 8:15 AM > *To:* Manger, James H > *Cc:* jose@ietf.org > > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > ** ** > > I guess I regard the ability to operate with bare public keys as a > feature, not a bug. There are many, many ways to authenticate keys, > ranging from X.509 with detailed certificate profiles to pre-shared key > fingerprints. Having bare public keys lets us address all of these use > cases.**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > Richard,**** > > **** > > Verifying a JWS signature with a raw public key in the JWS provides almos= t > no useful security property. To be useful you need to confirm the > authenticity of the public key from some other source. Generally the =93o= ther > source=94 that provides the authenticity can provide the actual public ke= y as > well.**** > > **** > > The =93danger=94 of including a raw public key is that silly code verifie= s the > maths then automatically =93trusts=94 the message. It is only a small dan= ger. I > am willing to ignore the danger, but only if there is real value in > including the raw public key. Perhaps DANE (key in DNS protected by DNSSE= C) > is an example of a mechanism that can confirm the authenticity of a hash = of > a key without providing the actual key. Though wouldn=92t it be better to= get > the full key from DANE once, and only send a key id in every JOSE message= ? > **** > > **** > > The closest analogy with certs is whether or not to include the > self-signed root cert at the end of a cert chain in the message. It > shouldn=92t be sent. It often is. That hasn=92t caused the sky to fall in= , > though it wastes a small (non-trivial??) portion of TLS traffic.**** > > **** > > --**** > > James Manger**** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Saturday, 9 March 2013 1:37 AM > *To:* Manger, James H > *Cc:* Peck, Michael A; jose@ietf.org**** > > > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > **** > > On Wed, Mar 6, 2013 at 10:55 PM, Manger, James H < > James.H.Manger@team.telstra.com> wrote:**** > > I agree, Michael. A raw public key in a JWS is inviting dangerous code.*= * > ** > > **** > > Could you be a little more precise here? What's the danger?**** > > **** > > The only difference between a key and a cert is that the cert provides th= e > recipient with some attributes that go along with the key (signed under > some authority) -- assuming the recipient supports X.509 and has an > appropriate trust anchor. So the only danger is that the recipient might > not check the attributes before accepting the signature.**** > > **** > > This is a completely separate question from whether the signature is > valid, in a cryptological / mathematical sense. And the answer you're > implying (that not checking attributes is dangerous) is clearly not true = in > all cases. For example, in PGP, you've validated the public key through > some out-of-band channel, and you really do just need the key here.**** > > **** > > JOSE should stick to crypto, and stay away from policy. To do otherwise > would cut off use cases unnecessariliy.**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On > Behalf Of *Peck, Michael A**** > > > *Sent:* Thursday, 7 March 2013 6:21 AM > *To:* Richard Barnes**** > > > *Cc:* jose@ietf.org > *Subject:* Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk" header > parameter**** > > **** > > In the case of JWS, it looks like with the =93jwk=94 header parameter, th= e > signed message itself can contain the raw public key to be used to verify > it.**** > > My concern is that the verifier will grab and use the public key without > ensuring its authenticity.**** > > This would be analogous to automatically trusting a self-signed X.509 > certificate.**** > > There should at least be some Security Considerations language that when > =93jwk=94 is used the verifier needs to use out of bands means to assure = that > the provided public key is trusted.**** > > **** > > CMS SignedData does not contain the raw public key used to sign the > message itself.**** > > It contains a SignerIdentifier to reference the public key and optionally > contains certificates (which would convey the public key, but along with > proof that it should be trusted).**** > > **** > > Rather than directly including the =93raw=94 public key, JWS provides lot= s of > other safer header parameters to reference the public key.**** > > **** > > On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A wrote:= * > *** > > What is the use case for the "jwk" (JSON Web Key) Header Parameter > described in section 4.1.3 of draft-ietf-jose-json-web-signature-08? > > It seems unsafe for a signature to provide, unauthenticated (not in a > signed certificate or protected by other means), the public key to be use= d > to verify itself. > I would think this field makes it too easy for implementations to do the > wrong thing. > > Thanks, > Mike**** > > **** > > ** ** > --bcaec5523bb6bb659704d7be841c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would prefer not to encourage abuse of fields. =A0Let's just provide = a field.
--Richard


On Tue,= Mar 12, 2013 at 2:31 PM, Peck, Michael A <mpeck@mitre.org> wr= ote:

JWS already has several X= .509 header parameters, and the =93kid=94 header parameter can be used anyw= here those don=92t fit =96 such as to provide a fingerprint to identify the public key.

If implementations really= wanted to (though I wouldn=92t recommend this), they could stuff the raw p= ublic key itself in the =93kid=94.

=A0<= /p>

Mike=

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 8:15 AM
To: Manger, James H
Cc: jose@ietf.org=


Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

=A0

I guess I regard the ability to operate with bare pu= blic keys as a feature, not a bug. =A0There are many, many ways to authenti= cate keys, ranging from X.509 with detailed certificate profiles to pre-sha= red key fingerprints. =A0Having bare public keys lets us address all of these use cases.

=A0

--Richard

=A0

=A0

On Tue, Mar 12, 2013 at 3:41 AM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:

Richard,

=A0=

Verifying = a JWS signature with a raw public key in the JWS provides almost no useful security property. To be useful you need to confirm the authenticity of th= e public key from some other source. Generally the =93other source=94 that = provides the authenticity can provide the actual public key as well.=

=A0=

The =93dan= ger=94 of including a raw public key is that silly code verifies the maths = then automatically =93trusts=94 the message. It is only a small danger. I am wi= lling to ignore the danger, but only if there is real value in including th= e raw public key. Perhaps DANE (key in DNS protected by DNSSEC) is an examp= le of a mechanism that can confirm the authenticity of a hash of a key without providing the actual key. Though w= ouldn=92t it be better to get the full key from DANE once, and only send a = key id in every JOSE message?

=A0=

The closes= t analogy with certs is whether or not to include the self-signed root cert at the end of a cert chain in the message. It shouldn=92t be sent. It ofte= n is. That hasn=92t caused the sky to fall in, though it wastes a small (no= n-trivial??) portion of TLS traffic.<= /u>

=A0=

--<= span lang=3D"EN-AU">

James Mang= er

=A0=

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Saturday, 9 March 2013 1:37 AM
To: Manger, James H
Cc: Peck, Michael A; jose@ietf.org


Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

=A0

On Wed, Mar 6, 2013 at 10:55 PM= , Manger, James H <James.H.Manger@team.telstra.com> wrote:

I agree, M= ichael. A raw public key in a JWS is inviting dangerous code.

=A0

Could you be a little more prec= ise here? =A0What's the danger?

=A0

The only difference between a k= ey and a cert is that the cert provides the recipient with some attributes = that go along with the key (signed under some authority) -- assuming the recipient supports X.509 and has an appropriate trust anch= or. =A0So the only danger is that the recipient might not check the attribu= tes before accepting the signature.

=A0

This is a completely separate q= uestion from whether the signature is valid, in a cryptological / mathemati= cal sense. =A0And the answer you're implying (that not checking attributes is dangerous) is clearly not true in all cases. =A0For= example, in PGP, you've validated the public key through some out-of-b= and channel, and you really do just need the key here.=

=A0

JOSE should stick to crypto, an= d stay away from policy. =A0To do otherwise would cut off use cases unneces= sariliy.

=A0

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A


Sent: Thursday, 7 March 2013 6:21 AM
To: Richard Barnes


Cc: jose@ietf.org=
Subject: Re: [jose] draft-ietf-jose-json-web-signature-08 "jwk&= quot; header parameter

=A0

In the case of JWS, it lo= oks like with the =93jwk=94 header parameter, the signed message itself can contain the raw public key to be used to verify it.

My concern is that the ve= rifier will grab and use the public key without ensuring its authenticity.<= /span>

This would be analogous t= o automatically trusting a self-signed X.509 certificate.

There should at least be = some Security Considerations language that when =93jwk=94 is used the verif= ier needs to use out of bands means to assure that the provided public key is = trusted.

=A0

CMS SignedData does not c= ontain the raw public key used to sign the message itself.

It contains a SignerIdent= ifier to reference the public key and optionally contains certificates (whi= ch would convey the public key, but along with proof that it should be truste= d).

=A0

Rather than directly incl= uding the =93raw=94 public key, JWS provides lots of other safer header par= ameters to reference the public key.

=A0

On Wed, Mar 6, 2013 at 12:28 PM, Peck, Michael A <= ;mpeck@mitre.org&g= t; wrote:

What is the use case for the "jwk" (JSON Web Key) Header Paramete= r described in section 4.1.3 of draft-ietf-jose-json-web-signature-08?

It seems unsafe for a signature to provide, unauthenticated (not in a signe= d certificate or protected by other means), the public key to be used to ve= rify itself.
I would think this field makes it too easy for implementations to do the wr= ong thing.

Thanks,
Mike

=A0

=A0


--bcaec5523bb6bb659704d7be841c-- From mpeck@mitre.org Tue Mar 12 11:43:13 2013 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 D330811E80BA for ; Tue, 12 Mar 2013 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.218 X-Spam-Level: X-Spam-Status: No, score=-6.218 tagged_above=-999 required=5 tests=[AWL=0.380, 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 s9lAuVpYx968 for ; Tue, 12 Mar 2013 11:43:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 8E38311E80A3 for ; Tue, 12 Mar 2013 11:43:11 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 334E81F0A13; Tue, 12 Mar 2013 14:43:11 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 236E91F09AC; Tue, 12 Mar 2013 14:43:11 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 14:43:10 -0400 From: "Peck, Michael A" To: "Richard Barnes (rlb@ipv.sx)" , "jose@ietf.org" Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: AQHOHCzB3S6yODPf9EOgrQ2hwfCM15iiZ/kg Date: Tue, 12 Mar 2013 18:43:10 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A16@IMCMBX04.MITRE.ORG> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A16IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 12 Mar 2013 18:43:13 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A16IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Richard, draft-ietf-jose-json-web-algorithms-08 defines A128KW and A256KW as using t= he RFC3394 AES Key Wrap. When you use them here do you mean the RFC5649 AES Key Wrap with Padding si= nce the plaintext is not guaranteed to be a multiple of 64 bits? Are the examples in your slides all assuming an existing key wrapping key h= as been pre-established? Should there also be examples showing how to asymmetrically encrypt keys? Are the current JWE mechanisms used to get the key wrapping key to the reci= pient? (I think I'm missing the big picture of where (if anywhere) this plugs into= JWE?) Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, March 08, 2013 1:43 PM To: jose@ietf.org Subject: [jose] A Unified Theory of JOSE Keys I've posted some draft slides for my presentation on JOSE keys: Some thoughts are below to get the discussion started early... What I'm proposing here is that we re-factor JWK and JWA to address all of = the use cases we have for keys -- including public keys, wrapped/unwrapped = private/symmetric keys, and key attributes. That is, instead of doing wrap= ped symmetric keys in JWE, public keys in JWK, and the remainder somewhere = else, we should just do all key management in JWK. This actually entails less work than you might imagine. JWE provides us wi= th a wrapped symmetric key format, and Mike's recent draft provides an unwr= apped, JSON-based symmetric key format. From these we can extrapolate to w= rapped private keys in a pretty straightforward fashion, and pick up the ab= ility to add attributes to keys as a bonus. The slide deck illustrates a p= roposed wrapping algorithm that would do this. At the end of the slide deck, there's a proposal to edit JWK and JWA to add= key wrapping. To make that a little more precise, I would imagine the con= tents of the revised JWK draft to look something like the following (omitti= ng identical sections): -----BEGIN----- 4. JSON Web Key (JWK) Format 4.1. "kty" (Key Type) Parameter 4.2. "use" (Key Use) Parameter 4.3. "alg" (Algorithm) Parameter 4.4. "kid" (Key ID) Parameter 4.5. "kat" (Wrapped Key Attributes) Parameter 4.6. "wk" (Wrapped Key) Parameter 4.7. "epk" (Ephemeral Public Key) Header Parameter 4.8. "jku" (JWK Set URL) Header Parameter 4.9. "jwk" (JSON Web Key) Header Parameter 4.10. "x5u" (X.509 URL) Header Parameter 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter 4.12. "x5c" (X.509 Certificate Chain) Header Parameter 4.13. "apu" (Agreement PartyUInfo) Header Parameter 4.14. "apv" (Agreement PartyVInfo) Header Parameter 5. Wrapped keys 5.1. Key Wrapping Procedure 5.2. Key Unwrapping Procedure -----END----- The revised JWA draft would just fold in the fields from draft-jones-jose-j= son-private-and-symmetric-key, and add the obvious encoding rules for RSA a= nd EC keys. Comments welcome! Thanks, --Richard --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A16IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Richard,

 <= /p>

draft-ietf-jose-json-web-= algorithms-08 defines A128KW and A256KW as using the RFC3394 AES Key Wrap.<= o:p>

When you use them here do= you mean the RFC5649 AES Key Wrap with Padding since the plaintext is not = guaranteed to be a multiple of 64 bits?

 <= /p>

Are the examples in your = slides all assuming an existing key wrapping key has been pre-established?<= o:p>

Should there also be exam= ples showing how to asymmetrically encrypt keys?

Are the current JWE mecha= nisms used to get the key wrapping key to the recipient?<= /p>

(I think I’m missin= g the big picture of where (if anywhere) this plugs into JWE?)

 <= /p>

Mike

 <= /p>

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 08, 2013 1:43 PM
To: jose@ietf.org
Subject: [jose] A Unified Theory of JOSE Keys

 

I've posted some draft slides for my presentation on= JOSE keys:

Some thoughts are below to get the discussion starte= d early...

 

What I'm proposing here is that we re-factor JWK and= JWA to address all of the use cases we have for keys -- including public k= eys, wrapped/unwrapped private/symmetric keys, and key attributes.  Th= at is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we shou= ld just do all key management in JWK.

 

This actually entails less work than you might imagi= ne.  JWE provides us with a wrapped symmetric key format, and Mike's r= ecent draft provides an unwrapped, JSON-based symmetric key format.  F= rom these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add a= ttributes to keys as a bonus.  The slide deck illustrates a proposed w= rapping algorithm that would do this.

 

At the end of the slide deck, there's a proposal to = edit JWK and JWA to add key wrapping.  To make that a little more prec= ise, I would imagine the contents of the revised JWK draft to look somethin= g like the following (omitting identical sections):

-----BEGIN-----

4.  JSON Web Key (JWK) Format

4.1.  "kty" (Key Type) Parameter=

4.2.  "use" (Key Use) Parameter<= /o:p>

4.3.  "alg" (Algorithm) Parameter

4.4.  "kid" (Key ID) Parameter

4.5.  "kat" (Wrapped Key Attributes) = Parameter

4.6.  "wk" (Wrapped Key) Parameter

4.7.  "epk" (Ephemeral Public Key) He= ader Parameter

4.8.  "jku" (JWK Set URL) Header Para= meter

4.9.  "jwk" (JSON Web Key) Header Par= ameter

4.10. "x5u" (X.509 URL) Header Parameter

4.11. "x5t" (X.509 Certificate Thumbprint)= Header Parameter

4.12. "x5c" (X.509 Certificate Chain) Head= er Parameter

4.13. "apu" (Agreement PartyUInfo) Header = Parameter

4.14. "apv" (Agreement PartyVInfo) Header = Parameter

5. Wrapped keys

5.1. Key Wrapping Procedure

5.2. Key Unwrapping Procedure

-----END-----

The revised JWA draft would just fold in the fields = from draft-jones-jose-json-private-and-symmetric-key, and add the obvious e= ncoding rules for RSA and EC keys.

 

Comments welcome!

 

Thanks,

--Richard

 

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A16IMCMBX04MITREOR_-- From mpeck@mitre.org Tue Mar 12 11:53:01 2013 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 CF69A11E8108 for ; Tue, 12 Mar 2013 11:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.282 X-Spam-Level: X-Spam-Status: No, score=-6.282 tagged_above=-999 required=5 tests=[AWL=0.317, 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 KAI-LiWKWoaS for ; Tue, 12 Mar 2013 11:53:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id BFFEE11E8152 for ; Tue, 12 Mar 2013 11:53:00 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 297561F0AC8 for ; Tue, 12 Mar 2013 14:52:59 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 013CE1F0AF3 for ; Tue, 12 Mar 2013 14:52:40 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 14:52:39 -0400 From: "Peck, Michael A" To: "jose@ietf.org" Thread-Topic: RSASSA-PSS signature Thread-Index: Ac4fUsSatNxE3pBSSnqP5xo0kQPdBQ== Date: Tue, 12 Mar 2013 18:52:39 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.51] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A36IMCMBX04MITREOR_" MIME-Version: 1.0 Subject: [jose] RSASSA-PSS signature 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, 12 Mar 2013 18:53:01 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A36IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signature= s but not RSASSA-PSS. The Security Considerations states: While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1, for interoperability reasons, because it commonly implemented. Shouldn't RSASSA-PSS at least be included as an option? I'm also not sure if I fully understand the interoperability concerns. JWS= is a new specification, so it makes sense to me to use whatever algorithms= are currently considered best practice, without need to worry about backwa= rds compatibility? Mike --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A36IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-jose-json-web-algorithms-08 includes RSAS= SA-PKCS1-v1_5 signatures but not RSASSA-PSS.

 

The Security Considerations states:

   While Section 8 of RFC 3447 [RFC3447] e= xplicitly calls for people not

   to adopt RSASSA-PKCS1 for new applicati= ons and instead requests that

   people transition to RSASSA-PSS, this s= pecification does include

   RSASSA-PKCS1, for interoperability reas= ons, because it commonly

   implemented.

 

Shouldn’t RSASSA-PSS at least be included as a= n option?

I’m also not sure if I fully understand the in= teroperability concerns.  JWS is a new specification, so it makes sens= e to me to use whatever algorithms are currently considered best practice, = without need to worry about backwards compatibility?

 

Mike

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0A36IMCMBX04MITREOR_-- From rlb@ipv.sx Tue Mar 12 12:07:56 2013 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 E722E11E81E0 for ; Tue, 12 Mar 2013 12:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.935, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 Jz3KjAQb3LWF for ; Tue, 12 Mar 2013 12:07:56 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F266711E81DE for ; Tue, 12 Mar 2013 12:07:55 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uz6so203056obc.6 for ; Tue, 12 Mar 2013 12:07:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=5AqVNJxNFWMVx8qNrhbtkrhxgEfyqf2neZF4mGmtQEQ=; b=nuIgh2AEl1cebZJ+AU5NsyYC9IQBtXCpMcn3uLqiMa296olN6lW/oDLvsZw7/djHLY 5PUI7pKDBEYfSzJBMFd4VEWCjM+bIeOdaVMZ+ahJEvQEeauxfJj5xK38QYeBpTURej+J ipT7n00DxaJiPGx414DefHuGhucN2vXBPY5zHPm1UNPqUkr0fpfumMKg5oFqmcftSj/p mUjzQ7TGO+cJOs9Oo/i/KI+ddrHXZS0xhAXa7Q8A2j9NqNvtgjD6F76M6KbkIZrEWXFw m3XFga+M9YtZX7s/JLX6ql0t+D8+E3pHV+WSGKscX0IAzsEtyzwEeXyxOj4yymW9ITxN ZArA== MIME-Version: 1.0 X-Received: by 10.182.39.69 with SMTP id n5mr13500785obk.72.1363115275537; Tue, 12 Mar 2013 12:07:55 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 12:07:55 -0700 (PDT) X-Originating-IP: [128.89.253.127] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A16@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A16@IMCMBX04.MITRE.ORG> Date: Tue, 12 Mar 2013 15:07:55 -0400 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=f46d04479755c966d104d7bf017e X-Gm-Message-State: ALoCoQkOODi/Rs6t08+Nvxs6j44rvJSXgKPORhs8UqJJMr35HwlZWvbwfhecGQp2u01tg5uAvSm2 Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 12 Mar 2013 19:07:57 -0000 --f46d04479755c966d104d7bf017e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike, > draft-ietf-jose-json-web-algorithms-08 defines A128KW and A256KW as using > the RFC3394 AES Key Wrap.**** > > When you use them here do you mean the RFC5649 AES Key Wrap with Padding > since the plaintext is not guaranteed to be a multiple of 64 bits? > Yes. So that would impose 64 bits + [0,64] bits of size overhead. > Are the examples in your slides all assuming an existing key wrapping key > has been pre-established? > Yes, the examples in the slides assume an existing pre-shared KEK between the sender and recipient. > **** > > Should there also be examples showing how to asymmetrically encrypt keys? > Yes, once this gets turned into a draft. (An examples document might be a good milestone for this WG.) > **** > > Are the current JWE mechanisms used to get the key wrapping key to the > recipient?**** > > (I think I=92m missing the big picture of where (if anywhere) this plugs > into JWE?) > No, I'm not positing how the pre-shared key was established. The idea is that the first example slide ("The Wrapping Algorithm (symm)") illustrates the current wrapping process for JWE. On the left side is a representation of a raw, unwrapped CMK. On the right side is the wrapped CMK, including two JWE header fields ("alg", "kid") and the content of the CMK component of the JWE (in the "wk" field) -- basically, the a slice out of a JWE. As I suggested above, one of the goals is to produce a unified approach to key protection. That means we would need to have JWE key wrapping as a special case of our more general algorithm. --Richard > **** > > ** ** > > Mike**** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 08, 2013 1:43 PM > *To:* jose@ietf.org > *Subject:* [jose] A Unified Theory of JOSE Keys**** > > ** ** > > I've posted some draft slides for my presentation on JOSE keys:**** > > **** > > Some thoughts are below to get the discussion started early...**** > > ** ** > > What I'm proposing here is that we re-factor JWK and JWA to address all o= f > the use cases we have for keys -- including public keys, wrapped/unwrappe= d > private/symmetric keys, and key attributes. That is, instead of doing > wrapped symmetric keys in JWE, public keys in JWK, and the remainder > somewhere else, we should just do all key management in JWK.**** > > ** ** > > This actually entails less work than you might imagine. JWE provides us > with a wrapped symmetric key format, and Mike's recent draft provides an > unwrapped, JSON-based symmetric key format. From these we can extrapolat= e > to wrapped private keys in a pretty straightforward fashion, and pick up > the ability to add attributes to keys as a bonus. The slide deck > illustrates a proposed wrapping algorithm that would do this.**** > > ** ** > > At the end of the slide deck, there's a proposal to edit JWK and JWA to > add key wrapping. To make that a little more precise, I would imagine th= e > contents of the revised JWK draft to look something like the following > (omitting identical sections):**** > > -----BEGIN-----**** > > 4. JSON Web Key (JWK) Format**** > > 4.1. "kty" (Key Type) Parameter**** > > 4.2. "use" (Key Use) Parameter**** > > 4.3. "alg" (Algorithm) Parameter**** > > 4.4. "kid" (Key ID) Parameter**** > > 4.5. "kat" (Wrapped Key Attributes) Parameter**** > > 4.6. "wk" (Wrapped Key) Parameter**** > > 4.7. "epk" (Ephemeral Public Key) Header Parameter**** > > 4.8. "jku" (JWK Set URL) Header Parameter**** > > 4.9. "jwk" (JSON Web Key) Header Parameter**** > > 4.10. "x5u" (X.509 URL) Header Parameter**** > > 4.11. "x5t" (X.509 Certificate Thumbprint) Header Parameter**** > > 4.12. "x5c" (X.509 Certificate Chain) Header Parameter**** > > 4.13. "apu" (Agreement PartyUInfo) Header Parameter**** > > 4.14. "apv" (Agreement PartyVInfo) Header Parameter**** > > 5. Wrapped keys**** > > 5.1. Key Wrapping Procedure**** > > 5.2. Key Unwrapping Procedure**** > > -----END-----**** > > The revised JWA draft would just fold in the fields from > draft-jones-jose-json-private-and-symmetric-key, and add the obvious > encoding rules for RSA and EC keys.**** > > ** ** > > Comments welcome!**** > > ** ** > > Thanks,**** > > --Richard**** > > ** ** > > ** ** > --f46d04479755c966d104d7bf017e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Mike,
=A0

draft-ietf-jose-json-web-= algorithms-08 defines A128KW and A256KW as using the RFC3394 AES Key Wrap.<= u>

When you use them here do= you mean the RFC5649 AES Key Wrap with Padding since the plaintext is not = guaranteed to be a multiple of 64 bits?


Yes. So that would impose 64 b= its + [0,64] bits of size overhead.
=A0=A0

Are the examples in your = slides all assuming an existing key wrapping key has been pre-established?<= /span>


= Yes, the examples in the slides assume an existing pre-shared KEK between t= he sender and recipient.
=A0

Should there also be exam= ples showing how to asymmetrically encrypt keys?


Yes, once this gets turned into a draft. =A0(An example= s document might be a good milestone for this WG.)
=A0

Are the current JWE mecha= nisms used to get the key wrapping key to the recipient?

(I think I=92m missing th= e big picture of where (if anywhere) this plugs into JWE?)

=

No, I'm not positing how the pre-share= d key was established.

The idea is that the first = example slide ("The Wrapping Algorithm (symm)") illustrates the c= urrent wrapping process for JWE. =A0On the left side is a representation of= a raw, unwrapped CMK. =A0On the right side is the wrapped CMK, including t= wo JWE header fields ("alg", "kid") and the content of = the CMK component of the JWE (in the "wk" field) -- basically, th= e a slice out of a JWE. =A0

As I suggested above, one of the goals is to produce a = unified approach to key protection. =A0That means we would need to have JWE= key wrapping as a special case of our more general algorithm.

--Richard

=A0

=A0<= /p>

Mike=

=A0<= /p>

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 08, 2013 1:43 PM
To: jose@ietf.org=
Subject: [jose] A Unified Theory of JOSE Keys

=A0

I've posted some draft slides for my presentatio= n on JOSE keys:

Some thoughts are below to get the discussion starte= d early...

=A0

What I'm proposing here is that we re-factor JWK= and JWA to address all of the use cases we have for keys -- including publ= ic keys, wrapped/unwrapped private/symmetric keys, and key attributes. =A0T= hat is, instead of doing wrapped symmetric keys in JWE, public keys in JWK, and the remainder somewhere else, we shou= ld just do all key management in JWK.

=A0

This actually entails less work than you might imagi= ne. =A0JWE provides us with a wrapped symmetric key format, and Mike's = recent draft provides an unwrapped, JSON-based symmetric key format. =A0Fro= m these we can extrapolate to wrapped private keys in a pretty straightforward fashion, and pick up the ability to add a= ttributes to keys as a bonus. =A0The slide deck illustrates a proposed wrap= ping algorithm that would do this.

=A0

At the end of the slide deck, there's a proposal= to edit JWK and JWA to add key wrapping. =A0To make that a little more pre= cise, I would imagine the contents of the revised JWK draft to look somethi= ng like the following (omitting identical sections):

-----BEGIN-----

4. =A0JSON Web Key (JWK) Format

4.1. =A0"kty" (Key Type) Parameter<= u>

4.2. =A0"use" (Key Use) Parameter

4.3. =A0"alg" (Algorithm) Parameter=

4.4. =A0"kid" (Key ID) Parameter=

4.5. =A0"kat" (Wrapped Key Attributes) Par= ameter

4.6. =A0"wk" (Wrapped Key) Parameter

4.7. =A0"epk" (Ephemeral Public Key) Heade= r Parameter

4.8. =A0"jku" (JWK Set URL) Header Paramet= er

4.9. =A0"jwk" (JSON Web Key) Header Parame= ter

4.10. "x5u" (X.509 URL) Header Parameter

4.11. "x5t" (X.509 Certificate Thumbprint)= Header Parameter

4.12. "x5c" (X.509 Certificate Chain) Head= er Parameter

4.13. "apu" (Agreement PartyUInfo) Header = Parameter

4.14. "apv" (Agreement PartyVInfo) Header = Parameter

5. Wrapped keys

5.1. Key Wrapping Procedure

5.2. Key Unwrapping Procedure

-----END-----

The revised JWA draft would just fold in the fields = from draft-jones-jose-json-private-and-symmetric-key, and add the obvious e= ncoding rules for RSA and EC keys.

=A0

Comments welcome!

=A0

Thanks,

--Richard

=A0

=A0


--f46d04479755c966d104d7bf017e-- From ve7jtb@ve7jtb.com Tue Mar 12 12:25:07 2013 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 2641421F859C for ; Tue, 12 Mar 2013 12:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.349, 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 1ehHL-HssxDX for ; Tue, 12 Mar 2013 12:25:05 -0700 (PDT) Received: from mail-gh0-f179.google.com (mail-gh0-f179.google.com [209.85.160.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0D421F8506 for ; Tue, 12 Mar 2013 12:25:03 -0700 (PDT) Received: by mail-gh0-f179.google.com with SMTP id r14so44854ghr.24 for ; Tue, 12 Mar 2013 12:25:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=Hddv8uwbXZ2chB9zkqKjTy7Lm5Zlf9Z1SxkTrCIsbg4=; b=mmT2WSyOF0jNrrR2KKWWBrnRoIBgyOqsgEhPjIK4KxuffJc+pj7WMncp0Y4f7YFH1Z IpEju8eQHZU6z1HIyjzI90wiYUSTasgWftXKTj/394kx2pZu35X0eKCkARV867JK0s0v tp0ZTduy5C0VxJ4O61oLg1bOSLG2zCKhEnVn9V4HI3nNrAJvPyXVuK5V+Gm+iTrAYo4+ YpDHweaIM6l6xJhCmGwNC+wrT/v6CaYMQV/wDAC6iR3478dtHFnQVFv1iqnsZMbkoKBi LS1mAR12EgG+C0NzzXC/STobG7WakenCVwz/jD468RAq3BfYVYQ1W6WEU7lkSPpVJLaX TrXw== X-Received: by 10.236.71.74 with SMTP id q50mr13016643yhd.144.1363116302545; Tue, 12 Mar 2013 12:25:02 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id s3sm25602850yhm.10.2013.03.12.12.24.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 12:24:58 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_65EB1296-380F-43A5-97DC-BF16CB09D452"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> Date: Tue, 12 Mar 2013 15:24:41 -0400 Message-Id: <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> To: "Peck, Michael A" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmoGreLy5ZbQcP88e2mQi4ECxhrDtx/0UqR/wwY2FedwSsZetusjFZAsHCZQj4f03ggOrdp Cc: "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 19:25:07 -0000 --Apple-Mail=_65EB1296-380F-43A5-97DC-BF16CB09D452 Content-Type: multipart/alternative; boundary="Apple-Mail=_301FACB1-02CA-4F92-9D38-F3ABB5BD512F" --Apple-Mail=_301FACB1-02CA-4F92-9D38-F3ABB5BD512F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 This has had a fair amount of discussion. While I think almost = everyone would prefer PSS, many implementations are going to be in = scripting languages where the underlying libraries only support = PKCS1-v1_5. We did a survey of platforms to evaluate if we could move to PSS and the = result lead us not to make PSS as the MTI. In think that was reported = out at the Atlanta IETF meeting. Nat may be able to forward that to you, I don't have it handy. If we were talking about starting from scratch and not building on = existing platforms likely the answer would have been different. The algorithms are extensible so PSS can be added. The other = consideration is that many of the people who care will be using ECESA = signatures anyway. John B. On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote: > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 = signatures but not RSASSA-PSS. > =20 > The Security Considerations states: > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people = not > to adopt RSASSA-PKCS1 for new applications and instead requests = that > people transition to RSASSA-PSS, this specification does include > RSASSA-PKCS1, for interoperability reasons, because it commonly > implemented. > =20 > Shouldn=92t RSASSA-PSS at least be included as an option? > I=92m also not sure if I fully understand the interoperability = concerns. JWS is a new specification, so it makes sense to me to use = whatever algorithms are currently considered best practice, without need = to worry about backwards compatibility? > =20 > Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_301FACB1-02CA-4F92-9D38-F3ABB5BD512F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 This has had a fair amount of = discussion.   While I think almost everyone would prefer PSS, many = implementations are going to be in scripting languages where the = underlying libraries only support PKCS1-v1_5.

We did = a survey of platforms to evaluate if we could move to PSS and the result = lead us not to make PSS as the MTI.  In think that was reported out = at the Atlanta IETF meeting.
Nat may be able to forward that = to you, I don't have it handy.

If we were = talking about starting from scratch and not building on existing = platforms likely the answer would have been = different.

The algorithms are extensible so PSS = can be added.   The other consideration is that many of the people = who care will be using ECESA signatures = anyway.

John B.

On = 2013-03-12, at 2:52 PM, "Peck, Michael A" <mpeck@mitre.org> wrote:

draft-ietf-jose-json-web-algorithms-08 includes = RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.
 
The = Security Considerations states:
   to = adopt RSASSA-PKCS1 for new applications and instead requests = that
   people transition = to RSASSA-PSS, this specification does include
   RSASSA-PKCS1, for interoperability = reasons, because it commonly
Shouldn=92t = RSASSA-PSS at least be included as an option?
I=92m also not sure if I fully understand the = interoperability concerns.  JWS is a new specification, so it makes = sense to me to use whatever algorithms are currently considered best = practice, without need to worry about backwards = compatibility?
, "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 19:49:12 -0000 --bcaec54ee09455629f04d7bf95b2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Since we are not putting requirements on algorithms (i.e., there is no MTI), there's no harm to having PSS in the algorithms list. Only benefit! --Richard On Tue, Mar 12, 2013 at 3:24 PM, John Bradley wrote: > This has had a fair amount of discussion. While I think almost everyone > would prefer PSS, many implementations are going to be in scripting > languages where the underlying libraries only support PKCS1-v1_5. > > We did a survey of platforms to evaluate if we could move to PSS and the > result lead us not to make PSS as the MTI. In think that was reported ou= t > at the Atlanta IETF meeting. > Nat may be able to forward that to you, I don't have it handy. > > If we were talking about starting from scratch and not building on > existing platforms likely the answer would have been different. > > The algorithms are extensible so PSS can be added. The other > consideration is that many of the people who care will be using ECESA > signatures anyway. > > John B. > > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote: > > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 > signatures but not RSASSA-PSS.**** > ** ** > The Security Considerations states:**** > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not*= * > ** > to adopt RSASSA-PKCS1 for new applications and instead requests that**= * > * > people transition to RSASSA-PSS, this specification does include**** > RSASSA-PKCS1, for interoperability reasons, because it commonly**** > implemented.**** > ** ** > Shouldn=92t RSASSA-PSS at least be included as an option?**** > I=92m also not sure if I fully understand the interoperability concerns. > JWS is a new specification, so it makes sense to me to use whatever > algorithms are currently considered best practice, without need to worry > about backwards compatibility?**** > ** ** > Mike**** > ** ** > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54ee09455629f04d7bf95b2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. =A0Only benefit= ! =A0
--Richard


On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com><= /span> wrote:
This has= had a fair amount of discussion. =A0 While I think almost everyone would p= refer PSS, many implementations are going to be in scripting languages wher= e the underlying libraries only support PKCS1-v1_5.

We did a survey of platforms to evaluate if we could move to= PSS and the result lead us not to make PSS as the MTI. =A0In think that wa= s reported out at the Atlanta IETF meeting.
Nat may be able to fo= rward that to you, I don't have it handy.

If we were talking about starting from scratch and not = building on existing platforms likely the answer would have been different.=

The algorithms are extensible so PSS can be added= . =A0 The other consideration is that many of the people who care will be u= sing ECESA signatures anyway.

John B.

= On 2013-03-12, at 2:52 PM, "Peck, Michael A" <mpeck@mitre.org> wrote:
draft-ietf-jose-json-web-algorithms-0= 8 includes RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.
=A0
The Security Considerations stat= es:
=A0=A0 While Section 8 of RFC 3447 [RFC3447] explicitly calls for= people not
=A0=A0 to adopt RSASSA-PKCS1 for new applications and instead requests that=
=A0=A0 people transition to RSASSA-PSS, this = specification does include
=A0=A0 RSASSA-PKCS1, for interoperability reasons, because it com= monly
=A0=A0 implemented.
=A0
Shouldn=92t RSASSA-PSS at least be included as an option?
I=92m also not sure if I fully understand the interoperability = concerns.=A0 JWS is a new specification, so it makes sense to me to use wha= tever algorithms are currently considered best practice, without need to wo= rry about backwards compatibility?
=A0
Mike


________= _______________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec54ee09455629f04d7bf95b2-- From trac+jose@trac.tools.ietf.org Tue Mar 12 12:52:05 2013 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 0C9E311E8118 for ; Tue, 12 Mar 2013 12:52:05 -0700 (PDT) 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 qz97wVAalF9y for ; Tue, 12 Mar 2013 12:52:04 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 80C0211E80F2 for ; Tue, 12 Mar 2013 12:52:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:52058 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFVEo-0007iI-J2; Tue, 12 Mar 2013 20:51:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rbarnes@bbn.com X-Trac-Project: jose Date: Tue, 12 Mar 2013 19:51:54 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/10 Message-ID: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, rbarnes@bbn.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130312195203.80C0211E80F2@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 12:52:03 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #10: Remove implementation requirements X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 19:52:05 -0000 #10: Remove implementation requirements There has been long-standing agreement in the group that JWA algorithms should not have requirements levels. Instead, applications using JWE/JWS should specify which algorithms should be used. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: algorithms | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Tue Mar 12 12:59:48 2013 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 D34B61F0D08 for ; Tue, 12 Mar 2013 12:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.652 X-Spam-Level: X-Spam-Status: No, score=-0.652 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RDNS_NONE=0.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 3o+Yk6U6o-4Q for ; Tue, 12 Mar 2013 12:59:45 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id DBCC321F852C for ; Tue, 12 Mar 2013 12:59:42 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id ta14so262010obb.14 for ; Tue, 12 Mar 2013 12:59:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=aY8fYHr7sO7yXhdbCS1amgY8YVEe3im2DAAWvGV2zR8=; b=PVwUdyikMCP0VQbn6lnEKtA8gwGeu111E8sdIZOg1Fn4NGMYPnBzWCoHB0uxgjyFMd 7U+kdkwddDIopXDuWN9361r/Z0l75Twmq2lKVxOghxxG2QeshfhZfeYUZbxQFJtp2fc1 Zf3pyRI27wdthGsT6VzenJqr9sWP3vwXEbigbRVkH0Y0b6L/+80aZUnv/9kO+Gu8Q4Ib VWr+O560FJQbHMMtjmkYdW/NpcE5GRY6Z+5z5WG2fuTSCAhcPI7NNJc/d8VJLHbAPQBQ CUKMkJ+lVdTpeNvAAuroK8NueOvn+jYAsUf4fKs8Pg3MMkZLXMZRE8CbE2T5PHrL81bn z6Yg== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr13199514oec.126.1363118382204; Tue, 12 Mar 2013 12:59:42 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 12:59:42 -0700 (PDT) X-Originating-IP: [128.89.253.127] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> Date: Tue, 12 Mar 2013 15:59:42 -0400 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=bcaec54fae48f5658004d7bfbabb X-Gm-Message-State: ALoCoQlx47RKh65tjeN0/s+erFqa7xIdpFXJjEzUVTnyOZg3PIU9os8zzFgOe4p+gD1axH6bkAtN Cc: "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 19:59:51 -0000 --bcaec54fae48f5658004d7bfbabb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, for everything but key agreement, we can just use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys. We should not be specifying key expansion here when we can avoid it. --Richard On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A wrote: > draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use > of Concat KDF on the shared secret Z established by ECDH-ES.**** > > ** ** > > The draft allows for an empty PartyUInfo and PartyVInfo but that may not > be allowed by NIST SP 800-56A (where the Concat KDF is defined).**** > > The current (March 2007) version of NIST SP 800-56A requires =93At a > minimum, *PartyUInfo **shall *include *ID**U*, the identifier of party *U= *.=94 > and an equivalent requirement for PartyVInfo. (Page 46 of > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Ma= r08-2007.pdf) > **** > > The August 2012 draft update to NIST SP 800-56A requires =93At a minimum, > PartyUInfo shall include IDu, an identifier for party U, as a distinct it= em > of information.=94 and an equivalent requirement for PartyVInfo. (Page 59= of > http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) > My interpretation of this text (others may interpret it differently) is > that PartyUInfo and PartyVInfo can=92t be empty.**** > > ** ** > > Instead of using the Concat KDF, a more appropriate choice may be the KDF > described in NIST SP 800-56C and RFC 5869.**** > > Its requirements are not as strict. (SP 800-56C Page 13: =93If the > information is available, *Context **should *include the identifiers of > the parties who are deriving and/or using the derived keying material=94)= ** > ** > > ** ** > > It would look something like this:**** > > ** ** > > Step 1 - Randomness Extraction:**** > > Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice > for all of the current algorithms)**** > > ** ** > > Step 2 - Expansion Step: **** > > Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 > with the same HMAC algorithm used in step 1 to produce needed keys from t= he > Key Derivation Key produced in step 1.**** > > The needed keys would depend on the values of alg and enc.**** > > If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit > key is needed (used to decrypt the CMK, which may then need to be split > into CEK/CIK).**** > > If alg is ECDH-ES, then the needed keys depend on =93enc=94:**** > > If enc is AES-GCM, a 128 bit key or 256 bit key is needed.**** > > If enc is one of the AEAD AES-CBC algorithms in > draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LE= N > is needed as it=92s then split into two by the AEAD algorithm.**** > > If enc is one of the current CBC+HMAC options in > draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK a= nd > a CIK. Counter Mode KDF could be invoked twice, with different labels ea= ch > time, or Counter Mode KDF could be invoked once to generate a big key whi= ch > would then be split into the CEK and CIK.**** > > ** ** > > Richard has already pointed out the issues with using the Concat KDF to > derive the CEK/CIK from the CMK. Instead, one option would be to use the > Expansion Step above: use the Counter Mode KDF with an HMAC to derive > necessary keys from the CMK. **** > > Even if we use encryption algorithms that combine the encryption and > integrity key such as the CBC+HMAC algorithms in > draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to tak= e > a smaller master key and create the combined encryption + integrity key > from it.**** > > ** ** > > ** ** > > Mike**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54fae48f5658004d7bfbabb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Actually, for everything but key agreement, we can just use=A0draft-mcgrew-= aead-aes-cbc-hmac-sha2, with larger keys. =A0We should not be specifying ke= y expansion here when we can avoid it.

--Richard



On Tue, Mar 12, 2013 at 2= :29 PM, Peck, Michael A <mpeck@mitre.org> wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1= describes the use of Concat KDF on the shared secret Z established by ECDH= -ES.

=A0

The draft allows for an empty PartyUInfo and PartyVI= nfo but that may not be allowed by NIST SP 800-56A (where the Concat KDF is= defined).

The current (March 2007) version of NIST SP 800-56A = requires =93At a minimum, PartyUInfo shall include IDU, the identifie= r of party U.=94 and an equivalent requirement for PartyVInfo. (Page 46 of http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar0= 8-2007.pdf )

The August 2012 draft update to NIST SP 800-56A requ= ires =93At a minimum, PartyUInfo shall include IDu, an identifier for party= U, as a distinct item of information.=94 and an equivalent requirement for= PartyVInfo. (Page 59 of http://csrc.nist.gov/publications/drafts/800-56a/d= raft-sp-800-56a.pdf )=A0 My interpretation of this text (others may int= erpret it differently) is that PartyUInfo and PartyVInfo can=92t be empty.

=A0

Instead of using the Concat KDF, a more appropriate = choice may be the KDF described in NIST SP 800-56C and RFC 5869.<= /u>

Its requirements are not as strict.=A0 (SP 800-56C Page 13: =93If the information is available, Context should include the identifiers of the = parties who are deriving and/or using the derived keying material=94)

=A0

It would look something like this:

=A0

Step 1 - Randomness Extraction:

Key Derivation Key :=3D HMAC(salt, Z)=A0=A0=A0=A0=A0= =A0=A0=A0 (HMAC-SHA256 should suffice for all of the current algorithms)=

=A0

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or se= ction 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produc= e needed keys from the Key Derivation Key produced in step 1.=

The needed keys would depend on the values of alg an= d enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single= 128 bit or 256 bit key is needed (used to decrypt the CMK, which may then = need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on = =93enc=94:

If enc is AES-GCM, a 128 bit key or 256 bit key is n= eeded.

If enc is one of the AEAD AES-CBC algorithms in draf= t-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is n= eeded as it=92s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in dra= ft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK and a = CIK.=A0 Counter Mode KDF could be invoked twice, with different labels each= time, or Counter Mode KDF could be invoked once to generate a big key which would then be split into the CEK = and CIK.

=A0

Richard has already pointed out the issues with usin= g the Concat KDF to derive the CEK/CIK from the CMK.=A0 Instead, one option= would be to use the Expansion Step above: =A0use the Counter Mode KDF with= an HMAC to derive necessary keys from the CMK.=A0

Even if we use encryption algorithms that combine th= e encryption and integrity key such as the CBC+HMAC algorithms in draft-mcg= rew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take a smaller= master key and create the combined encryption + integrity key from it.

=A0

=A0

Mike

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec54fae48f5658004d7bfbabb-- From Michael.Jones@microsoft.com Tue Mar 12 13:12:23 2013 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 BDF5211E8167 for ; Tue, 12 Mar 2013 13:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 vkpsSTet9a1v for ; Tue, 12 Mar 2013 13:12:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id 79A0D11E8164 for ; Tue, 12 Mar 2013 13:12:21 -0700 (PDT) Received: from BN1AFFO11FD008.protection.gbl (10.58.52.200) by BN1AFFO11HUB021.protection.gbl (10.58.52.131) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 20:12:18 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD008.mail.protection.outlook.com (10.58.52.68) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 20:12:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 20:11:42 +0000 From: Mike Jones To: Richard Barnes , John Bradley Thread-Topic: [jose] RSASSA-PSS signature Thread-Index: Ac4fUsSatNxE3pBSSnqP5xo0kQPdBQABHnOAAADa5gAAAKOmYA== Date: Tue, 12 Mar 2013 20:11:41 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(377454001)(199002)(189002)(377424002)(16236675001)(33656001)(47976001)(55846006)(51856001)(47446002)(54316002)(63696002)(50986001)(49866001)(59766001)(79102001)(65816001)(77982001)(54356001)(31966008)(80022001)(16406001)(69226001)(562884003)(76482001)(46102001)(66066001)(20776003)(5343655001)(15202345001)(5343635001)(74662001)(74502001)(56776001)(53806001)(47736001)(4396001)(512954001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB021; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 20:12:23 -0000 --_004_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Your statement that there are no MTI algorithms is actually incorrect. The= current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) algorit= hms, and indeed, as currently chartered, we are required to define the set = of MTI algorithms. The spreadsheet characterizing platform support for possible algorithms tha= t John referred to is attached. As you can see, RSA PKCS1-v1_5 is the only= ubiquitously implemented asymmetric encryption algorithm. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Tuesday, March 12, 2013 12:49 PM To: John Bradley Cc: Peck, Michael A; jose@ietf.org Subject: Re: [jose] RSASSA-PSS signature Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. Only benefit! --Richard On Tue, Mar 12, 2013 at 3:24 PM, John Bradley > wrote: This has had a fair amount of discussion. While I think almost everyone w= ould prefer PSS, many implementations are going to be in scripting language= s where the underlying libraries only support PKCS1-v1_5. We did a survey of platforms to evaluate if we could move to PSS and the re= sult lead us not to make PSS as the MTI. In think that was reported out at= the Atlanta IETF meeting. Nat may be able to forward that to you, I don't have it handy. If we were talking about starting from scratch and not building on existing= platforms likely the answer would have been different. The algorithms are extensible so PSS can be added. The other consideratio= n is that many of the people who care will be using ECESA signatures anyway= . John B. On 2013-03-12, at 2:52 PM, "Peck, Michael A" > wrote: draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signature= s but not RSASSA-PSS. The Security Considerations states: While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1, for interoperability reasons, because it commonly implemented. Shouldn't RSASSA-PSS at least be included as an option? I'm also not sure if I fully understand the interoperability concerns. JWS= is a new specification, so it makes sense to me to use whatever algorithms= are currently considered best practice, without need to worry about backwa= rds compatibility? Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Your statement that there= are no MTI algorithms is actually incorrect.  The current JWA draft s= pecifies REQUIRED (and RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, we are required to define the set of MTI a= lgorithms.

 <= /p>

The spreadsheet character= izing platform support for possible algorithms that John referred to is att= ached.  As you can see, RSA PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption algorithm.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS signature

 

Since we are not putting requirements on algorithms = (i.e., there is no MTI), there's no harm to having PSS in the algorithms li= st.  Only benefit!  

--Richard

 

 

On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

This has had a fair amount of discussion.   Whi= le I think almost everyone would prefer PSS, many implementations are going= to be in scripting languages where the underlying libraries only support P= KCS1-v1_5.

 

We did a survey of platforms to evaluate if we could= move to PSS and the result lead us not to make PSS as the MTI.  In th= ink that was reported out at the Atlanta IETF meeting.

Nat may be able to forward that to you, I don't have= it handy.

 

If we were talking about starting from scratch and n= ot building on existing platforms likely the answer would have been differe= nt.

 

The algorithms are extensible so PSS can be added. &= nbsp; The other consideration is that many of the people who care will be u= sing ECESA signatures anyway.

 

John B.

 

On 2013-03-12, at 2:52 PM, "Peck, Michael A&quo= t; <mpeck@mitre.org= > wrote:

 

draft-ietf-jose-json-web-algorithms-08 = includes RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.=

 

The Security Considerations states:

   While Section 8 of RFC 344= 7 [RFC3447] explicitly calls for people not

   to adopt RSASSA-PKCS1 for = new applications and instead requests that

   people transition to RSASS= A-PSS, this specification does include

   RSASSA-PKCS1, for interope= rability reasons, because it commonly

   implemented.

 

Shouldn’t RSASSA-PSS at least be = included as an option?

I’m also not sure if I fully unde= rstand the interoperability concerns.  JWS is a new specification, so = it makes sense to me to use whatever algorithms are currently considered best practice, without need to worry about backwards compatibility?

 

Mike

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx" Content-Description: Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx Content-Disposition: attachment; filename="Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx"; size=18750; creation-date="Mon, 29 Oct 2012 04:56:21 GMT"; modification-date="Sat, 28 Jul 2012 02:24:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_004_4E1F6AAD24975D4BA5B168042967394367500130TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 12 13:21:03 2013 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 0382D11E8140 for ; Tue, 12 Mar 2013 13:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6] 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 2GPuSiIPoeUT for ; Tue, 12 Mar 2013 13:20:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9C111E8108 for ; Tue, 12 Mar 2013 13:20:59 -0700 (PDT) Received: from BL2FFO11FD005.protection.gbl (10.173.161.200) by BL2FFO11HUB035.protection.gbl (10.173.161.115) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 20:20:56 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 20:20:56 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 20:20:00 +0000 From: Mike Jones To: Richard Barnes , "Peck, Michael A" Thread-Topic: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: AQHOH1w+q0obM/4B3E2z5wOsWscejpiifSFA Date: Tue, 12 Mar 2013 20:19:59 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675001A6TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(24454001)(124975001)(243025002)(377454001)(31966008)(512954001)(63696002)(16406001)(79102001)(53806001)(46102001)(4396001)(33656001)(49866001)(77982001)(54316002)(44976002)(56816002)(5343635001)(47446002)(76482001)(74502001)(74662001)(51856001)(50986001)(69226001)(20776003)(16297215001)(15202345001)(59766001)(66066001)(56776001)(65816001)(47736001)(47976001)(80022001)(55846006)(54356001)(5343655001)(16236675001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB035; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 20:21:03 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675001A6TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As previously extensively discussed, the McGrew draft does two things - one= helpful and one not: 1. It specifies using a key that is actually the concatenation of an AES-C= BC key and an HMAC SHA-2 key, rather than use of a KDF. That's good, as it= 's simple for implementers. 2. It specifies that the initialization vector and integrity value be conc= atenated with other values in particular ways, and conversely, how to extra= ct them when decrypting. That's not good, as it adds complexity for implem= enters - especially when JWEs already utilize a straightforward representat= ion for these values, which doesn't require the binary concatenation and ex= traction conventions specified by McGrew. I know that John Bradley is going to ask the question tomorrow whether we s= hould change to doing the first for our composite CBC+HMAC algorithms. I b= elieve that doing the second would be counterproductive. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Tuesday, March 12, 2013 1:00 PM To: Peck, Michael A Cc: jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK Actually, for everything but key agreement, we can just use draft-mcgrew-ae= ad-aes-cbc-hmac-sha2, with larger keys. We should not be specifying key ex= pansion here when we can avoid it. --Richard On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A > wrote: draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of C= oncat KDF on the shared secret Z established by ECDH-ES. The draft allows for an empty PartyUInfo and PartyVInfo but that may not be= allowed by NIST SP 800-56A (where the Concat KDF is defined). The current (March 2007) version of NIST SP 800-56A requires "At a minimum,= PartyUInfo shall include IDU, the identifier of party U." and an equivalen= t requirement for PartyVInfo. (Page 46 of http://csrc.nist.gov/publications= /nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf ) The August 2012 draft update to NIST SP 800-56A requires "At a minimum, Par= tyUInfo shall include IDu, an identifier for party U, as a distinct item of= information." and an equivalent requirement for PartyVInfo. (Page 59 of ht= tp://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) My i= nterpretation of this text (others may interpret it differently) is that Pa= rtyUInfo and PartyVInfo can't be empty. Instead of using the Concat KDF, a more appropriate choice may be the KDF d= escribed in NIST SP 800-56C and RFC 5869. Its requirements are not as strict. (SP 800-56C Page 13: "If the informati= on is available, Context should include the identifiers of the parties who = are deriving and/or using the derived keying material") It would look something like this: Step 1 - Randomness Extraction: Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice f= or all of the current algorithms) Step 2 - Expansion Step: Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 w= ith the same HMAC algorithm used in step 1 to produce needed keys from the = Key Derivation Key produced in step 1. The needed keys would depend on the values of alg and enc. If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key= is needed (used to decrypt the CMK, which may then need to be split into C= EK/CIK). If alg is ECDH-ES, then the needed keys depend on "enc": If enc is AES-GCM, a 128 bit key or 256 bit key is needed. If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-h= mac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it's then spli= t into two by the AEAD algorithm. If enc is one of the current CBC+HMAC options in draft-ietf-jose-json-web-a= lgorithms-08, then two keys are needed, a CEK and a CIK. Counter Mode KDF = could be invoked twice, with different labels each time, or Counter Mode KD= F could be invoked once to generate a big key which would then be split int= o the CEK and CIK. Richard has already pointed out the issues with using the Concat KDF to der= ive the CEK/CIK from the CMK. Instead, one option would be to use the Expa= nsion Step above: use the Counter Mode KDF with an HMAC to derive necessar= y keys from the CMK. Even if we use encryption algorithms that combine the encryption and integr= ity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-s= ha2-01, there will still be a need to take a smaller master key and create = the combined encryption + integrity key from it. Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943675001A6TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As previously extensively= discussed, the McGrew draft does two things – one helpful and one no= t:

 <= /p>

1.  It specifies usi= ng a key that is actually the concatenation of an AES-CBC key and an HMAC S= HA-2 key, rather than use of a KDF.  That’s good, as it’s = simple for implementers.

 <= /p>

2.  It specifies tha= t the initialization vector and integrity value be concatenated with other = values in particular ways, and conversely, how to extract them when decrypting.  That’s not good, as it adds complexity for im= plementers – especially when JWEs already utilize a straightforward r= epresentation for these values, which doesn’t require the binary conc= atenation and extraction conventions specified by McGrew.=

 <= /p>

I know that John Bradley = is going to ask the question tomorrow whether we should change to doing the= first for our composite CBC+HMAC algorithms.  I believe that doing the second would be counterproductive.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 1:00 PM
To: Peck, Michael A
Cc: jose@ietf.org
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK

 

Actually, for everything but key agreement, we can j= ust use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  W= e should not be specifying key expansion here when we can avoid it.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <= ;mpeck@mitre.org&g= t; wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the= use of Concat KDF on the shared secret Z established by ECDH-ES.

 

The draft allows for an empty PartyUInfo and PartyVInfo but that m= ay not be allowed by NIST SP 800-56A (where the Concat KDF is defined).

The current (March 2007) version of NIST SP 800-56A requires ̶= 0;At a minimum, PartyUInfo shall include IDU, the identifie= r of party U.” and an equivalent requirement for PartyVInfo. (Page 46 of = http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar0= 8-2007.pdf )

The August 2012 draft update to NIST SP 800-56A requires “At= a minimum, PartyUInfo shall include IDu, an identifier for party U, as a d= istinct item of information.” and an equivalent requirement for PartyVInfo. (Page 59 of http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )=   My interpretation of this text (others may interpret it differently)= is that PartyUInfo and PartyVInfo can’t be empty.

 

Instead of using the Concat KDF, a more appropriate choice may be = the KDF described in NIST SP 800-56C and RFC 5869.

Its requirements are not as strict.  (SP 800-56C Page 13: “If the information is available, Context should include the identifiers of the = parties who are deriving and/or using the derived keying material”)

 

It would look something like this:

 

Step 1 - Randomness Extraction:

Key Derivation Key :=3D HMAC(salt, Z)     = ;    (HMAC-SHA256 should suffice for all of the current algo= rithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of R= FC 5869 with the same HMAC algorithm used in step 1 to produce needed keys = from the Key Derivation Key produced in step 1.

The needed keys would depend on the values of alg and enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 b= it or 256 bit key is needed (used to decrypt the CMK, which may then need t= o be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on “enc”= ;:

If enc is AES-GCM, a 128 bit key or 256 bit key is needed.

If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-= aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as i= t’s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in draft-ietf-jo= se-json-web-algorithms-08, then two keys are needed, a CEK and a CIK. = Counter Mode KDF could be invoked twice, with different labels each time, or Counter Mode KDF could be invoked once to g= enerate a big key which would then be split into the CEK and CIK.

 

Richard has already pointed out the issues with using the Concat K= DF to derive the CEK/CIK from the CMK.  Instead, one option would be t= o use the Expansion Step above:  use the Counter Mode KDF with an HMAC to derive necessary keys from the CMK. =

Even if we use encryption algorithms that combine the encryption a= nd integrity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-a= es-cbc-hmac-sha2-01, there will still be a need to take a smaller master key and create the combined encryption = 3; integrity key from it.

 

 

Mike

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B1680429673943675001A6TK5EX14MBXC283r_-- From ietf@meetecho.com Tue Mar 12 13:23:31 2013 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 1291211E8189 for ; Tue, 12 Mar 2013 13:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.661 X-Spam-Level: X-Spam-Status: No, score=-0.661 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 bzyZuhbDlBN6 for ; Tue, 12 Mar 2013 13:23:30 -0700 (PDT) Received: from smtpdg8.aruba.it (smtpdg226.aruba.it [62.149.158.226]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7A011E8192 for ; Tue, 12 Mar 2013 13:23:29 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd03.ad.aruba.it with bizsmtp id AkPR1l00G2w8SR601kPTRH; Tue, 12 Mar 2013 21:23:28 +0100 Date: Tue, 12 Mar 2013 16:23:23 -0400 (EDT) From: Meetecho Team To: jose@ietf.org Message-ID: <21489256.13.1363119803617.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_12_19680343.1363119803615" Subject: [jose] Meetecho support for JOSE session 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, 12 Mar 2013 20:23:31 -0000 ------=_Part_12_19680343.1363119803615 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, a virtual room has been reserved on the Meetecho system for the JOSE WG meeting session. Access to the on-line session (including audio and video streams) will be made available (just a couple of minutes before session start time) at: http://www.meetecho.com/ietf86/jose The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf86 Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_12_19680343.1363119803615-- From rlb@ipv.sx Tue Mar 12 13:24:12 2013 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 1D15011E81A4 for ; Tue, 12 Mar 2013 13:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.133 X-Spam-Level: X-Spam-Status: No, score=-1.133 tagged_above=-999 required=5 tests=[AWL=-0.708, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 vP4wGgl8gB75 for ; Tue, 12 Mar 2013 13:24:11 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 22D6111E81A0 for ; Tue, 12 Mar 2013 13:24:11 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so283216obc.13 for ; Tue, 12 Mar 2013 13:24:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EV/xpy3OoqEr+ZXgguWi9IG1bEMgJC1arp+QRZtiGT0=; b=E/jOTONmPsspl5k1s+APdkloCScrt8Kom/KJgjpXcVHUlYMWfwIK4R+CbdaO10BHcp RPxY0DmTqmdOllYKQH2cj5YLOfDCPJMSutus817g9OCtWnJ/REFByRr6NcpekI2WCr+D pZOvNUIC6m5OUk74yLjkLwqpISA7ooFra/lmTE7jwvKNDD/HntCC+6tVVb+MGuwM1Tvz 4QqboD3Ef7n0T8F9sV5Tq3InGhzG1H09AF64Zzg47k2UUsvvG8Z4e53nPeleSDDjgyqG GhK9jNVQtOjAJ1MxPPYSRbsI6PIwL96kue7eRziL6bCTE0Re+/UJ6m3XAwH98sda+wBo A7Pw== MIME-Version: 1.0 X-Received: by 10.182.132.43 with SMTP id or11mr13384033obb.67.1363119849262; Tue, 12 Mar 2013 13:24:09 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 13:24:09 -0700 (PDT) X-Originating-IP: [128.89.253.127] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 16:24:09 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=14dae93a0c1766ecbb04d7c012f2 X-Gm-Message-State: ALoCoQnAt/e9XezSsuPV4IJ1qyX6l37YgzHozFYFnoopro4klEZaFIfFm806E4eoqiMp9ABxGO9c Cc: John Bradley , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 20:24:12 -0000 --14dae93a0c1766ecbb04d7c012f2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I know the current JWA says that. That's a bug. I just submitted an issue. We have discussed this several times in the working group, most recently in Atlanta, where there was a fair degree of agreement on removing requirements levels. --Richard On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones wr= ote: > Your statement that there are no MTI algorithms is actually incorrect. > The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) > algorithms, and indeed, as currently chartered, we are required to define > the set of MTI algorithms.**** > > ** ** > > The spreadsheet characterizing platform support for possible algorithms > that John referred to is attached. As you can see, RSA PKCS1-v1_5 is the > only ubiquitously implemented asymmetric encryption algorithm.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Tuesday, March 12, 2013 12:49 PM > *To:* John Bradley > *Cc:* Peck, Michael A; jose@ietf.org > *Subject:* Re: [jose] RSASSA-PSS signature**** > > ** ** > > Since we are not putting requirements on algorithms (i.e., there is no > MTI), there's no harm to having PSS in the algorithms list. Only benefit= ! > **** > > --Richard**** > > ** ** > > ** ** > > On Tue, Mar 12, 2013 at 3:24 PM, John Bradley wrote:*= * > ** > > This has had a fair amount of discussion. While I think almost everyone > would prefer PSS, many implementations are going to be in scripting > languages where the underlying libraries only support PKCS1-v1_5.**** > > ** ** > > We did a survey of platforms to evaluate if we could move to PSS and the > result lead us not to make PSS as the MTI. In think that was reported ou= t > at the Atlanta IETF meeting.**** > > Nat may be able to forward that to you, I don't have it handy.**** > > ** ** > > If we were talking about starting from scratch and not building on > existing platforms likely the answer would have been different.**** > > ** ** > > The algorithms are extensible so PSS can be added. The other > consideration is that many of the people who care will be using ECESA > signatures anyway.**** > > ** ** > > John B.**** > > ** ** > > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote:**** > > ** ** > > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 > signatures but not RSASSA-PSS.**** > > **** > > The Security Considerations states:**** > > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not*= * > ** > > to adopt RSASSA-PKCS1 for new applications and instead requests that**= * > * > > people transition to RSASSA-PSS, this specification does include**** > > RSASSA-PKCS1, for interoperability reasons, because it commonly**** > > implemented.**** > > **** > > Shouldn=92t RSASSA-PSS at least be included as an option?**** > > I=92m also not sure if I fully understand the interoperability concerns. > JWS is a new specification, so it makes sense to me to use whatever > algorithms are currently considered best practice, without need to worry > about backwards compatibility?**** > > **** > > Mike**** > > **** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --14dae93a0c1766ecbb04d7c012f2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes, I know the current JWA says tha= t. =A0That's a bug. =A0I just submitted an issue. =A0We have discussed = this several times in the working group, most recently in Atlanta, where th= ere was a fair degree of agreement on removing requirements levels.<= div>
--Richard

<= font color=3D"#222222" face=3D"arial, sans-serif">

On Tue, Mar 12, 2013 at 4:= 11 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

Your statement that there= are no MTI algorithms is actually incorrect.=A0 The current JWA draft spec= ifies REQUIRED (and RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, we are required to define the set of MTI a= lgorithms.

=A0<= /p>

The spreadsheet character= izing platform support for possible algorithms that John referred to is att= ached.=A0 As you can see, RSA PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption algorithm.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS signature

=A0

Since we are not putting requirements on algorithms = (i.e., there is no MTI), there's no harm to having PSS in the algorithm= s list. =A0Only benefit! =A0

--Richard

=A0

=A0

On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

This has had a fair amount of discussion. =A0 While = I think almost everyone would prefer PSS, many implementations are going to= be in scripting languages where the underlying libraries only support PKCS= 1-v1_5.

=A0

We did a survey of platforms to evaluate if we could= move to PSS and the result lead us not to make PSS as the MTI. =A0In think= that was reported out at the Atlanta IETF meeting.

Nat may be able to forward that to you, I don't = have it handy.

=A0

If we were talking about starting from scratch and n= ot building on existing platforms likely the answer would have been differe= nt.

=A0

The algorithms are extensible so PSS can be added. = =A0 The other consideration is that many of the people who care will be usi= ng ECESA signatures anyway.

=A0

John B.

=A0

On 2013-03-12, at 2:52 PM, "Peck, Michael A&quo= t; <mpeck@mitre.org= > wrote:

=A0

draft-ietf-jose-json-web-algorithms-08 = includes RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.

=A0

The Security Considerations states:<= /u>

=A0=A0 While Section 8 of RFC 3447 [RFC= 3447] explicitly calls for people not

=A0=A0 to adopt RSASSA-PKCS1 for new ap= plications and instead requests that

=A0=A0 people transition to RSASSA-PSS,= this specification does include

=A0=A0 RSASSA-PKCS1, for interoperabili= ty reasons, because it commonly

=A0=A0 implemented.

=A0

Shouldn=92t RSASSA-PSS at least be incl= uded as an option?

I=92m also not sure if I fully understa= nd the interoperability concerns.=A0 JWS is a new specification, so it make= s sense to me to use whatever algorithms are currently considered best practice, without need to worry about backwards compatibility?=

=A0

Mike

=A0

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--14dae93a0c1766ecbb04d7c012f2-- From Michael.Jones@microsoft.com Tue Mar 12 13:30:37 2013 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 B81B121F8C85 for ; Tue, 12 Mar 2013 13:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 22rV772e06D4 for ; Tue, 12 Mar 2013 13:30:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 812CA21F8B98 for ; Tue, 12 Mar 2013 13:30:34 -0700 (PDT) Received: from BY2FFO11FD022.protection.gbl (10.1.15.204) by BY2FFO11HUB039.protection.gbl (10.1.14.122) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 20:30:32 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 20:30:31 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 20:29:46 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] RSASSA-PSS signature Thread-Index: Ac4fUsSatNxE3pBSSnqP5xo0kQPdBQABHnOAAADa5gAAAKOmYAAAlSGAAAAX+gA= Date: Tue, 12 Mar 2013 20:29:45 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675002CB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943675002CBTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(377454001)(377424002)(24454001)(74502001)(15202345001)(31966008)(5343635001)(79102001)(66066001)(54356001)(20776003)(47446002)(46102001)(65816001)(53806001)(5343655001)(56776001)(51856001)(63696002)(76482001)(55846006)(56816002)(49866001)(4396001)(80022001)(50986001)(59766001)(77982001)(47976001)(47736001)(54316002)(44976002)(74662001)(16406001)(16236675001)(69226001)(512954001)(33656001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB039; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: John Bradley , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 20:30:37 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675002CBTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I obviously defer to the working group on whether it's a bug or not. I was= just trying to have us be clear on what the specs actually say and why. We should probably try to get a clear decision on whether to change that to= morrow. Maybe John should incorporate a slide on it into his presentation,= since he's already covering all the other open issues? Cheers, -- Mike From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Tuesday, March 12, 2013 1:24 PM To: Mike Jones Cc: John Bradley; Peck, Michael A; jose@ietf.org Subject: Re: [jose] RSASSA-PSS signature Yes, I know the current JWA says that. That's a bug. I just submitted an = issue. We have discussed this several times in the working group, most rec= ently in Atlanta, where there was a fair degree of agreement on removing re= quirements levels. --Richard On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones > wrote: Your statement that there are no MTI algorithms is actually incorrect. The= current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) algorit= hms, and indeed, as currently chartered, we are required to define the set = of MTI algorithms. The spreadsheet characterizing platform support for possible algorithms tha= t John referred to is attached. As you can see, RSA PKCS1-v1_5 is the only= ubiquitously implemented asymmetric encryption algorithm. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, March 12, 2013 12:49 PM To: John Bradley Cc: Peck, Michael A; jose@ietf.org Subject: Re: [jose] RSASSA-PSS signature Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. Only benefit! --Richard On Tue, Mar 12, 2013 at 3:24 PM, John Bradley > wrote: This has had a fair amount of discussion. While I think almost everyone w= ould prefer PSS, many implementations are going to be in scripting language= s where the underlying libraries only support PKCS1-v1_5. We did a survey of platforms to evaluate if we could move to PSS and the re= sult lead us not to make PSS as the MTI. In think that was reported out at= the Atlanta IETF meeting. Nat may be able to forward that to you, I don't have it handy. If we were talking about starting from scratch and not building on existing= platforms likely the answer would have been different. The algorithms are extensible so PSS can be added. The other consideratio= n is that many of the people who care will be using ECESA signatures anyway= . John B. On 2013-03-12, at 2:52 PM, "Peck, Michael A" > wrote: draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signature= s but not RSASSA-PSS. The Security Considerations states: While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1, for interoperability reasons, because it commonly implemented. Shouldn't RSASSA-PSS at least be included as an option? I'm also not sure if I fully understand the interoperability concerns. JWS= is a new specification, so it makes sense to me to use whatever algorithms= are currently considered best practice, without need to worry about backwa= rds compatibility? Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943675002CBTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I obviously defer to the = working group on whether it’s a bug or not.  I was just trying t= o have us be clear on what the specs actually say and why.

 <= /p>

We should probably try to= get a clear decision on whether to change that tomorrow.  Maybe John = should incorporate a slide on it into his presentation, since he’s already covering all the other open issues?

 <= /p>

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

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

 <= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Tuesday, March 12, 2013 1:24 PM
To: Mike Jones
Cc: John Bradley; Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS signature

 

Yes, I kno= w the current JWA says that.  That's a bug.  I just submitted an = issue.  We have discussed this several times in the working group, most recently in Atlanta, where there was a fair degree of agreement on re= moving requirements levels.

 

--Richard

 

 

 

On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

Your statement that there are no MTI al= gorithms is actually incorrect.  The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) algorithms, and indeed, as currentl= y chartered, we are required to define the set of MTI algorithms.

 

The spreadsheet characterizing platform= support for possible algorithms that John referred to is attached.  As you can see, RSA PKCS1-v1_5 is the only ubiquitously im= plemented asymmetric encryption algorithm.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS signature

 

Since we are not putting requirements on algorithms (i.e., there i= s no MTI), there's no harm to having PSS in the algorithms list.  Only= benefit!  

--Richard

 

 

On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:

This has had a fair amount of discussion.   While I think alm= ost everyone would prefer PSS, many implementations are going to be in scri= pting languages where the underlying libraries only support PKCS1-v1_5.

 

We did a survey of platforms to evaluate if we could move to PSS a= nd the result lead us not to make PSS as the MTI.  In think that was r= eported out at the Atlanta IETF meeting.

Nat may be able to forward that to you, I don't have it handy.

 

If we were talking about starting from scratch and not building on= existing platforms likely the answer would have been different.=

 

The algorithms are extensible so PSS can be added.   The othe= r consideration is that many of the people who care will be using ECESA sig= natures anyway.

 

John B.

 

On 2013-03-12, at 2:52 PM, "Peck, Michael A" <mpeck@mitre.org> wrote= :

 

draft-ietf-jose-json-web-algorithms-08 includes RSASS= A-PKCS1-v1_5 signatures but not RSASSA-PSS.

 

The Security Considerations states:=

   While Section 8 of RFC 3447 [RFC3447] ex= plicitly calls for people not

   to adopt RSASSA-PKCS1 for new applicatio= ns and instead requests that

   people transition to RSASSA-PSS, this sp= ecification does include

   RSASSA-PKCS1, for interoperability reaso= ns, because it commonly

   implemented.

 

Shouldn’t RSASSA-PSS at least be included as an= option?

I’m also not sure if I fully understand the int= eroperability concerns.  JWS is a new specification, so it makes sense to me to use whatever algorithms are currently considered best pract= ice, without need to worry about backwards compatibility?=

 

Mike

 

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943675002CBTK5EX14MBXC283r_-- From trac+jose@trac.tools.ietf.org Tue Mar 12 13:32:16 2013 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 7D97E21F8C8D for ; Tue, 12 Mar 2013 13:32:16 -0700 (PDT) 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 Q0EsbcDp1TRe for ; Tue, 12 Mar 2013 13:32:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A532921F8C8C for ; Tue, 12 Mar 2013 13:32:15 -0700 (PDT) Received: from localhost ([127.0.0.1]:54891 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFVrY-0000a1-JL; Tue, 12 Mar 2013 21:31:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rbarnes@bbn.com X-Trac-Project: jose Date: Tue, 12 Mar 2013 20:31:56 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/11 Message-ID: <054.e72d4c43dc02c0b9f61660ef223433e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rbarnes@bbn.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130312203215.A532921F8C8C@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 13:32:15 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #11: Use RFC 5116 and remove MAC field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 20:32:16 -0000 #11: Use RFC 5116 and remove MAC field RFC 5116 defines a standard interface to AEAD algorithms (including CCM and GCM), which produces a combined ciphertext and ICV as a single octet sequence. JWE should use this standard interface instead of its own, and remove the "JWE Integrity Value" from JWE. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose From ve7jtb@ve7jtb.com Tue Mar 12 13:43:37 2013 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 B123A11E80D2 for ; Tue, 12 Mar 2013 13:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=-1.591, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 DG0EYKXuAEvi for ; Tue, 12 Mar 2013 13:43:36 -0700 (PDT) Received: from mail-gg0-x231.google.com (mail-gg0-x231.google.com [IPv6:2607:f8b0:4002:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 966041F0C36 for ; Tue, 12 Mar 2013 13:43:36 -0700 (PDT) Received: by mail-gg0-f177.google.com with SMTP id q1so61607gge.8 for ; Tue, 12 Mar 2013 13:43:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ZkNJKAJoYJ3OsNUM8nIftXdOjcfDZcKWXxy4PDAhUD8=; b=KlzLxmcE5VuYUxsQ5ao3CCN2Ocyf5UfEPfedw6jfYY1YvBAQEZwP5OmpU5kuLV6jcq Gj/+tM4m/kVtX/7zMZVIOT82DE6OetUtU/EGSB9FPS7XGIaJXp+pLgpU0txg7ZQO0nMT lcxjlH6fucjN2r1Y2BlZlgKKEWAHQhSZ4Dcd9pR9BRvcf0DWSV07bNZYN2M9YXlGb5lu VnuwW5lwYo8kj7wZnf5n07UddqQhpsUlURbMzfn1ZNqjB3vakdwSoIyUQREpw1nSFi9P dSIKcB5pCnoRsbtzt4BNVKOIS8cSgIyQGpagvfrzfdPgs7b1CK93bJU7OkLuIlSokfg0 ShwA== X-Received: by 10.236.127.68 with SMTP id c44mr13731207yhi.113.1363121012340; Tue, 12 Mar 2013 13:43:32 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id j23sm19141739yha.3.2013.03.12.13.43.18 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 13:43:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_70EC8503-6F96-48CF-A985-237118933C3D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675002CB@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 16:43:09 -0400 Message-Id: <345FB995-5251-4746-B293-3F03049EFA6A@ve7jtb.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B1680429673943675002CB@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmBcmBZQR6MI0ei3gzV+4biD/RgZSK4SNzmtGjElzgAKC/mFCvuOjXIjuNeTXKC4YyJRfW2 Cc: Richard Barnes , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 20:43:37 -0000 --Apple-Mail=_70EC8503-6F96-48CF-A985-237118933C3D Content-Type: multipart/alternative; boundary="Apple-Mail=_1182ED92-E719-4712-92D3-F471EE85CE91" --Apple-Mail=_1182ED92-E719-4712-92D3-F471EE85CE91 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I have already updated the slides and sent them on to Jim and Karen to = include the issue. The question is given the recent feedback on interoperability, is if = IDESG will allow us through with no MTI. MTI is not mandatory to use as a WG chair once mentioned. =20 Is there really a objection to having libraries include the ability to = do RSA-PKCS1-v1.5 encryption as a base? I agree applications determine the algorithms used.=20 John B. On 2013-03-12, at 4:29 PM, Mike Jones = wrote: > I obviously defer to the working group on whether it=92s a bug or not. = I was just trying to have us be clear on what the specs actually say = and why. > =20 > We should probably try to get a clear decision on whether to change = that tomorrow. Maybe John should incorporate a slide on it into his = presentation, since he=92s already covering all the other open issues? > =20 > Cheers, > -- Mike > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Tuesday, March 12, 2013 1:24 PM > To: Mike Jones > Cc: John Bradley; Peck, Michael A; jose@ietf.org > Subject: Re: [jose] RSASSA-PSS signature > =20 > Yes, I know the current JWA says that. That's a bug. I just = submitted an issue. We have discussed this several times in the working = group, most recently in Atlanta, where there was a fair degree of = agreement on removing requirements levels. > =20 > --Richard > =20 > =20 > =20 > On Tue, Mar 12, 2013 at 4:11 PM, Mike Jones = wrote: > Your statement that there are no MTI algorithms is actually incorrect. = The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) = algorithms, and indeed, as currently chartered, we are required to = define the set of MTI algorithms. > =20 > The spreadsheet characterizing platform support for possible = algorithms that John referred to is attached. As you can see, RSA = PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption = algorithm. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Tuesday, March 12, 2013 12:49 PM > To: John Bradley > Cc: Peck, Michael A; jose@ietf.org > Subject: Re: [jose] RSASSA-PSS signature > =20 > Since we are not putting requirements on algorithms (i.e., there is no = MTI), there's no harm to having PSS in the algorithms list. Only = benefit! =20 > --Richard > =20 > =20 > On Tue, Mar 12, 2013 at 3:24 PM, John Bradley = wrote: > This has had a fair amount of discussion. While I think almost = everyone would prefer PSS, many implementations are going to be in = scripting languages where the underlying libraries only support = PKCS1-v1_5. > =20 > We did a survey of platforms to evaluate if we could move to PSS and = the result lead us not to make PSS as the MTI. In think that was = reported out at the Atlanta IETF meeting. > Nat may be able to forward that to you, I don't have it handy. > =20 > If we were talking about starting from scratch and not building on = existing platforms likely the answer would have been different. > =20 > The algorithms are extensible so PSS can be added. The other = consideration is that many of the people who care will be using ECESA = signatures anyway. > =20 > John B. > =20 > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote: > =20 > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 = signatures but not RSASSA-PSS. > =20 > The Security Considerations states: > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people = not > to adopt RSASSA-PKCS1 for new applications and instead requests = that > people transition to RSASSA-PSS, this specification does include > RSASSA-PKCS1, for interoperability reasons, because it commonly > implemented. > =20 > Shouldn=92t RSASSA-PSS at least be included as an option? > I=92m also not sure if I fully understand the interoperability = concerns. JWS is a new specification, so it makes sense to me to use = whatever algorithms are currently considered best practice, without need = to worry about backwards compatibility? > =20 > Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 --Apple-Mail=_1182ED92-E719-4712-92D3-F471EE85CE91 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I have already updated the = slides and sent them on to Jim and Karen to include the = issue.

The question is given the recent feedback on = interoperability, is if IDESG will allow us through with no = MTI.

MTI is not mandatory to use as a WG chair = once mentioned.   

Is there really a = objection to having libraries include the ability to do RSA-PKCS1-v1.5 = encryption as a base?

I agree applications = determine the algorithms used. 

John = B.

On 2013-03-12, at 4:29 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I obviously defer to the = working group on whether it=92s a bug or not.  I was just trying to = have us be clear on what the specs actually say and = why.
 
We should probably try to get a clear = decision on whether to change that tomorrow.  Maybe John should = incorporate a slide on it into his presentation, since he=92s already = covering all the other open issues?
 
 
Yes, I know the current JWA says = that.  That's a bug.  I just submitted an issue.  We have = discussed this several times in the working group, most recently in = Atlanta, where there was a fair degree of agreement on removing = requirements levels.
 
From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Tuesday, March 12, 2013 = 12:49 PM
To: John = Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS = signature
Since we are = not putting requirements on algorithms (i.e., there is no MTI), there's = no harm to having PSS in the algorithms list.  Only benefit! =  
 
The Security Considerations = states:
   to adopt RSASSA-PKCS1 for new applications = and instead requests that
   people transition to RSASSA-PSS, = this specification does include
   RSASSA-PKCS1, for interoperability = reasons, because it commonly
   = implemented.
 
Mike
 
jose@ietf.org
 

In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 12 Mar 2013 16:48:31 -0400 Message-Id: References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkSJEAWxyLrYnTtCDrQgoeygvtopb6KnkGR2JretNx6SC5FfzV2hBl1nFHGlGR2PY2y/cc3 Cc: Richard Barnes , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 20:48:55 -0000 --Apple-Mail=_4E158538-B01C-4B1D-B600-80A94B299A87 Content-Type: multipart/alternative; boundary="Apple-Mail=_38C3AE83-3761-46A6-8BDF-92F03EB9A579" --Apple-Mail=_38C3AE83-3761-46A6-8BDF-92F03EB9A579 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Yes I have the recommendation to change from using a KDF to generate the = CEK and CIK from the CMK to concatenating the CEK and CIK together as in = the McGrew draft. I don't yet have a slide on the new/old issue of concatenating the tag = to the message body vs sending it in a separate field. =20 If people want me to I can add it as well. Though I thought that was a = closed issue. =20 John B. On 2013-03-12, at 4:19 PM, Mike Jones = wrote: > As previously extensively discussed, the McGrew draft does two things = =96 one helpful and one not: > =20 > 1. It specifies using a key that is actually the concatenation of an = AES-CBC key and an HMAC SHA-2 key, rather than use of a KDF. That=92s = good, as it=92s simple for implementers. > =20 > 2. It specifies that the initialization vector and integrity value be = concatenated with other values in particular ways, and conversely, how = to extract them when decrypting. That=92s not good, as it adds = complexity for implementers =96 especially when JWEs already utilize a = straightforward representation for these values, which doesn=92t require = the binary concatenation and extraction conventions specified by McGrew. > =20 > I know that John Bradley is going to ask the question tomorrow whether = we should change to doing the first for our composite CBC+HMAC = algorithms. I believe that doing the second would be counterproductive. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Tuesday, March 12, 2013 1:00 PM > To: Peck, Michael A > Cc: jose@ietf.org > Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK > =20 > Actually, for everything but key agreement, we can just use = draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys. We should not be = specifying key expansion here when we can avoid it. > =20 > --Richard > =20 > =20 >=20 > On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A = wrote: > draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use = of Concat KDF on the shared secret Z established by ECDH-ES. > =20 > The draft allows for an empty PartyUInfo and PartyVInfo but that may = not be allowed by NIST SP 800-56A (where the Concat KDF is defined). > The current (March 2007) version of NIST SP 800-56A requires =93At a = minimum, PartyUInfo shall include IDU, the identifier of party U.=94 and = an equivalent requirement for PartyVInfo. (Page 46 = ofhttp://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_M= ar08-2007.pdf ) > The August 2012 draft update to NIST SP 800-56A requires =93At a = minimum, PartyUInfo shall include IDu, an identifier for party U, as a = distinct item of information.=94 and an equivalent requirement for = PartyVInfo. (Page 59 of = http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) = My interpretation of this text (others may interpret it differently) is = that PartyUInfo and PartyVInfo can=92t be empty. > =20 > Instead of using the Concat KDF, a more appropriate choice may be the = KDF described in NIST SP 800-56C and RFC 5869. > Its requirements are not as strict. (SP 800-56C Page 13: =93If the = information is available, Context should include the identifiers of the = parties who are deriving and/or using the derived keying material=94) >=20 > =20 > It would look something like this: > =20 > Step 1 - Randomness Extraction: > Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should = suffice for all of the current algorithms) > =20 > Step 2 - Expansion Step: > Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC = 5869 with the same HMAC algorithm used in step 1 to produce needed keys = from the Key Derivation Key produced in step 1. > The needed keys would depend on the values of alg and enc. > If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 = bit key is needed (used to decrypt the CMK, which may then need to be = split into CEK/CIK). > If alg is ECDH-ES, then the needed keys depend on =93enc=94: > If enc is AES-GCM, a 128 bit key or 256 bit key is needed. > If enc is one of the AEAD AES-CBC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + = MAC_KEY_LEN is needed as it=92s then split into two by the AEAD = algorithm. > If enc is one of the current CBC+HMAC options in = draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK = and a CIK. Counter Mode KDF could be invoked twice, with different = labels each time, or Counter Mode KDF could be invoked once to generate = a big key which would then be split into the CEK and CIK. > =20 > Richard has already pointed out the issues with using the Concat KDF = to derive the CEK/CIK from the CMK. Instead, one option would be to use = the Expansion Step above: use the Counter Mode KDF with an HMAC to = derive necessary keys from the CMK.=20 > Even if we use encryption algorithms that combine the encryption and = integrity key such as the CBC+HMAC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to = take a smaller master key and create the combined encryption + integrity = key from it. > =20 > =20 > Mike > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_38C3AE83-3761-46A6-8BDF-92F03EB9A579 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Yes I have the recommendation = to change from using a KDF to generate the CEK and CIK from the CMK to = concatenating the CEK and CIK together as in the McGrew = draft.






As previously = extensively discussed, the McGrew draft does two things =96 one helpful = and one not:
 
1.  It specifies using a key that is = actually the concatenation of an AES-CBC key and an HMAC SHA-2 key, = rather than use of a KDF.  That=92s good, as it=92s simple for = implementers.
 
2.  It specifies that the initialization = vector and integrity value be concatenated with other values in = particular ways, and conversely, how to extract them when = decrypting.  That=92s not good, as it adds complexity for = implementers =96 especially when JWEs already utilize a straightforward = representation for these values, which doesn=92t require the binary = concatenation and extraction conventions specified by = McGrew.
 
I know that John Bradley is going to ask the = question tomorrow whether we should change to doing the first for our = composite CBC+HMAC algorithms.  I believe that doing the second = would be counterproductive.
 
 
 jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Tuesday, March 12, 2013 = 1:00 PM
To: Peck, Michael = A
Cc: jose@ietf.org
Subject: Re: [jose] Concat KDF = issues with ECDH-ES and for deriving CEK/CIK from = CMK
Actually, for = everything but key agreement, we can just = use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  We = should not be specifying key expansion here when we can avoid = it.
 

On = Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <mpeck@mitre.org> = wrote:
The draft = allows for an empty PartyUInfo and PartyVInfo but that may not be = allowed by NIST SP 800-56A (where the Concat KDF is = defined).
The current = (March 2007) version of NIST SP 800-56A requires =93At a minimum, PartyUInfo shall include IDU U.=94 and an = equivalent requirement for PartyVInfo. (Page 46 of )
The August 2012 draft update to NIST SP 800-56A = requires =93At a minimum, PartyUInfo shall include IDu, an identifier = for party U, as a distinct item of information.=94 and an equivalent = requirement for PartyVInfo. (Page 59 of http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )  My = interpretation of this text (others may interpret it differently) is = that PartyUInfo and PartyVInfo can=92t be empty.
Its requirements are not as = strict.  (SP 800-56C Page 13: =93 Context should include the identifiers of the parties who = are deriving and/or using the derived keying = material=94)

It would look = something like this:
Step 1 - = Randomness Extraction:
Key = Derivation Key :=3D HMAC(salt, = Z)         (HMAC-SHA256 should = suffice for all of the current algorithms)
 
Use = the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 = with the same HMAC algorithm used in step 1 to produce needed keys from = the Key Derivation Key produced in step 1.
The needed keys would depend on the values of alg = and enc.
If alg is = ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key is = needed (used to decrypt the CMK, which may then need to be split into = CEK/CIK).
If alg is = ECDH-ES, then the needed keys depend on =93enc=94:
If enc is AES-GCM, a 128 bit key or 256 bit key is = needed.
If enc is one = of the AEAD AES-CBC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + = MAC_KEY_LEN is needed as it=92s then split into two by the AEAD = algorithm.
If enc is one = of the current CBC+HMAC options in = draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK = and a CIK.  Counter Mode KDF could be invoked twice, with different = labels each time, or Counter Mode KDF could be invoked once to generate = a big key which would then be split into the CEK and = CIK.
Richard has = already pointed out the issues with using the Concat KDF to derive the = CEK/CIK from the CMK.  Instead, one option would be to use the = Expansion Step above:  use the Counter Mode KDF with an HMAC to = derive necessary keys from the CMK. 
Even if we use encryption algorithms that combine = the encryption and integrity key such as the CBC+HMAC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to = take a smaller master key and create the combined encryption + integrity = key from it.
jose@ietf.org
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_38C3AE83-3761-46A6-8BDF-92F03EB9A579-- --Apple-Mail=_4E158538-B01C-4B1D-B600-80A94B299A87 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMjA0ODMxWjAjBgkqhkiG9w0BCQQxFgQU57W9QQih EiQZAtHF5F3/jMYFlKAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAGkoUOUKz2+OSCDBAcv3/vnOWDLDyOQigSaIKwVeM ihXbjnTgy7YSJEScZLKoHt+9O2K3f3vqvZ9JBWNqMC/fYf9shzvhAYOP6VQ3ZFEzD4hJQmBB9hO2 qqKKWaj2QlmG30FREV/VS2r2Ic3qL/voaj/3eAQOsTveUFc3iti2usjRHQAX2n0D/0iXeQMKSC0V oXQrhfYrUaw1QlbFmnK4guyhf0pAsOgjLfIXWFHVpU+VsIAhHSy2fl0FWZjMhtEh5H5cR5USDDLy FdcLFDmoDjkxxZbKCdESnfqIjgk4ydlFlJT7x7fV6f5J/5w1dOdyJ7FPQH5LAMY6N4g3KBTWsgAA AAAAAA== --Apple-Mail=_4E158538-B01C-4B1D-B600-80A94B299A87-- From mpeck@mitre.org Tue Mar 12 14:01:48 2013 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 EFA3721F8CD6 for ; Tue, 12 Mar 2013 14:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.727 X-Spam-Level: X-Spam-Status: No, score=-5.727 tagged_above=-999 required=5 tests=[AWL=-0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 Ebml1gZNsISo for ; Tue, 12 Mar 2013 14:01:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 037C821F8CDB for ; Tue, 12 Mar 2013 14:01:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 956FB6250489; Tue, 12 Mar 2013 17:01:42 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 8286B6250403; Tue, 12 Mar 2013 17:01:42 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 17:01:42 -0400 From: "Peck, Michael A" To: John Bradley , Mike Jones Thread-Topic: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: Ac4fTKr2pTLwejeuRSCB0FriUWdwPwAMP7MAAAC1WYAAAP8cgAAIETzA Date: Tue, 12 Mar 2013 21:01:41 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B77IMCMBX04MITREOR_" MIME-Version: 1.0 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 21:01:48 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B77IMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think that #2 actually reduces complexity for implementers. They can implement the RFC 5116 interface once (or eventually just invoke a= crypto library that implements it for them) - then use that implementation= for all protocols that use the RFC 5116 interface, not just JOSE, and know= that the details of authenticated encryption have been taken care of. Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, March 12, 2013 4:49 PM To: Mike Jones Cc: Richard Barnes; Peck, Michael A; jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK Yes I have the recommendation to change from using a KDF to generate the CE= K and CIK from the CMK to concatenating the CEK and CIK together as in the = McGrew draft. I don't yet have a slide on the new/old issue of concatenating the tag to t= he message body vs sending it in a separate field. If people want me to I can add it as well. Though I thought that was a clo= sed issue. John B. On 2013-03-12, at 4:19 PM, Mike Jones > wrote: As previously extensively discussed, the McGrew draft does two things - one= helpful and one not: 1. It specifies using a key that is actually the concatenation of an AES-C= BC key and an HMAC SHA-2 key, rather than use of a KDF. That's good, as it= 's simple for implementers. 2. It specifies that the initialization vector and integrity value be conc= atenated with other values in particular ways, and conversely, how to extra= ct them when decrypting. That's not good, as it adds complexity for implem= enters - especially when JWEs already utilize a straightforward representat= ion for these values, which doesn't require the binary concatenation and ex= traction conventions specified by McGrew. I know that John Bradley is going to ask the question tomorrow whether we s= hould change to doing the first for our composite CBC+HMAC algorithms. I b= elieve that doing the second would be counterproductive. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, March 12, 2013 1:00 PM To: Peck, Michael A Cc: jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK Actually, for everything but key agreement, we can just use draft-mcgrew-ae= ad-aes-cbc-hmac-sha2, with larger keys. We should not be specifying key ex= pansion here when we can avoid it. --Richard On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A > wrote: draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of C= oncat KDF on the shared secret Z established by ECDH-ES. The draft allows for an empty PartyUInfo and PartyVInfo but that may not be= allowed by NIST SP 800-56A (where the Concat KDF is defined). The current (March 2007) version of NIST SP 800-56A requires "At a minimum,= PartyUInfo shall include IDU, the identifier of party U." and an equivalen= t requirement for PartyVInfo. (Page 46 ofhttp://csrc.nist.gov/publications/= nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf ) The August 2012 draft update to NIST SP 800-56A requires "At a minimum, Par= tyUInfo shall include IDu, an identifier for party U, as a distinct item of= information." and an equivalent requirement for PartyVInfo. (Page 59 of ht= tp://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) My i= nterpretation of this text (others may interpret it differently) is that Pa= rtyUInfo and PartyVInfo can't be empty. Instead of using the Concat KDF, a more appropriate choice may be the KDF d= escribed in NIST SP 800-56C and RFC 5869. Its requirements are not as strict. (SP 800-56C Page 13: "If the informati= on is available, Context should include the identifiers of the parties who = are deriving and/or using the derived keying material") It would look something like this: Step 1 - Randomness Extraction: Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice f= or all of the current algorithms) Step 2 - Expansion Step: Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 w= ith the same HMAC algorithm used in step 1 to produce needed keys from the = Key Derivation Key produced in step 1. The needed keys would depend on the values of alg and enc. If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key= is needed (used to decrypt the CMK, which may then need to be split into C= EK/CIK). If alg is ECDH-ES, then the needed keys depend on "enc": If enc is AES-GCM, a 128 bit key or 256 bit key is needed. If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-h= mac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it's then spli= t into two by the AEAD algorithm. If enc is one of the current CBC+HMAC options in draft-ietf-jose-json-web-a= lgorithms-08, then two keys are needed, a CEK and a CIK. Counter Mode KDF = could be invoked twice, with different labels each time, or Counter Mode KD= F could be invoked once to generate a big key which would then be split int= o the CEK and CIK. Richard has already pointed out the issues with using the Concat KDF to der= ive the CEK/CIK from the CMK. Instead, one option would be to use the Expa= nsion Step above: use the Counter Mode KDF with an HMAC to derive necessar= y keys from the CMK. Even if we use encryption algorithms that combine the encryption and integr= ity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-s= ha2-01, there will still be a need to take a smaller master key and create = the combined encryption + integrity key from it. Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B77IMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think that #2 actually = reduces complexity for implementers.

They can implement the RF= C 5116 interface once (or eventually just invoke a crypto library that impl= ements it for them) – then use that implementation for all protocols that use the RFC 5116 interface, not just JOSE, and know that th= e details of authenticated encryption have been taken care of.

 <= /p>

Mike

 <= /p>

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; jose@ietf.org
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK

 

Yes I have the recommendation to change from using a= KDF to generate the CEK and CIK from the CMK to concatenating the CEK and = CIK together as in the McGrew draft.

 

I don't yet have a slide on the new/old issue of con= catenating the tag to the message body vs sending it in a separate field. &= nbsp; 

 

If people want me to I can add it as well.  Tho= ugh I thought that was a closed issue.  

 

John B.

 

On 2013-03-12, at 4:19 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:



As previously extensively= discussed, the McGrew draft does two things – one helpful and one no= t:

 <= /p>

1.  It specifies usi= ng a key that is actually the concatenation of an AES-CBC key and an HMAC S= HA-2 key, rather than use of a KDF.  That’s good, as it’s = simple for implementers.

 <= /p>

2.  It specifies tha= t the initialization vector and integrity value be concatenated with other = values in particular ways, and conversely, how to extract them when decrypting.  That’s not good, as it adds complexity for im= plementers – especially when JWEs already utilize a straightforward r= epresentation for these values, which doesn’t require the binary conc= atenation and extraction conventions specified by McGrew.=

 <= /p>

I know that John Bradley = is going to ask the question tomorrow whether we should change to doing the= first for our composite CBC+HMAC algorithms.  I believe that doing the second would be counterproductive.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, Mar= ch 12, 2013 1:00 PM
To: Peck, Michael = A
Cc: jose@ietf.org
Subject: Re: [jose= ] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

Actually, for everything but key agreement, we can j= ust use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  W= e should not be specifying key expansion here when we can avoid it.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <= ;mpeck@mitre.org> wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1= describes the use of Concat KDF on the shared secret Z established by ECDH= -ES.

 

The draft allows for an empty PartyUInfo and PartyVI= nfo but that may not be allowed by NIST SP 800-56A (where the Concat KDF is= defined).

The current (March 2007) version of NIST SP 800-56A = requires “At a minimum, PartyUInfo shall include IDU, the identifier of party = U.” and an equivalent requirement for PartyVInfo. (Page 46 of<= a href=3D"http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revi= sion1_Mar08-2007.pdf" target=3D"_blank">http:/= /csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007= .pdf )<= o:p>

The August 2012 draft update to NIST SP 800-56A requ= ires “At a minimum, PartyUInfo shall include IDu, an identifier for p= arty U, as a distinct item of information.” and an equivalent require= ment for PartyVInfo. (Page 59 of = ;http://csrc.n= ist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )  My interpretation of this text (others may interpret it differently) is th= at PartyUInfo and PartyVInfo can’t be empty.

 

Instead of using the Concat KDF, a more appropriate = choice may be the KDF described in NIST SP 800-56C and RFC 5869.=

Its requirements are not as strict.  (SP 800-56C Page 13: “If the information is available, Context should include the identifiers of the parties who are deriving and/or using the derived k= eying material”)

 

It would look something like this:

 

Step 1 - Randomness Extraction:

Key Derivation Key :=3D HMAC(salt, Z)  &nb= sp;      (HMAC-SHA256 should suffice for all of th= e current algorithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or se= ction 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produc= e needed keys from the Key Derivation Key produced in step 1.

The needed keys would depend on the values of alg an= d enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, = a single 128 bit or 256 bit key is needed (used to decrypt the CMK, which m= ay then need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on &#= 8220;enc”:

If enc is AES-GCM, a 128 bit key or 256 bit key is n= eeded.

If enc is one of the AEAD AES-CBC algorithms in draf= t-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN = is needed as it’s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in= draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK an= d a CIK.  Counter Mode KDF could be invoked twice, with different labe= ls each time, or Counter Mode KDF could be invoked once to generate a big key which would then be split into the CEK = and CIK.

 

Richard has already pointed out the issues with usin= g the Concat KDF to derive the CEK/CIK from the CMK.  Instead, one opt= ion would be to use the Expansion Step above:  use the Counter Mode KD= F with an HMAC to derive necessary keys from the CMK. 

Even if we use encryption algorithms that combine th= e encryption and integrity key such as the CBC+HMAC algorithms in draft= -mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take a sma= ller master key and create the combined encryption + integrity key from it.

 

 

Mike

 


_______________________________________________
jose mailing list
jose@ietf.org=
https://www.ietf.org/mailman/listinfo/jose

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B77IMCMBX04MITREOR_-- From Michael.Jones@microsoft.com Tue Mar 12 14:07:50 2013 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 2564311E80E9 for ; Tue, 12 Mar 2013 14:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.952 X-Spam-Level: X-Spam-Status: No, score=-1.952 tagged_above=-999 required=5 tests=[AWL=-0.554, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6] 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 vwcrUM+xU07c for ; Tue, 12 Mar 2013 14:07:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 2046C11E814C for ; Tue, 12 Mar 2013 14:07:44 -0700 (PDT) Received: from BY2FFO11FD019.protection.gbl (10.1.15.202) by BY2FFO11HUB020.protection.gbl (10.1.14.140) with Microsoft SMTP Server (TLS) id 15.0.620.12; Tue, 12 Mar 2013 21:07:41 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD019.mail.protection.outlook.com (10.1.14.107) with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Tue, 12 Mar 2013 21:07:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 12 Mar 2013 21:06:25 +0000 From: Mike Jones To: "Peck, Michael A" , John Bradley Thread-Topic: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: AQHOH1w+q0obM/4B3E2z5wOsWscejpiifSFAgAAKD4CAAAOugIAAAM6g Date: Tue, 12 Mar 2013 21:06:24 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] Content-Type: multipart/mixed; boundary="_004_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(377454001)(377424002)(24454001)(189002)(51444002)(124975001)(243025002)(5343655001)(47446002)(512954001)(5343635001)(65816001)(54356001)(77982001)(47976001)(16236675001)(76482001)(4396001)(79102001)(47736001)(56776001)(55846006)(66066001)(44976002)(80022001)(31966008)(562884003)(15202345001)(63696002)(20776003)(49866001)(33656001)(56816002)(59766001)(53806001)(54316002)(51856001)(69226001)(46102001)(74502001)(74662001)(16406001)(50986001)(550254004)(17910905001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB020; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078310077C Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 12 Mar 2013 21:07:50 -0000 --_004_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_ Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_" --_000_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Possibly using the McGrew draft had been discussed before, but there was st= rong push-back on it. It would change more than the CBC/HMAC representatio= n - it would change all the JWE representations, as it would remove the Ini= tialization Vector and Integrity Value fields, and instead require all impl= ementations to implement and apply the AEAD binary encoding and decoding co= nventions. Note that this would change AES-GCM too - not just AES-CBC/HMAC= . If commonly available crypto libraries implemented algorithms using the AEA= D encoding conventions I would have no problem with this. But in fact, the= y don't. I don't know of a single library in the attached set of surveyed = implementations that do. Thus, adopting the AEAD encoding/decoding convent= ions would create extra work for all implementations in practice - not make= things simpler. It would only be simpler if the existing crypto libraries= implemented this standard interface. We should therefore steer clear of this. Best wishes, -- Mike P.S. Jim Schaad also points out that CMS doesn't use the RFC 5116 interfac= e either. From: Peck, Michael A [mailto:mpeck@mitre.org] Sent: Tuesday, March 12, 2013 2:02 PM To: John Bradley; Mike Jones Cc: Richard Barnes; jose@ietf.org Subject: RE: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK I think that #2 actually reduces complexity for implementers. They can implement the RFC 5116 interface once (or eventually just invoke a= crypto library that implements it for them) - then use that implementation= for all protocols that use the RFC 5116 interface, not just JOSE, and know= that the details of authenticated encryption have been taken care of. Mike From: John Bradley [mailto:ve7jtb@ve7jtb.com] Sent: Tuesday, March 12, 2013 4:49 PM To: Mike Jones Cc: Richard Barnes; Peck, Michael A; jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK Yes I have the recommendation to change from using a KDF to generate the CE= K and CIK from the CMK to concatenating the CEK and CIK together as in the = McGrew draft. I don't yet have a slide on the new/old issue of concatenating the tag to t= he message body vs sending it in a separate field. If people want me to I can add it as well. Though I thought that was a clo= sed issue. John B. On 2013-03-12, at 4:19 PM, Mike Jones > wrote: As previously extensively discussed, the McGrew draft does two things - one= helpful and one not: 1. It specifies using a key that is actually the concatenation of an AES-C= BC key and an HMAC SHA-2 key, rather than use of a KDF. That's good, as it= 's simple for implementers. 2. It specifies that the initialization vector and integrity value be conc= atenated with other values in particular ways, and conversely, how to extra= ct them when decrypting. That's not good, as it adds complexity for implem= enters - especially when JWEs already utilize a straightforward representat= ion for these values, which doesn't require the binary concatenation and ex= traction conventions specified by McGrew. I know that John Bradley is going to ask the question tomorrow whether we s= hould change to doing the first for our composite CBC+HMAC algorithms. I b= elieve that doing the second would be counterproductive. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, March 12, 2013 1:00 PM To: Peck, Michael A Cc: jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK= from CMK Actually, for everything but key agreement, we can just use draft-mcgrew-ae= ad-aes-cbc-hmac-sha2, with larger keys. We should not be specifying key ex= pansion here when we can avoid it. --Richard On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A > wrote: draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of C= oncat KDF on the shared secret Z established by ECDH-ES. The draft allows for an empty PartyUInfo and PartyVInfo but that may not be= allowed by NIST SP 800-56A (where the Concat KDF is defined). The current (March 2007) version of NIST SP 800-56A requires "At a minimum,= PartyUInfo shall include IDU, the identifier of party U." and an equivalen= t requirement for PartyVInfo. (Page 46 ofhttp://csrc.nist.gov/publications/= nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf ) The August 2012 draft update to NIST SP 800-56A requires "At a minimum, Par= tyUInfo shall include IDu, an identifier for party U, as a distinct item of= information." and an equivalent requirement for PartyVInfo. (Page 59 of ht= tp://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) My i= nterpretation of this text (others may interpret it differently) is that Pa= rtyUInfo and PartyVInfo can't be empty. Instead of using the Concat KDF, a more appropriate choice may be the KDF d= escribed in NIST SP 800-56C and RFC 5869. Its requirements are not as strict. (SP 800-56C Page 13: "If the informati= on is available, Context should include the identifiers of the parties who = are deriving and/or using the derived keying material") It would look something like this: Step 1 - Randomness Extraction: Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice f= or all of the current algorithms) Step 2 - Expansion Step: Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 w= ith the same HMAC algorithm used in step 1 to produce needed keys from the = Key Derivation Key produced in step 1. The needed keys would depend on the values of alg and enc. If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit key= is needed (used to decrypt the CMK, which may then need to be split into C= EK/CIK). If alg is ECDH-ES, then the needed keys depend on "enc": If enc is AES-GCM, a 128 bit key or 256 bit key is needed. If enc is one of the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-h= mac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it's then spli= t into two by the AEAD algorithm. If enc is one of the current CBC+HMAC options in draft-ietf-jose-json-web-a= lgorithms-08, then two keys are needed, a CEK and a CIK. Counter Mode KDF = could be invoked twice, with different labels each time, or Counter Mode KD= F could be invoked once to generate a big key which would then be split int= o the CEK and CIK. Richard has already pointed out the issues with using the Concat KDF to der= ive the CEK/CIK from the CMK. Instead, one option would be to use the Expa= nsion Step above: use the Counter Mode KDF with an HMAC to derive necessar= y keys from the CMK. Even if we use encryption algorithms that combine the encryption and integr= ity key such as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-s= ha2-01, there will still be a need to take a smaller master key and create = the combined encryption + integrity key from it. Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Possibly using the McGrew= draft had been discussed before, but there was strong push-back on it.&nbs= p; It would change more than the CBC/HMAC representation – it would change all the JWE representations, as it would remove the Initializ= ation Vector and Integrity Value fields, and instead require all implementa= tions to implement and apply the AEAD binary encoding and decoding conventi= ons.  Note that this would change AES-GCM too – not just AES-CBC/HMAC.

 <= /p>

If commonly available cry= pto libraries implemented algorithms using the AEAD encoding conventions I = would have no problem with this.  But in fact, they don’t.  I don’t know of a single library in the attached set of surveyed imp= lementations that do.  Thus, adopting the AEAD encoding/decoding conve= ntions would create extra work for all implementations in practice – = not make things simpler.  It would only be simpler if the existing crypto libraries implemented this standard interface.=

 <= /p>

We should therefore steer= clear of this.

 <= /p>

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

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

 <= /p>

P.S.  Jim Schaad als= o points out that CMS doesn’t use the RFC 5116 interface either.=

 <= /p>

From: Peck, Mi= chael A [mailto:mpeck@mitre.org]
Sent: Tuesday, March 12, 2013 2:02 PM
To: John Bradley; Mike Jones
Cc: Richard Barnes; jose@ietf.org
Subject: RE: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK

 

I think that #2 actually = reduces complexity for implementers.

They can implement the RF= C 5116 interface once (or eventually just invoke a crypto library that impl= ements it for them) – then use that implementation for all protocols that use the RFC 5116 interface, not just JOSE, and know that th= e details of authenticated encryption have been taken care of.

 <= /p>

Mike

 <= /p>

 <= /p>

From: John Bra= dley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; jose@ietf.org
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK

 

Yes I have the recommendation to change from using a= KDF to generate the CEK and CIK from the CMK to concatenating the CEK and = CIK together as in the McGrew draft.

 

I don't yet have a slide on the new/old issue of con= catenating the tag to the message body vs sending it in a separate field. &= nbsp; 

 

If people want me to I can add it as well.  Tho= ugh I thought that was a closed issue.  

 

John B.

 

On 2013-03-12, at 4:19 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

 

As previously extensively= discussed, the McGrew draft does two things – one helpful and one no= t:

 <= /p>

1.  It specifies usi= ng a key that is actually the concatenation of an AES-CBC key and an HMAC S= HA-2 key, rather than use of a KDF.  That’s good, as it’s = simple for implementers.

 <= /p>

2.  It specifies tha= t the initialization vector and integrity value be concatenated with other = values in particular ways, and conversely, how to extract them when decrypting.  That’s not good, as it adds complexity for im= plementers – especially when JWEs already utilize a straightforward r= epresentation for these values, which doesn’t require the binary conc= atenation and extraction conventions specified by McGrew.=

 <= /p>

I know that John Bradley = is going to ask the question tomorrow whether we should change to doing the= first for our composite CBC+HMAC algorithms.  I believe that doing the second would be counterproductive.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, Mar= ch 12, 2013 1:00 PM
To: Peck, Michael = A
Cc: jose@ietf.org
Subject: Re: [jose= ] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

 

Actually, for everything but key agreement, we can j= ust use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  W= e should not be specifying key expansion here when we can avoid it.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <= ;mpeck@mitre.org> wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1= describes the use of Concat KDF on the shared secret Z established by ECDH= -ES.

 

The draft allows for an empty PartyUInfo and PartyVI= nfo but that may not be allowed by NIST SP 800-56A (where the Concat KDF is= defined).

The current (March 2007) version of NIST SP 800-56A = requires “At a minimum, PartyUInfo shall include IDU, the identifier of party = U.” and an equivalent requirement for PartyVInfo. (Page 46 of<= a href=3D"http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revi= sion1_Mar08-2007.pdf" target=3D"_blank">http:/= /csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007= .pdf )<= o:p>

The August 2012 draft update to NIST SP 800-56A requ= ires “At a minimum, PartyUInfo shall include IDu, an identifier for p= arty U, as a distinct item of information.” and an equivalent require= ment for PartyVInfo. (Page 59 of = ;http://csrc.n= ist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )  My interpretation of this text (others may interpret it differently) is th= at PartyUInfo and PartyVInfo can’t be empty.

 

Instead of using the Concat KDF, a more appropriate = choice may be the KDF described in NIST SP 800-56C and RFC 5869.=

Its requirements are not as strict.  (SP 800-56C Page 13: “If the information is available, Context should include the identifiers of the parties who are deriving and/or using the derived k= eying material”)

 

It would look something like this:

 

Step 1 - Randomness Extraction:

Key Derivation Key :=3D HMAC(salt, Z)  &nb= sp;      (HMAC-SHA256 should suffice for all of th= e current algorithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or se= ction 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produc= e needed keys from the Key Derivation Key produced in step 1.

The needed keys would depend on the values of alg an= d enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, = a single 128 bit or 256 bit key is needed (used to decrypt the CMK, which m= ay then need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on &#= 8220;enc”:

If enc is AES-GCM, a 128 bit key or 256 bit key is n= eeded.

If enc is one of the AEAD AES-CBC algorithms in draf= t-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN = is needed as it’s then split into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in= draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK an= d a CIK.  Counter Mode KDF could be invoked twice, with different labe= ls each time, or Counter Mode KDF could be invoked once to generate a big key which would then be split into the CEK = and CIK.

 

Richard has already pointed out the issues with usin= g the Concat KDF to derive the CEK/CIK from the CMK.  Instead, one opt= ion would be to use the Expansion Step above:  use the Counter Mode KD= F with an HMAC to derive necessary keys from the CMK. 

Even if we use encryption algorithms that combine th= e encryption and integrity key such as the CBC+HMAC algorithms in draft= -mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take a sma= ller master key and create the combined encryption + integrity key from it.

 

 

Mike

 


_______________________________________________
jose mailing list
jose@ietf.org=
https://www.ietf.org/mailman/listinfo/jose

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_-- --_004_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_ Content-Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet; name="Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx" Content-Description: Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx Content-Disposition: attachment; filename="Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx"; size=18750; creation-date="Mon, 29 Oct 2012 04:56:21 GMT"; modification-date="Sat, 28 Jul 2012 02:24:02 GMT" Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQDF3RNAiwEAAJQGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADM VclqwzAQvRf6D0bXEittoZQSp4cuxzaQ9AMUa2KL2JLQTNPk7ztWFtqQBZNAe7GwpXnLDHruPc7r KplBQONsJq7TrkjA5k4bW2TiY/TauRcJkrJaVc5CJhaA4rF/edEbLTxgwtUWM1ES+QcpMS+hVpg6 D5Z3Ji7Uivg1FNKrfKoKkDfd7p3MnSWw1KEGQ/R7zzBRnxUlL3P+vFQyNlYkT8tzDVUmlPeVyRWx UDmzeouk4yYTk4N2+WfN0Cn6AEpjCUB1lfpgmDEMgYiNoZA7OQNU2I505SrlyigMS+Pxiq3vYWh2 9rta1b3zOILRkAxUoDdVs3c5r+SXC9Oxc9P0MEjb1sQWpbUydq37AH88jDIu12cW0viLwC113PwT Hbd/pIP4zoGMz9NHEmGODABpUQGe2e0S9BhzqQLoIfFtLs4u4Cf2ER2kxtwBGZfTe/47qiLoIX6O uEFwHjlFA7SfwjqymuqOZyAIZGATWrsu/4aRI7g94VYwQ5PxGvQObhn/Kf1vAAAA//8DAFBLAwQU AAYACAAAACEAtVUwI/UAAABMAgAACwAIAl9yZWxzLy5yZWxzIKIEAiigAAIAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIySz07DMAzG70i8Q+T7 6m5ICKGlu0xIuyFUHsAk7h+1jaMkQPf2hAOCSmPb0fbnzz9b3u7maVQfHGIvTsO6KEGxM2J712p4 rZ9WD6BiImdpFMcajhxhV93ebF94pJSbYtf7qLKLixq6lPwjYjQdTxQL8exypZEwUcphaNGTGahl 3JTlPYa/HlAtPNXBaggHeweqPvo8+bK3NE1veC/mfWKXToxAnhM7y3blQ2YLqc/bqJpCy0mDFfOc 0xHJ+yJjA54m2lxP9P+2OHEiS4nQSODzPN+Kc0Dr64Eun2ip+L3OPOKnhOFNZPhhwcUPVF8AAAD/ /wMAUEsDBBQABgAIAAAAIQDeCf0oAgEAANQDAAAaAAgBeGwvX3JlbHMvd29ya2Jvb2sueG1sLnJl bHMgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC8k89qwzAMxu+DvYPRfXGSbmWU Or2MQa9b9wAmUeLQxDaW9idvP5NDukDJLqEXgyT8fT/Qp/3hp+/EFwZqnVWQJSkItKWrWtso+Di9 PjyDINa20p2zqGBAgkNxf7d/w05z/ESm9SSiiiUFhtnvpKTSYK8pcR5tnNQu9JpjGRrpdXnWDco8 Tbcy/NWAYqYpjpWCcKw2IE6Dj87/a7u6bkt8ceVnj5avWMhvF85kEDmK6tAgK5haJMfJJonEIK/D 5DeGyZdgshvDZEsw2zVhyOiA1TuHmEK6rGrWXoJ5WhWGhy6GfgoMjfWS/eOa9hxPCS/uYynHd9qH nN1i8QsAAP//AwBQSwMEFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAB4bC93b3JrYm9vay54bWyM Uk1PwzAMvSPxH6LcWdruQ9u0dhICxC4IibGdQ+Ou0dKkSlK6/XvcTC1DcOBkO3559nvJan2qFPkE 66TRKY1HESWgcyOkPqT0fft0N6fEea4FV0ZDSs/g6Dq7vVm1xh4/jDkSJNAupaX39ZIxl5dQcTcy NWjsFMZW3GNpD8zVFrhwJYCvFEuiaMYqLjW9MCztfzhMUcgcHkzeVKD9hcSC4h7Xd6WsHc1WhVSw uygivK5feIV7nxQlijv/KKQHkdIplqaFHwe2qe8bqbC7GEdjyrJB5KslAgreKL9FeT07+pVMkmTW ITsrdhJa932pK8lpL7UwbUonc7T23FdxglUbWnspfIlU8XSR9GfPIA+lT+ksxlvIzq7og4E4JkSi g7q3ztQYX6qLGxSAuV1KTOxGxB3DLzTOGtCYD+jkT/T4Co35gA4usUCEK+Vc5WhVF8ISk+ksCdNZ /1uyLwAAAP//AwBQSwMEFAAGAAgAAAAhAPtipW2UBgAApxsAABMAAAB4bC90aGVtZS90aGVtZTEu eG1s7FlPb9s2FL8P2HcgdG9tJ7YbB3WK2LGbrU0bxG6HHmmZllhTokDSSX0b2uOAAcO6YZcBu+0w bCvQArt0nyZbh60D+hX2SEqyGMtL0gYb1tWHRCJ/fP/f4yN19dqDiKFDIiTlcdurXa56iMQ+H9M4 aHt3hv1LGx6SCsdjzHhM2t6cSO/a1vvvXcWbKiQRQbA+lpu47YVKJZuVivRhGMvLPCExzE24iLCC VxFUxgIfAd2IVdaq1WYlwjT2UIwjIHt7MqE+QUNN0tvKiPcYvMZK6gGfiYEmTZwVBjue1jRCzmWX CXSIWdsDPmN+NCQPlIcYlgom2l7V/LzK1tUK3kwXMbVibWFd3/zSdemC8XTN8BTBKGda69dbV3Zy +gbA1DKu1+t1e7WcngFg3wdNrSxFmvX+Rq2T0SyA7OMy7W61Ua27+AL99SWZW51Op9FKZbFEDcg+ 1pfwG9VmfXvNwRuQxTeW8PXOdrfbdPAGZPHNJXz/SqtZd/EGFDIaT5fQ2qH9fko9h0w42y2FbwB8 o5rCFyiIhjy6NIsJj9WqWIvwfS76ANBAhhWNkZonZIJ9iOIujkaCYs0AbxJcmLFDvlwa0ryQ9AVN VNv7MMGQEQt6r55//+r5U/Tq+ZPjh8+OH/50/OjR8cMfLS1n4S6Og+LCl99+9ufXH6M/nn7z8vEX 5XhZxP/6wye//Px5ORAyaCHRiy+f/PbsyYuvPv39u8cl8G2BR0X4kEZEolvkCB3wCHQzhnElJyNx vhXDEFNnBQ6Bdgnpngod4K05ZmW4DnGNd1dA8SgDXp/dd2QdhGKmaAnnG2HkAPc4Zx0uSg1wQ/Mq WHg4i4Ny5mJWxB1gfFjGu4tjx7W9WQJVMwtKx/bdkDhi7jMcKxyQmCik5/iUkBLt7lHq2HWP+oJL PlHoHkUdTEtNMqQjJ5AWi3ZpBH6Zl+kMrnZss3cXdTgr03qHHLpISAjMSoQfEuaY8TqeKRyVkRzi iBUNfhOrsEzIwVz4RVxPKvB0QBhHvTGRsmzNbQH6Fpx+A0O9KnX7HptHLlIoOi2jeRNzXkTu8Gk3 xFFShh3QOCxiP5BTCFGM9rkqg+9xN0P0O/gBxyvdfZcSx92nF4I7NHBEWgSInpmJEl9eJ9yJ38Gc TTAxVQZKulOpIxr/XdlmFOq25fCubLe9bdjEypJn90SxXoX7D5boHTyL9wlkxfIW9a5Cv6vQ3ltf oVfl8sXX5UUphiqtGxLba5vOO1rZeE8oYwM1Z+SmNL23hA1o3IdBvc4cOkl+EEtCeNSZDAwcXCCw WYMEVx9RFQ5CnEDfXvM0kUCmpAOJEi7hvGiGS2lrPPT+yp42G/ocYiuHxGqPj+3wuh7Ojhs5GSNV YM60GaN1TeCszNavpERBt9dhVtNCnZlbzYhmiqLDLVdZm9icy8HkuWowmFsTOhsE/RBYuQnHfs0a zjuYkbG2u/VR5hbjhYt0kQzxmKQ+0nov+6hmnJTFypIiWg8bDPrseIrVCtxamuwbcDuLk4rs6ivY Zd57Ey9lEbzwElA7mY4sLiYni9FR22s11hoe8nHS9iZwVIbHKAGvS91MYhbAfZOvhA37U5PZZPnC m61MMTcJanD7Ye2+pLBTBxIh1Q6WoQ0NM5WGAIs1Jyv/WgPMelEKlFSjs0mxvgHB8K9JAXZ0XUsm E+KrorMLI9p29jUtpXymiBiE4yM0YjNxgMH9OlRBnzGVcONhKoJ+ges5bW0z5RbnNOmKl2IGZ8cx S0KclludolkmW7gpSLkM5q0gHuhWKrtR7vyqmJS/IFWKYfw/U0XvJ3AFsT7WHvDhdlhgpDOl7XGh Qg5VKAmp3xfQOJjaAdECV7wwDUEFd9TmvyCH+r/NOUvDpDWcJNUBDZCgsB+pUBCyD2XJRN8pxGrp 3mVJspSQiaiCuDKxYo/IIWFDXQObem/3UAihbqpJWgYM7mT8ue9pBo0C3eQU882pZPnea3Pgn+58 bDKDUm4dNg1NZv9cxLw9WOyqdr1Znu29RUX0xKLNqmdZAcwKW0ErTfvXFOGcW62tWEsarzUy4cCL yxrDYN4QJXCRhPQf2P+o8Jn94KE31CE/gNqK4PuFJgZhA1F9yTYeSBdIOziCxskO2mDSpKxp09ZJ Wy3brC+40835njC2luws/j6nsfPmzGXn5OJFGju1sGNrO7bS1ODZkykKQ5PsIGMcY76UFT9m8dF9 cPQOfDaYMSVNMMGnKoGhhx6YPIDktxzN0q2/AAAA//8DAFBLAwQUAAYACAAAACEAQb/4YNkAAADK AQAAIwAAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzrJHBTsMwDEDvSPxD5DtJ uwNCaOkuCGlXGB/gpW4b0TpRbBD7e4J2odMkLpws2/Lzk73dfS2z+aQiMbGH1jZgiEPqI48e3g7P dw9gRJF7nBOThxMJ7Lrbm+0Lzah1SKaYxVQKi4dJNT86J2GiBcWmTFw7QyoLak3L6DKGdxzJbZrm 3pXfDOhWTLPvPZR9vwFzOOW6+W92GoYY6CmFj4VYr6xwiseZKhDLSOrB2nNFzqG1VRbcdY/2Pz1y iaxUXkm1HlpWRhc9d5G39hj5R9KtPtB9AwAA//8DAFBLAwQUAAYACAAAACEA++hdR2ABAAB1AgAA GAAAAHhsL3dvcmtzaGVldHMvc2hlZXQyLnhtbIySwWrDMAyG74O9g/G9cbp16xqSlEEp62Ewxra7 4yiJaWwF213bt5+SkDLopTcJSZ9//XK6PpmW/YLzGm3G51HMGViFpbZ1xr+/trMXznyQtpQtWsj4 GTxf5/d36RHd3jcAgRHB+ow3IXSJEF41YKSPsANLlQqdkYFSVwvfOZDlMGRa8RDHz8JIbflISNwt DKwqrWCD6mDAhhHioJWB9PtGd36iGXULzki3P3QzhaYjRKFbHc4DlDOjkl1t0cmipb1P84VUE3tI rvBGK4ceqxARToxCr3deiZUgUp6WmjbobWcOqoy/zrnI08GcHw1H/y9mvdcF4r4v7MqMx32ruOrd Dl5/OFZCJQ9t+MTjG+i6CXTYRbQg9f0SSXnegFfkHoGix8urGxkkYTtZw7t0tbaetVANTUvO3MiJ I4oDdv3o8omzAkNAM2UNnRfojD2WVYhhSnq5lw+T/wEAAP//AwBQSwMEFAAGAAgAAAAhAPvoXUdg AQAAdQIAABgAAAB4bC93b3Jrc2hlZXRzL3NoZWV0My54bWyMksFqwzAMhu+DvYPxvXG6desakpRB KethMMa2u+MoiWlsBdtd27efkpAy6KU3CUmff/1yuj6Zlv2C8xptxudRzBlYhaW2dca/v7azF858 kLaULVrI+Bk8X+f3d+kR3d43AIERwfqMNyF0iRBeNWCkj7ADS5UKnZGBUlcL3zmQ5TBkWvEQx8/C SG35SEjcLQysKq1gg+pgwIYR4qCVgfT7Rnd+ohl1C85Itz90M4WmI0ShWx3OA5Qzo5JdbdHJoqW9 T/OFVBN7SK7wRiuHHqsQEU6MQq93XomVIFKelpo26G1nDqqMv865yNPBnB8NR/8vZr3XBeK+L+zK jMd9q7jq3Q5efzhWQiUPbfjE4xvougl02EW0IPX9Ekl53oBX5B6BosfLqxsZJGE7WcO7dLW2nrVQ DU1LztzIiSOKA3b96PKJswJDQDNlDZ0X6Iw9llWIYUp6uZcPk/8BAAD//wMAUEsDBBQABgAIAAAA IQBwba3KEQ4AAP9VAAAYAAAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1srJxbc+o4Esfft2q/A8X7 AOZO6uRMDRgOd8xld585xEmogTgLnNt8+m1Zsix1O2pNLS/gyD+1Wq3+S7JN/On3n+dT6Xt8uR6T t8dyUKmVS/HbIXk6vr08lv+1G/3WLZeut/3b0/6UvMWP5V/xtfz753/+49OP5PLn9TWObyWw8HZ9 LL/ebu8P1er18Bqf99dK8h6/wZnn5HLe3+DPy0v1+n6J909ppfOpWq/V2tXz/vhWlhYeLj42kufn 4yEOk8O3c/x2k0Yu8Wl/A/+vr8f3a2btfPAxd95f/vz2/tshOb+Dia/H0/H2KzVaLp0PD5OXt+Sy /3qCfv8MmvtDZjv9g5g/Hw+X5Jo83ypgriodpX3uVXtVsPT509MReiDCXrrEz4/lP4KHXaNbrn7+ lAbo38f4x9U4Lt32X7fxKT7c4icYp3LpryQ5bw974VsPBk3/uRQBP8lCMUZfk+RPYWwC1WrQ7DU1 IprdH27H7/EgPgH9R70B4/xf6QkcgxtV7Yd5nPk0Ssc1upSe4uf9t9Ntk/wYx8eX1xs416w0IVIi YA9Pv8L4eoCRgsYrqdlDcgIb8Fk6H0XGQaD3P9PvH8en2+tjuVvpdDqNZqPTKpcO36635PwfeSIQ XumKdVURvnXFVqvZ7jL1oJ9pg/Ct6gVBpR5w1aBHaTX4VtWa9UqzGTRr7brbUTib1oRv7ahXD9uq Inyrir1KUOulgbnefomRD+CcI0YdZQG+lYW2tuCoBpJPPYbvrJqzmQDyL60gDnQf+ZgGevDhQNfL uuhwMMgGXxyoih3ds6/x9TY6ikR0e51lQpCnAvTY1WyWBEGeBR2/JAiyLBAHyuNepd3m00cMsQxu ngfdSrfb7rA5G2TjLw5Uo20/dQVZDogDPTQ++gp6mb9wkNUUa4hPwtazTBIHqjL47hiTepZD4iCr 4RVYMeOlgRUHqiZMXbqP7jSqynksnSPD/W3/+dMl+VGCJQzcuL7vxYIYPIheiBmx0ahooepZ8oMp EqY4YeYPYQcmw3IJ6l9h3v7+udH9VP0Oc/FBIX2JQJg10mzZyIAircBGQorUbGJIiSYyMqJID1n5 UoCgDo0pgtqZUKLRtr2dFiAoKrMCpGNbmUtETGg6uA0bWRQgTdSjZUFLyMyKIl3UpYgiHRTdNUUa TdvfDUWaqKEtReq2kR0luj2NVEEDWggwNVtCEIrIpCx3D2lBumNoCX0U7hgyOQhrj2X41MOButen BBr2gSRg7tY2UP/DAgJl4FAi4K42glJnRIkeMvKFIihxxiwxYYkpS8xYYk4J1N0FSyxZYsUSEUus WWLDEluW2LkIK/1hUblj+gtrsI4YWYfTnxI4/SUB+w+dubly0zUnpEQb6X8oEVf6U4KkP0VQUo0p gQQyYYkpS8xYYk4J5OmCJZYssWKJiCXWLLFhiS1L7FyElf4wy94x/YU19+xPCZz+koBPnf4BWkRD irTRaj2UiCv/KUHynyIou8csMWGJKUvMWGJOCZz/LLFkiRVLRCyxZokNS2xZYucirPyHafaO+S+s 2dN/gLYU/QIEzd0DicBnrgCU3iFF2mihGUrEpQBKEAVQBCuAJSYsMWWJGUvMJQEXoTpodbRrXFAj SCRL3siKNRKxxJolNiyxZYmdi7A0ADlyRw0Ia/YaQDRQgGANSARkrIczQAkeUqSN1pKhROBTW0Ej PqIE0QBFsAZYYsISU5aYscRcEk4NUCMoIkveyIo1ErHEmiU2LLFliZ2LsDQAQbujBoQ1Zh0oQLAG JAIy1tkboAQPKdJGs95QIhAIbQWN+IgSRAMUwRpgiQlLTFlixhJzScCn7i5ZB6gRFJElb2TFGolY Ys0SG5bYssTORVgagJuYd9SAsMasAwUI1oBErHUAJXhIkRZKzqFEXBqgRA+58kUi4ka7Tq0eSpyx ZCDiGsHZN5EI3J/QSAdd308lYrqLOjRjiTnvyYJHljyyoq6goES8kTVrZCMJ8dRCxy2ooc31VkJm bIMaGsYdY8hSBLR2R0UIa8yqUIAg/wcSsVYFlB0hRVooxYYSMVMMjdqIEkQREnErQjJORUgEblno kSWKoM6gPs9YYs57suCRJY+sqCsothFvZM0a2UiCUYSEzNhSRTCGLEWIJy13lERqjlklihgsCsVY 6wRK+bCAaaM7S0PFuHRRgBBhKMatDAU5paEYc0broklvWuAQFgePzD28WXgwSw9mVeAOVoiHmTVv ZqMQRiSKMqNMVcKZsmUinr+Zj5dh4v8/nqqJX2CgpaOOUrdfwAREJtKOuXjUUTqFyo7JtNDtp6Fi nDKRTZkIuaooMIMyd8wjEx6Z8siMR+YFCErbBY8sFeKS/Yo3E/HIWiHy51zixwobvtKWR3ZOxJYB SOqeMhDm7NWCyoAyVAaSMVeLOpJKKH6yBG2ZTAsxQ8WYOY4SYlSAUBlQl/EkPy6wg6Qy4ZEpj8x4 ZK4QVwYvCsyg0Cw9zKx4MxGPrBVST3+YKIUgQ+4YuS1vd6eQDwJhK0E8kbvjgiAf8Jn7OqoEylAl SMac7Otosg/F7+5ACRaD7sUOFWNGIkDjPVKMGXO6caI+d9FCNy5oi1xkK0Z86YuKJnJo6gPNfKC5 gszuY5cWHszSg1kpxuwZvlyKPOystR3xa10pChp8sg3a6mp5YAm0K4CMYbSFATPsPYUhzHFLBGWo MCQDnzp/6vjmq/h5KRJGC92cGirGlRkjxVjCQAL7UsCg+X/MIxOF5BPhlK8045G5Qly9XHgwSw9m VeAOEnbEI2uF5JHY6JJ8xPEqvPVgdor5IBZ27sOces/cF+bsG0x0UaAMzX3JwGee+yjEofh9NM59 xAwV80Ek0jlnpBh37su2TIbkPotMVEv5bnha0DayO+ORuUJcvVx4MEsPZlXgDgp6xCNrheSR2OiS fMTxmrL1YHaK+SAWdu7DcN4z94U5bt4vYNCAD8TP+MGONe+TG0mSMfXRQWvDUNkRC6EWEd6AjBQE 5jRDLw5kYyaDfB4rM/lcNvFpfeoDzXyguQ+08IGWCvoggdIpY+VjKPKB1grKA7fxqbbNIDMB8Nju MuiDBLC1AP29pxaEOW4dKGBQXg3Ev6OgOb6BNuNhAdMheyBph9GChMw8p1qgDPJ5rPzJ57aJKnG2 PvWBZj7Q3Ada+EBLBUGf9eyALypWPoYiH2itoDxwG59q2wxya8GdALYWxPO5O14o00eCdE9UwKC8 Gohb+WhdaJA7p5IxQ9FC+/ihsmOlOVpfRkUMuij/ohi4jaGTw7jCSifKsWJcCTTxYKYF/qDwzHhk 7tHSwoNZejArxbiiE3nYWWs7+TWyHGNz/NAObKsqOZCdu21bD+Lp3B31QB8IUj0UMGjAB+KJCl4b 0O3RsIBpkX2StGMGq0f0UMAQPVCfqR4k49YDz0xVv0yfUXhmPDJXiMubhQez9GBWijH3Ijg6kYed tbaT64GODdEDi+zcbVt6EP+reUc9pOaY6wbFmNFroBwdKMac+5t4r6QY89qiixJnqBhXVowUY+Zf D60zXxSTb23HpGTi0dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQx3HjU2nowOzdj57t4jnq/+b/u8SS5 gKH5Tp8kN5EmQmXH1ATNd2nHne+Sced71q9sZhrrXmQlE1Xiamvqwcw8mLkHs/Bglh7MyoOJPJi1 YoxLAI9aWw9m52bsfBdP5u6Y7/JBn7kTJPudumTc87tkzFxukfldMu75XTKuHBwpf9z5Lu3kc9NY 1cpLJqrE1dbUg5l5MHMPZuHBLD2YlQcTeTBrxeQR23jU2nowOzdj57t4iGTmu/vf6wUN2xXzfQdN tO/u1xUkX8QjHu0NaFFIi6aqSPy+Q19VdnLrtt8gBctvcEvc85LvADFeHODuj7ACFU3N9ND9o754 cY+Esql8QItCWjTNivJAzPIio4to8zQHKGtpYRwv88rZ6ZVxOjKO18bxRh7b0YNIWdFzR0nQMOqg eT0uXXQF1K8rKJ++B7QopEULVWSPem7d9hsmE8tvMS5Q9jdHXViB/pgzU1BD02lfnBZU+rKt9I7G gBaFWVHPGDJZETqUDdNSUVYfu+hCZZVDWb0IirLjtXG8ydC2Pr01Tu/ksR05cePAX+fyNoMQpB7x Zj4maTT6EJk0QHm2DmhRSItWqsiKRgfdzdpkkNnFdCjsbomLO/9uyUtBq1tdpL5+XUFmt0hRSKlI FVnd6qEbDpsMMruV5o7VrQa+ynTqM6UhU0GB+WjhbuVQllEDWhRaRbZLYofrHemG3A+LXyhpl7r5 VC4TKIdyl3S9rCik1CYrMoIIRVDD9ljsUUyPxWQBZX9rshg1hJV0bck82lpFdpOwidNNgnjcwyZg NGxtNCn0GxrKmh/QotAqsj0Si3EWBNYjAcsg6VFro1sE/YaGco9IUWhRtkfmys16pNZeM4/a6EKv 39BQ7hEpCi3K9shcDVmP5DpnZXaHjJqGco9IUdgwi2yPxBLiPWpqvTFj1CGjpqHcI1IUNswi2yNz /WBjBLBOoG4+BUqL8o2R8m1o5/jykr5b8lo6JN/E+x878BIzXareeVlvPoj9InhOzrThTDoNkDNd OJMuGORMD86kcy4+02g8CCkVtNOowZla0Zl6B6yly3RVm4M3V77vX+LF/vJyfLuWTvEzdKxWgeBe 5Lsv0+Nb8p6WQqp+TW7wAsvsr1d4/WkM22bxKszSc5Lcsj/AMWF3G9++vZeSyxFemJm+0fSx/J5c bpf98QYtPByfHsuXyVM6IcLrQE9xtL/cdHwDiK8uzen0KqSqT0APqvrVrZ//BwAA//8DAFBLAwQU AAYACAAAACEA1ohQeh4IAAD2WwAADQAAAHhsL3N0eWxlcy54bWzsXO1v2jgY/37S/Q9RvncBBm2p gGnQ5jSp601rJ91XAwZ8TWIuMSvsdP/7PbbjxLyEZLyFdt6kLQl++fl5tx/brQ9z37O+4zAiNGjb 1XcV28LBgA5JMG7b357ci2vbihgKhsijAW7bCxzZHzq//9aK2MLDjxOMmQVNBFHbnjA2vXGcaDDB Pore0SkO4JcRDX3E4DUcO9E0xGgY8Uq+59QqlUvHRySwZQs3/qBIIz4Kn2fTiwH1p4iRPvEIW4i2 bMsf3HwaBzREfQ+gzqt1NFBti5e15n0yCGlER+wdNOfQ0YgM8DrKptN0oKVOa0QDFlkDOgsY0ApI JVq9eQ7oS+Dy3+BrXKzTin5Y35EHX6q202kNqEdDiwFpAJn4EiAfyxI95JF+SHixEfKJt5Cfa/yD oGZczicwNv7R4UAknE6rz0tt6Csc99u2G//htYp1uNT2lnYr4s9p2v0YEuRZ3wICgomtz4+81zVK FQd+Wa1UigPP58AWKjV7QKbLQ3ZGMth9DNHaNLBj9JM1pliEgYKn5Nhl41DiIUQyAlklnpfYjWtu IeBDpwX2i+EwcOHFip+fFlOwDwGYWi4zjiyXU3ocokW11iheIaIeGXIU456wSgmZuUrzZvrxDyQY 4jketu3LumhdA1wUXEZft03+9zR99S7v3N7dgQfgur2rIzQKzfYOjvSu28xuVMgYyGifhkMIAzTv pr51Wh4eMRCLkIwn/H9Gp1xIKGPgNDutIUFjGiAPHh3ZynJNiB8gVGjbPh6SmQ9yJ33hmtQ5vJud e4HeBb7CvYnSOw+GTSBuUUNZ1RNtIArO1vIplELFgf6K/IXKS04dh1EKQC5z0zHuIjtbyaeRG9re UTqXeohls1vjf4U+an2oIefUSAdcsEIeW9dB/SxjcxBrY5R0LB24Uuozg1OQLiVLQGyMwbYPsOc9 ciP81ygx8A2wXvORFcx812efwMfDdIZPK9QjBCXxo7Tp8gUYkVWpDvXjSvCoV7LQdOotHmZ+H4eu mA6K3sTXrnA76ftHj4wDH/MJFgASRb6ElOEBExNUEZ5kIWikCOCxDARXKYJLHQG8bKEBnzqmw92H As20f4ByTAo4ukxJCdOE631lJ+my5qNcMeNiulk2k9qS1hodxXw7S2pqaYPvdZrBi4IjG5Rsqsas dAEEn8nL35QYq/elzjstpKSaL7UwMuDrAgMQciyn8/NRtlpp8GDoKUtz4B0PEHSsGHCO9NLgnQe9 suxiwkAlM8djWZZhTCCAkC1ZYwXpcGIMLSqpgc5SMYaXo2oZBFW29RKi6ROeg5EVlsDZpm9ZQIGN rwMoDOC8gILzU6xf0kh42Qx0S5ABdfLa2lJ7i3uWSEAhhB4cTu6ztD8ZvFK1crxLCRTZj4X71c7i RmIIgRv/zCDc/BLiEZmfwr9nhWwJJMB8ZNucRRVwG1ItypXRLHhnokKaRK7G/MtGZVnDD2diStDh rIAikRgVUCyP2T1RzJwFL5GYcuFpEgOPaSyUwNs6y80yGCAGUt6ObzCyIECuuGwIAO3QEMRUFya3 2jrK0ipKMhO2eIa1bXfRUIHgoe6MeIwEfF5bu+JLiavF/6A0KQ+GVi8vEoer5R/wjIXIU10At/Uq 15u6eOCLLkkNLnMpKCFra32AC1QdgCPSikPWG8aQzv6BKsN5uqpUq8PEHz5AckmkqPsylS0qEe05 YiF5jtPaEgGFXFMQ6Z8gYMfBUKtEZ8wjgV4kmqAhfdGKzOSzSqDx2bYwtPJzH0WYt8CHkOQ24+6z 0/NPxMeR9YBfrK/UR4GozPc4xEBUXyr/DDYuL7WXpt5WMgfriTeZ1tuUeEPJmsKEhuQHkJuvKoxx gIV0rC00WAwI+pUy2DTBt3qAFKTTInjhSOJlqL9nESOjxT2K2D1QS5SNJiEJnp+oS+RSFd/IAXtE /uRJI14AKCoNmaXSQd+moqJ6vYU9EvyDzCZtXEFdIYaeDypUPme9dbX5vPX21fJqtV1RFoacUp4r hSQAPAgFEP8YJq1S8QyZZExV9i4EY6oKmR4tdVaovNGC2Gm8EYeNZoyq1UXjrOMNH0vp5pL9QCGt VJ5dd+yFKqZxgAkDWCGKGQO4uwHUNhSvbaLauMlX38L6c9OV1e17K1qs5isxjHRXn2OM4BkawSIz FhMM7xEMmzDgzAPhQr7paGHAa9StLR7moAtjxtP8amtjRhuyT4AYbTDacP75EuMbTN5EHO3ZutKz S97E+AbjG8ShMpNFfKW5dOMbjG84jm/IyambbQ7Lh7b33eZQ7pKJYTacuRaHWgvx4U0zW63LJWen zJamlQsa9mX/m0oQmDSZ2IDHU3ZmY9+26xpWJ6iFLK0yRqfeK2DCGxPe8JOMZsuuvFXmp5aejGaH v87+7HKZ/WpWME2YZIxpIVU5rzApPm0SnwniLFw+WZJ7IdWGnSq5ddZ3LeZW2TAly62jKL3pRMmr sSunPVf1thPm2omiTXIv5UUp8SHECxYCzjT9vO6u5BW3/ARaqZtfxX24Quj32/wKBsPetrAFZ0RP NaW3yrKuwEsp0/CwYgS5KsChU8bveBZ3miVncWFGNMQjNPPYU/Jj206fP4v7J+FIblzqC/lOmWii bafP9/ySy6o4eQvnJe8jWHyF/61ZSNr2v3fdq+btnVu7uK50ry/q73Hjotno3l406r3u7a3brNQq vf/g4Cy/EPsGLofe48JpcTE2XAtVrd9EHlxLHcaDjcE/pt/atvYi4XNlcAC2/FcMwhH7kcWF3Z3/ AQAA//8DAFBLAwQUAAYACAAAACEAgy/oZb8EAAB4DgAAFAAAAHhsL3NoYXJlZFN0cmluZ3MueG1s vFfdkto2FL7vTN/hjK82nQFjNrvdZsA7xAsh+wMMTnbTq46wBahrS44kQ+jT9Fn6ZD3CkDiSl+aq N8z48/nT4XyfjnvXX/IMNlQqJnjfC9odDyhPRMr4qu99/DBqXXmgNOEpyQSnfW9HlXcd/vxTTykN 6MtV31trXbzxfZWsaU5UWxSU45ulkDnR+ChXviokJalaU6rzzO92Opd+Thj3IBEl133v9TmmKTn7 XNKoQoLOuRf2FAt7OryhKpGs0Fhiz9dhzzdw9YpNYxviIqXtP5UNz8YzG7p9iv3bp6ENk2zlM65t eBx3Ly5t8Pehnd805Y0qSILNwlMrKjfUC9EObN9xfH712gUvgq4NYqE2hEXa0LypwHlTknnckGTY 5D6Z/mKnGTZFHDZFbOjtPB4Ef1zYIRFtTQdD5w8aRjfjltPhcJhlZhoSiEpsLtyw5ZLR1phmWU44 DAscQypJBrEmaGUnGwTdq7snG51MbWSAf7drh+RwDDFg9DZyYPRvgtH6XfTQZN0Az3Z67U79vFzs 7ABvkTfJLiJKZ9R+d0s2BG6jgY0PeCoFS234oyIrJ8ZzurTtoqaJaU+GH2xDM/0tiMuiEFLDomSZ BmSYgIwtJJE7v8iINnphO06m6DcRGlTlS1P0+0+vs0VG+PMrdP3In7nYOqoxI5LkMCG5c8opalcc 39t14AEcHqCgxDS5ZwvbOGoiSNREkKqOR5LZIZAQ2LImSuzftGZ3URy0HhuoZPxwjmDrAw4aLJiG Z+oMS80Kp/SU1R3dwZMkxQ8ErJueiIqkjgcm3KxlrJI9h/GCgXg82CNrotZ2Q2pOKJqWk0GM0z9/ n3C76AaWG2rg3s12Gj8MIlNfvR43dN3qWMCpSC9lwz/UTmaHqZkcM7n11IxeSoUTe7zq4aLt3DJf B/qrUad93u7Y1cx2kdwVSN7D1gDdtnMtHm1e9GUKCCRVHBQBQPJDs9bVdQ2a3Iy4OXmO3Gz0aFgF DkoIpaIK6intyIY5qOo/QIeD1QkmGBmHoP1b+xy2TK9B4nPLbE9KOYqwl/Bf7WpQl65tbDK1oRdX kmtnJ7lG0RxwtaWy6tySSdzzWG42GbMionhrkPRzyRCAXEiKT4oSmTiUNZqJ0Q6qj8ptXIVeY2gu eOubouO2aaLsY6ZwFgmeEA13N6NX7tFMxIl9H2BMUAVNGK4BKa6UfMlWpcS7H+s9QyKfiDiN4RME nfYlnMV4U8A9FQWRqZP5oVsNvV3REW+es8bL+1gNCusNlWxT1TnC27squPHgsbMAPjGeiq0Cjv4b 5x77NIN45jD8keEqbx9hD6J1YL/ADM7ATeLYHNV0vMZeZA3+vTsY4VQsxZfvA8mwJ2f4w3xc2v+C DcnwOyPw8CkRGdJerhZ9bzTCb4Kg0zGwHAmuK7uImA2BGXRJcpbtKrhrgP3nBq2AnHEhDejvU+lw TjNK1KEtpoJDEf9XAc2U+0YHXGOSrEyrfUavsaWyqhjEEpRY6i1BaplbETcjKquO4iFqnz5mar/v tA7NONtYhPQqMmr9Kzp8HMzf7/ey9xwzljJBQu8putSUQ4qjIhk+Y4lIoQNbkVx5wTLEROl8IFUB 7fQVWpMkH78cw38BAAD//wMAUEsDBBQABgAIAAAAIQBgQQnkUQEAAGYCAAARAAgBZG9jUHJvcHMv Y29yZS54bWwgogQBKKAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACEklFLwzAUhd8F/0PJ e5s201lC28EmexAHghPFt5jcbWVNGpJot39v2m61Q8HH3HPy5ZxLstlBVsEXGFvWKkdJFKMAFK9F qbY5elkvwxQF1jElWFUryNERLJoV11cZ15TXBp5MrcG4EmzgScpSrnO0c05TjC3fgWQ28g7lxU1t JHP+aLZYM75nW8AkjqdYgmOCOYZbYKgHIjohBR+Q+tNUHUBwDBVIUM7iJErwj9eBkfbPC50ycsrS HbXvdIo7Zgvei4P7YMvB2DRN1Ey6GD5/gt9Wj89d1bBU7a44oCITnHIDzNWmWLAKPoI524PJ8Gje 7rBi1q38ujcliPmxWJV7CB78pm2Gf6se2nXoySACn4r2Hc7K62Rxv16igsQJCeNpSNJ1klIypbfp e/v4xf02ZT+Qpwj/Eu9aYkwouaExGRHPgKLLffkzim8AAAD//wMAUEsDBBQABgAIAAAAIQDcWXjt 3AsAALQbAAAnAAAAeGwvcHJpbnRlclNldHRpbmdzL3ByaW50ZXJTZXR0aW5nczEuYmlu7Fd5NNTr G3+tpWsva0mKso+d6DbJdCUma5Yxdt80GPsuxrWEEJUllFHWLINCssSPe8kIRdMokSVZsmXf4ved ln/6655z//id8zs+73ne53ne932e830/Z545z4sFWGAAjMBFIAO0gD5sGQB5eM0LQMAR+MMiAxSB HFAAqrDlCH4FHSNgfg/6BI13AD0doANT+9z3OsKaA5jDPj08M8CeHpzNBx4QnPffg+5HCkZY08Py 0/81s4GRjumI3K+r/97n/5aC8wRtAECT72gCyQw/7V/1zw0UHyfA6jKAK1q0r/8OGm+/Qn5UkYEJ XtyB92jyM/7Xc7v+/zcDv/4ymuDrGqNNLtBuzQnKgfm3mnIHAeAIMAPucH25wHUMATe42mg1fAQo AxVYlGHLABjDUXqQnSPOzemcoxMEgIGdE2SMC4LgVR8fyOubbwQ54dzdAED5erhCAT/URXcTX7y9 KwSMIG93V18f2gkVObkAWBw9cLSv+WdA8QEgf9HInHYvVtj+p9jA867vhetgnoUTDqEDe45oHjjE SotGG2v9QdO9LLQZAOnvCjDQfa+rk3IA/lejxdCBcaUfmz8UAnHJzcEd7+EFeXtDjjIoOx87BAJ4 WnBuB7KMK2np/m3J5nrIjCur//F+DQK6gqHznafsU93RodaKuenHA/vyqntF8eiRd7z8hoICbaXH NKpH+xLQayyEKN6HD4owTGlEU+fJD1USuMwPx7kNUDrnJDQr78cUchee5+Tae/8IKsz9sl9IMOGG 6ru6TEpvZvDmYP9c54tM1cfWqk9cJ11lZWzOZH9KzezPsFR/dz1kTZ44cV7kiW+lgMiWSuGQD1OR 5HzoyOFWDJ5dVvNS6RbmUwtZ2OqG5IOrfE/8pXZkF/3DEPluEblr7X2lqhrIyKmDZGIdMyXiOiQv kXoyd3VwOJhDasdAoOhruO7sRdwii1soau2sMCXpCx6PENdeFhrLTL2/QVqgcyOY5L/tkknEefP4 nxQTv5opfaA1qGF1L2LM95z5GCrmGeT3oeHa0ox5rLPwWuD1hUq/4sd1v5cZuykaChmEXl8XliTE mi0a35vKulQ4+GalM36DNUC8Yy2hWsjp+Zza2gfJHYnZTe0xwoutRqiK7b2XTmZHzaY9cX6mZA4i Ezmyi+YnHQQrZ3hNPXISC8Qt6KrbVUvDVYjSs/ENNX5CnklOT63WGU4FFS/oe27iyQiH7dtkZGcI sw8pZAUbsWbVxCFQkS5vg63YTz+iz/moopeP+lW2bq4GQZoWqfN8fXn2TR2PriFbf0KwI3n4aLnl 0vYe/tET05uJGPvAF0UcOjOK7JbLXMWhunsIZYyUOR9DoZUH0i5XKghIUiN6059Vj2sgVMqP7N28 8oQ36cuBv4fV8Z9Kup7J41YmUrqt7ebt0wxUl1+Js/UyMk2MFmrjwjCvVFAOQ5svMfqGyUEKqR1J 9D6fw2Lvi9jq1d1gt+vgU0oTvNdaSfGxOHZcXC9T/GyrStWqWL3vtRSiYyhKndSSSzHRTTDSbrqk RbEME4mv5Y2au5ZXddPtzCazLb7gM1NdeJFees4frZSXggqzvdpZkTuKoblbsoNBSHnU1Wp9BWtK cPD6IDGh5mWX1A7vE751iprkVo+pv0zRGNnd9nT2VtAn6sbo5mcdl/dx22v1CAkCTrkoLWUHsRid vHqp+ckGRWqdasFPx5Q1jpw/et+GsLPcP1soGbozjWQXHvBxORF0RuK2/VC9+xrXwSHmrFkR54gL bR4VPQycpsdQxhw3KDZxLmJ/JaMlc7v3kpDSovtEh2vjgq7IsRXVluQczdCyyfYsjKoo9RiaiiwJ QllrlKK5yvVetBaYP47ykJ3Jmcc+oJvwzGOgogP8hJd71DhnsuugHFN7BhOH4L/EzG4ru8ZN6B4t XuW8YqLuIeYsG+40nkrKb7BfdKpIS9Pw8NWMI17zZdPC9J8zdZ1R6bpWYtnnuwRtxFUJt7Bj0SzB iNUlng3pmf/c9+eqJuQwmGmIVh2spvz2NAHDXew9oZIBxYakPDtPiBogSh3fOB8e8jdeQ3ihNvq0 9pyWNR8nz+BQE9SRJ4IojMnK647bscdqcHtcGuexlJcuYfdDRuVIMWJLeUmXzff3m5grPVxr7mNj K/QfIVc3IsKj5PND12Jt6UkxUboVciR1FqRXhMtp6WnliZtQtSSdWcNY1VT+aphMHXYIc8amIHDe KiEuhuQ7VBvl1iogkJ2KC3mj3yFDjzBMg67+NmktGU20dS3uHXk09mava/X7qcduTgcnXRyb9WNk 9y/xV82/FkWpJZzscVAdODF8okM6w9Ra5Vl5C7Vo+lHsXKi6TrQ00jPkOrFPkqtL/GKuUIzwZsmi eLzULeiD4dmCSdazc6ph+OcLxd2Ayns3kRJwmPhBVUTW8eohq3jzm+aM/pmHuOxvt41DEg2a1KZn fiNXsbeZ04Ku+TyfEv3dyBGd1RZdPMF3tMyqvMyXHSvMFC4SKxb0kMCr4DLPbyHQoINPooZOfGlJ DZEnsT0/1ZPzEK2W/siXPrkX8fA3pxWmoSKvIWeeuaTDZq+H25uPys95rnuIjSdW5G7dXLiF5M3/ mFgRCZvJyC6ddmEH3KI22XNbTVWMEJ/XKSzRtj76IHnrpic+Mo+D/pXcxscThHp1MYIj1rV//y0J I+uFNm5s+3jSlPxbLcZhLvHocQMc+WQyC1///rHpQ5gUL/a8tpQABcPU7vufPcQa98S0B4exVIiT e4PD7LHtgZgX1xvFywIxhheyeB8vKJFdslSQYvpxFoGCY8r6lkm3CuRlNZC9akTDj+r6lnduFUiQ NkSxTzt7yR5ibVGTXxm1rye31JSfEpPVSyz2fTfixcXn9lfKXWprSX3qQgbVr+BjlbPNK9FNsq91 MOGCdUdND1T5xd/+bbfL6pD9h+XDK6MZF56z1GTdrnfADm6yjwauZ7NgdUsDHpD/LLYgaYxxJAdq XosUPykcJKJjTWd+x1nR33GeyrL4cTmEWkEkYgie1O41jahigzWGiMss8wLYRMaNhltH2XpywyDV Zp2mviWfrfG5Ragef3zYOqi8cmDiLdP91WyImf/0gzhIaUDxiF3LWHuiJ0Gfny+dUkMfX5ckJ3uq bolrdDtVjuRnOprF4fzKUyuJHBMZf7dnuetIeoSmjAy3oxuxCmPD6oy7jbSsyPLrdn7foSkTe/mt 2LvpTLuq6HCMQkKH6ECLpkx6K9Tz6WZ2qt6ogkX3K5qeUozX4H19C4dVaqkZpR1QduRfvWCgq6FE jQhRVdJtIO511jn9CaFdxlxVGYcm8dQ7hCfPnFCUYce9vT749Y023crUZT1tLYxKjg1H0sURtckW 9blmaQfFeEvunp4/fRN03Ve0RgNm790pUB01TrtW2fd5NCi6/uJkpqdZuohM5lgVvUuJkP7BWybu +TddzmLudgukHCnXT7rhUF2h9KhoH26Ss1E9ViFAIPICRUSmi+ry9Wh/epugpudOP5cVa70S57ug 6RlvYVRHg9isVSN1Cd3bsB6M5rgza1VNXcqeDLUMQnOkzyZyl03a9TZYLmasZM4m2pdNWuYH+39W RqfPWmVSl3Int9fmM0Jta5GC9fnH8jc9Ol3UnWs5vtbnO+RvyvW4qLvVcug05JvprQ6XUn2afYQl g9En0Kt2T6hL+ZOnTZYz2DNmW6zLJll6Q65MKQupDERTshrxLOdrOklDq8L9fhuv2xmMx0NEbZoU rarUu1TN8yrDbbYb6vqk74grba8jD4ce2ygJGLJpFJT8fM/szBeRFWQ3auz2Mksxu+29Yy9rM80u oRAHrjxMUX2tvEDNm+d50ebN00lpntOdeSpYZiu7bf9VubivkMS4v3eHjn4HBgBK41r6aGV6wA33 sQHAAZ5dgew3GwLwsxPggT1wBqywTQMbOAB3eO57p/b9aO5gResyD4BD8ItWCY6Ug0UFtuXht6ws 3BHLwUMR8MJD/tue2o+ZtqsGv3j54Mwep0NpTfMudhnYZWCXgV0GdhnYZWCXgV0GdhnYZWCXgf8J A/8FAAD//wMAUEsDBBQABgAIAAAAIQCiocrBnAEAAFwDAAAQAAgBZG9jUHJvcHMvYXBwLnhtbCCi BAEooAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJyTQWsbMRCF74X8h0X3WGs7lGK0CsVp yKGlBjvJWdXOekW0ktBMFru/vtpdHMttcultNO/x+DQjidtDZ4seIhrvKjaflawAp31t3L5ij7v7 6y+sQFKuVtY7qNgRkN3Kq09iE32ASAawSBEOK9YShRXnqFvoFM6S7JLS+NgpSse4575pjIY7r187 cMQXZfmZw4HA1VBfh7dANiWuevrf0NrrgQ+fdseQgKX4GoI1WlG6pfxhdPToGyq+HTRYwXNRJLot 6Ndo6ChLwfOj2GplYZ2CZaMsguDnhngANQxto0xEKXpa9aDJxwLN7zS2BSt+KYQBp2K9ikY5SliD bTqMtQ1IUT77+IItAKHgyTA1xzL35rW5kcvRkIpL4xAwgSThEnFnyAL+bDYq0jvEy5x4ZJh4J5zt wDfP+d5IR2nxsTSR5rcaB5X4/iJa+y4od8z2tfYx+DhuUfCTLL4b94KPYefvFMFpM5dNsW1VhDot 86SfG+IhLSXaIWTdKreH+uT5Vxje0dP0WeT8ZlYuy/REsp7g528h/wAAAP//AwBQSwMEFAAGAAgA AAAhADYCE9FAAgAAHwYAABQAAAB4bC90YWJsZXMvdGFibGUxLnhtbHRU23LaMBB970z/QaP3YuQ0 5DJABkhpkyHAxKTtq7AFVkeWPJKA+O+zvhZR9VGrc/bsro52+PCeCXRk2nAlR5j0+hgxGauEy/0I v23mX24xMpbKhAol2QgXzOCH8edPQ0u3giFgSzPCqbX5fRCYOGUZNT2VMwk3O6UzauGo94HJNaOJ SRmzmQjCfn8QZJRLjHgCshhJmkH2TZkUTgk3uaDF0glqthvhCbnfhCFGVlkqzKs6Rak6QeVQdwoC TEPo8X33BFnDK0hELW2PkLeDTJUGbHtT5iuV3Wgfj4f0YNWcC8s0OpcPxnX/MyUOmTQoVgdpQbGk VJnqC7e5N0P3zCmJ3GE3U0WAaupprKmmGSqH4LJufSxo9pz1kwqXdOMjfW1Jj8zEmucWXODSBj7a dUvrLb9tXPy1Dw9zaYr7xWWiTgZOlh8v2oJiyueaMSEiWwiww3elEl++QZtuFaHfrv6VD3/T4vkq cuGhD37Xwp/pkaLn2cTlEB+HdKOcghfiYkaNFRcN9n1E+F/1u01kohVPHC2vP0j3XdY/1g7cawzS TQvgEYsXfOuQvMYgf01Y2PTCFF5PkG7IL+FMF7lVjorXF6Rrfl14OP8aYkq9fiCd+V8P28LR9fqB dAZewaaKooVD8XoCvmrzTlIlrPfHOJRyZbnW/V+l3U9YRq4VK3MEZ8vDNKuk+gtPcqca/WpHVsEX lvBDBtoGduCca2PrtVNtwzK2ABNehMqNaeGnM9jaDbNGdNGzQsYfAAAA//8DAFBLAQItABQABgAI AAAAIQDF3RNAiwEAAJQGAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9UeXBlc10ueG1sUEsB Ai0AFAAGAAgAAAAhALVVMCP1AAAATAIAAAsAAAAAAAAAAAAAAAAAxAMAAF9yZWxzLy5yZWxzUEsB Ai0AFAAGAAgAAAAhAN4J/SgCAQAA1AMAABoAAAAAAAAAAAAAAAAA6gYAAHhsL19yZWxzL3dvcmti b29rLnhtbC5yZWxzUEsBAi0AFAAGAAgAAAAhALq0cdpiAQAAcQIAAA8AAAAAAAAAAAAAAAAALAkA AHhsL3dvcmtib29rLnhtbFBLAQItABQABgAIAAAAIQD7YqVtlAYAAKcbAAATAAAAAAAAAAAAAAAA ALsKAAB4bC90aGVtZS90aGVtZTEueG1sUEsBAi0AFAAGAAgAAAAhAEG/+GDZAAAAygEAACMAAAAA AAAAAAAAAAAAgBEAAHhsL3dvcmtzaGVldHMvX3JlbHMvc2hlZXQxLnhtbC5yZWxzUEsBAi0AFAAG AAgAAAAhAPvoXUdgAQAAdQIAABgAAAAAAAAAAAAAAAAAmhIAAHhsL3dvcmtzaGVldHMvc2hlZXQy LnhtbFBLAQItABQABgAIAAAAIQD76F1HYAEAAHUCAAAYAAAAAAAAAAAAAAAAADAUAAB4bC93b3Jr c2hlZXRzL3NoZWV0My54bWxQSwECLQAUAAYACAAAACEAcG2tyhEOAAD/VQAAGAAAAAAAAAAAAAAA AADGFQAAeGwvd29ya3NoZWV0cy9zaGVldDEueG1sUEsBAi0AFAAGAAgAAAAhANaIUHoeCAAA9lsA AA0AAAAAAAAAAAAAAAAADSQAAHhsL3N0eWxlcy54bWxQSwECLQAUAAYACAAAACEAgy/oZb8EAAB4 DgAAFAAAAAAAAAAAAAAAAABWLAAAeGwvc2hhcmVkU3RyaW5ncy54bWxQSwECLQAUAAYACAAAACEA YEEJ5FEBAABmAgAAEQAAAAAAAAAAAAAAAABHMQAAZG9jUHJvcHMvY29yZS54bWxQSwECLQAUAAYA CAAAACEA3Fl47dwLAAC0GwAAJwAAAAAAAAAAAAAAAADPMwAAeGwvcHJpbnRlclNldHRpbmdzL3By aW50ZXJTZXR0aW5nczEuYmluUEsBAi0AFAAGAAgAAAAhAKKhysGcAQAAXAMAABAAAAAAAAAAAAAA AAAA8D8AAGRvY1Byb3BzL2FwcC54bWxQSwECLQAUAAYACAAAACEANgIT0UACAAAfBgAAFAAAAAAA AAAAAAAAAADCQgAAeGwvdGFibGVzL3RhYmxlMS54bWxQSwUGAAAAAA8ADwD0AwAANEUAAAAA --_004_4E1F6AAD24975D4BA5B16804296739436750053ATK5EX14MBXC283r_-- From mpeck@mitre.org Tue Mar 12 14:10:09 2013 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 C7E7F21F84BE for ; Tue, 12 Mar 2013 14:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=0.312, 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 iyHQUO6KJK08 for ; Tue, 12 Mar 2013 14:10:07 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id EACD221F8D39 for ; Tue, 12 Mar 2013 14:10:06 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 897021F0306; Tue, 12 Mar 2013 17:10:06 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 659E51F0A7B; Tue, 12 Mar 2013 17:10:06 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.76]) by IMCCAS04.MITRE.ORG ([129.83.29.81]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 17:10:05 -0400 From: "Peck, Michael A" To: Mike Jones , Richard Barnes , John Bradley Thread-Topic: [jose] RSASSA-PSS signature Thread-Index: Ac4fUsSatNxE3pBSSnqP5xo0kQPdBQAJgDiAAADa5gAAAMlQgAAGmVaA Date: Tue, 12 Mar 2013 21:10:05 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B9DIMCMBX04MITREOR_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 21:10:09 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B9DIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My original message was not about encryption algorithms, it was about the R= SASSA-PSS signature algorithm, which is not in JWA at all (I also don't see= it listed in Mike's spreadsheet). If you'd like to bring up encryption algorithms too, RFC 3447 states: Two encryption schemes are specified in this document: RSAES-OAEP and RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; RSAES-PKCS1-v1_5 is included only for compatibility with existing applications, and is not recommended for new applications. 10 years later, it may be appropriate to start encouraging movement away fr= om RSAES-PKCS1-v1_5 rather than further encouraging its use. Should the CFRG be asked for an opinion? Mike From: Mike Jones [mailto:Michael.Jones@microsoft.com] Sent: Tuesday, March 12, 2013 4:12 PM To: Richard Barnes; John Bradley Cc: Peck, Michael A; jose@ietf.org Subject: RE: [jose] RSASSA-PSS signature Your statement that there are no MTI algorithms is actually incorrect. The= current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) algorit= hms, and indeed, as currently chartered, we are required to define the set = of MTI algorithms. The spreadsheet characterizing platform support for possible algorithms tha= t John referred to is attached. As you can see, RSA PKCS1-v1_5 is the only= ubiquitously implemented asymmetric encryption algorithm. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Tuesday, March 12, 2013 12:49 PM To: John Bradley Cc: Peck, Michael A; jose@ietf.org Subject: Re: [jose] RSASSA-PSS signature Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. Only benefit! --Richard On Tue, Mar 12, 2013 at 3:24 PM, John Bradley > wrote: This has had a fair amount of discussion. While I think almost everyone w= ould prefer PSS, many implementations are going to be in scripting language= s where the underlying libraries only support PKCS1-v1_5. We did a survey of platforms to evaluate if we could move to PSS and the re= sult lead us not to make PSS as the MTI. In think that was reported out at= the Atlanta IETF meeting. Nat may be able to forward that to you, I don't have it handy. If we were talking about starting from scratch and not building on existing= platforms likely the answer would have been different. The algorithms are extensible so PSS can be added. The other consideratio= n is that many of the people who care will be using ECESA signatures anyway= . John B. On 2013-03-12, at 2:52 PM, "Peck, Michael A" > wrote: draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signature= s but not RSASSA-PSS. The Security Considerations states: While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not to adopt RSASSA-PKCS1 for new applications and instead requests that people transition to RSASSA-PSS, this specification does include RSASSA-PKCS1, for interoperability reasons, because it commonly implemented. Shouldn't RSASSA-PSS at least be included as an option? I'm also not sure if I fully understand the interoperability concerns. JWS= is a new specification, so it makes sense to me to use whatever algorithms= are currently considered best practice, without need to worry about backwa= rds compatibility? Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B9DIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My original message was n= ot about encryption algorithms, it was about the RSASSA-PSS signature algor= ithm, which is not in JWA at all (I also don’t see it listed in Mike’s spreadsheet). 

 <= /p>

If you’d like to br= ing up encryption algorithms too, RFC 3447 states:

   Two encryption schemes are specif= ied in this document: RSAES-OAEP and

   RSAES-PKCS1-v1_5.  RSAES-OAE= P is recommended for new applications;

   RSAES-PKCS1-v1_5 is included only= for compatibility with existing

   applications, and is not recommen= ded for new applications.

 <= /p>

10 years later, it may be= appropriate to start encouraging movement away from RSAES-PKCS1-v1_5 rathe= r than further encouraging its use.

Should the CFRG be asked = for an opinion?

 <= /p>

Mike

 <= /p>

From: Mike Jon= es [mailto:Michael.Jones@microsoft.com]
Sent: Tuesday, March 12, 2013 4:12 PM
To: Richard Barnes; John Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: RE: [jose] RSASSA-PSS signature

 

Your statement that there= are no MTI algorithms is actually incorrect.  The current JWA draft s= pecifies REQUIRED (and RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, we are required to define the set of MTI a= lgorithms.

 <= /p>

The spreadsheet character= izing platform support for possible algorithms that John referred to is att= ached.  As you can see, RSA PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption algorithm.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 PM
To: John Bradley
Cc: Peck, Michael A; jose@ietf.org<= /a>
Subject: Re: [jose] RSASSA-PSS signature

 

Since we are not putting requirements on algorithms = (i.e., there is no MTI), there's no harm to having PSS in the algorithms li= st.  Only benefit!  

--Richard

 

 

On Tue, Mar 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

This has had a fair amount of discussion.   Whi= le I think almost everyone would prefer PSS, many implementations are going= to be in scripting languages where the underlying libraries only support P= KCS1-v1_5.

 

We did a survey of platforms to evaluate if we could= move to PSS and the result lead us not to make PSS as the MTI.  In th= ink that was reported out at the Atlanta IETF meeting.

Nat may be able to forward that to you, I don't have= it handy.

 

If we were talking about starting from scratch and n= ot building on existing platforms likely the answer would have been differe= nt.

 

The algorithms are extensible so PSS can be added. &= nbsp; The other consideration is that many of the people who care will be u= sing ECESA signatures anyway.

 

John B.

 

On 2013-03-12, at 2:52 PM, "Peck, Michael A&quo= t; <mpeck@mitre.org= > wrote:

 

draft-ietf-jose-json-web-algorithms-08 = includes RSASSA-PKCS1-v1_5 signatures but not RSASSA-PSS.=

 

The Security Considerations states:

   While Section 8 of RFC 344= 7 [RFC3447] explicitly calls for people not

   to adopt RSASSA-PKCS1 for = new applications and instead requests that

   people transition to RSASS= A-PSS, this specification does include

   RSASSA-PKCS1, for interope= rability reasons, because it commonly

   implemented.

 

Shouldn’t RSASSA-PSS at least be = included as an option?

I’m also not sure if I fully unde= rstand the interoperability concerns.  JWS is a new specification, so = it makes sense to me to use whatever algorithms are currently considered best practice, without need to worry about backwards compatibility?

 

Mike

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFC0B9DIMCMBX04MITREOR_-- From trac+jose@trac.tools.ietf.org Tue Mar 12 14:16:01 2013 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 73E6121F8AD4 for ; Tue, 12 Mar 2013 14:16:01 -0700 (PDT) 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 MiFBLdfBTb9r for ; Tue, 12 Mar 2013 14:16:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A3DEE21F8ABA for ; Tue, 12 Mar 2013 14:15:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:57944 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFWY2-0006P2-MA; Tue, 12 Mar 2013 22:15:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, bcampbell@pingidentity.com X-Trac-Project: jose Date: Tue, 12 Mar 2013 21:15:50 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/12 Message-ID: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, bcampbell@pingidentity.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130312211600.A3DEE21F8ABA@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 14:15:59 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2013 21:16:01 -0000 #12: x5c incorrect in JWE No use case (that I'm aware of anyway) has been suggested for "x5c" in JWE that cannot be addressed in a more straightforward and efficient way using other available header parameters like "x5u", "kid", etc. I suggest "x5c" be removed from JWE. If it must stay, there are a couple of issues with its definition in http://tools.ietf.org/html/draft-ietf-jose-json-web- encryption-08#section-4.1.9 that need to be fixed. 1) It states that "the certificate containing the public key of the entity that encrypted the JWE MUST be the first certificate" but for all the JWE algorithms currently defined that certificate would have to have the public key of the entity that corresponds to its private key which will be used to decrypt. 2) It also states that "the recipient MUST verify the certificate chain according to [RFC5280] and reject..." which is really awkward because that certificate chain certifies the recipient (why would you validate your own cert chain?) not the sender. There was a message and subsequent shortish discussion thread on the list a while back about this too: http://www.ietf.org/mail- archive/web/jose/current/msg01438.html -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: jose From ve7jtb@ve7jtb.com Tue Mar 12 15:21:03 2013 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 D95CE11E812D for ; Tue, 12 Mar 2013 15:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.974 X-Spam-Level: X-Spam-Status: No, score=-2.974 tagged_above=-999 required=5 tests=[AWL=0.624, 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 gsq9gWl8jXSc for ; Tue, 12 Mar 2013 15:21:02 -0700 (PDT) Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) by ietfa.amsl.com (Postfix) with ESMTP id A009A11E8110 for ; Tue, 12 Mar 2013 15:21:02 -0700 (PDT) Received: by mail-gh0-f169.google.com with SMTP id r18so81500ghr.28 for ; Tue, 12 Mar 2013 15:21:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=SdJ9n8BgmJgENH7ijsw/Zf2kG43QS9rtvb2bY7f9s9E=; b=a9LWHC9gp0wdEnc/e0GAzEvr27bwIVX00+WqszDAj+wWiMzCy8El7oinBsk0FU+WEn ULuu8qm+spfs2Cx61kfWURVoQXLQHtXV2i1Pk+AvXpbigm4uAoX93ydE53MzBNqXH1xT hbZ5DVDTYDQ5Rk5NvEhz901x5R12hTwRzgKmsqomtOqJpdICvffvpCbETmJml398csgM ZwGkZ4+QkFJi8ScABN/FYLrJoID4gI4d5QICwKHYBRXNee7fNM+v+g84ERg+FJhxOB4W 8dqqFXuxBFBE6uJLG53qpKCXaCbqvYseFTITU45l/PbMM4Kam7kOFHF7iZv0iIABzQaD yVzA== X-Received: by 10.236.153.131 with SMTP id f3mr13572033yhk.145.1363126861632; Tue, 12 Mar 2013 15:21:01 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id s3sm26479000yhm.10.2013.03.12.15.20.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 15:20:59 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_875E8D7E-6889-44B7-B438-A35460763411"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG> Date: Tue, 12 Mar 2013 18:20:44 -0400 Message-Id: <636E709D-6919-4D18-BE76-3FC34BB3CC6C@ve7jtb.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG> To: "Peck, Michael A" X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmvYv/9H90s5f7kChPTHPprvU+gm+04yL+zwrVD1I5M+DAPnk8YbZHRpWH3i/1yCHd5o9ec Cc: Richard Barnes , Mike Jones , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 22:21:04 -0000 --Apple-Mail=_875E8D7E-6889-44B7-B438-A35460763411 Content-Type: multipart/alternative; boundary="Apple-Mail=_C6785D8B-DB6E-4099-A968-E48414F4DC9B" --Apple-Mail=_C6785D8B-DB6E-4099-A968-E48414F4DC9B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 RSA PKCS1-v1.5 is used for both signing and encryption as you are aware = it is an encryption/padding alg that is used with a hash function for = signature. The same argument you are making can be used to include RSA-OAEP. One of the reasons PKCS1 v1.5 padding is so popular is that it can be = used to wrap both a key and a hash where the alternative needs to = padding als and to be secure two keys. I agree that it would be better in a perfect world. Nothing stops additional algorithms being defined. We have people = using the current padding who had strong opinions on that. =20 I have yet to see anyone want PSS/OAEP strongly other than as a matter = of principal (I have been one of them). If you feel strongly put forward a use case and propose adding them. John B. On 2013-03-12, at 5:10 PM, "Peck, Michael A" wrote: > My original message was not about encryption algorithms, it was about = the RSASSA-PSS signature algorithm, which is not in JWA at all (I also = don=92t see it listed in Mike=92s spreadsheet).=20 > =20 > If you=92d like to bring up encryption algorithms too, RFC 3447 = states: > Two encryption schemes are specified in this document: RSAES-OAEP = and > RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; > RSAES-PKCS1-v1_5 is included only for compatibility with existing > applications, and is not recommended for new applications. > =20 > 10 years later, it may be appropriate to start encouraging movement = away from RSAES-PKCS1-v1_5 rather than further encouraging its use. > Should the CFRG be asked for an opinion? > =20 > Mike > =20 > From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 > Sent: Tuesday, March 12, 2013 4:12 PM > To: Richard Barnes; John Bradley > Cc: Peck, Michael A; jose@ietf.org > Subject: RE: [jose] RSASSA-PSS signature > =20 > Your statement that there are no MTI algorithms is actually incorrect. = The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) = algorithms, and indeed, as currently chartered, we are required to = define the set of MTI algorithms. > =20 > The spreadsheet characterizing platform support for possible = algorithms that John referred to is attached. As you can see, RSA = PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption = algorithm. > =20 > -- Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Tuesday, March 12, 2013 12:49 PM > To: John Bradley > Cc: Peck, Michael A; jose@ietf.org > Subject: Re: [jose] RSASSA-PSS signature > =20 > Since we are not putting requirements on algorithms (i.e., there is no = MTI), there's no harm to having PSS in the algorithms list. Only = benefit! =20 > --Richard > =20 > =20 > On Tue, Mar 12, 2013 at 3:24 PM, John Bradley = wrote: > This has had a fair amount of discussion. While I think almost = everyone would prefer PSS, many implementations are going to be in = scripting languages where the underlying libraries only support = PKCS1-v1_5. > =20 > We did a survey of platforms to evaluate if we could move to PSS and = the result lead us not to make PSS as the MTI. In think that was = reported out at the Atlanta IETF meeting. > Nat may be able to forward that to you, I don't have it handy. > =20 > If we were talking about starting from scratch and not building on = existing platforms likely the answer would have been different. > =20 > The algorithms are extensible so PSS can be added. The other = consideration is that many of the people who care will be using ECESA = signatures anyway. > =20 > John B. > =20 > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote: > =20 > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 = signatures but not RSASSA-PSS. > =20 > The Security Considerations states: > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people = not > to adopt RSASSA-PKCS1 for new applications and instead requests = that > people transition to RSASSA-PSS, this specification does include > RSASSA-PKCS1, for interoperability reasons, because it commonly > implemented. > =20 > Shouldn=92t RSASSA-PSS at least be included as an option? > I=92m also not sure if I fully understand the interoperability = concerns. JWS is a new specification, so it makes sense to me to use = whatever algorithms are currently considered best practice, without need = to worry about backwards compatibility? > =20 > Mike > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_C6785D8B-DB6E-4099-A968-E48414F4DC9B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 RSA PKCS1-v1.5 is used for both = signing and encryption as you are aware it is an encryption/padding alg = that is used with a hash function for signature.

The = same argument you are making can be used to include = RSA-OAEP.

One of the reasons PKCS1 v1.5 padding = is so popular is that it can be used to wrap both a key and a hash where = the alternative needs to padding als and to be secure two = keys.
I agree that it would be better in a perfect = world.

Nothing stops additional algorithms being = defined.   We have people using the current padding who had strong = opinions on that.  
I have yet to see anyone want = PSS/OAEP strongly other than as a matter of principal (I have been one = of them).

If you feel strongly put forward a = use case and propose adding them.

John = B.


On 2013-03-12, at 5:10 PM, = "Peck, Michael A" <mpeck@mitre.org> wrote:

My original message was = not about encryption algorithms, it was about the RSASSA-PSS signature = algorithm, which is not in JWA at all (I also don=92t see it listed in = Mike=92s spreadsheet). 
 
If you=92d like to bring = up encryption algorithms too, RFC 3447 = states:
   Two = encryption schemes are specified in this document: RSAES-OAEP = and
   = RSAES-PKCS1-v1_5.  RSAES-OAEP is recommended for new = applications;
   = applications, and is not recommended for new = applications.
 
10 years later, it may be appropriate to = start encouraging movement away from RSAES-PKCS1-v1_5 rather than = further encouraging its use.
Should the CFRG be asked for an = opinion?
 
Mike
 
From: Mike Jones = [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, March 12, 2013 = 4:12 PM
To: Richard Barnes; John = Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: RE: [jose] RSASSA-PSS = signature
Your statement that there are no MTI algorithms is = actually incorrect.  The current JWA draft specifies REQUIRED (and = RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, = we are required to define the set of MTI = algorithms.
 
The spreadsheet characterizing platform = support for possible algorithms that John referred to is attached.  = As you can see, RSA PKCS1-v1_5 is the only ubiquitously implemented = asymmetric encryption algorithm.
 
 
 jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Tuesday, March 12, 2013 = 12:49 PM
To: John = Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS = signature
Since we are = not putting requirements on algorithms (i.e., there is no MTI), there's = no harm to having PSS in the algorithms list.  Only benefit! =  
 
The Security Considerations = states:
   to adopt RSASSA-PKCS1 for new applications = and instead requests that
   people transition to RSASSA-PSS, = this specification does include
   RSASSA-PKCS1, for interoperability = reasons, because it commonly
   = implemented.
 
Mike
 
jose@ietf.org
, "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 22:25:13 -0000 --14dae93a0c1747c7d704d7c1c3fc Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Identifiers are cheap, modern algorithms are good. Just add them! --Richard On Tue, Mar 12, 2013 at 6:20 PM, John Bradley wrote: > RSA PKCS1-v1.5 is used for both signing and encryption as you are aware i= t > is an encryption/padding alg that is used with a hash function for > signature. > > The same argument you are making can be used to include RSA-OAEP. > > One of the reasons PKCS1 v1.5 padding is so popular is that it can be use= d > to wrap both a key and a hash where the alternative needs to padding als > and to be secure two keys. > I agree that it would be better in a perfect world. > > Nothing stops additional algorithms being defined. We have people using > the current padding who had strong opinions on that. > I have yet to see anyone want PSS/OAEP strongly other than as a matter of > principal (I have been one of them). > > If you feel strongly put forward a use case and propose adding them. > > John B. > > > On 2013-03-12, at 5:10 PM, "Peck, Michael A" wrote: > > My original message was not about encryption algorithms, it was about the > RSASSA-PSS signature algorithm, which is not in JWA at all (I also don=92= t > see it listed in Mike=92s spreadsheet). **** > > If you=92d like to bring up encryption algorithms too, RFC 3447 states:**= ** > Two encryption schemes are specified in this document: RSAES-OAEP and*= * > ** > RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications;**** > RSAES-PKCS1-v1_5 is included only for compatibility with existing**** > applications, and is not recommended for new applications.**** > > 10 years later, it may be appropriate to start encouraging movement away > from RSAES-PKCS1-v1_5 rather than further encouraging its use.**** > Should the CFRG be asked for an opinion?**** > > Mike**** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Tuesday, March 12, 2013 4:12 PM > *To:* Richard Barnes; John Bradley > *Cc:* Peck, Michael A; jose@ietf.org > *Subject:* RE: [jose] RSASSA-PSS signature**** > ** ** > Your statement that there are no MTI algorithms is actually incorrect. > The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) > algorithms, and indeed, as currently chartered, we are required to define > the set of MTI algorithms.**** > > The spreadsheet characterizing platform support for possible algorithms > that John referred to is attached. As you can see, RSA PKCS1-v1_5 is the > only ubiquitously implemented asymmetric encryption algorithm.**** > > -- Mike**** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org > ] *On Behalf Of *Richard Barnes > *Sent:* Tuesday, March 12, 2013 12:49 PM > *To:* John Bradley > *Cc:* Peck, Michael A; jose@ietf.org > *Subject:* Re: [jose] RSASSA-PSS signature**** > ** ** > Since we are not putting requirements on algorithms (i.e., there is no > MTI), there's no harm to having PSS in the algorithms list. Only benefit= ! > **** > --Richard**** > ** ** > ** ** > On Tue, Mar 12, 2013 at 3:24 PM, John Bradley wrote:*= * > ** > This has had a fair amount of discussion. While I think almost everyone > would prefer PSS, many implementations are going to be in scripting > languages where the underlying libraries only support PKCS1-v1_5.**** > ** ** > We did a survey of platforms to evaluate if we could move to PSS and the > result lead us not to make PSS as the MTI. In think that was reported ou= t > at the Atlanta IETF meeting.**** > Nat may be able to forward that to you, I don't have it handy.**** > ** ** > If we were talking about starting from scratch and not building on > existing platforms likely the answer would have been different.**** > ** ** > The algorithms are extensible so PSS can be added. The other > consideration is that many of the people who care will be using ECESA > signatures anyway.**** > ** ** > John B.**** > ** ** > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote:**** > ** ** > > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 > signatures but not RSASSA-PSS.**** > **** > The Security Considerations states:**** > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not*= * > ** > to adopt RSASSA-PKCS1 for new applications and instead requests that**= * > * > people transition to RSASSA-PSS, this specification does include**** > RSASSA-PKCS1, for interoperability reasons, because it commonly**** > implemented.**** > **** > Shouldn=92t RSASSA-PSS at least be included as an option?**** > I=92m also not sure if I fully understand the interoperability concerns. > JWS is a new specification, so it makes sense to me to use whatever > algorithms are currently considered best practice, without need to worry > about backwards compatibility?**** > **** > Mike**** > **** > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > --14dae93a0c1747c7d704d7c1c3fc Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Identifiers are cheap, modern algorithms are good. =A0Just add them!
--= Richard


On Tue, Mar= 12, 2013 at 6:20 PM, John Bradley <ve7jtb@ve7jtb.com> wrote= :
RSA PKCS= 1-v1.5 is used for both signing and encryption as you are aware it is an en= cryption/padding alg that is used with a hash function for signature.

The same argument you are making can be used to include RSA-= OAEP.

One of the reasons PKCS1 v1.5 padding is so = popular is that it can be used to wrap both a key and a hash where the alte= rnative needs to padding als and to be secure two keys.
I agree that it would be better in a perfect world.

=
Nothing stops additional algorithms being defined. =A0 We have people = using the current padding who had strong opinions on that. =A0
I = have yet to see anyone want PSS/OAEP strongly other than as a matter of pri= ncipal (I have been one of them).

If you feel strongly put forward a use case and propose= adding them.

John B.
=


On 2013-03-12, at 5:10 PM, "Peck, Mi= chael A" <mpec= k@mitre.org> wrote:

My original message was not about encry= ption algorithms, it was about the RSASSA-PSS signature algorithm, which is= not in JWA at all (I also don=92t see it listed in Mike=92s spreadsheet).= =A0
=A0
If you=92d like to bring up encryption algorithms too, RFC 3447 sta= tes:
=A0=A0 Two= encryption schemes are specified in this document: RSAES-OAEP and
=A0=A0 RSA= ES-PKCS1-v1_5.=A0 RSAES-OAEP is recommended for new applications;=
=A0=A0 RSA= ES-PKCS1-v1_5 is included only for compatibility with existing
=A0=A0 app= lications, and is not recommended for new applications.
=A0
10 years later, it m= ay be appropriate to start encouraging movement away from RSAES-PKCS1-v1_5 = rather than further encouraging its use.
Should the CFRG be asked for an opinion?<= /u>
=A0
Mike
=A0=
From:=A0Mike Jones [mailto:Michael.Jones@microsoft.com]=A0
Sent:=A0Tuesday, March 12, 2013 4:12 PM
To:=A0Richard Barnes; John Bradley
Cc:=A0Pec= k, Michael A; jose@ietf.= org
Subject:=A0RE: [jose] RSASSA-PSS signature
=A0
Your statement that there are no MTI algorithms is actually incorre= ct.=A0 The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONA= L) algorithms, and indeed, as currently chartered, we are required to defin= e the set of MTI algorithms.
=A0
The spreadsheet characterizing platform support for possible algori= thms that John referred to is attached.=A0 As you can see, RSA PKCS1-v1_5 i= s the only ubiquitously implemented asymmetric encryption algorithm.=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
=A0
From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behalf O= f=A0Richard Barnes
Sent:=A0Tuesday, March 12, 2013 12:49 PM
To:<= span>=A0John Bradley
Cc:=A0Peck, Michael A;=A0jose@ietf.org
Subject:=A0Re: [jose] RSASSA-PSS signature
=A0
Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. =A0Only benefit= ! =A0
--Richard
=A0
=A0
On Tue, Mar 12, 2013 at = 3:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This has had a fair amount of discussion. =A0 W= hile I think almost everyone would prefer PSS, many implementations are goi= ng to be in scripting languages where the underlying libraries only support= PKCS1-v1_5.
=A0
We did a survey of platforms to evaluate if we could move to PSS and the re= sult lead us not to make PSS as the MTI. =A0In think that was reported out = at the Atlanta IETF meeting.
Nat may be able to forward that to you, I don't have it handy.
=A0
<= div>
If we were talking about starting from scratch and n= ot building on existing platforms likely the answer would have been differe= nt.
=A0
The algorithms are extensible so PSS can be added. =A0 The other considerat= ion is that many of the people who care will be using ECESA signatures anyw= ay.
=A0
John B.<= /u>
=A0
draft-ietf-jo= se-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signatures but not RSA= SSA-PSS.
=A0=
The Security Considerations states:
=A0=A0 While Section 8 of RFC 3447 [RFC3447] explicitl= y calls for people not
=A0=A0 to adopt RSASSA-PKCS1 for new applications and = instead requests that
=A0=A0 people transition to RSASSA-PSS, this specifica= tion does include
=A0=A0 RSASSA-PKCS1, for interoperability reasons, bec= ause it commonly
=A0=A0 implemented.
=A0=
Shouldn=92t RSASSA-PSS at least be in= cluded as an option?
I=92m also not sure if I fully understand the interope= rability concerns.=A0 JWS is a new specification, so it makes sense to me t= o use whatever algorithms are currently considered best practice, without n= eed to worry about backwards compatibility?
=A0
Mike
=A0
_______________________________________________ jose mailing list
= jose@ietf.org
= https://www.ietf.org/mailman/listinfo/jose
=A0


_______________________________________________
jose mailing listjose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=

=

--14dae93a0c1747c7d704d7c1c3fc-- From rlb@ipv.sx Tue Mar 12 15:29:40 2013 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 4296E11E80F5 for ; Tue, 12 Mar 2013 15:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.35 X-Spam-Level: X-Spam-Status: No, score=-2.35 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 uMHpyb2FU9nq for ; Tue, 12 Mar 2013 15:29:39 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3042C11E80F0 for ; Tue, 12 Mar 2013 15:29:39 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so423976oag.32 for ; Tue, 12 Mar 2013 15:29:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IILxFN5hrmEIObZMLiostBW/p6L+FtjeSrDkljSPqFg=; b=NI2eIiGysEYHdo0QqpD+OvVIiAp0nhqQRO+etR0186jWWPYYbnYSDpDxYu/ksLpoU3 4tibsJtwWChB6OhwnNxMkVD20MSZhl5BPSL6AWsofUZEk+iZVVhY+VzYLyAsAZBLgEE4 ukDIqUbAZ99lalCvBFeYfDUqvtL5GZh4P26REqX2BicYTb0ZQpHQadupR0kz1cRqiwBp JwWGTXXNGkf+lq6Yepn5PMpCPMLJuo4Gz2oYX+lB3a8yvqr9ni4cytxuxqBzPKvv8uWn klOAGnIexRJz3mzAj9iArStylkdmL21AwfHo+7O96dleMALFelEN3GugMkxfRyLfeEN1 e4TQ== MIME-Version: 1.0 X-Received: by 10.182.132.43 with SMTP id or11mr13650492obb.67.1363127378805; Tue, 12 Mar 2013 15:29:38 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 12 Mar 2013 15:29:38 -0700 (PDT) X-Originating-IP: [128.89.253.127] In-Reply-To: References: Date: Tue, 12 Mar 2013 18:29:38 -0400 Message-ID: From: Richard Barnes To: Dick Hardt Content-Type: multipart/alternative; boundary=14dae93a0c17328a8704d7c1d3ce X-Gm-Message-State: ALoCoQk7kS/mRl8JdZQLd2EHiarxJ3DA8qoecxsHf5+/AXILMFtfyFo3R28EHk8EIza5d+05J65G Cc: Anthony Nadalin , Karen O'Donoghue , Jim Schaad , Mike Jones , Tim Bray , jose , John Bradley , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 22:29:40 -0000 --14dae93a0c17328a8704d7c1d3ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dick, If I understand your use case correctly, what you're actually looking for is a way to populate the "additional data" that's protected under the AEAD algorithm. Unfortunately, under current JWE, that's conflated with the header. I think the correct resolution to this problem is to remove the JWE header from the integrity check, and add a separate field to JWE for additional data. --Richard On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt wrote: > Agreed. > > In an implementation I am working on, I need an audience signal in a JWE > so that recipients of the JWE token know who can decrypt and process it. > > While on that topic, it seems that I can't have 'aud' in the header, so I > would need to have a URI for that property such as 'aud.example.com' > > btw: per Richard's comment, the code to use app specific payload data is > pretty ugly with > > jwt.['prop.example.com'] > > but I put all the app properties in the one object so I do > > jwt.['prop.example.com'].prop1 > > -- Dick > > > > On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin w= rote: > >> oh great now you are going to tell us what is crypto related and what >> is not, that is pretty much n application call not a spec call >> >> Sent from Windows Mail >> >> *From:* Mike Jones >> *Sent:* March 12, 2013 7:02 AM >> >> *To:* Jim Schaad, Richard Barnes >> *CC:* John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose >> >> *Subject:* Re: [jose] Proposed resolution of header criticality issue >> >> +1 to only putting crypto-related things in the headers. >> >> *From:* Richard Barnes >> *Sent:* March 12, 2013 6:53 AM >> >> *To:* Jim Schaad >> *CC:* John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen >> O'Donoghue >> *Subject:* Re: [jose] Proposed resolution of header criticality issue >> >> Note that my proposed text did not say that the libraries would not >> return header stuff, only that you shouldn't cram non-crypto-related thi= ngs >> in there. >> >> >> >> On Tuesday, March 12, 2013, Jim Schaad wrote: >> >>> I am not truly happy with this idea. If the application cares about >>> who =93owns=94 a key for a signature then it needs to somehow get that >>> information. That may be done by getting the way and key from the secu= rity >>> library and that may be done by just returning the claims from the enve= lope. >>> **** >>> >>> ** ** >>> >>> Jim**** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *John Bradley >>> *Sent:* Tuesday, March 12, 2013 9:15 AM >>> *To:* Mike Jones >>> *Cc:* Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue >>> *Subject:* Re: [jose] Proposed resolution of header criticality issue**= * >>> * >>> >>> ** ** >>> >>> I am OK with getting rid of it if we make it clear that claims from the >>> envelope will not be passed on to applications.**** >>> >>> ** ** >>> >>> If we don't do that we will compromise interoperability between >>> libraries. Envelope is for JOSE only and not made available, that mak= es >>> things like timestamps and other things that the application layer need= s to >>> interpret can't go in the envelope they need to be in the body in some = way. >>> **** >>> >>> ** ** >>> >>> I just want it one way or the other.**** >>> >>> ** ** >>> >>> John B.**** >>> >>> ** ** >>> >>> ** ** >>> >>> On 2013-03-12, at 9:06 AM, Mike Jones >>> wrote:**** >>> >>> >>> >>> **** >>> >>> I=92m with Richard on this. The application-specific-data/meta field >>> isn=92t needed.**** >>> >>> **** >>> >>> -- Mike**** >>> >>> **** >>> >>> *From:* Richard Barnes >>> *Sent:* March 11, 2013 10:02 PM >>> *To:* John Bradley >>> *CC:* Tim Bray, Manger, James H, Karen ODonoghue, jose >>> *Subject:* Re: [jose] Proposed resolution of header criticality issue**= * >>> * >>> >>> **** >>> >>> +1 to cheers. I already high-fived Mike in person. **** >>> >>> ** ** >>> >>> FWIW, my preference would be to get rid of "asd" or "meta" (part 5). I >>> don't think it's relevant to the criticality discussion, and it's just = not >>> needed. **** >>> >>> ** ** >>> >>> --Richard**** >>> >>> ** ** >>> >>> ** ** >>> >>> On Mon, Mar 11, 2013 at 11:01 PM, John Bradley >>> wrote:**** >>> >>> ** ** >>> >>> On 2013-03-11, at 10:48 PM, "Manger, James H" < >>> James.H.Manger@team.telstra.com> wrote:**** >>> >>> ** ** >>> >>> I=92ll add some cheers =97 this does look like substant >>> >>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > > > -- > -- Dick > --14dae93a0c17328a8704d7c1d3ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dick,

If I understand your use case correctly, what y= ou're actually looking for is a way to populate the "additional da= ta" that's protected under the AEAD algorithm. =A0Unfortunately, u= nder current JWE, that's conflated with the header. =A0I think the corr= ect resolution to this problem is to remove the JWE header from the integri= ty check, and add a separate field to JWE for additional data.

--Richard



On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt <dick.hard= t@gmail.com> wrote:
Agreed.

= In an implementation I am working on, I need an audience signal in a JWE so= that recipients of the JWE token know who can decrypt and process it.

While on that topic, it seems that I can't have 'aud' in the he= ader, so I would need to have a URI for that property such as 'aud.example.com'

btw: per Richard's comment, the code to use app specific payload d= ata is pretty ugly with


but I put all the app properties in the one object so I do

jwt.['prop.example.com'].prop1

-- Dick



<= div class=3D"gmail_quote">
On Tue, Mar 12, 2013 at 7:05 AM= , Anthony Nadalin <tonynad@microsoft.com> wrote:
oh great now you are going to tell us what is crypto related and what = is not, that is pretty much n application call not a spec call
=A0
Sent from Windows Mail
=A0
From:=A0Mike Jones
Sent:=A0March 12, 2013 7:02 AM

To:=A0Jim Schaad, Richard Barnes
CC:=A0John Bradley, Tim Bray, James H Manger, Karen O'= Donoghue, jose

Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
+1 to=A0only putting crypto-related things in the headers.
=A0
From:=A0Richard Barnes
Sent:=A0March 12, 2013 6:53 AM

To:=A0Jim Schaad
CC:=A0John Bradley, Mike Jones, James H Manger, Tim Bray, = jose, Karen O'Donoghue
Subject:=A0Re: [jose] Proposed resolution of header critic= ality issue
=A0
Note that my proposed text did not say that the libraries would not return = header stuff, only that you shouldn't cram non-crypto-related things in= there.=A0



On Tuesday, March 12, 2013, Jim Schaad wrote:

I am not truly happy= with this idea.=A0 If the application cares about who =93owns=94 a key for= a signature then it needs to somehow get that information.=A0 That may be done by getting the way and key from the security library and = that may be done by just returning the claims from the envelope.<= /u>

=A0

Jim

=A0

=A0

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Dono= ghue
Subject: Re: [jose] Proposed resolution of header criticality issue<= u>

=A0

I am OK with getting rid of it if we make it clear that claims from the = envelope will not be passed on to applications.

=A0

If we don't do that we will compromise interoperability between libr= aries. =A0 Envelope is for JOSE only and not made available, that makes thi= ngs like timestamps and other things that the application layer needs to in= terpret can't go in the envelope they need to be in the body in some way.

=A0

I just want it one way or the other.

=A0

John B.

=A0

=A0

On 2013-03-12, at 9:06 AM, Mike Jones <Michael.Jones@microsoft.com= > wrote:



I= =92m with Richard on this.=A0 The=A0application-specific-data/meta field is= n=92t needed.

= =A0

-= - Mike

= =A0

From:=A0Richard Barnes
Sent:=A0March 11, 2013 10:02 PM
To:=A0John Bradley
CC:=A0Tim Bray, Manger, James H, Karen ODonoghue, jose<= br> Subject:=A0Re: [jose] Proposed resolution of header cri= ticality issue

= =A0

+= 1 to cheers. =A0I already high-fived Mike in person.

<= u>=A0

F= WIW, my preference would be to get rid of "asd" or "meta&quo= t; (part 5). =A0I don't think it's relevant to the criticality disc= ussion, and it's just not needed. =A0

<= u>=A0

-= -Richard

<= u>=A0

=A0

O= n Mon, Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:

<= u>=A0

O= n 2013-03-11, at 10:48 PM, "Manger, James H" <James.H.Mange= r@team.telstra.com> wrote:

<= u>=A0

I=92ll add some cheers = =97 this does look like substant


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




--
-- Dick

--14dae93a0c17328a8704d7c1d3ce-- From ve7jtb@ve7jtb.com Tue Mar 12 15:47:20 2013 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 7BC4811E80F0 for ; Tue, 12 Mar 2013 15:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.078 X-Spam-Level: X-Spam-Status: No, score=-3.078 tagged_above=-999 required=5 tests=[AWL=0.520, 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 x6msIlSEO8ED for ; Tue, 12 Mar 2013 15:47:19 -0700 (PDT) Received: from mail-ye0-f176.google.com (mail-ye0-f176.google.com [209.85.213.176]) by ietfa.amsl.com (Postfix) with ESMTP id C56F611E80FF for ; Tue, 12 Mar 2013 15:47:18 -0700 (PDT) Received: by mail-ye0-f176.google.com with SMTP id m9so84760yen.21 for ; Tue, 12 Mar 2013 15:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=BBYGgTADpHWqYMFSqNL0qWoc9/AjL3WSBqD4LB3nGf0=; b=SbRBqJW4XCwRQMcgYuhjpOHuH4dn0axzARRSS2IIK9aBgizIMIRdSrJgHM732R5vjj bFn9+YgAuZDDut159Ks+0wqpIGo9niq1bL3Cr5Cuz9ekEMo/x7Z0ZZ1iIre13AHp5vGb 57dfMPwJlTGaoZeGIuZdm4Ppjzb1PmQOR/fQF7xvh9sstKazKjvg/8NfUfMtAEjyHRXu iROdWgvf7Iy77sNVpL0BjggVVN5KDh6r8vq/nWrOeBl4gx6i6sBIICTmMCy0LE+NQaR+ HoljKodTHEGfolhaEIV7PUGp1Rn6XIrdDn8VXH7hFGi80W9CwvnR7395GGUWKz5IWS4a 36nA== X-Received: by 10.236.153.9 with SMTP id e9mr13881463yhk.205.1363128438233; Tue, 12 Mar 2013 15:47:18 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id w7sm32267166yhj.0.2013.03.12.15.47.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 15:47:16 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_974BD6DB-EC62-4C1B-B7EC-EC43C3D2DCDE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Tue, 12 Mar 2013 18:47:13 -0400 Message-Id: <4B3A1183-265C-47DC-8A03-87D939D047E6@ve7jtb.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG> <636E709D-6919-4D18-BE76-3FC34BB3CC6C@ve7jtb.com> To: Richard Barnes X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkt236FysrLdmodBoKvZYkGfnOUEtKlEd2YT6wXH9oXBP81EHBrEd4kT08ZnrJjTjeb3H9I Cc: Mike Jones , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 22:47:20 -0000 --Apple-Mail=_974BD6DB-EC62-4C1B-B7EC-EC43C3D2DCDE Content-Type: multipart/alternative; boundary="Apple-Mail=_003E78C3-1A8F-4D8C-9612-48D3D647B587" --Apple-Mail=_003E78C3-1A8F-4D8C-9612-48D3D647B587 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 If only I were King:) If the workgroup wants them added they get added. I don't have = anything against adding them, other than not wanting to fill up the = specs with cruft that will scare away developers. Is someone saying they want to use OAEP/PSS? Someone anyone saying = they need it would probably be sufficient to get the WG to make the = addition. Honestly my very early draft with Nat had OAEP/PSS as the defaults and = we got talked out of that. =20 However my argument for OAEP/PSS is academic so real deployer desire is = going to be more influential. John B. On 2013-03-12, at 6:25 PM, Richard Barnes wrote: > Identifiers are cheap, modern algorithms are good. Just add them! > --Richard >=20 >=20 > On Tue, Mar 12, 2013 at 6:20 PM, John Bradley = wrote: > RSA PKCS1-v1.5 is used for both signing and encryption as you are = aware it is an encryption/padding alg that is used with a hash function = for signature. >=20 > The same argument you are making can be used to include RSA-OAEP. >=20 > One of the reasons PKCS1 v1.5 padding is so popular is that it can be = used to wrap both a key and a hash where the alternative needs to = padding als and to be secure two keys. > I agree that it would be better in a perfect world. >=20 > Nothing stops additional algorithms being defined. We have people = using the current padding who had strong opinions on that. =20 > I have yet to see anyone want PSS/OAEP strongly other than as a matter = of principal (I have been one of them). >=20 > If you feel strongly put forward a use case and propose adding them. >=20 > John B. >=20 >=20 > On 2013-03-12, at 5:10 PM, "Peck, Michael A" wrote: >=20 >> My original message was not about encryption algorithms, it was about = the RSASSA-PSS signature algorithm, which is not in JWA at all (I also = don=92t see it listed in Mike=92s spreadsheet).=20 >> =20 >> If you=92d like to bring up encryption algorithms too, RFC 3447 = states: >> Two encryption schemes are specified in this document: RSAES-OAEP = and >> RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications; >> RSAES-PKCS1-v1_5 is included only for compatibility with existing >> applications, and is not recommended for new applications. >> =20 >> 10 years later, it may be appropriate to start encouraging movement = away from RSAES-PKCS1-v1_5 rather than further encouraging its use. >> Should the CFRG be asked for an opinion? >> =20 >> Mike >> =20 >> From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 >> Sent: Tuesday, March 12, 2013 4:12 PM >> To: Richard Barnes; John Bradley >> Cc: Peck, Michael A; jose@ietf.org >> Subject: RE: [jose] RSASSA-PSS signature >> =20 >> Your statement that there are no MTI algorithms is actually = incorrect. The current JWA draft specifies REQUIRED (and RECOMMENED and = OPTIONAL) algorithms, and indeed, as currently chartered, we are = required to define the set of MTI algorithms. >> =20 >> The spreadsheet characterizing platform support for possible = algorithms that John referred to is attached. As you can see, RSA = PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption = algorithm. >> =20 >> -- Mike >> =20 >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes >> Sent: Tuesday, March 12, 2013 12:49 PM >> To: John Bradley >> Cc: Peck, Michael A; jose@ietf.org >> Subject: Re: [jose] RSASSA-PSS signature >> =20 >> Since we are not putting requirements on algorithms (i.e., there is = no MTI), there's no harm to having PSS in the algorithms list. Only = benefit! =20 >> --Richard >> =20 >> =20 >> On Tue, Mar 12, 2013 at 3:24 PM, John Bradley = wrote: >> This has had a fair amount of discussion. While I think almost = everyone would prefer PSS, many implementations are going to be in = scripting languages where the underlying libraries only support = PKCS1-v1_5. >> =20 >> We did a survey of platforms to evaluate if we could move to PSS and = the result lead us not to make PSS as the MTI. In think that was = reported out at the Atlanta IETF meeting. >> Nat may be able to forward that to you, I don't have it handy. >> =20 >> If we were talking about starting from scratch and not building on = existing platforms likely the answer would have been different. >> =20 >> The algorithms are extensible so PSS can be added. The other = consideration is that many of the people who care will be using ECESA = signatures anyway. >> =20 >> John B. >> =20 >> On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote: >> =20 >> draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 = signatures but not RSASSA-PSS. >> =20 >> The Security Considerations states: >> While Section 8 of RFC 3447 [RFC3447] explicitly calls for people = not >> to adopt RSASSA-PKCS1 for new applications and instead requests = that >> people transition to RSASSA-PSS, this specification does include >> RSASSA-PKCS1, for interoperability reasons, because it commonly >> implemented. >> =20 >> Shouldn=92t RSASSA-PSS at least be included as an option? >> I=92m also not sure if I fully understand the interoperability = concerns. JWS is a new specification, so it makes sense to me to use = whatever algorithms are currently considered best practice, without need = to worry about backwards compatibility? >> =20 >> Mike >> =20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> =20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 >=20 --Apple-Mail=_003E78C3-1A8F-4D8C-9612-48D3D647B587 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 If = only I were King:)

If the workgroup wants them added = they get added.   I don't have anything against adding them, other = than not wanting to fill up the specs with cruft that will scare away = developers.

Is someone saying they want to use = OAEP/PSS?    Someone anyone saying they need it would probably = be sufficient to get the WG to make the addition.
Honestly my = very early draft with Nat had OAEP/PSS as the defaults and we got talked = out of that.   

However my argument = for OAEP/PSS is academic so real deployer desire is going to be more = influential.

John = B.


On 2013-03-12, at 6:25 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

Identifiers are cheap, modern algorithms are good. =  Just add them!
--Richard


On Tue, Mar 12, 2013 at 6:20 PM, John Bradley = <ve7jtb@ve7jtb.com> wrote:
RSA PKCS1-v1.5 is used for both signing = and encryption as you are aware it is an encryption/padding alg that is = used with a hash function for signature.

The same argument you are making can be used to include = RSA-OAEP.

One of the reasons PKCS1 v1.5 padding = is so popular is that it can be used to wrap both a key and a hash where = the alternative needs to padding als and to be secure two keys.
I agree that it would be better in a perfect = world.

Nothing stops additional algorithms being = defined.   We have people using the current padding who had strong = opinions on that.  
I have yet to see anyone want = PSS/OAEP strongly other than as a matter of principal (I have been one = of them).

If you feel strongly put forward a use case and = propose adding them.

John B.


On 2013-03-12, at 5:10 = PM, "Peck, Michael A" <mpeck@mitre.org> wrote:

My original message was not about encryption algorithms, it was about = the RSASSA-PSS signature algorithm, which is not in JWA at all (I also = don=92t see it listed in Mike=92s = spreadsheet). 
 
If you=92d like to bring up encryption algorithms too, RFC 3447 = states:
   = Two encryption schemes are specified in this document: RSAES-OAEP = and
   = RSAES-PKCS1-v1_5.  RSAES-OAEP is recommended for new = applications;
   = RSAES-PKCS1-v1_5 is included only for compatibility with = existing
   = applications, and is not recommended for new = applications.
 
10 years later, it may be appropriate to start encouraging movement = away from RSAES-PKCS1-v1_5 rather than further encouraging its = use.
Should the CFRG be asked for an opinion?
 
Mike
 
From: = Mike Jones [mailto:Michael.Jones@microsoft.com] 
Sent: Tuesday, March 12, 2013 4:12 = PM
To: Richard Barnes; John = Bradley
Cc: Peck, Michael A; jose@ietf.org
Subject: RE: [jose] RSASSA-PSS = signature
 
Your statement that there are no MTI algorithms is actually = incorrect.  The current JWA draft specifies REQUIRED (and = RECOMMENED and OPTIONAL) algorithms, and indeed, as currently chartered, = we are required to define the set of MTI = algorithms.
 
The spreadsheet characterizing platform support for possible = algorithms that John referred to is attached.  As you can see, RSA = PKCS1-v1_5 is the only ubiquitously implemented asymmetric encryption = algorithm.
 
            = ;            &= nbsp;           &nb= sp;            = ;           -- = Mike
 
From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] O= n Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 12:49 = PM
To: John = Bradley
Cc: Peck, Michael = A; jose@ietf.org
Subject: Re: [jose] RSASSA-PSS = signature
 
Since we are not putting requirements on algorithms (i.e., there is no = MTI), there's no harm to having PSS in the algorithms list.  Only = benefit!  
--Richard
 
 
On Tue, Mar = 12, 2013 at 3:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This has = had a fair amount of discussion.   While I think almost everyone = would prefer PSS, many implementations are going to be in scripting = languages where the underlying libraries only support = PKCS1-v1_5.
 
We did a survey of platforms to evaluate if we could move to PSS and the = result lead us not to make PSS as the MTI.  In think that was = reported out at the Atlanta IETF = meeting.
Nat may be able to forward that to you, I don't have it = handy.
 
If we were talking about starting from scratch and not = building on existing platforms likely the answer would have been = different.
 
The algorithms are extensible so PSS can be added.   The other = consideration is that many of the people who care will be using ECESA = signatures anyway.
 
John = B.
 
On = 2013-03-12, at 2:52 PM, "Peck, Michael A" <mpeck@mitre.org> wrote:
 
draft-ietf-jose-js= on-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signatures but not = RSASSA-PSS.
 
The Security = Considerations states:
   = While Section 8 of RFC 3447 [RFC3447] explicitly calls for people = not
   to = adopt RSASSA-PKCS1 for new applications and instead requests = that
   = people transition to RSASSA-PSS, this specification does = include
   = RSASSA-PKCS1, for interoperability reasons, because it = commonly
   = implemented.
 
Shouldn=92t = RSASSA-PSS at least be included as an option?
I=92m also not = sure if I fully understand the interoperability concerns.  JWS is a = new specification, so it makes sense to me to use whatever algorithms = are currently considered best practice, without need to worry about = backwards compatibility?
 
Mike=
 
______________= _________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=




= --Apple-Mail=_003E78C3-1A8F-4D8C-9612-48D3D647B587-- --Apple-Mail=_974BD6DB-EC62-4C1B-B7EC-EC43C3D2DCDE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMjI0NzEzWjAjBgkqhkiG9w0BCQQxFgQUYmsJQ+ft YojMTxv5IFsIvx3MZ3YwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAEGs7rcIIy9HejkMc1PJGuKvATQ5OWqBSWG/1fcWB NaTqYwaUu5L0s+tRb2vE4BYUEbIY7IfHWK/nW8k648XhJDPPFh6mpaSju+w6U8HHmPy7DltcX1II ThsagfjjTgDRxm8YgSh1bMTni88Gj5r5Y6EE98XvXw8wped+LdNcDjR3arAQhrjyccqaCUMMMtqM JcMHyU2tFEbbJGvVU+KzTaQFEipIRSSvBPRCjtQ6WxS9LFJyrrATPRazmwQjnzIFf9AJz6pMblXj sCvq2Ja1bRL02HlVgI3airM6EJH8i79QH7t71Uel5ck49XYRfee/zfY52YHWkGQ/wXUlKHEfJAAA AAAAAA== --Apple-Mail=_974BD6DB-EC62-4C1B-B7EC-EC43C3D2DCDE-- From bcampbell@pingidentity.com Tue Mar 12 15:53:31 2013 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 CA7D211E810B for ; Tue, 12 Mar 2013 15:53:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.825 X-Spam-Level: X-Spam-Status: No, score=-5.825 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 e7J7Eh578BTV for ; Tue, 12 Mar 2013 15:53:30 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id 47B8911E810A for ; Tue, 12 Mar 2013 15:53:30 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKUT+x6VC8EMjl9DpGXehYHQeooA0HLJnE@postini.com; Tue, 12 Mar 2013 15:53:30 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so1907620obb.6 for ; Tue, 12 Mar 2013 15:53:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=vtSE56YWySwSANEWQU9yGRTVxlmStbde7E8O+e+8xgs=; b=oYwL/M7dmo2I+ODl9aql5V2GAe90EJDqfkdpD6BsgEY/Nv2LGhHS42dDPXj6iYw69X doyix0My7Uikm7W0Gewq2i7F8foZQKbnXa3QMV4Ogfnasge0TDZyIhzix3/Vk3DcssEW lF75JY5jpCc7/d7x/Q0OFvjWf2ZZhgsWRA7QqONwgyySg8ykD7Nhg2x4vB4KyI9silnl sioCkjwh+zHcyEELi5fKK7V3zm9sSFkcyC8so2eY77NX3YPBh22iqfDS7aOjFDLh4hm3 sbVO2wrGnQ2kTXR5ROHh+INXzU31HDJW70k6arrwwlVrJf61jrbrwlPsCyTIJ07gXGlI 98ow== X-Received: by 10.50.151.179 with SMTP id ur19mr13334062igb.79.1363128809007; Tue, 12 Mar 2013 15:53:29 -0700 (PDT) X-Received: by 10.50.151.179 with SMTP id ur19mr13334055igb.79.1363128808873; Tue, 12 Mar 2013 15:53:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 12 Mar 2013 15:52:58 -0700 (PDT) In-Reply-To: <636E709D-6919-4D18-BE76-3FC34BB3CC6C@ve7jtb.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC0A36@IMCMBX04.MITRE.ORG> <9E337D95-53AD-431D-A053-76F1F5EF7FAA@ve7jtb.com> <4E1F6AAD24975D4BA5B168042967394367500130@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B9D@IMCMBX04.MITRE.ORG> <636E709D-6919-4D18-BE76-3FC34BB3CC6C@ve7jtb.com> From: Brian Campbell Date: Tue, 12 Mar 2013 18:52:58 -0400 Message-ID: To: John Bradley Content-Type: multipart/alternative; boundary=e89a8f3b9ff56fcf2d04d7c22882 X-Gm-Message-State: ALoCoQlzEbZ8Y2haPOus0dBekc+qfSvKDRHzJVvJrPdDnmfQ58JcS7/aFTC+uzzcPuH4fsszfyRqdjWyXcZJHOrNR0CrJUlcNeq6C1O3aQcgauV6XpiJqofA1tG3Jsh5qBjNryQvNuM/ Cc: Richard Barnes , Mike Jones , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] RSASSA-PSS signature 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, 12 Mar 2013 22:53:31 -0000 --e89a8f3b9ff56fcf2d04d7c22882 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable RSA-OAEP is already included, no? http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4= .1But it is OPTIONAL while RSAES-PKCS1-V1_5 is REQUIRED. Wasn't that what was behind the statement/question about starting to encourage movement away from RSAES-PKCS1-v1_5 rather than encouraging its use? Or I did I miss the point there? On Tue, Mar 12, 2013 at 6:20 PM, John Bradley wrote: > RSA PKCS1-v1.5 is used for both signing and encryption as you are aware i= t > is an encryption/padding alg that is used with a hash function for > signature. > > The same argument you are making can be used to include RSA-OAEP. > > One of the reasons PKCS1 v1.5 padding is so popular is that it can be use= d > to wrap both a key and a hash where the alternative needs to padding als > and to be secure two keys. > I agree that it would be better in a perfect world. > > Nothing stops additional algorithms being defined. We have people using > the current padding who had strong opinions on that. > I have yet to see anyone want PSS/OAEP strongly other than as a matter of > principal (I have been one of them). > > If you feel strongly put forward a use case and propose adding them. > > John B. > > > On 2013-03-12, at 5:10 PM, "Peck, Michael A" wrote: > > My original message was not about encryption algorithms, it was about the > RSASSA-PSS signature algorithm, which is not in JWA at all (I also don=92= t > see it listed in Mike=92s spreadsheet). **** > > If you=92d like to bring up encryption algorithms too, RFC 3447 states:**= ** > Two encryption schemes are specified in this document: RSAES-OAEP and*= * > ** > RSAES-PKCS1-v1_5. RSAES-OAEP is recommended for new applications;**** > RSAES-PKCS1-v1_5 is included only for compatibility with existing**** > applications, and is not recommended for new applications.**** > > 10 years later, it may be appropriate to start encouraging movement away > from RSAES-PKCS1-v1_5 rather than further encouraging its use.**** > Should the CFRG be asked for an opinion?**** > > Mike**** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > *Sent:* Tuesday, March 12, 2013 4:12 PM > *To:* Richard Barnes; John Bradley > *Cc:* Peck, Michael A; jose@ietf.org > *Subject:* RE: [jose] RSASSA-PSS signature**** > ** ** > Your statement that there are no MTI algorithms is actually incorrect. > The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONAL) > algorithms, and indeed, as currently chartered, we are required to define > the set of MTI algorithms.**** > > The spreadsheet characterizing platform support for possible algorithms > that John referred to is attached. As you can see, RSA PKCS1-v1_5 is the > only ubiquitously implemented asymmetric encryption algorithm.**** > > -- Mike**** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org > ] *On Behalf Of *Richard Barnes > *Sent:* Tuesday, March 12, 2013 12:49 PM > *To:* John Bradley > *Cc:* Peck, Michael A; jose@ietf.org > *Subject:* Re: [jose] RSASSA-PSS signature**** > ** ** > Since we are not putting requirements on algorithms (i.e., there is no > MTI), there's no harm to having PSS in the algorithms list. Only benefit= ! > **** > --Richard**** > ** ** > ** ** > On Tue, Mar 12, 2013 at 3:24 PM, John Bradley wrote:*= * > ** > This has had a fair amount of discussion. While I think almost everyone > would prefer PSS, many implementations are going to be in scripting > languages where the underlying libraries only support PKCS1-v1_5.**** > ** ** > We did a survey of platforms to evaluate if we could move to PSS and the > result lead us not to make PSS as the MTI. In think that was reported ou= t > at the Atlanta IETF meeting.**** > Nat may be able to forward that to you, I don't have it handy.**** > ** ** > If we were talking about starting from scratch and not building on > existing platforms likely the answer would have been different.**** > ** ** > The algorithms are extensible so PSS can be added. The other > consideration is that many of the people who care will be using ECESA > signatures anyway.**** > ** ** > John B.**** > ** ** > On 2013-03-12, at 2:52 PM, "Peck, Michael A" wrote:**** > ** ** > > draft-ietf-jose-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 > signatures but not RSASSA-PSS.**** > **** > The Security Considerations states:**** > While Section 8 of RFC 3447 [RFC3447] explicitly calls for people not*= * > ** > to adopt RSASSA-PKCS1 for new applications and instead requests that**= * > * > people transition to RSASSA-PSS, this specification does include**** > RSASSA-PKCS1, for interoperability reasons, because it commonly**** > implemented.**** > **** > Shouldn=92t RSASSA-PSS at least be included as an option?**** > I=92m also not sure if I fully understand the interoperability concerns. > JWS is a new specification, so it makes sense to me to use whatever > algorithms are currently considered best practice, without need to worry > about backwards compatibility?**** > **** > Mike**** > **** > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8f3b9ff56fcf2d04d7c22882 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
RSA-OAEP is already included, no?=A0 http:/= /tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.1= But it is OPTIONAL while RSAES-PKCS1-V1_5 is REQUIRED. Wasn't that wha= t was behind the statement/question about starting to encourage movement aw= ay from RSAES-PKCS1-v1_5 rather than encouraging its use? Or I did I miss t= he point there?





On Tue, Mar 12, 2013 at 6:20 PM, John Bradley <ve7jtb@ve7jtb.com&= gt; wrote:
RSA PKCS= 1-v1.5 is used for both signing and encryption as you are aware it is an en= cryption/padding alg that is used with a hash function for signature.

The same argument you are making can be used to include RSA-= OAEP.

One of the reasons PKCS1 v1.5 padding is so = popular is that it can be used to wrap both a key and a hash where the alte= rnative needs to padding als and to be secure two keys.
I agree that it would be better in a perfect world.

=
Nothing stops additional algorithms being defined. =A0 We have people = using the current padding who had strong opinions on that. =A0
I = have yet to see anyone want PSS/OAEP strongly other than as a matter of pri= ncipal (I have been one of them).

If you feel strongly put forward a use case and propose= adding them.

John B.
=


On 2013-03-12, at 5:10 PM, "Peck, Mi= chael A" <mpec= k@mitre.org> wrote:

My original message was not about encry= ption algorithms, it was about the RSASSA-PSS signature algorithm, which is= not in JWA at all (I also don=92t see it listed in Mike=92s spreadsheet).= =A0
=A0
If you=92d like to bring up encryption algorithms too, RFC 3447 sta= tes:
=A0=A0 Two= encryption schemes are specified in this document: RSAES-OAEP and
=A0=A0 RSA= ES-PKCS1-v1_5.=A0 RSAES-OAEP is recommended for new applications;=
=A0=A0 RSA= ES-PKCS1-v1_5 is included only for compatibility with existing
=A0=A0 app= lications, and is not recommended for new applications.
=A0
10 years later, it m= ay be appropriate to start encouraging movement away from RSAES-PKCS1-v1_5 = rather than further encouraging its use.
Should the CFRG be asked for an opinion?<= /u>
=A0
Mike
=A0=
From:=A0Mike Jones [mailto:Michael.Jones@microsoft.com]=A0
Sent:=A0Tuesday, March 12, 2013 4:12 PM
To:=A0Richard Barnes; John Bradley
Cc:=A0Pec= k, Michael A; jose@ietf.= org
Subject:=A0RE: [jose] RSASSA-PSS signature
=A0
Your statement that there are no MTI algorithms is actually incorre= ct.=A0 The current JWA draft specifies REQUIRED (and RECOMMENED and OPTIONA= L) algorithms, and indeed, as currently chartered, we are required to defin= e the set of MTI algorithms.
=A0
The spreadsheet characterizing platform support for possible algori= thms that John referred to is attached.=A0 As you can see, RSA PKCS1-v1_5 i= s the only ubiquitously implemented asymmetric encryption algorithm.=
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
=A0
From:=A0jose-bounces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behalf O= f=A0Richard Barnes
Sent:=A0Tuesday, March 12, 2013 12:49 PM
To:<= span>=A0John Bradley
Cc:=A0Peck, Michael A;=A0jose@ietf.org
Subject:=A0Re: [jose] RSASSA-PSS signature
=A0
Since we are not putting requirements on algorithms (i.e., there is no MTI)= , there's no harm to having PSS in the algorithms list. =A0Only benefit= ! =A0
--Richard
=A0
=A0
On Tue, Mar 12, 2013 at = 3:24 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
This has had a fair amount of discussion. =A0 W= hile I think almost everyone would prefer PSS, many implementations are goi= ng to be in scripting languages where the underlying libraries only support= PKCS1-v1_5.
=A0
We did a survey of platforms to evaluate if we could move to PSS and the re= sult lead us not to make PSS as the MTI. =A0In think that was reported out = at the Atlanta IETF meeting.
Nat may be able to forward that to you, I don't have it handy.
=A0
If we were talking about starting from scratch and n= ot building on existing platforms likely the answer would have been differe= nt.
=A0
The algorithms are extensible so PSS can be added. =A0 The other considerat= ion is that many of the people who care will be using ECESA signatures anyw= ay.
=A0
John B.<= /u>
=A0
draft-ietf-jo= se-json-web-algorithms-08 includes RSASSA-PKCS1-v1_5 signatures but not RSA= SSA-PSS.
=A0=
The Security Considerations states:
=A0=A0 While Section 8 of RFC 3447 [RFC3447] explicitl= y calls for people not
=A0=A0 to adopt RSASSA-PKCS1 for new applications and = instead requests that
=A0=A0 people transition to RSASSA-PSS, this specifica= tion does include
=A0=A0 RSASSA-PKCS1, for interoperability reasons, bec= ause it commonly
=A0=A0 implemented.
=A0=
Shouldn=92t RSASSA-PSS at least be in= cluded as an option?
I=92m also not sure if I fully understand the interope= rability concerns.=A0 JWS is a new specification, so it makes sense to me t= o use whatever algorithms are currently considered best practice, without n= eed to worry about backwards compatibility?
=A0
Mike
=A0
_______________________________________________ jose mailing list
= jose@ietf.org
= https://www.ietf.org/mailman/listinfo/jose
=A0


_______________________________________________
jose mailing listjose@ietf.org
https://www.ietf.org/mailman/listinfo/jose=

=


__________________= _____________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8f3b9ff56fcf2d04d7c22882-- From dick.hardt@gmail.com Tue Mar 12 15:57:10 2013 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 B1E3811E80F0 for ; Tue, 12 Mar 2013 15:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=0.755, 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 ggzhZEZmhjyY for ; Tue, 12 Mar 2013 15:57:09 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6C111E80E8 for ; Tue, 12 Mar 2013 15:57:09 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so355669pbc.15 for ; Tue, 12 Mar 2013 15:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=4nEySmBVzPWF8X+UjzMfetIswg8tknbKHskS1znabtY=; b=FsVImp62Vq5hqtyDStR9/ydFYX65EX9zZJ5QZI7F0tLB4uZaXbjLNVvL+CB0xD2bTn nq0rR6uXWhQH2W/LEsIHMiFGVfJvbl5UaihwkoJF9q4LR3hxTrMiiEmS7e4I79rPFBbF RRA1+xHPvAo1NQG1LwNZ3NPpGDYVd4w8KPK2a6Sbd8zgXdSl7xDQ3IocVdYXqoHMzDPn FIUiFJtkAMR7h5H7mdIcjL5XdT1JhbDVEHYcdKUOhm8rtIbblxaY6J4sm86Fujfxj/ot eHfM0pML7ICArqjS/kwRU8qWvLUpNaI13zffDsCpkwYQfL4oNAqP05kutstseJ+njzU1 cqGQ== X-Received: by 10.68.129.163 with SMTP id nx3mr41336174pbb.13.1363129028921; Tue, 12 Mar 2013 15:57:08 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id kl4sm26814821pbc.31.2013.03.12.15.57.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 15:57:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_896F9C7A-A3C1-4A39-8EE4-C40968D42BC6" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Tue, 12 Mar 2013 15:57:01 -0700 Message-Id: References: To: Richard Barnes X-Mailer: Apple Mail (2.1499) Cc: Anthony Nadalin , Karen O'Donoghue , Jim Schaad , Mike Jones , Tim Bray , jose , John Bradley , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 22:57:10 -0000 --Apple-Mail=_896F9C7A-A3C1-4A39-8EE4-C40968D42BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Richard I know enough about crypto to follow the directions in the spec and get = something that interoperates with other implementations. i.e., I don't = know if your statement below is what I am actually looking for. Here is the protocol: 1) Alice gives Bob a JWE where Charlie, Dennis or Eric may be the = audience 2) Bob knows how to talk to Charlie but not Dennis or Eric, so Bob gives = the JWE to Charlie 3) Charlie needs to be able to look at the JWE and see who the audience = is to determine if he can process it, or if he needs to hand it to = Dennis or Eric. In JWE, the only plaintext metadata that is available is the JWE header, = so I would like an audience signal there, as it enables a token = recipient to know if they are the recipient or not. Currently a = recipient can guess they are not if the KID is not understood, but that = does not help signal who will understand, and also does assist = developers in detecting they have an old key vs signed for the wrong = recipient. I don't want to add another plaintext field. In my implementation = (assuming I did it correctly) the header has integrity protection. -- Dick On Mar 12, 2013, at 3:29 PM, Richard Barnes wrote: > Hi Dick, >=20 > If I understand your use case correctly, what you're actually looking = for is a way to populate the "additional data" that's protected under = the AEAD algorithm. Unfortunately, under current JWE, that's conflated = with the header. I think the correct resolution to this problem is to = remove the JWE header from the integrity check, and add a separate field = to JWE for additional data. >=20 > --Richard >=20 >=20 >=20 > On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt = wrote: > Agreed. >=20 > In an implementation I am working on, I need an audience signal in a = JWE so that recipients of the JWE token know who can decrypt and process = it. >=20 > While on that topic, it seems that I can't have 'aud' in the header, = so I would need to have a URI for that property such as = 'aud.example.com' >=20 > btw: per Richard's comment, the code to use app specific payload data = is pretty ugly with >=20 > jwt.['prop.example.com'] >=20 > but I put all the app properties in the one object so I do >=20 > jwt.['prop.example.com'].prop1 >=20 > -- Dick >=20 >=20 >=20 > On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin = wrote: > oh great now you are going to tell us what is crypto related and what = is not, that is pretty much n application call not a spec call > =20 > Sent from Windows Mail > =20 > From: Mike Jones > Sent: March 12, 2013 7:02 AM >=20 > To: Jim Schaad, Richard Barnes > CC: John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose >=20 > Subject: Re: [jose] Proposed resolution of header criticality issue > =20 > +1 to only putting crypto-related things in the headers. > =20 > From: Richard Barnes > Sent: March 12, 2013 6:53 AM >=20 > To: Jim Schaad > CC: John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen = O'Donoghue > Subject: Re: [jose] Proposed resolution of header criticality issue > =20 > Note that my proposed text did not say that the libraries would not = return header stuff, only that you shouldn't cram non-crypto-related = things in there.=20 >=20 >=20 >=20 > On Tuesday, March 12, 2013, Jim Schaad wrote: > I am not truly happy with this idea. If the application cares about = who =93owns=94 a key for a signature then it needs to somehow get that = information. That may be done by getting the way and key from the = security library and that may be done by just returning the claims from = the envelope. >=20 > =20 >=20 > Jim >=20 > =20 >=20 > =20 >=20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley > Sent: Tuesday, March 12, 2013 9:15 AM > To: Mike Jones > Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue > Subject: Re: [jose] Proposed resolution of header criticality issue >=20 > =20 >=20 > I am OK with getting rid of it if we make it clear that claims from = the envelope will not be passed on to applications. >=20 > =20 >=20 > If we don't do that we will compromise interoperability between = libraries. Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body = in some way. >=20 > =20 >=20 > I just want it one way or the other. >=20 > =20 >=20 > John B. >=20 > =20 >=20 > =20 >=20 > On 2013-03-12, at 9:06 AM, Mike Jones = wrote: >=20 >=20 >=20 >=20 > I=92m with Richard on this. The application-specific-data/meta field = isn=92t needed. >=20 > =20 >=20 > -- Mike >=20 > =20 >=20 > From: Richard Barnes > Sent: March 11, 2013 10:02 PM > To: John Bradley > CC: Tim Bray, Manger, James H, Karen ODonoghue, jose > Subject: Re: [jose] Proposed resolution of header criticality issue >=20 > =20 >=20 > +1 to cheers. I already high-fived Mike in person. >=20 > =20 >=20 > FWIW, my preference would be to get rid of "asd" or "meta" (part 5). = I don't think it's relevant to the criticality discussion, and it's just = not needed. =20 >=20 > =20 >=20 > --Richard >=20 > =20 >=20 > =20 >=20 > On Mon, Mar 11, 2013 at 11:01 PM, John Bradley = wrote: >=20 > =20 >=20 > On 2013-03-11, at 10:48 PM, "Manger, James H" = wrote: >=20 > =20 >=20 > I=92ll add some cheers =97 this does look like substant >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 >=20 >=20 > --=20 > -- Dick >=20 --Apple-Mail=_896F9C7A-A3C1-4A39-8EE4-C40968D42BC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Richard

I know enough about crypto to follow the = directions in the spec and get something that interoperates with other = implementations. i.e., I don't know if your statement below is what I am = actually looking for.

Here is the = protocol:

1) Alice gives Bob a JWE where = Charlie, Dennis or Eric may be the audience

2) = Bob knows how to talk to Charlie but not Dennis or Eric, so Bob gives = the JWE to Charlie

3) Charlie needs to be able = to look at the JWE and see who the audience is to determine if he can = process it, or if he needs to hand it to Dennis or = Eric.

In JWE, the only plaintext metadata that = is available is the JWE header, so I would like an audience signal = there, as it enables a token recipient to know if they are the recipient = or not. Currently a recipient can guess they are not if the KID is not = understood, but that does not help signal who will understand, and also = does assist developers in detecting they have an old key vs signed for = the wrong recipient.

I don't want to add = another plaintext field. In my implementation (assuming I did it = correctly) the header has integrity = protection.

-- = Dick


On Mar 12, 2013, at 3:29 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

Hi Dick,

If I understand your use case = correctly, what you're actually looking for is a way to populate the = "additional data" that's protected under the AEAD algorithm. =  Unfortunately, under current JWE, that's conflated with the = header.  I think the correct resolution to this problem is to = remove the JWE header from the integrity check, and add a separate field = to JWE for additional data.

--Richard



On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Agreed.

In an implementation I am working = on, I need an audience signal in a JWE so that recipients of the JWE = token know who can decrypt and process it.

While on that topic, it seems that I can't have 'aud' in the header, so = I would need to have a URI for that property such as 'aud.example.com'

btw: per Richard's comment, the code to use app specific payload = data is pretty ugly with


but I put all the app properties in the one object so I = do

jwt.['prop.example.com'].prop1

-- Dick



On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
oh great now you are going to tell us what is crypto related and = what is not, that is pretty much n application call not a spec = call
 
Sent from Windows Mail
 
From: Mike Jones
Sent: March 12, 2013 7:02 AM

To: Jim Schaad, Richard Barnes
CC: John Bradley, Tim Bray, James H Manger, Karen = O'Donoghue, jose

Subject: Re: [jose] Proposed resolution of header = criticality issue
 
+1 to only putting crypto-related things in the headers.
 
From: Richard Barnes
Sent: March 12, 2013 6:53 AM

To: Jim Schaad
CC: John Bradley, Mike Jones, James H Manger, Tim = Bray, jose, Karen O'Donoghue
Subject: Re: [jose] Proposed resolution of header = criticality issue
 
Note that my proposed text did not say that the libraries would not = return header stuff, only that you shouldn't cram non-crypto-related = things in there. 



On Tuesday, March 12, 2013, Jim Schaad wrote:

I am not truly happy with this idea.  If = the application cares about who =93owns=94 a key for a signature then it = needs to somehow get that information.  That may be done by getting the way and key from the security library = and that may be done by just returning the claims from the = envelope.

 

Jim

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen = O'Donoghue
Subject: Re: [jose] Proposed resolution of header criticality = issue

 

I am OK with getting rid of it if we = make it clear that claims from the envelope will not be passed on to = applications.

 

If we don't do that we will compromise interoperability between = libraries.   Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body in some way.

 

I just want it one way or the other.

 

John B.

 

 

On 2013-03-12, at 9:06 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:



I=92m = with Richard on this.  The application-specific-data/meta = field isn=92t needed.

 =

-- = Mike

 =

From: Ric= hard Barnes
Sent: March 11, 2013 10:02 PM
To: John Bradley
CC: Tim Bray, Manger, James H, Karen ODonoghue, jose
Subject:<= /span> Re: [jose] Proposed resolution of header = criticality issue

 =

+1 to = cheers.  I already high-fived Mike in person.

&n= bsp;

FWIW, = my preference would be to get rid of "asd" or "meta" (part 5).  I = don't think it's relevant to the criticality discussion, and it's just = not needed.  

&n= bsp;

--Richard=

&n= bsp;

&n= bsp;

On Mon, = Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

&n= bsp;

On = 2013-03-11, at 10:48 PM, "Manger, James H" = <James.H.Manger@team.telstra.com> = wrote:

&n= bsp;

I=92ll add some cheers =97 this does look = like substant


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose




--
-- Dick


= --Apple-Mail=_896F9C7A-A3C1-4A39-8EE4-C40968D42BC6-- From watsonm@netflix.com Tue Mar 12 15:58:57 2013 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 3AE8711E8124 for ; Tue, 12 Mar 2013 15:58:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 14N6t1i-bMg3 for ; Tue, 12 Mar 2013 15:58:55 -0700 (PDT) Received: from exout104.netflix.com (exout104.netflix.com [69.53.237.163]) by ietfa.amsl.com (Postfix) with ESMTP id B65B911E8127 for ; Tue, 12 Mar 2013 15:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; bh=4LyL5xJ9qXdSeM1KZUW9RiGiqM8=; b=MgZiFmKXMu/lMKp5aa/Apa1wqsk4cC2FWn9hCtCThUFCxXqsWe3XTGUbk/k2rXcNl68Q2Lq+ obXZuKc2/1OrSLwDSkehtZBpBnk9w0Z1aAW8JYAd4gIE0cS9cIAYGpCddEb/RB1Hi+N/ZwMt LK6R0ae8qPHEnFePghvzCNqIJni6gGcpVZXBQqvKIL2dNKkNFsPi7O6BN54EnbCA8gpXgMdd 5u3q7vnwysIy2MtgphMQZS17pHDF6/J0P4ffQED+zGGRAzgg/xr+puFoRLLfil1KXpjjhd60 gY31+YYUWV6gE+ofcLSZe+zhzxfwGvb/TRJXpgnoQBlGTJnLLaj8/Q== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; b=J5fzhwfNwQn7bNsdsi6hjU0VTRpMu1+zVapmCkJ7lB+xRnAO9fUUSYERaImKhghnEmxPgR+y XV4Ze77AUNRL3NbdeKZs75XNr3zXmwqaQRRjP9sOT9385IwP/tsiiiYdl0eYXe8acJOg7Xtm Z3mtocl5hSgNUHQVmAFuWSVTE7otzE71kOobkwpLMQNnfpAS6+Nm9V9QaHC5bRvQhv0b0sSO T1YvJ/eiacATOt7O+qRBTGc7c8vzuaY47akHv/xgrr2dWrYy1LPjsBoH45AO0LmmZkR6lkjd E5kxwGiN62E9MHZJj/OmCIdb/qpYDJDx7uBxihFgZov0CM48HixR7Q== Received: from EXFE103.corp.netflix.com (10.64.32.103) by exout104.netflix.com (10.64.240.74) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 12 Mar 2013 15:58:49 -0700 Received: from EXMB106.corp.netflix.com ([169.254.6.135]) by exfe103.corp.netflix.com ([10.64.32.103]) with mapi id 14.02.0283.003; Tue, 12 Mar 2013 15:58:54 -0700 From: Mark Watson To: Richard Barnes Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: AQHOHCzC1ChjIIhtSkaPN+ZxIgTDipict+CAgAK/VwCAAAd1gIAABnUAgABC8ICAAggNgIABV4QA Date: Tue, 12 Mar 2013 22:58:54 +0000 Message-ID: <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.26.2] Content-Type: multipart/alternative; boundary="_000_0B984978DAB040499E3675FD43D24384netflixcom_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 12 Mar 2013 22:58:57 -0000 --_000_0B984978DAB040499E3675FD43D24384netflixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Richard, Regarding the proposal for a binary-optimized JSON encoding, isn't this a b= it orthogonal to the problem at hand ? I understand that this is one area where such a thing would be useful, but = there have been various attempts to define such things in the past (BSON, u= bjson, =85). A big advantage of JSON is that the data is self-describing, i= n terms of types: you don't need any external "document type definition" or= "schema" to decode and manipulate a JSON object. If you are going to specify something like this, I'd suggest at least inclu= de the member names that have been moved to the binary segment somewhere. S= o then a decoder can undo the translation and give back a regular JSON obje= ct with base64-encoded members, without access to this side-information. But I would ask if this trouble is really worth it for the 25% space saving= ? =85Mark On Mar 11, 2013, at 7:30 PM, Manger, James H wrote: =93A Unified Theory of JOSE Keys=94 looks quite good. It looks like a key is a JSON object with any number of name/value pairs. F= or some names, the value is a base64[url]-encoding of binary data. To wrap a key, its name/value pairs are divided into 3 groups: 1. non-confidential name/value pairs 2. confidential non-binary name/value pairs 3. confidential binary name/value pairs The first group are put into the =93kat=94 (key attributes?) field of the o= utput. The second group =97 if its not empty =97 becomes the first binary segment = of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the out= put indicates the second group is present. The third group (in order) become subsequent binary segments of the plainte= xt. The names in the third group (and their order) is determined by the typ= e of the key being wrapped (=93kty=94 attribute). The plaintext is wrapped (encrypted), then base64url-encoded to give the = =93wk=94 attribute in the output. Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat=94. I= assume this is a typo. =93kat=94 would include =93n=94 and =93e=94, but = =93d=94 (the private exponent) would always be encrypted and hence be insid= e =93wk=94. Q2. Does key wrapping give integrity protection that you might want for nam= e/value pairs even when they are not confidential. For instance, could it b= e useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat= =94? Do recipients need to check both the first binary segment and =93kat= =94 when looking for any attribute not explicitly listed in the =93encoding= rules=94? Does the first binary segment take precedence over =93kat=94? Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples show = it as a top-level attribute instead. A4. The symmetric key examples don=92t include a key type (=93kty=94). Is i= t implied by something at a higher level (eg a JWE), or is there a default = value meaning =93a shared symmetric secret, with no specific associated cry= pto algorithm=94? Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be be= tter for encoding the length of binary segments. 2 bytes (64 KB max) might = be too small, particularly if the binary encoding is used for all JOSE mess= ages (eg JWE) not just keys. -- James Manger From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, 11 March 2013 6:29 AM To: Mike Jones Cc: Leif Johansson; jose@ietf.org Subject: Re: [jose] A Unified Theory of JOSE Keys So it seems to me that the group has three questions to answer when it come= s to wrapped keys: Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes? Answer 1.A: JWE Answer 1.B: Key wrap, derived from JWE Q2(Packing): How should the wrapped key+attributes be expressed? Answer 2.A: JSON format (not packed) Answer 2.B: JSON, with binary parts expressed directly JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in my Un= ified Theory is 1.B / 2.B. For context, I'm working from a few principles here: -- We should not define multiple ways to wrap symmetric keys -- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS) -- We should choose encodings that minimize the size overhead imposed by th= e encoding If we agree on these principles, then the answers to the above questions se= em pretty clear. It seems to me that Steve's point on Question 1 pretty much decides the que= stion for B. If we want systems using JOSE to have any hope of getting acc= reditation (e.g., under FIPS), then they will have to use standard mechanis= ms for protecting keys, even if those keys are packaged with other attribu= tes. Mike's message misses the point that the key wrap algorithm isn't act= ually being used to protect the key itself -- for that you would use a norm= al, content-oriented encryption algorithm, in contravention of the FIPS req= uirements. Question 2 is mostly a question of backward compatibility and efficiency. = If we want to have any hope of being backward-compatible with JWE key wrapp= ing -- that is, avoiding having two ways to do the same thing -- then we ne= ed a way to handle the octets of a key directly, as opposed to base64-encod= ed within a JSON object. That would be option 2.B. There are also compactness arguments for 1.B and 2.B. If you do 1.A, then = in addition to the header, you have to carry a separate CMK, IV, and MAC va= lue. If you're using AES-GCM with a 128-bit key, that's a total of 44 octe= ts (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key wrap, the = wrapping algorithm adds a maximum of 16 octets to the object. The differen= ce in case 2 is even greater, because you're talking about double-base64 en= coding, which entails a penalty of 30% of the payload. If you're protectin= g an AES key, this might only be a few octets, but if you're protecting a 2= 048-bit RSA key, then you're talking hundreds of octets. So if you care ab= out compactness, 1.B and 2.B make a lot more sense. To respond to Mike's specific points: I=92ll note that in JSON Web Encryption, we are already using standard meth= ods for encrypting key values for the Content Master Key =96 specifically A= ES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agr= eement). However, the actual key you're wrapping is still protected with a content-o= riented algorithm. So you're still violating the FIPS requirements. What we=92re talking about here, however, is encrypting potentially more th= an just key values =96 in this case, key values with associated key use inf= ormation, algorithm information, key ID information, and potentially other = attributes. As such, using the JWK JSON representation of this information= as the payload of a standard JWE encryption seems like the obvious solutio= n, which doesn=92t require inventing anything we don=92t already have. Absolutely agree that JSON is the right representation. But the key is sti= ll included in that representation, so you need to apply key wrapping algor= ithms to it. And, as discussed above, it's a lot more efficient if you pac= k the JSON so that the binary isn't double-encoded. draft-miller-jose-jwe-protected-jwk already describes doing that. I believ= e that we should adopt this as a working group document as soon as the rech= artering is complete. That draft has some excellent suggestions for password-based key wrapping. = We should incorporate that into whatever solution we come up with. But fo= r the reasons discussed above, it's wrong in using JWK for the encapsulatio= n. I also disagree that we need a separate document for this. If we're going = to avoid having two ways to wrap keys, this needs to be part of JWE/JWK. --Richard -- Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_0B984978DAB040499E3675FD43D24384netflixcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <252DD5CDE3C96E468E2935E7C2051C24@netflix.com> Content-Transfer-Encoding: quoted-printable Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't thi= s a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful,= but there have been various attempts to define such things in the past (BS= ON, ubjson, =85). A big advantage of JSON is that the data is self-describi= ng, in terms of types: you don't need any external "document type definition" or "schema" to= decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at least = include the member names that have been moved to the binary segment somewhe= re. So then a decoder can undo the translation and give back a regular JSON= object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space s= aving ?

=85Mark


On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

=93A Unified Theory of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.
 
It looks like a key is a JSON object with any number of n= ame/value pairs. For some names, the value is a base64[url]-encoding of bin= ary data.
 
To wrap a key, its name/value pairs are divided into 3 gr= oups:
1.       non-confidential name/value pairs
2.       confidential non-binary name/value pairs
3.       confidential binary name/value pairs
 
The first group are put into the =93kat=94 (key attribute= s?) field of the output.
 
The second group =97 if its not empty =97 becomes the fir= st binary segment of the plaintext (as a UTF-8-encoded JSON object). =93wj= =94:true in the output indicates the second group is present.
 
The third group (in order) become subsequent binary segme= nts of the plaintext. The names in the third group (and their order) is det= ermined by the type of the key being wrapped (=93kty=94 attribute).
 
The plaintext is wrapped (encrypted), then base64url-enco= ded to give the =93wk=94 attribute in the output.
 
 
Q1. The examples of wrapping an RSA key include =93d=94:= =85 in =93kat=94. I assume this is a typo. =93kat=94 would include =93n=94 = and =93e=94, but =93d=94 (the private exponent) would always be encrypted and hence be inside =93wk=94.
 
Q2. Does key wrapping give integrity protection that you = might want for name/value pairs even when they are not confidential. For in= stance, could it be useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? Do recipients ne= ed to check both the first binary segment and =93kat=94 when looking for an= y attribute not explicitly listed in the =93encoding rules=94? Does the fir= st binary segment take precedence over =93kat=94?
 
Q3. Should =93kty=94 (key type) appear within =93kat=94? = The examples show it as a top-level attribute instead.
 
A4. The symmetric key examples don=92t include a key type= (=93kty=94). Is it implied by something at a higher level (eg a JWE), or i= s there a default value meaning =93a shared symmetric secret, with no specific associated crypto algorithm=94?
 
Q5. Using a VARINT (variable-length integer) instead of 2= bytes would be better for encoding the length of binary segments. 2 bytes = (64 KB max) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just key= s.
 
 
--
James Manger
 
From:&nbs= p;jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Ba= rnes
Sent: Monday, 11 M= arch 2013 6:29 AM
To: Mike Jones
Cc: Leif Johansson= ; jose@ietf.org=
Subject: Re: [jose= ] A Unified Theory of JOSE Keys
 
So it seems to me that the group has three questions to answer when it come= s to wrapped keys:
 
Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes?  
    Answer 1.A: JWE
    Answer 1.B: Key wrap, derived from JWE
 
Q2(Packing): How should the wrapped key+attributes be expressed?
    Answer 2.A: JSON format (not packed)
    Answer 2.B: JSON, with binary parts expressed directly <= o:p>
 
JWE-within-JWK represents answer 1.A / 2.A.  The solution proposed in = my Unified Theory is 1.B / 2.B.  
 
For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys
-- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by th= e encoding
If we agree on these principles, then the answers to the above questions se= em pretty clear.
 
It seems to me that Steve's point on Question 1 pretty much decides the que= stion for B.  If we want systems using JOSE to have any hope of gettin= g accreditation (e.g., under FIPS), then they will have to use standard mec= hanisms for protecting keys, even if those keys are  packaged with other attributes.  Mike's message = misses the point that the key wrap algorithm isn't actually being used to p= rotect the key itself -- for that you would use a normal, content-oriented = encryption algorithm, in contravention of the FIPS requirements.
 
Question 2 is mostly a question of backward compatibility and efficiency. &= nbsp;If we want to have any hope of being backward-compatible with JWE key = wrapping -- that is, avoiding having two ways to do the same thing -- then = we need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object.  T= hat would be option 2.B.
 
There are also compactness arguments for 1.B and 2.B.  If you do 1.A, = then in addition to the header, you have to carry a separate CMK, IV, and M= AC value.  If you're using AES-GCM with a 128-bit key, that's a total = of 44 octets (16 CMK, 16 MAC, 12 IV).  In contrast, if you just do AES key wrap, the wrapping algorithm adds a maxim= um of 16 octets to the object.  The difference in case 2 is even great= er, because you're talking about double-base64 encoding, which entails a pe= nalty of 30% of the payload.  If you're protecting an AES key, this might only be a few octets, but if you're prot= ecting a 2048-bit RSA key, then you're talking hundreds of octets.  So= if you care about compactness, 1.B and 2.B make a lot more sense.
 
To respond to Mike's specific points:
 
I=92ll note that in JSON Web Encryption, w= e are already using standard methods for encrypting key values for the Cont= ent Master Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement= ).
 
However, the actual key you're wrapping is still protected with a content-o= riented algorithm.  So you're still violating the FIPS requirements.
 
 
What we=92re talking about here, however, = is encrypting potentially more than just key values =96 in this case, key v= alues with associated key use information, algorithm information, key ID information, and potentially other attribute= s.  As such, using the JWK JSON representation of this information as = the payload of a standard JWE encryption seems like the obvious solution, w= hich doesn=92t require inventing anything we don=92t already have.
 
Absolutely agree that JSON is the right representation.  But the key i= s still included in that representation, so you need to apply key wrapping = algorithms to it.  And, as discussed above, it's a lot more efficient = if you pack the JSON so that the binary isn't double-encoded.
  
draft-miller-jose-jwe-protected-jwk alread= y describes doing that.  I believe that we should adopt this as a work= ing group document as soon as the rechartering is complete.
 
That draft has some excellent suggestions for password-based key wrapping. =  We should incorporate that into whatever solution we come up with. &n= bsp;But for the reasons discussed above, it's wrong in using JWK for the en= capsulation.
 
I also disagree that we need a separate document for this.  If we're g= oing to avoid having two ways to wrap keys, this needs to be part of JWE/JW= K.
 
--Richard
 
       =             &nb= sp;            =             &nb= sp;            =    -- Mike
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= /a>

--_000_0B984978DAB040499E3675FD43D24384netflixcom_-- From ve7jtb@ve7jtb.com Tue Mar 12 16:13:26 2013 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 D772111E80E1 for ; Tue, 12 Mar 2013 16:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=0.446, 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 d810OlAjzY-W for ; Tue, 12 Mar 2013 16:13:24 -0700 (PDT) Received: from mail-gh0-f176.google.com (mail-gh0-f176.google.com [209.85.160.176]) by ietfa.amsl.com (Postfix) with ESMTP id 94C2B21F8CD4 for ; Tue, 12 Mar 2013 16:13:24 -0700 (PDT) Received: by mail-gh0-f176.google.com with SMTP id f16so88851ghb.7 for ; Tue, 12 Mar 2013 16:13:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=3rxNvjoqTLuKNc3kFN6q1rEkym8U2oXyCNkm4UYpJMA=; b=eBMRmAUy7i/FHljQe7pfaCYt3fRQjV71eFAF1xDq9WtJ6wD6cDTdG8t3EOW8ShxmD3 Zx1MIjk2IgIkOc6Mvvwr31VEhShZd6Dbod4nKjgGbpBmtNznI2+TzKFOl9czvQQtT17R UFIKMYu6eerhvKuOL+kH7nvVbJemQcbmdQ0gZb2aPX/H66WoNohqPSgcFABJV9fz28Ru P/mH8n1fvdtk1eJdQf0N63vc4uH9J23e0XMM09zo9Ll+76Jc3OhLMZSBOmTo3jeM+rdb dRnTV6kCRkQUVHX3Q/sEE4LuW6jb5bJFPuYIcNDb6RJuYCboKuMyPSus6AgMzDt5L7kh BIGQ== X-Received: by 10.236.121.42 with SMTP id q30mr14069473yhh.24.1363130003867; Tue, 12 Mar 2013 16:13:23 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id y3sm1118793yha.11.2013.03.12.16.13.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 16:13:21 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_11FBCA84-F57C-4EF3-82AF-10DDF1BAD356"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Tue, 12 Mar 2013 19:13:18 -0400 Message-Id: References: To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnyUwDXGolyMWClOKFRIbyT7MdmIb2cNP2y6JlCqojUD7E/aYBRf4o5t8K3hSSbx4Wr6taI Cc: Anthony Nadalin , Karen O'Donoghue , Richard Barnes , Jim Schaad , Mike Jones , Tim Bray , jose , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 23:13:27 -0000 --Apple-Mail=_11FBCA84-F57C-4EF3-82AF-10DDF1BAD356 Content-Type: multipart/alternative; boundary="Apple-Mail=_52833F5F-DAA4-4078-8370-915EF6BB973D" --Apple-Mail=_52833F5F-DAA4-4078-8370-915EF6BB973D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Currently the header has integrity protection. The proposed changes to the spec allow what you are doing. The thing = is that a standard JWE library is not going to know about your = forwarding rules.=20 My proposal was to add a containing element for all the additional = claims intended for processing outside of the JWE/JWS crypto library. That reduces namespace collision and allows the library to pass back to = the application any claims in the header that are not intended for = JWEJWS. The three alternatives are: 1 preclude non JWE/S claims in the header (won't work for you) 2 a dedicated JSON member that contains claims intended for applications = or external extensions 3 throw in everything as a top level claim and have applications sniff = the header looking for what they need. The proposal going to the meeting tomorrow is 2 based on it being the = cleanest way to pass on the additional claims to applications using a = general purpose JOSE lib. John B. On 2013-03-12, at 6:57 PM, Dick Hardt wrote: > Hi Richard >=20 > I know enough about crypto to follow the directions in the spec and = get something that interoperates with other implementations. i.e., I = don't know if your statement below is what I am actually looking for. >=20 > Here is the protocol: >=20 > 1) Alice gives Bob a JWE where Charlie, Dennis or Eric may be the = audience >=20 > 2) Bob knows how to talk to Charlie but not Dennis or Eric, so Bob = gives the JWE to Charlie >=20 > 3) Charlie needs to be able to look at the JWE and see who the = audience is to determine if he can process it, or if he needs to hand it = to Dennis or Eric. >=20 > In JWE, the only plaintext metadata that is available is the JWE = header, so I would like an audience signal there, as it enables a token = recipient to know if they are the recipient or not. Currently a = recipient can guess they are not if the KID is not understood, but that = does not help signal who will understand, and also does assist = developers in detecting they have an old key vs signed for the wrong = recipient. >=20 > I don't want to add another plaintext field. In my implementation = (assuming I did it correctly) the header has integrity protection. >=20 > -- Dick >=20 >=20 > On Mar 12, 2013, at 3:29 PM, Richard Barnes wrote: >=20 >> Hi Dick, >>=20 >> If I understand your use case correctly, what you're actually looking = for is a way to populate the "additional data" that's protected under = the AEAD algorithm. Unfortunately, under current JWE, that's conflated = with the header. I think the correct resolution to this problem is to = remove the JWE header from the integrity check, and add a separate field = to JWE for additional data. >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt = wrote: >> Agreed. >>=20 >> In an implementation I am working on, I need an audience signal in a = JWE so that recipients of the JWE token know who can decrypt and process = it. >>=20 >> While on that topic, it seems that I can't have 'aud' in the header, = so I would need to have a URI for that property such as = 'aud.example.com' >>=20 >> btw: per Richard's comment, the code to use app specific payload data = is pretty ugly with >>=20 >> jwt.['prop.example.com'] >>=20 >> but I put all the app properties in the one object so I do >>=20 >> jwt.['prop.example.com'].prop1 >>=20 >> -- Dick >>=20 >>=20 >>=20 >> On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin = wrote: >> oh great now you are going to tell us what is crypto related and what = is not, that is pretty much n application call not a spec call >> =20 >> Sent from Windows Mail >> =20 >> From: Mike Jones >> Sent: March 12, 2013 7:02 AM >>=20 >> To: Jim Schaad, Richard Barnes >> CC: John Bradley, Tim Bray, James H Manger, Karen O'Donoghue, jose >>=20 >> Subject: Re: [jose] Proposed resolution of header criticality issue >> =20 >> +1 to only putting crypto-related things in the headers. >> =20 >> From: Richard Barnes >> Sent: March 12, 2013 6:53 AM >>=20 >> To: Jim Schaad >> CC: John Bradley, Mike Jones, James H Manger, Tim Bray, jose, Karen = O'Donoghue >> Subject: Re: [jose] Proposed resolution of header criticality issue >> =20 >> Note that my proposed text did not say that the libraries would not = return header stuff, only that you shouldn't cram non-crypto-related = things in there.=20 >>=20 >>=20 >>=20 >> On Tuesday, March 12, 2013, Jim Schaad wrote: >> I am not truly happy with this idea. If the application cares about = who =93owns=94 a key for a signature then it needs to somehow get that = information. That may be done by getting the way and key from the = security library and that may be done by just returning the claims from = the envelope. >>=20 >> =20 >>=20 >> Jim >>=20 >> =20 >>=20 >> =20 >>=20 >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of John Bradley >> Sent: Tuesday, March 12, 2013 9:15 AM >> To: Mike Jones >> Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen O'Donoghue >> Subject: Re: [jose] Proposed resolution of header criticality issue >>=20 >> =20 >>=20 >> I am OK with getting rid of it if we make it clear that claims from = the envelope will not be passed on to applications. >>=20 >> =20 >>=20 >> If we don't do that we will compromise interoperability between = libraries. Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body = in some way. >>=20 >> =20 >>=20 >> I just want it one way or the other. >>=20 >> =20 >>=20 >> John B. >>=20 >> =20 >>=20 >> =20 >>=20 >> On 2013-03-12, at 9:06 AM, Mike Jones = wrote: >>=20 >>=20 >>=20 >>=20 >> I=92m with Richard on this. The application-specific-data/meta field = isn=92t needed. >>=20 >> =20 >>=20 >> -- Mike >>=20 >> =20 >>=20 >> From: Richard Barnes >> Sent: March 11, 2013 10:02 PM >> To: John Bradley >> CC: Tim Bray, Manger, James H, Karen ODonoghue, jose >> Subject: Re: [jose] Proposed resolution of header criticality issue >>=20 >> =20 >>=20 >> +1 to cheers. I already high-fived Mike in person. >>=20 >> =20 >>=20 >> FWIW, my preference would be to get rid of "asd" or "meta" (part 5). = I don't think it's relevant to the criticality discussion, and it's just = not needed. =20 >>=20 >> =20 >>=20 >> --Richard >>=20 >> =20 >>=20 >> =20 >>=20 >> On Mon, Mar 11, 2013 at 11:01 PM, John Bradley = wrote: >>=20 >> =20 >>=20 >> On 2013-03-11, at 10:48 PM, "Manger, James H" = wrote: >>=20 >> =20 >>=20 >> I=92ll add some cheers =97 this does look like substant >>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >>=20 >>=20 >>=20 >> --=20 >> -- Dick >>=20 >=20 --Apple-Mail=_52833F5F-DAA4-4078-8370-915EF6BB973D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 dick.hardt@gmail.com> = wrote:
Hi = Richard

I know enough about crypto to follow the = directions in the spec and get something that interoperates with other = implementations. i.e., I don't know if your statement below is what I am = actually looking for.

Here is the = protocol:

1) Alice gives Bob a JWE where = Charlie, Dennis or Eric may be the audience

2) = Bob knows how to talk to Charlie but not Dennis or Eric, so Bob gives = the JWE to Charlie

3) Charlie needs to be able = to look at the JWE and see who the audience is to determine if he can = process it, or if he needs to hand it to Dennis or = Eric.

In JWE, the only plaintext metadata that = is available is the JWE header, so I would like an audience signal = there, as it enables a token recipient to know if they are the recipient = or not. Currently a recipient can guess they are not if the KID is not = understood, but that does not help signal who will understand, and also = does assist developers in detecting they have an old key vs signed for = the wrong recipient.

I don't want to add = another plaintext field. In my implementation (assuming I did it = correctly) the header has integrity = protection.

-- = Dick


On Mar 12, 2013, at 3:29 PM, = Richard Barnes <rlb@ipv.sx> = wrote:

Hi Dick,

If I understand your use case = correctly, what you're actually looking for is a way to populate the = "additional data" that's protected under the AEAD algorithm. =  Unfortunately, under current JWE, that's conflated with the = header.  I think the correct resolution to this problem is to = remove the JWE header from the integrity check, and add a separate field = to JWE for additional data.

--Richard



On Tue, Mar 12, 2013 at 1:07 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
Agreed.

In an implementation I am working = on, I need an audience signal in a JWE so that recipients of the JWE = token know who can decrypt and process it.

While on that topic, it seems that I can't have 'aud' in the header, so = I would need to have a URI for that property such as 'aud.example.com'

btw: per Richard's comment, the code to use app specific payload = data is pretty ugly with


but I put all the app properties in the one object so I = do

jwt.['prop.example.com'].prop1

-- Dick



On Tue, Mar 12, 2013 at 7:05 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
oh great now you are going to tell us what is crypto related and = what is not, that is pretty much n application call not a spec = call
 
Sent from Windows Mail
 
From: Mike Jones
Sent: March 12, 2013 7:02 AM

To: Jim Schaad, Richard Barnes
CC: John Bradley, Tim Bray, James H Manger, Karen = O'Donoghue, jose

Subject: Re: [jose] Proposed resolution of header = criticality issue
 
+1 to only putting crypto-related things in the headers.
 
From: Richard Barnes
Sent: March 12, 2013 6:53 AM

To: Jim Schaad
CC: John Bradley, Mike Jones, James H Manger, Tim = Bray, jose, Karen O'Donoghue
Subject: Re: [jose] Proposed resolution of header = criticality issue
 
Note that my proposed text did not say that the libraries would not = return header stuff, only that you shouldn't cram non-crypto-related = things in there. 



On Tuesday, March 12, 2013, Jim Schaad wrote:

I am not truly happy with this idea.  If = the application cares about who =93owns=94 a key for a signature then it = needs to somehow get that information.  That may be done by getting the way and key from the security library = and that may be done by just returning the claims from the = envelope.

 

Jim

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of John Bradley
Sent: Tuesday, March 12, 2013 9:15 AM
To: Mike Jones
Cc: Richard Barnes; James H Manger; Tim Bray; jose; Karen = O'Donoghue
Subject: Re: [jose] Proposed resolution of header criticality = issue

 

I am OK with getting rid of it if we = make it clear that claims from the envelope will not be passed on to = applications.

 

If we don't do that we will compromise interoperability between = libraries.   Envelope is for JOSE only and not made available, that = makes things like timestamps and other things that the application layer = needs to interpret can't go in the envelope they need to be in the body in some way.

 

I just want it one way or the other.

 

John B.

 

 

On 2013-03-12, at 9:06 AM, Mike Jones = <Michael.Jones@microsoft.com> wrote:



I=92m = with Richard on this.  The application-specific-data/meta = field isn=92t needed.

 =

-- = Mike

 =

From: Ric= hard Barnes
Sent: March 11, 2013 10:02 PM
To: John Bradley
CC: Tim Bray, Manger, James H, Karen ODonoghue, jose
Subject:<= /span> Re: [jose] Proposed resolution of header = criticality issue

 =

+1 to = cheers.  I already high-fived Mike in person.

&n= bsp;

FWIW, = my preference would be to get rid of "asd" or "meta" (part 5).  I = don't think it's relevant to the criticality discussion, and it's just = not needed.  

&n= bsp;

--Richard=

&n= bsp;

&n= bsp;

On Mon, = Mar 11, 2013 at 11:01 PM, John Bradley <ve7jtb@ve7jtb.com> = wrote:

&n= bsp;

On = 2013-03-11, at 10:48 PM, "Manger, James H" = <James.H.Manger@team.telstra.com> = wrote:

&n= bsp;

I=92ll add some cheers =97 this does look = like substant


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose




--
-- Dick

=


= --Apple-Mail=_52833F5F-DAA4-4078-8370-915EF6BB973D-- --Apple-Mail=_11FBCA84-F57C-4EF3-82AF-10DDF1BAD356 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMjMxMzE5WjAjBgkqhkiG9w0BCQQxFgQURuY/TA0J H8odCForwU504EgKYLMwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAUFYDt30JWm6mL139QKQp72hkmeEuSVqyjjQjjDst RZ37omZYFr24V3+mSgQ3f5FLnIgnfIBs3EXCkfeZxYy0MveYD5nKJVFKMmgJBf0Q21JgUVcyBX6N wQZgHXFnf90m0bLma1sKiNUXLg25i1whLA6HVjAuWiO9J/Y/ZDx/2DKU8f11RWetDQVGOlDbkfmD o/cRZRdRBCNGwqHAhXj+U2V1JjZk0Vt60ORhnbiYkqnvV5PJZpZDjk0zTpHF3GsZbdjE7dYWyUBg 4zAZs3B6gcZrEfmN38h2dBgu3mEi1Id45jyaKBK3pZFiAsrKl/EpP8bJcyb7WXYJ0MrZogY5mAAA AAAAAA== --Apple-Mail=_11FBCA84-F57C-4EF3-82AF-10DDF1BAD356-- From dick.hardt@gmail.com Tue Mar 12 16:39:07 2013 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 BC4AE21F88F7 for ; Tue, 12 Mar 2013 16:39:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.994 X-Spam-Level: X-Spam-Status: No, score=-2.994 tagged_above=-999 required=5 tests=[AWL=0.605, 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 HaJAx540z758 for ; Tue, 12 Mar 2013 16:39:07 -0700 (PDT) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 13A3621F88C7 for ; Tue, 12 Mar 2013 16:39:07 -0700 (PDT) Received: by mail-pb0-f47.google.com with SMTP id rp2so382629pbb.20 for ; Tue, 12 Mar 2013 16:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=2uIgKUQExzL8OaezwWVrdfJB/ZjWMOiMmweGHT81V7U=; b=O9ik0+27HeV9duGFkgdiQwyGJKNfvWL6adY8NlvkGKEnY/v2/YoSzU6fJFzaplkrJo QqPqTVBiGPbZ5xiYhIj70U/LK0PHzan8AD1R7IJqYJO4fohjMXDs2LsgHG7WUdmCc2Vl +VfYn1ROsVSthv8lp97a6nCpIeiAy/PYNRj4KQCebimN4gnUKbbbfiQIs+P5ieVzSsFM GcbuVCrhC1gCV0L+tu3d5eofYuyxFd1QWtJ/5XQiURlaPx0/XkTAO7xB9dwwYZzjpLXS rpJzB3YXoIywJVMYeN56oMDolC4BALDw6+3eP+6hUOY7UQqDowb2Oc+u+v0hEoS5uSUs dWBA== X-Received: by 10.68.25.201 with SMTP id e9mr40438833pbg.145.1363131546747; Tue, 12 Mar 2013 16:39:06 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ri1sm26947575pbc.16.2013.03.12.16.39.03 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 16:39:04 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: Date: Tue, 12 Mar 2013 16:39:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> References: To: John Bradley X-Mailer: Apple Mail (2.1499) Cc: Anthony Nadalin , Karen O'Donoghue , Richard Barnes , Jim Schaad , Mike Jones , Tim Bray , jose , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 23:39:07 -0000 On Mar 12, 2013, at 4:13 PM, John Bradley wrote: > Currently the header has integrity protection. Glad to hear I did that right. >=20 > The proposed changes to the spec allow what you are doing. The thing = is that a standard JWE library is not going to know about your = forwarding rules.=20 I would hope that a standard JWE library would ignore my forwarding = rules. That is done at the protocol layer (which should be obvious since = the JWE library won't know how to forward) In my libraries, I have a JWT parser that will give me the header and = the payload if a JWS. Hopefully other libraries will have parsers so = that the App can make decision about what to do. > My proposal was to add a containing element for all the additional = claims intended for processing outside of the JWE/JWS crypto library. Or I could just add an app specific claim like I do in the payload. > That reduces namespace collision and allows the library to pass back = to the application any claims in the header that are not intended for = JWEJWS. We already have a mechanism for namespace collision in the payload. Why = invent a new one? btw: I like my parsing implementation just fine -- passing back just the = claims does not meet my purpose -- I want to see all of the header, and = see the payload if it is a JWS >=20 > The three alternatives are: > 1 preclude non JWE/S claims in the header (won't work for you) > 2 a dedicated JSON member that contains claims intended for = applications or external extensions > 3 throw in everything as a top level claim and have applications sniff = the header looking for what they need. Why not use the same extension mechanism that is being used for the = payload? Or allow me to put payload properties into the header as well? = There is no namespace collision since it is a reserved property value. >=20 > The proposal going to the meeting tomorrow is 2 based on it being the = cleanest way to pass on the additional claims to applications using a = general purpose JOSE lib. I don't just want the additional claims, I want the full header parsed = and be able to look at all of it. -- Dick= From ve7jtb@ve7jtb.com Tue Mar 12 16:47:12 2013 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 0842C11E80E7 for ; Tue, 12 Mar 2013 16:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.208 X-Spam-Level: X-Spam-Status: No, score=-3.208 tagged_above=-999 required=5 tests=[AWL=0.391, 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 H-JJkkwYVmZ4 for ; Tue, 12 Mar 2013 16:47:11 -0700 (PDT) Received: from mail-gh0-f169.google.com (mail-gh0-f169.google.com [209.85.160.169]) by ietfa.amsl.com (Postfix) with ESMTP id EBA7011E80CC for ; Tue, 12 Mar 2013 16:47:03 -0700 (PDT) Received: by mail-gh0-f169.google.com with SMTP id r18so94866ghr.14 for ; Tue, 12 Mar 2013 16:47:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=HW/k/VBgGlIBPzvEf3S7Lou4mkt2ue58EYKxTzkLULs=; b=EJ8+JJT18a78C5M3hmHfyw66XyuJpFl59FO1CI4q9grXfwS1Pz3sP9v+dTW8wc6kjW bTl2FhrdQePSeefJkaGfNk4TP9If167GDLoZq/I0qtO9plLzwpDSf8gMqDPGibW4JjVy zezeX3OnmQ/0KY8sWMA68ziSE2IejwjbOk3A87MC8DTVpYf/hSBK+uucPV43Q5jrS771 avAbTKidkIt/XY5BbnQK3GNDdQBTInEv6uImqmdTSFdCLr6OMPMzPkpzXOsTwQH53Xvg v0qmSypmGe5qWsZD333rJU3qqdGTI7FZUEI3RIg9rfLuYVCx7eV4jfGnWGjSW5HhXA48 6oKA== X-Received: by 10.236.116.163 with SMTP id g23mr13661683yhh.147.1363132022672; Tue, 12 Mar 2013 16:47:02 -0700 (PDT) Received: from [192.168.11.16] (ip-64-134-186-130.public.wayport.net. [64.134.186.130]) by mx.google.com with ESMTPS id e8sm32541703yhh.16.2013.03.12.16.46.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Mar 2013 16:47:00 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_C752F9CA-B7F4-47A6-B9F3-7145D59ACA1D"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> Date: Tue, 12 Mar 2013 19:46:59 -0400 Message-Id: <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> References: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl0aalocTwvGfNNTBl9+bnthm6Dlpa/ICsIrGcgMeV7v0PaUydsf+tjp6XnLNwVqCbmu88q Cc: Anthony Nadalin , Karen O'Donoghue , Richard Barnes , Jim Schaad , Mike Jones , Tim Bray , jose , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 12 Mar 2013 23:47:12 -0000 --Apple-Mail=_C752F9CA-B7F4-47A6-B9F3-7145D59ACA1D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The application wanting to see the whole header is also a valid = perspective. I guess the question is if every application should have to create its = own way to extract the header info or should a lib be expected to make = them available. Some of this discussion comes from CMS where the crypto info/header info = is not exposed to applications. I think that is not the right thing to do. If we are going with adding top level claims then we should probably say = there is an expectation that the header is also available to = applications, which is what I think you expect. John B. On 2013-03-12, at 7:39 PM, Dick Hardt wrote: >=20 > On Mar 12, 2013, at 4:13 PM, John Bradley wrote: >=20 >> Currently the header has integrity protection. >=20 > Glad to hear I did that right. >=20 >>=20 >> The proposed changes to the spec allow what you are doing. The = thing is that a standard JWE library is not going to know about your = forwarding rules.=20 >=20 > I would hope that a standard JWE library would ignore my forwarding = rules. That is done at the protocol layer (which should be obvious since = the JWE library won't know how to forward) >=20 > In my libraries, I have a JWT parser that will give me the header and = the payload if a JWS. Hopefully other libraries will have parsers so = that the App can make decision about what to do. >=20 >> My proposal was to add a containing element for all the additional = claims intended for processing outside of the JWE/JWS crypto library. >=20 > Or I could just add an app specific claim like I do in the payload. >=20 >> That reduces namespace collision and allows the library to pass back = to the application any claims in the header that are not intended for = JWEJWS. >=20 > We already have a mechanism for namespace collision in the payload. = Why invent a new one? >=20 > btw: I like my parsing implementation just fine -- passing back just = the claims does not meet my purpose -- I want to see all of the header, = and see the payload if it is a JWS >=20 >>=20 >> The three alternatives are: >> 1 preclude non JWE/S claims in the header (won't work for you) >> 2 a dedicated JSON member that contains claims intended for = applications or external extensions >> 3 throw in everything as a top level claim and have applications = sniff the header looking for what they need. >=20 > Why not use the same extension mechanism that is being used for the = payload? Or allow me to put payload properties into the header as well? = There is no namespace collision since it is a reserved property value. >=20 >>=20 >> The proposal going to the meeting tomorrow is 2 based on it being the = cleanest way to pass on the additional claims to applications using a = general purpose JOSE lib. >=20 > I don't just want the additional claims, I want the full header parsed = and be able to look at all of it. >=20 > -- Dick --Apple-Mail=_C752F9CA-B7F4-47A6-B9F3-7145D59ACA1D Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzEyMjM0NjYwWjAjBgkqhkiG9w0BCQQxFgQUqRhTisXP of52wrtb6seZ1vQRmX0wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAcObBpzYGUlLu1uM21zOFOb+hzlM7BG0QofAn8WTp yGI+BDXbd1HMUWrbRMOP2rpQgmdMlncP0YcAlzDQW+AgEavnXV4/n0w/5JObeVgPEyPjngKMQxEN Wxd4n4TLI9lXN90k/UN1B4bUQcAVc/pxqwUIETnc2rhRp3tciExEYxLqJ/s2poPuWoOatooUvKHk sY2Gda6RgmNJJwZ7HTU2o7V8oSgeWs3bI/KaoYwb4mmr+ypSyMuLWNWoCoaZYtMIBwN5Ycm5VARN 0/h6yTciEIMpG+jZ5udKf4bcsrM/iFJPfgrMSgMcTFq9q6X1OmqAjJCH82RkwIzVD36i02jA5wAA AAAAAA== --Apple-Mail=_C752F9CA-B7F4-47A6-B9F3-7145D59ACA1D-- From dick.hardt@gmail.com Tue Mar 12 17:24:46 2013 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 5B6B111E80E9 for ; Tue, 12 Mar 2013 17:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 6i0VaS8+gY31 for ; Tue, 12 Mar 2013 17:24:45 -0700 (PDT) Received: from mail-bk0-x232.google.com (mail-bk0-x232.google.com [IPv6:2a00:1450:4008:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id D933621F8697 for ; Tue, 12 Mar 2013 17:24:44 -0700 (PDT) Received: by mail-bk0-f50.google.com with SMTP id jg9so194225bkc.9 for ; Tue, 12 Mar 2013 17:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=/oNX7JUsQh7F566NNN6kfXWVUx1Vpvb9ZGXjsnvmMD0=; b=w9QhgaUHFuXX6eZPZHNQTxO9lNU+hnflFyXnVtBh0ABSqpVV6CFFiRd6HXNjJU0RYQ u6yC6QB7eOeCOD3Yox4WVy/yVK4SQefEc7ipQsNnvmZbah48bHc9iSDd+kmvsz8iKZc3 9UHgeuW8ruZjcIdbFZs6CdYMmQ4up8gni0m4qvVXajZL0muJ+s6g/S5n1CeBVmEevaNQ +Dqz/IrKPuzgAuNufamsfGCI9dKUYsFfVyLwdnO9dVKzc678cVC/BFRF/ptEh4kUDwSs AyvD60or7r7lVCkZReyqBWaGD18y4hB8y5H7Yhlzb7OpzdNZvr/2SRKQbpTogw3C1b23 snzA== MIME-Version: 1.0 X-Received: by 10.205.112.80 with SMTP id er16mr6964518bkc.12.1363134283756; Tue, 12 Mar 2013 17:24:43 -0700 (PDT) Received: by 10.204.37.130 with HTTP; Tue, 12 Mar 2013 17:24:43 -0700 (PDT) In-Reply-To: <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> References: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> Date: Tue, 12 Mar 2013 17:24:43 -0700 Message-ID: From: Dick Hardt To: John Bradley Content-Type: multipart/alternative; boundary=14dae9c093c6c3e91504d7c36ea1 Cc: Anthony Nadalin , Karen O'Donoghue , Richard Barnes , Jim Schaad , Mike Jones , Tim Bray , jose , James H Manger Subject: Re: [jose] Proposed resolution of header criticality issue 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, 13 Mar 2013 00:24:46 -0000 --14dae9c093c6c3e91504d7c36ea1 Content-Type: text/plain; charset=ISO-8859-1 I expect to look at the header to see the 'kid' so I know what key to fetch to hand to the library. Does not make sense for the library to store and manage keys -- I expect the keys are handed to the library as needed. On Tue, Mar 12, 2013 at 4:46 PM, John Bradley wrote: > The application wanting to see the whole header is also a valid > perspective. > > I guess the question is if every application should have to create its own > way to extract the header info or should a lib be expected to make them > available. > > Some of this discussion comes from CMS where the crypto info/header info > is not exposed to applications. > > I think that is not the right thing to do. > > If we are going with adding top level claims then we should probably say > there is an expectation that the header is also available to applications, > which is what I think you expect. > > John B. > > On 2013-03-12, at 7:39 PM, Dick Hardt wrote: > > > > > On Mar 12, 2013, at 4:13 PM, John Bradley wrote: > > > >> Currently the header has integrity protection. > > > > Glad to hear I did that right. > > > >> > >> The proposed changes to the spec allow what you are doing. The thing > is that a standard JWE library is not going to know about your forwarding > rules. > > > > I would hope that a standard JWE library would ignore my forwarding > rules. That is done at the protocol layer (which should be obvious since > the JWE library won't know how to forward) > > > > In my libraries, I have a JWT parser that will give me the header and > the payload if a JWS. Hopefully other libraries will have parsers so that > the App can make decision about what to do. > > > >> My proposal was to add a containing element for all the additional > claims intended for processing outside of the JWE/JWS crypto library. > > > > Or I could just add an app specific claim like I do in the payload. > > > >> That reduces namespace collision and allows the library to pass back to > the application any claims in the header that are not intended for JWEJWS. > > > > We already have a mechanism for namespace collision in the payload. Why > invent a new one? > > > > btw: I like my parsing implementation just fine -- passing back just the > claims does not meet my purpose -- I want to see all of the header, and see > the payload if it is a JWS > > > >> > >> The three alternatives are: > >> 1 preclude non JWE/S claims in the header (won't work for you) > >> 2 a dedicated JSON member that contains claims intended for > applications or external extensions > >> 3 throw in everything as a top level claim and have applications sniff > the header looking for what they need. > > > > Why not use the same extension mechanism that is being used for the > payload? Or allow me to put payload properties into the header as well? > There is no namespace collision since it is a reserved property value. > > > >> > >> The proposal going to the meeting tomorrow is 2 based on it being the > cleanest way to pass on the additional claims to applications using a > general purpose JOSE lib. > > > > I don't just want the additional claims, I want the full header parsed > and be able to look at all of it. > > > > -- Dick > > -- -- Dick --14dae9c093c6c3e91504d7c36ea1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I expect to look at the header to see the 'kid' so= I know what key to fetch to hand to the library. Does not make sense for t= he library to store and manage keys -- I expect the keys are handed to the = library as needed.


On Tue, Mar 1= 2, 2013 at 4:46 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:<= br>
The application wanting to see the whole header is also a valid perspective= .

I guess the question is if every application should have to create its own = way to extract the header info or should a lib be expected to make them ava= ilable.

Some of this discussion comes from CMS where the crypto info/header info is= not exposed to applications.

I think that is not the right thing to do.

If we are going with adding top level claims then we should probably say th= ere is an expectation that the header is also available to applications, wh= ich is what I think you expect.

John B.

On 2013-03-12, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

>
> On Mar 12, 2013, at 4:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> Currently the header has integrity protection.
>
> Glad to hear I did that right.
>
>>
>> The proposed changes to the spec allow what you are doing. =A0 The= thing is that a standard JWE library is not going to know about your forwa= rding rules.
>
> I would hope that a standard JWE library would ignore my forwarding ru= les. That is done at the protocol layer (which should be obvious since the = JWE library won't know how to forward)
>
> In my libraries, I have a JWT parser that will give me the header and = the payload if a JWS. Hopefully other libraries will have parsers so that t= he App can make decision about what to do.
>
>> My proposal was to add a containing element for all the additional= claims intended for processing outside of the JWE/JWS crypto library.
>
> Or I could just add an app specific claim like I do in the payload. >
>> That reduces namespace collision and allows the library to pass ba= ck to the application any claims in the header that are not intended for JW= EJWS.
>
> We already have a mechanism for namespace collision in the payload. Wh= y invent a new one?
>
> btw: I like my parsing implementation just fine -- passing back just t= he claims does not meet my purpose -- I want to see all of the header, and = see the payload if it is a JWS
>
>>
>> The three alternatives are:
>> 1 preclude non JWE/S claims in the header =A0(won't work for y= ou)
>> 2 a dedicated JSON member that contains claims intended for applic= ations or external extensions
>> 3 throw in everything as a top level claim and have applications s= niff the header looking for what they need.
>
> Why not use the same extension mechanism that is being used for the pa= yload? Or allow me to put payload properties into the header as well? There= is no namespace collision since it is a reserved property value.
>
>>
>> The proposal going to the meeting tomorrow is 2 based on it being = the cleanest way to pass on the additional claims to applications using a g= eneral purpose JOSE lib.
>
> I don't just want the additional claims, I want the full header pa= rsed and be able to look at all of it.
>
> -- Dick




--
= -- Dick
--14dae9c093c6c3e91504d7c36ea1-- From James.H.Manger@team.telstra.com Tue Mar 12 17:58:56 2013 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 686DC21F8CA2 for ; Tue, 12 Mar 2013 17:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.273 X-Spam-Level: X-Spam-Status: No, score=-0.273 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, RELAY_IS_203=0.994] 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 juLbLO1IQQmE for ; Tue, 12 Mar 2013 17:58:54 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 826B421F8CA1 for ; Tue, 12 Mar 2013 17:58:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,833,1355058000"; d="scan'208,217";a="118762866" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipobni.tcif.telstra.com.au with ESMTP; 13 Mar 2013 11:58:50 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7012"; a="120669107" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccni.tcif.telstra.com.au with ESMTP; 13 Mar 2013 11:58:50 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Wed, 13 Mar 2013 11:58:50 +1100 From: "Manger, James H" To: Mike Jones , "Peck, Michael A" , John Bradley Date: Wed, 13 Mar 2013 11:58:49 +1100 Thread-Topic: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: AQHOH1w+q0obM/4B3E2z5wOsWscejpiifSFAgAAKD4CAAAOugIAAAM6ggAAp4lA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B8467A5WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 13 Mar 2013 00:58:56 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B8467A5WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHVzaW5nIHRoZSBNY0dyZXcgZHJhZnQgYW5kIFJGQyA1MTE2IGludGVyZmFjZS4NCg0K VGhlIEpPU0Utc3BlY2lmaWMgQTEyOENCQytIUzI1NiBhbGdvcml0aG0gbG9va3MgbGlrZSBhIHZh bGlhbnQgYXR0ZW1wdCB0byBoaWRlIHNvbWUgb2YgdGhlIGJpbmFyeSBwcm9jZXNzaW5nIGludm9s dmVkIHdpdGggY3J5cHRvIOKAkyB3aGljaCBoYXMgYWx3YXlzIGJlZW4gZGVmaW5lZCBvbiBieXRl cywgbm90IHRleHQuIEJ1dCB0aGUgcmVzdWx0IGlzIGEgcG9vciBjaGltZXJhLg0KDQpGb3IgaW5z dGFuY2UsIEpXRSBpbmNsdWRlcyB0aGUgSVYgYXMgcGFydCBvZiB0aGUgYWRkaXRpb25hbCBhdXRo ZW50aWNhdGVkIGRhdGEgKEFBRCkuIE5vIG90aGVyIEFFQUQgc3lzdGVtIGlzIGRlZmluZWQgbGlr ZSB0aGlzLiBFdmVyeXdoZXJlIGVsc2UgdGhlIElWL25vbmNlIGFuZCBBQUQgYXJlIHNlcGFyYXRl LiBJIGhvcGUgdGhhdCBkb2VzbuKAmXQgYWR2ZXJzZWx5IGFmZmVjdCB0aGUgY3J5cHRvIHByb3Bl cnRpZXMsIGJ1dCBpdCBkb2VzIHJhaXNlIHF1ZXN0aW9ucyBhYm91dCB3aGV0aGVyIGl0IGlzIGlt cG9ydGFudCBmb3Igc29tZSBjcnlwdG8gcmVhc29uLg0KDQpFdmVyeSBBRUFEIGFsZ29yaXRobSB0 cmVhdHMgdGhlIEFBRCBhbmQgY2lwaGVydGV4dCBhcyBieXRlcyBhcnJheXMgd2l0aCBubyByZXN0 cmljdGlvbnMgb24gdGhlaXIgY29udGVudCAob25seSByZXN0cmljdGlvbnMgb24gdGhlaXIgbGVu Z3RoKS4gSGVuY2UgdGhleSB1c2Ugc29tZSBiaW5hcnkgcGFja2luZyB3aGVuIHByb2Nlc3Npbmcg Ym90aCB0byBjYWxjdWxhdGUgYW4gaW50ZWdyaXR5IGNoZWNrLiBFWENFUFQgdGhlIEpPU0Utc3Bl Y2lmaWMgQUVBRCBhbGdvcml0aG1zIChBMTI4Q0JDK0hTMjU2IGFuZCBBMjU2Q0JDK0hTNTEyKS4g VGhleSBmb3JjZSBiYXNlNjR1cmwtZW5jb2RpbmcgKmluc2lkZSogdGhlIEFFQUQgYWxnb3JpdGht IHNvIHRoZXkgY2FuIHVzZSBhIHRleHQgZG90IOKAnC7igJ0gYXMgYSBzZXBhcmF0b3IuDQoNCldo aWxlIEExMjhDQkMrSFMyNTYgaXMgaW1wbGVtZW50ZWQgYnkgaGFuZCBpbiBKT1NFLXNwZWNpZmlj IGNvZGUgdXNpbmcgQUVTIGFuZCBITUFDIHByaW1pdGl2ZXMgdGhlIHByb2JsZW1zIHdpdGggdGhp cyBjaGltZXJhIGFyZSBtYWlubHkgaGlkZGVuLiBIb3dldmVyLCBJIGRvbuKAmXQgYmVsaWV2ZSBh bnkgZ2VuZXJpYyBBRUFEIGludGVyZmFjZSBjYW4gZXZlciBoYW5kbGUgdGhpcyBKT1NFLXNwZWNp ZmljIGFsZ29yaXRobSBlZmZpY2llbnRseS4NCg0KVGhlIOKAnGV4dHJhIHdvcmvigJ0gb2YgYWRv cHRpbmcgdGhlIEFFQUQgZW5jb2RpbmcvZGVjb2RpbmcgY29udmVudGlvbnMgaXM6IGNvbmNhdGVu YXRpbmcgYnl0ZSBhcnJheXM7IGFuZCB0YWtpbmcgYSBrbm93bi1sZW5ndGggcHJlZml4IGFuZCBz dWZmaXggZnJvbSBhIGJ5dGUgYXJyYXkuIFlvdSBjYW5ub3QgZ2V0IG11Y2ggc2ltcGxlci4gSXQg Y2FuIG9ubHkgYmUgYW4gYW5ub3lhbmNlIGZvciBhIGxhbmd1YWdlIHRoYXQgaXMgbm90IGJ5dGUt YXJyYXktZnJpZW5kbHksIGJ1dCBldmVuIHN1Y2ggYSBsYW5ndWFnZSB3aWxsIGhhdmUgdG8gaGFu ZGxlIGJ5dGUgYXJyYXlzIGF0IHNvbWUgcG9pbnQgdG8gaW50ZXJmYWNlIHdpdGggY3J5cHRvLg0K DQpFdmVuIHVzaW5nIHRoZSBNY0dyZXcgZHJhZnQgdGhlbiBzZXBhcmF0aW5nIHRoZSBvdXRwdXQg aW50byBJVi9jaXBoZXJ0ZXh0L01BQyB0byByZS1wYWNrYWdlIGFzIGEgSk9TRSBtZXNzYWdlIHdv dWxkIGJlIGJldHRlciB0aGFuIHRoZSBKT1NFLXNwZWNpZmljIEExMjhDQkMrSFMyNTYgYW5kIEEy NTZDQkMrSFM1MTIuDQoNClAuUy4gSSB0aGluayBFQ01BU2NyaXB0IGVkaXRpb24gNiBpcyBpbnRy b2R1Y2luZyBzdXBwb3J0IGZvciBieXRlIGFycmF5cyBzbyBldmVuIGhhc3NsZSBoYW5kbGluZyBi eXRlcyBpbiBKYXZhU2NyaXB0IHNob3VsZCBmYWRlLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCkZy b206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIE1pa2UgSm9uZXMNClNlbnQ6IFdlZG5lc2RheSwgMTMgTWFyY2ggMjAxMyA4 OjA2IEFNDQpUbzogUGVjaywgTWljaGFlbCBBOyBKb2huIEJyYWRsZXkNCkNjOiBSaWNoYXJkIEJh cm5lczsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSBDb25jYXQgS0RGIGlzc3Vl cyB3aXRoIEVDREgtRVMgYW5kIGZvciBkZXJpdmluZyBDRUsvQ0lLIGZyb20gQ01LDQoNClBvc3Np Ymx5IHVzaW5nIHRoZSBNY0dyZXcgZHJhZnQgaGFkIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSwgYnV0 IHRoZXJlIHdhcyBzdHJvbmcgcHVzaC1iYWNrIG9uIGl0LiAgSXQgd291bGQgY2hhbmdlIG1vcmUg dGhhbiB0aGUgQ0JDL0hNQUMgcmVwcmVzZW50YXRpb24g4oCTIGl0IHdvdWxkIGNoYW5nZSBhbGwg dGhlIEpXRSByZXByZXNlbnRhdGlvbnMsIGFzIGl0IHdvdWxkIHJlbW92ZSB0aGUgSW5pdGlhbGl6 YXRpb24gVmVjdG9yIGFuZCBJbnRlZ3JpdHkgVmFsdWUgZmllbGRzLCBhbmQgaW5zdGVhZCByZXF1 aXJlIGFsbCBpbXBsZW1lbnRhdGlvbnMgdG8gaW1wbGVtZW50IGFuZCBhcHBseSB0aGUgQUVBRCBi aW5hcnkgZW5jb2RpbmcgYW5kIGRlY29kaW5nIGNvbnZlbnRpb25zLiAgTm90ZSB0aGF0IHRoaXMg d291bGQgY2hhbmdlIEFFUy1HQ00gdG9vIOKAkyBub3QganVzdCBBRVMtQ0JDL0hNQUMuDQoNCklm IGNvbW1vbmx5IGF2YWlsYWJsZSBjcnlwdG8gbGlicmFyaWVzIGltcGxlbWVudGVkIGFsZ29yaXRo bXMgdXNpbmcgdGhlIEFFQUQgZW5jb2RpbmcgY29udmVudGlvbnMgSSB3b3VsZCBoYXZlIG5vIHBy b2JsZW0gd2l0aCB0aGlzLiAgQnV0IGluIGZhY3QsIHRoZXkgZG9u4oCZdC4gIEkgZG9u4oCZdCBr bm93IG9mIGEgc2luZ2xlIGxpYnJhcnkgaW4gdGhlIGF0dGFjaGVkIHNldCBvZiBzdXJ2ZXllZCBp bXBsZW1lbnRhdGlvbnMgdGhhdCBkby4gIFRodXMsIGFkb3B0aW5nIHRoZSBBRUFEIGVuY29kaW5n L2RlY29kaW5nIGNvbnZlbnRpb25zIHdvdWxkIGNyZWF0ZSBleHRyYSB3b3JrIGZvciBhbGwgaW1w bGVtZW50YXRpb25zIGluIHByYWN0aWNlIOKAkyBub3QgbWFrZSB0aGluZ3Mgc2ltcGxlci4gIEl0 IHdvdWxkIG9ubHkgYmUgc2ltcGxlciBpZiB0aGUgZXhpc3RpbmcgY3J5cHRvIGxpYnJhcmllcyBp bXBsZW1lbnRlZCB0aGlzIHN0YW5kYXJkIGludGVyZmFjZS4NCg0KV2Ugc2hvdWxkIHRoZXJlZm9y ZSBzdGVlciBjbGVhciBvZiB0aGlzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBCZXN0IHdpc2hlcywNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIC0tIE1pa2UNCg0K UC5TLiAgSmltIFNjaGFhZCBhbHNvIHBvaW50cyBvdXQgdGhhdCBDTVMgZG9lc27igJl0IHVzZSB0 aGUgUkZDIDUxMTYgaW50ZXJmYWNlIGVpdGhlci4NCg0KRnJvbTogUGVjaywgTWljaGFlbCBBIFtt YWlsdG86bXBlY2tAbWl0cmUub3JnXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMgMjow MiBQTQ0KVG86IEpvaG4gQnJhZGxleTsgTWlrZSBKb25lcw0KQ2M6IFJpY2hhcmQgQmFybmVzOyBq b3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtqb3NlXSBD b25jYXQgS0RGIGlzc3VlcyB3aXRoIEVDREgtRVMgYW5kIGZvciBkZXJpdmluZyBDRUsvQ0lLIGZy b20gQ01LDQoNCkkgdGhpbmsgdGhhdCAjMiBhY3R1YWxseSByZWR1Y2VzIGNvbXBsZXhpdHkgZm9y IGltcGxlbWVudGVycy4NClRoZXkgY2FuIGltcGxlbWVudCB0aGUgUkZDIDUxMTYgaW50ZXJmYWNl IG9uY2UgKG9yIGV2ZW50dWFsbHkganVzdCBpbnZva2UgYSBjcnlwdG8gbGlicmFyeSB0aGF0IGlt cGxlbWVudHMgaXQgZm9yIHRoZW0pIOKAkyB0aGVuIHVzZSB0aGF0IGltcGxlbWVudGF0aW9uIGZv ciBhbGwgcHJvdG9jb2xzIHRoYXQgdXNlIHRoZSBSRkMgNTExNiBpbnRlcmZhY2UsIG5vdCBqdXN0 IEpPU0UsIGFuZCBrbm93IHRoYXQgdGhlIGRldGFpbHMgb2YgYXV0aGVudGljYXRlZCBlbmNyeXB0 aW9uIGhhdmUgYmVlbiB0YWtlbiBjYXJlIG9mLg0KDQpNaWtlDQoNCg0KRnJvbTogSm9obiBCcmFk bGV5IFttYWlsdG86dmU3anRiQHZlN2p0Yi5jb21dDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxMiwg MjAxMyA0OjQ5IFBNDQpUbzogTWlrZSBKb25lcw0KQ2M6IFJpY2hhcmQgQmFybmVzOyBQZWNrLCBN aWNoYWVsIEE7IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW2pvc2VdIENvbmNhdCBLREYgaXNzdWVzIHdpdGggRUNESC1FUyBhbmQgZm9yIGRlcml2aW5n IENFSy9DSUsgZnJvbSBDTUsNCg0KWWVzIEkgaGF2ZSB0aGUgcmVjb21tZW5kYXRpb24gdG8gY2hh bmdlIGZyb20gdXNpbmcgYSBLREYgdG8gZ2VuZXJhdGUgdGhlIENFSyBhbmQgQ0lLIGZyb20gdGhl IENNSyB0byBjb25jYXRlbmF0aW5nIHRoZSBDRUsgYW5kIENJSyB0b2dldGhlciBhcyBpbiB0aGUg TWNHcmV3IGRyYWZ0Lg0KDQpJIGRvbid0IHlldCBoYXZlIGEgc2xpZGUgb24gdGhlIG5ldy9vbGQg aXNzdWUgb2YgY29uY2F0ZW5hdGluZyB0aGUgdGFnIHRvIHRoZSBtZXNzYWdlIGJvZHkgdnMgc2Vu ZGluZyBpdCBpbiBhIHNlcGFyYXRlIGZpZWxkLg0KDQpJZiBwZW9wbGUgd2FudCBtZSB0byBJIGNh biBhZGQgaXQgYXMgd2VsbC4gIFRob3VnaCBJIHRob3VnaHQgdGhhdCB3YXMgYSBjbG9zZWQgaXNz dWUuDQoNCkpvaG4gQi4NCg0KT24gMjAxMy0wMy0xMiwgYXQgNDoxOSBQTSwgTWlrZSBKb25lcyA8 TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29m dC5jb20+PiB3cm90ZToNCg0KQXMgcHJldmlvdXNseSBleHRlbnNpdmVseSBkaXNjdXNzZWQsIHRo ZSBNY0dyZXcgZHJhZnQgZG9lcyB0d28gdGhpbmdzIOKAkyBvbmUgaGVscGZ1bCBhbmQgb25lIG5v dDoNCg0KMS4gIEl0IHNwZWNpZmllcyB1c2luZyBhIGtleSB0aGF0IGlzIGFjdHVhbGx5IHRoZSBj b25jYXRlbmF0aW9uIG9mIGFuIEFFUy1DQkMga2V5IGFuZCBhbiBITUFDIFNIQS0yIGtleSwgcmF0 aGVyIHRoYW4gdXNlIG9mIGEgS0RGLiAgVGhhdOKAmXMgZ29vZCwgYXMgaXTigJlzIHNpbXBsZSBm b3IgaW1wbGVtZW50ZXJzLg0KDQoyLiAgSXQgc3BlY2lmaWVzIHRoYXQgdGhlIGluaXRpYWxpemF0 aW9uIHZlY3RvciBhbmQgaW50ZWdyaXR5IHZhbHVlIGJlIGNvbmNhdGVuYXRlZCB3aXRoIG90aGVy IHZhbHVlcyBpbiBwYXJ0aWN1bGFyIHdheXMsIGFuZCBjb252ZXJzZWx5LCBob3cgdG8gZXh0cmFj dCB0aGVtIHdoZW4gZGVjcnlwdGluZy4gIFRoYXTigJlzIG5vdCBnb29kLCBhcyBpdCBhZGRzIGNv bXBsZXhpdHkgZm9yIGltcGxlbWVudGVycyDigJMgZXNwZWNpYWxseSB3aGVuIEpXRXMgYWxyZWFk eSB1dGlsaXplIGEgc3RyYWlnaHRmb3J3YXJkIHJlcHJlc2VudGF0aW9uIGZvciB0aGVzZSB2YWx1 ZXMsIHdoaWNoIGRvZXNu4oCZdCByZXF1aXJlIHRoZSBiaW5hcnkgY29uY2F0ZW5hdGlvbiBhbmQg ZXh0cmFjdGlvbiBjb252ZW50aW9ucyBzcGVjaWZpZWQgYnkgTWNHcmV3Lg0KDQpJIGtub3cgdGhh dCBKb2huIEJyYWRsZXkgaXMgZ29pbmcgdG8gYXNrIHRoZSBxdWVzdGlvbiB0b21vcnJvdyB3aGV0 aGVyIHdlIHNob3VsZCBjaGFuZ2UgdG8gZG9pbmcgdGhlIGZpcnN0IGZvciBvdXIgY29tcG9zaXRl IENCQytITUFDIGFsZ29yaXRobXMuICBJIGJlbGlldmUgdGhhdCBkb2luZyB0aGUgc2Vjb25kIHdv dWxkIGJlIGNvdW50ZXJwcm9kdWN0aXZlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAtLSBNaWtlDQoNCkZyb206IGpvc2UtYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2Ut Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86Ym91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBS aWNoYXJkIEJhcm5lcw0KU2VudDogVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMgMTowMCBQTQ0KVG86 IFBlY2ssIE1pY2hhZWwgQQ0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW2pvc2VdIENvbmNhdCBLREYgaXNzdWVzIHdpdGggRUNESC1FUyBhbmQg Zm9yIGRlcml2aW5nIENFSy9DSUsgZnJvbSBDTUsNCg0KQWN0dWFsbHksIGZvciBldmVyeXRoaW5n IGJ1dCBrZXkgYWdyZWVtZW50LCB3ZSBjYW4ganVzdCB1c2UgZHJhZnQtbWNncmV3LWFlYWQtYWVz LWNiYy1obWFjLXNoYTIsIHdpdGggbGFyZ2VyIGtleXMuICBXZSBzaG91bGQgbm90IGJlIHNwZWNp Znlpbmcga2V5IGV4cGFuc2lvbiBoZXJlIHdoZW4gd2UgY2FuIGF2b2lkIGl0Lg0KDQotLVJpY2hh cmQNCg0KDQpPbiBUdWUsIE1hciAxMiwgMjAxMyBhdCAyOjI5IFBNLCBQZWNrLCBNaWNoYWVsIEEg PG1wZWNrQG1pdHJlLm9yZzxtYWlsdG86bXBlY2tAbWl0cmUub3JnPj4gd3JvdGU6DQpkcmFmdC1p ZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0wOCBzZWN0aW9uIDQuNy4xIGRlc2NyaWJlcyB0 aGUgdXNlIG9mIENvbmNhdCBLREYgb24gdGhlIHNoYXJlZCBzZWNyZXQgWiBlc3RhYmxpc2hlZCBi eSBFQ0RILUVTLg0KDQpUaGUgZHJhZnQgYWxsb3dzIGZvciBhbiBlbXB0eSBQYXJ0eVVJbmZvIGFu ZCBQYXJ0eVZJbmZvIGJ1dCB0aGF0IG1heSBub3QgYmUgYWxsb3dlZCBieSBOSVNUIFNQIDgwMC01 NkEgKHdoZXJlIHRoZSBDb25jYXQgS0RGIGlzIGRlZmluZWQpLg0KVGhlIGN1cnJlbnQgKE1hcmNo IDIwMDcpIHZlcnNpb24gb2YgTklTVCBTUCA4MDAtNTZBIHJlcXVpcmVzIOKAnEF0IGEgbWluaW11 bSwgUGFydHlVSW5mbyBzaGFsbCBpbmNsdWRlIElEVSwgdGhlIGlkZW50aWZpZXIgb2YgcGFydHkg VS7igJ0gYW5kIGFuIGVxdWl2YWxlbnQgcmVxdWlyZW1lbnQgZm9yIFBhcnR5VkluZm8uIChQYWdl IDQ2IG9maHR0cDovL2NzcmMubmlzdC5nb3YvcHVibGljYXRpb25zL25pc3RwdWJzLzgwMC01NkEv U1A4MDAtNTZBX1JldmlzaW9uMV9NYXIwOC0yMDA3LnBkZiApDQpUaGUgQXVndXN0IDIwMTIgZHJh ZnQgdXBkYXRlIHRvIE5JU1QgU1AgODAwLTU2QSByZXF1aXJlcyDigJxBdCBhIG1pbmltdW0sIFBh cnR5VUluZm8gc2hhbGwgaW5jbHVkZSBJRHUsIGFuIGlkZW50aWZpZXIgZm9yIHBhcnR5IFUsIGFz IGEgZGlzdGluY3QgaXRlbSBvZiBpbmZvcm1hdGlvbi7igJ0gYW5kIGFuIGVxdWl2YWxlbnQgcmVx dWlyZW1lbnQgZm9yIFBhcnR5VkluZm8uIChQYWdlIDU5IG9mIGh0dHA6Ly9jc3JjLm5pc3QuZ292 L3B1YmxpY2F0aW9ucy9kcmFmdHMvODAwLTU2YS9kcmFmdC1zcC04MDAtNTZhLnBkZiApICBNeSBp bnRlcnByZXRhdGlvbiBvZiB0aGlzIHRleHQgKG90aGVycyBtYXkgaW50ZXJwcmV0IGl0IGRpZmZl cmVudGx5KSBpcyB0aGF0IFBhcnR5VUluZm8gYW5kIFBhcnR5VkluZm8gY2Fu4oCZdCBiZSBlbXB0 eS4NCg0KSW5zdGVhZCBvZiB1c2luZyB0aGUgQ29uY2F0IEtERiwgYSBtb3JlIGFwcHJvcHJpYXRl IGNob2ljZSBtYXkgYmUgdGhlIEtERiBkZXNjcmliZWQgaW4gTklTVCBTUCA4MDAtNTZDIGFuZCBS RkMgNTg2OS4NCg0KSXRzIHJlcXVpcmVtZW50cyBhcmUgbm90IGFzIHN0cmljdC4gIChTUCA4MDAt NTZDIFBhZ2UgMTM6IOKAnElmIHRoZSBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUsIENvbnRleHQg c2hvdWxkIGluY2x1ZGUgdGhlIGlkZW50aWZpZXJzIG9mIHRoZSBwYXJ0aWVzIHdobyBhcmUgZGVy aXZpbmcgYW5kL29yIHVzaW5nIHRoZSBkZXJpdmVkIGtleWluZyBtYXRlcmlhbOKAnSkNCg0KSXQg d291bGQgbG9vayBzb21ldGhpbmcgbGlrZSB0aGlzOg0KDQpTdGVwIDEgLSBSYW5kb21uZXNzIEV4 dHJhY3Rpb246DQpLZXkgRGVyaXZhdGlvbiBLZXkgOj0gSE1BQyhzYWx0LCBaKSAgICAgICAgIChI TUFDLVNIQTI1NiBzaG91bGQgc3VmZmljZSBmb3IgYWxsIG9mIHRoZSBjdXJyZW50IGFsZ29yaXRo bXMpDQoNClN0ZXAgMiAtIEV4cGFuc2lvbiBTdGVwOg0KVXNlIHRoZSBDb3VudGVyIE1vZGUgS0RG IGRlZmluZWQgaW4gU1AgODAwLTEwOCBvciBzZWN0aW9uIDIuMyBvZiBSRkMgNTg2OSB3aXRoIHRo ZSBzYW1lIEhNQUMgYWxnb3JpdGhtIHVzZWQgaW4gc3RlcCAxIHRvIHByb2R1Y2UgbmVlZGVkIGtl eXMgZnJvbSB0aGUgS2V5IERlcml2YXRpb24gS2V5IHByb2R1Y2VkIGluIHN0ZXAgMS4NClRoZSBu ZWVkZWQga2V5cyB3b3VsZCBkZXBlbmQgb24gdGhlIHZhbHVlcyBvZiBhbGcgYW5kIGVuYy4NCklm IGFsZyBpcyBFQ0RILUVTK0ExMjhLVyBvciBFQ0RILUVTK0EyNTZLVywgYSBzaW5nbGUgMTI4IGJp dCBvciAyNTYgYml0IGtleSBpcyBuZWVkZWQgKHVzZWQgdG8gZGVjcnlwdCB0aGUgQ01LLCB3aGlj aCBtYXkgdGhlbiBuZWVkIHRvIGJlIHNwbGl0IGludG8gQ0VLL0NJSykuDQpJZiBhbGcgaXMgRUNE SC1FUywgdGhlbiB0aGUgbmVlZGVkIGtleXMgZGVwZW5kIG9uIOKAnGVuY+KAnToNCklmIGVuYyBp cyBBRVMtR0NNLCBhIDEyOCBiaXQga2V5IG9yIDI1NiBiaXQga2V5IGlzIG5lZWRlZC4NCklmIGVu YyBpcyBvbmUgb2YgdGhlIEFFQUQgQUVTLUNCQyBhbGdvcml0aG1zIGluIGRyYWZ0LW1jZ3Jldy1h ZWFkLWFlcy1jYmMtaG1hYy1zaGEyLTAxLCBhIGtleSBvZiBFTkNfS0VZX0xFTiArIE1BQ19LRVlf TEVOIGlzIG5lZWRlZCBhcyBpdOKAmXMgdGhlbiBzcGxpdCBpbnRvIHR3byBieSB0aGUgQUVBRCBh bGdvcml0aG0uDQpJZiBlbmMgaXMgb25lIG9mIHRoZSBjdXJyZW50IENCQytITUFDIG9wdGlvbnMg aW4gZHJhZnQtaWV0Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMtMDgsIHRoZW4gdHdvIGtleXMg YXJlIG5lZWRlZCwgYSBDRUsgYW5kIGEgQ0lLLiAgQ291bnRlciBNb2RlIEtERiBjb3VsZCBiZSBp bnZva2VkIHR3aWNlLCB3aXRoIGRpZmZlcmVudCBsYWJlbHMgZWFjaCB0aW1lLCBvciBDb3VudGVy IE1vZGUgS0RGIGNvdWxkIGJlIGludm9rZWQgb25jZSB0byBnZW5lcmF0ZSBhIGJpZyBrZXkgd2hp Y2ggd291bGQgdGhlbiBiZSBzcGxpdCBpbnRvIHRoZSBDRUsgYW5kIENJSy4NCg0KUmljaGFyZCBo YXMgYWxyZWFkeSBwb2ludGVkIG91dCB0aGUgaXNzdWVzIHdpdGggdXNpbmcgdGhlIENvbmNhdCBL REYgdG8gZGVyaXZlIHRoZSBDRUsvQ0lLIGZyb20gdGhlIENNSy4gIEluc3RlYWQsIG9uZSBvcHRp b24gd291bGQgYmUgdG8gdXNlIHRoZSBFeHBhbnNpb24gU3RlcCBhYm92ZTogIHVzZSB0aGUgQ291 bnRlciBNb2RlIEtERiB3aXRoIGFuIEhNQUMgdG8gZGVyaXZlIG5lY2Vzc2FyeSBrZXlzIGZyb20g dGhlIENNSy4NCkV2ZW4gaWYgd2UgdXNlIGVuY3J5cHRpb24gYWxnb3JpdGhtcyB0aGF0IGNvbWJp bmUgdGhlIGVuY3J5cHRpb24gYW5kIGludGVncml0eSBrZXkgc3VjaCBhcyB0aGUgQ0JDK0hNQUMg YWxnb3JpdGhtcyBpbiBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMi0wMSwgdGhl cmUgd2lsbCBzdGlsbCBiZSBhIG5lZWQgdG8gdGFrZSBhIHNtYWxsZXIgbWFzdGVyIGtleSBhbmQg Y3JlYXRlIHRoZSBjb21iaW5lZCBlbmNyeXB0aW9uICsgaW50ZWdyaXR5IGtleSBmcm9tIGl0Lg0K DQoNCk1pa2UNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0Kam9zZSBtYWlsaW5nIGxpc3QNCmpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBs aXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B8467A5WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly80NjQyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxp Lk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21h Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6 IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi O30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNv bnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJw bGU+PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+KzEgZm9yIHVzaW5nIHRoZSBNY0dyZXcgZHJhZnQgYW5kIFJGQyA1MTE2IGlu dGVyZmFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoZSBKT1NFLXNwZWNpZmljIEExMjhDQkMrSFMy NTYgYWxnb3JpdGhtIGxvb2tzIGxpa2UgYSB2YWxpYW50IGF0dGVtcHQgdG8gaGlkZSBzb21lIG9m IHRoZSBiaW5hcnkgcHJvY2Vzc2luZyBpbnZvbHZlZCB3aXRoIGNyeXB0byDigJMgd2hpY2ggaGFz IGFsd2F5cyBiZWVuIGRlZmluZWQgb24gYnl0ZXMsIG5vdCB0ZXh0LiBCdXQgdGhlIHJlc3VsdCBp cyBhIHBvb3IgY2hpbWVyYS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkZvciBpbnN0YW5jZSwgSldFIGlu Y2x1ZGVzIHRoZSBJViBhcyBwYXJ0IG9mIHRoZSBhZGRpdGlvbmFsIGF1dGhlbnRpY2F0ZWQgZGF0 YSAoQUFEKS4gTm8gb3RoZXIgQUVBRCBzeXN0ZW0gaXMgZGVmaW5lZCBsaWtlIHRoaXMuIEV2ZXJ5 d2hlcmUgZWxzZSB0aGUgSVYvbm9uY2UgYW5kIEFBRCBhcmUgc2VwYXJhdGUuIEkgaG9wZSB0aGF0 IGRvZXNu4oCZdCBhZHZlcnNlbHkgYWZmZWN0IHRoZSBjcnlwdG8gcHJvcGVydGllcywgYnV0IGl0 IGRvZXMgcmFpc2UgcXVlc3Rpb25zIGFib3V0IHdoZXRoZXIgaXQgaXMgaW1wb3J0YW50IGZvciBz b21lIGNyeXB0byByZWFzb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FdmVyeSBBRUFEIGFsZ29yaXRo bSB0cmVhdHMgdGhlIEFBRCBhbmQgY2lwaGVydGV4dCBhcyBieXRlcyBhcnJheXMgd2l0aCBubyBy ZXN0cmljdGlvbnMgb24gdGhlaXIgY29udGVudCAob25seSByZXN0cmljdGlvbnMgb24gdGhlaXIg bGVuZ3RoKS4gSGVuY2UgdGhleSB1c2Ugc29tZSBiaW5hcnkgcGFja2luZyB3aGVuIHByb2Nlc3Np bmcgYm90aCB0byBjYWxjdWxhdGUgYW4gaW50ZWdyaXR5IGNoZWNrLiBFWENFUFQgdGhlIEpPU0Ut c3BlY2lmaWMgQUVBRCBhbGdvcml0aG1zIChBMTI4Q0JDK0hTMjU2IGFuZCBBMjU2Q0JDK0hTNTEy KS4gVGhleSBmb3JjZSBiYXNlNjR1cmwtZW5jb2RpbmcgKjxiPmluc2lkZTwvYj4qIHRoZSBBRUFE IGFsZ29yaXRobSBzbyB0aGV5IGNhbiB1c2UgYSB0ZXh0IGRvdCDigJwu4oCdIGFzIGEgc2VwYXJh dG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hpbGUgQTEyOENCQytIUzI1NiBpcyBpbXBsZW1lbnRl ZCBieSBoYW5kIGluIEpPU0Utc3BlY2lmaWMgY29kZSB1c2luZyBBRVMgYW5kIEhNQUMgcHJpbWl0 aXZlcyB0aGUgcHJvYmxlbXMgd2l0aCB0aGlzIGNoaW1lcmEgYXJlIG1haW5seSBoaWRkZW4uIEhv d2V2ZXIsIEkgZG9u4oCZdCBiZWxpZXZlIGFueSBnZW5lcmljIEFFQUQgaW50ZXJmYWNlIGNhbiBl dmVyIGhhbmRsZSB0aGlzIEpPU0Utc3BlY2lmaWMgYWxnb3JpdGhtIGVmZmljaWVudGx5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+VGhlIOKAnGV4dHJhIHdvcmvigJ0gb2YgYWRvcHRpbmcgdGhlIDwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QUVBRCBlbmNvZGluZy9kZWNvZGlu ZyBjb252ZW50aW9ucyBpczogY29uY2F0ZW5hdGluZyBieXRlIGFycmF5czsgYW5kIHRha2luZyBh IGtub3duLWxlbmd0aCBwcmVmaXggYW5kIHN1ZmZpeCBmcm9tIGEgYnl0ZSBhcnJheS4gWW91IGNh bm5vdCBnZXQgbXVjaCBzaW1wbGVyLiBJdCBjYW4gb25seSBiZSBhbiBhbm5veWFuY2UgZm9yIGEg bGFuZ3VhZ2UgdGhhdCBpcyBub3QgYnl0ZS1hcnJheS1mcmllbmRseSwgYnV0IGV2ZW4gc3VjaCBh IGxhbmd1YWdlIHdpbGwgaGF2ZSB0byBoYW5kbGUgYnl0ZSBhcnJheXMgYXQgc29tZSBwb2ludCB0 byBpbnRlcmZhY2Ugd2l0aCBjcnlwdG8uPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5FdmVuIHVzaW5nIHRoZSBNY0dyZXcgZHJhZnQgdGhlbiBzZXBhcmF0 aW5nIHRoZSBvdXRwdXQgaW50byBJVi9jaXBoZXJ0ZXh0L01BQyB0byByZS1wYWNrYWdlIGFzIGEg Sk9TRSBtZXNzYWdlIHdvdWxkIGJlIGJldHRlciB0aGFuIHRoZSBKT1NFLXNwZWNpZmljIEExMjhD QkMrSFMyNTYgYW5kIEEyNTZDQkMrSFM1MTIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QLlMuIEkgdGhp bmsgRUNNQVNjcmlwdCBlZGl0aW9uIDYgaXMgaW50cm9kdWNpbmcgc3VwcG9ydCBmb3IgYnl0ZSBh cnJheXMgc28gZXZlbiBoYXNzbGUgaGFuZGxpbmcgYnl0ZXMgaW4gSmF2YVNjcmlwdCBzaG91bGQg ZmFkZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQn PjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gam9zZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhh bGYgT2YgPC9iPk1pa2UgSm9uZXM8YnI+PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgMTMgTWFyY2gg MjAxMyA4OjA2IEFNPGJyPjxiPlRvOjwvYj4gUGVjaywgTWljaGFlbCBBOyBKb2huIEJyYWRsZXk8 YnI+PGI+Q2M6PC9iPiBSaWNoYXJkIEJhcm5lczsgam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0 OjwvYj4gUmU6IFtqb3NlXSBDb25jYXQgS0RGIGlzc3VlcyB3aXRoIEVDREgtRVMgYW5kIGZvciBk ZXJpdmluZyBDRUsvQ0lLIGZyb20gQ01LPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlBvc3NpYmx5IHVzaW5nIHRoZSBN Y0dyZXcgZHJhZnQgaGFkIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZSwgYnV0IHRoZXJlIHdhcyBzdHJv bmcgcHVzaC1iYWNrIG9uIGl0LiZuYnNwOyBJdCB3b3VsZCBjaGFuZ2UgbW9yZSB0aGFuIHRoZSBD QkMvSE1BQyByZXByZXNlbnRhdGlvbiDigJMgaXQgd291bGQgY2hhbmdlIGFsbCB0aGUgSldFIHJl cHJlc2VudGF0aW9ucywgYXMgaXQgd291bGQgcmVtb3ZlIHRoZSBJbml0aWFsaXphdGlvbiBWZWN0 b3IgYW5kIEludGVncml0eSBWYWx1ZSBmaWVsZHMsIGFuZCBpbnN0ZWFkIHJlcXVpcmUgYWxsIGlt cGxlbWVudGF0aW9ucyB0byBpbXBsZW1lbnQgYW5kIGFwcGx5IHRoZSBBRUFEIGJpbmFyeSBlbmNv ZGluZyBhbmQgZGVjb2RpbmcgY29udmVudGlvbnMuJm5ic3A7IE5vdGUgdGhhdCB0aGlzIHdvdWxk IGNoYW5nZSBBRVMtR0NNIHRvbyDigJMgbm90IGp1c3QgQUVTLUNCQy9ITUFDLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPklmIGNvbW1vbmx5IGF2YWlsYWJsZSBjcnlw dG8gbGlicmFyaWVzIGltcGxlbWVudGVkIGFsZ29yaXRobXMgdXNpbmcgdGhlIEFFQUQgZW5jb2Rp bmcgY29udmVudGlvbnMgSSB3b3VsZCBoYXZlIG5vIHByb2JsZW0gd2l0aCB0aGlzLiZuYnNwOyBC dXQgaW4gZmFjdCwgdGhleSBkb27igJl0LiZuYnNwOyBJIGRvbuKAmXQga25vdyBvZiBhIHNpbmds ZSBsaWJyYXJ5IGluIHRoZSBhdHRhY2hlZCBzZXQgb2Ygc3VydmV5ZWQgaW1wbGVtZW50YXRpb25z IHRoYXQgZG8uJm5ic3A7IFRodXMsIGFkb3B0aW5nIHRoZSBBRUFEIGVuY29kaW5nL2RlY29kaW5n IGNvbnZlbnRpb25zIHdvdWxkIGNyZWF0ZSBleHRyYSB3b3JrIGZvciBhbGwgaW1wbGVtZW50YXRp b25zIGluIHByYWN0aWNlIOKAkyBub3QgbWFrZSB0aGluZ3Mgc2ltcGxlci4mbmJzcDsgSXQgd291 bGQgb25seSBiZSBzaW1wbGVyIGlmIHRoZSBleGlzdGluZyBjcnlwdG8gbGlicmFyaWVzIGltcGxl bWVudGVkIHRoaXMgc3RhbmRhcmQgaW50ZXJmYWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPldlIHNob3VsZCB0aGVyZWZvcmUgc3RlZXIgY2xlYXIgb2YgdGhpcy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgQmVz dCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5QLlMuJm5ic3A7IEppbSBTY2hhYWQgYWxz byBwb2ludHMgb3V0IHRoYXQgQ01TIGRvZXNu4oCZdCB1c2UgdGhlIFJGQyA1MTE2IGludGVyZmFj ZSBlaXRoZXIuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxk aXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBs YW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gUGVjaywgTWlj aGFlbCBBIFs8YSBocmVmPSJtYWlsdG86bXBlY2tAbWl0cmUub3JnIj5tYWlsdG86bXBlY2tAbWl0 cmUub3JnPC9hPl0gPGJyPjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyAyOjAy IFBNPGJyPjxiPlRvOjwvYj4gSm9obiBCcmFkbGV5OyBNaWtlIEpvbmVzPGJyPjxiPkNjOjwvYj4g UmljaGFyZCBCYXJuZXM7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYu b3JnPC9hPjxicj48Yj5TdWJqZWN0OjwvYj4gUkU6IFtqb3NlXSBDb25jYXQgS0RGIGlzc3VlcyB3 aXRoIEVDREgtRVMgYW5kIGZvciBkZXJpdmluZyBDRUsvQ0lLIGZyb20gQ01LPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFu Zz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgdGhpbmsgdGhhdCAjMiBhY3R1YWxseSByZWR1Y2Vz IGNvbXBsZXhpdHkgZm9yIGltcGxlbWVudGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGV5IGNhbiBp bXBsZW1lbnQgdGhlIFJGQyA1MTE2IGludGVyZmFjZSBvbmNlIChvciBldmVudHVhbGx5IGp1c3Qg aW52b2tlIGEgY3J5cHRvIGxpYnJhcnkgdGhhdCBpbXBsZW1lbnRzIGl0IGZvciB0aGVtKSDigJMg dGhlbiB1c2UgdGhhdCBpbXBsZW1lbnRhdGlvbiBmb3IgYWxsIHByb3RvY29scyB0aGF0IHVzZSB0 aGUgUkZDIDUxMTYgaW50ZXJmYWNlLCBub3QganVzdCBKT1NFLCBhbmQga25vdyB0aGF0IHRoZSBk ZXRhaWxzIG9mIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbiBoYXZlIGJlZW4gdGFrZW4gY2FyZSBv Zi4gPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+TWlrZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20n PjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh aG9tYSIsInNhbnMtc2VyaWYiJz4gSm9obiBCcmFkbGV5IFs8YSBocmVmPSJtYWlsdG86dmU3anRi QHZlN2p0Yi5jb20iPm1haWx0bzp2ZTdqdGJAdmU3anRiLmNvbTwvYT5dIDxicj48Yj5TZW50Ojwv Yj4gVHVlc2RheSwgTWFyY2ggMTIsIDIwMTMgNDo0OSBQTTxicj48Yj5Ubzo8L2I+IE1pa2UgSm9u ZXM8YnI+PGI+Q2M6PC9iPiBSaWNoYXJkIEJhcm5lczsgUGVjaywgTWljaGFlbCBBOyA8YSBocmVm PSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+PGI+U3ViamVjdDo8 L2I+IFJlOiBbam9zZV0gQ29uY2F0IEtERiBpc3N1ZXMgd2l0aCBFQ0RILUVTIGFuZCBmb3IgZGVy aXZpbmcgQ0VLL0NJSyBmcm9tIENNSzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+WWVzIEkgaGF2ZSB0aGUg cmVjb21tZW5kYXRpb24gdG8gY2hhbmdlIGZyb20gdXNpbmcgYSBLREYgdG8gZ2VuZXJhdGUgdGhl IENFSyBhbmQgQ0lLIGZyb20gdGhlIENNSyB0byBjb25jYXRlbmF0aW5nIHRoZSBDRUsgYW5kIENJ SyB0b2dldGhlciBhcyBpbiB0aGUgTWNHcmV3IGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT PkkgZG9uJ3QgeWV0IGhhdmUgYSBzbGlkZSBvbiB0aGUgbmV3L29sZCBpc3N1ZSBvZiBjb25jYXRl bmF0aW5nIHRoZSB0YWcgdG8gdGhlIG1lc3NhZ2UgYm9keSB2cyBzZW5kaW5nIGl0IGluIGEgc2Vw YXJhdGUgZmllbGQuICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPklm IHBlb3BsZSB3YW50IG1lIHRvIEkgY2FuIGFkZCBpdCBhcyB3ZWxsLiAmbmJzcDtUaG91Z2ggSSB0 aG91Z2h0IHRoYXQgd2FzIGEgY2xvc2VkIGlzc3VlLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5Kb2huIEIuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5PbiAyMDEzLTAz LTEyLCBhdCA0OjE5IFBNLCBNaWtlIEpvbmVzICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5K b25lc0BtaWNyb3NvZnQuY29tIj5NaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+QXMgcHJldmlvdXNseSBleHRlbnNpdmVseSBkaXNjdXNzZWQsIHRo ZSBNY0dyZXcgZHJhZnQgZG9lcyB0d28gdGhpbmdzIOKAkyBvbmUgaGVscGZ1bCBhbmQgb25lIG5v dDo8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ MS4mbmJzcDsgSXQgc3BlY2lmaWVzIHVzaW5nIGEga2V5IHRoYXQgaXMgYWN0dWFsbHkgdGhlIGNv bmNhdGVuYXRpb24gb2YgYW4gQUVTLUNCQyBrZXkgYW5kIGFuIEhNQUMgU0hBLTIga2V5LCByYXRo ZXIgdGhhbiB1c2Ugb2YgYSBLREYuJm5ic3A7IFRoYXTigJlzIGdvb2QsIGFzIGl04oCZcyBzaW1w bGUgZm9yIGltcGxlbWVudGVycy48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+Mi4mbmJzcDsgSXQgc3BlY2lmaWVzIHRoYXQgdGhlIGluaXRpYWxp emF0aW9uIHZlY3RvciBhbmQgaW50ZWdyaXR5IHZhbHVlIGJlIGNvbmNhdGVuYXRlZCB3aXRoIG90 aGVyIHZhbHVlcyBpbiBwYXJ0aWN1bGFyIHdheXMsIGFuZCBjb252ZXJzZWx5LCBob3cgdG8gZXh0 cmFjdCB0aGVtIHdoZW4gZGVjcnlwdGluZy4mbmJzcDsgVGhhdOKAmXMgbm90IGdvb2QsIGFzIGl0 IGFkZHMgY29tcGxleGl0eSBmb3IgaW1wbGVtZW50ZXJzIOKAkyBlc3BlY2lhbGx5IHdoZW4gSldF cyBhbHJlYWR5IHV0aWxpemUgYSBzdHJhaWdodGZvcndhcmQgcmVwcmVzZW50YXRpb24gZm9yIHRo ZXNlIHZhbHVlcywgd2hpY2ggZG9lc27igJl0IHJlcXVpcmUgdGhlIGJpbmFyeSBjb25jYXRlbmF0 aW9uIGFuZCBleHRyYWN0aW9uIGNvbnZlbnRpb25zIHNwZWNpZmllZCBieSBNY0dyZXcuPC9zcGFu PjxzcGFuIGxhbmc9RU4tVVM+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkga25vdyB0 aGF0IEpvaG4gQnJhZGxleSBpcyBnb2luZyB0byBhc2sgdGhlIHF1ZXN0aW9uIHRvbW9ycm93IHdo ZXRoZXIgd2Ugc2hvdWxkIGNoYW5nZSB0byBkb2luZyB0aGUgZmlyc3QgZm9yIG91ciBjb21wb3Np dGUgQ0JDK0hNQUMgYWxnb3JpdGhtcy4mbmJzcDsgSSBiZWxpZXZlIHRoYXQgZG9pbmcgdGhlIHNl Y29uZCB3b3VsZCBiZSBjb3VudGVycHJvZHVjdGl2ZS48L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPUVOLVVT PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tIE1pa2U8L3NwYW4+ PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGNsYXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNl c0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOmpvc2UtPGEgaHJl Zj0ibWFpbHRvOmJvdW5jZXNAaWV0Zi5vcmciPmJvdW5jZXNAaWV0Zi5vcmc8L2E+XTxzcGFuIGNs YXNzPWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+PGI+T24gQmVoYWxmIE9mPHNw YW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+UmljaGFyZCBC YXJuZXM8YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAxMiwgMjAxMyAxOjAwIFBNPGJyPjxiPlRvOjwvYj48 c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9zcGFuPlBlY2ssIE1pY2hh ZWwgQTxicj48Yj5DYzo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48 YnI+PGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj5SZTogW2pvc2VdIENvbmNhdCBLREYgaXNzdWVzIHdpdGggRUNESC1FUyBhbmQgZm9y IGRlcml2aW5nIENFSy9DSUsgZnJvbSBDTUs8L3NwYW4+PHNwYW4gbGFuZz1FTi1VUz48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1F Ti1VUz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5BY3R1YWxseSwgZm9yIGV2ZXJ5dGhpbmcgYnV0IGtleSBh Z3JlZW1lbnQsIHdlIGNhbiBqdXN0IHVzZSZuYnNwO2RyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMt aG1hYy1zaGEyLCB3aXRoIGxhcmdlciBrZXlzLiAmbmJzcDtXZSBzaG91bGQgbm90IGJlIHNwZWNp Znlpbmcga2V5IGV4cGFuc2lvbiBoZXJlIHdoZW4gd2UgY2FuIGF2b2lkIGl0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBs YW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIGxhbmc9 RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5PbiBUdWUsIE1hciAxMiwgMjAxMyBhdCAyOjI5IFBNLCBQ ZWNrLCBNaWNoYWVsIEEgJmx0OzxhIGhyZWY9Im1haWx0bzptcGVja0BtaXRyZS5vcmciIHRhcmdl dD0iX2JsYW5rIj48c3BhbiBzdHlsZT0nY29sb3I6cHVycGxlJz5tcGVja0BtaXRyZS5vcmc8L3Nw YW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5kcmFmdC1pZXRmLWpvc2UtanNvbi13 ZWItYWxnb3JpdGhtcy0wOCBzZWN0aW9uIDQuNy4xIGRlc2NyaWJlcyB0aGUgdXNlIG9mIENvbmNh dCBLREYgb24gdGhlIHNoYXJlZCBzZWNyZXQgWiBlc3RhYmxpc2hlZCBieSBFQ0RILUVTLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n PUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPlRoZSBkcmFmdCBhbGxvd3MgZm9yIGFuIGVtcHR5IFBh cnR5VUluZm8gYW5kIFBhcnR5VkluZm8gYnV0IHRoYXQgbWF5IG5vdCBiZSBhbGxvd2VkIGJ5IE5J U1QgU1AgODAwLTU2QSAod2hlcmUgdGhlIENvbmNhdCBLREYgaXMgZGVmaW5lZCkuPG86cD48L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4t VVM+VGhlIGN1cnJlbnQgKE1hcmNoIDIwMDcpIHZlcnNpb24gb2YgTklTVCBTUCA4MDAtNTZBIHJl cXVpcmVzIOKAnDwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTEuNXB0 Jz5BdCBhIG1pbmltdW0sPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwv c3Bhbj48aT5QYXJ0eVVJbmZvPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZuYnNw Ozwvc3Bhbj48L2k+PGI+c2hhbGw8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5i c3A7PC9zcGFuPjwvYj5pbmNsdWRlPHNwYW4gY2xhc3M9YXBwbGUtY29udmVydGVkLXNwYWNlPiZu YnNwOzwvc3Bhbj48aT5JRDwvaT48L3NwYW4+PGk+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9u dC1zaXplOjguMHB0Jz5VPC9zcGFuPjwvaT48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTEuNXB0Jz4sIHRoZSBpZGVudGlmaWVyIG9mIHBhcnR5PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48aT5VPC9pPi7igJ0gYW5kIGFuIGVxdWl2YWxlbnQg cmVxdWlyZW1lbnQgZm9yIFBhcnR5VkluZm8uIChQYWdlIDQ2IG9mPGEgaHJlZj0iaHR0cDovL2Nz cmMubmlzdC5nb3YvcHVibGljYXRpb25zL25pc3RwdWJzLzgwMC01NkEvU1A4MDAtNTZBX1Jldmlz aW9uMV9NYXIwOC0yMDA3LnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjpw dXJwbGUnPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9uaXN0cHVicy84MDAtNTZB L1NQODAwLTU2QV9SZXZpc2lvbjFfTWFyMDgtMjAwNy5wZGY8L3NwYW4+PC9hPjxzcGFuIGNsYXNz PWFwcGxlLWNvbnZlcnRlZC1zcGFjZT4mbmJzcDs8L3NwYW4+KTwvc3Bhbj48c3BhbiBsYW5nPUVO LVVTPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBsYW5nPUVOLVVTPlRoZSBBdWd1c3QgMjAxMiBkcmFmdCB1cGRhdGUgdG8gTklTVCBTUCA4 MDAtNTZBIHJlcXVpcmVzIOKAnEF0IGEgbWluaW11bSwgUGFydHlVSW5mbyBzaGFsbCBpbmNsdWRl IElEdSwgYW4gaWRlbnRpZmllciBmb3IgcGFydHkgVSwgYXMgYSBkaXN0aW5jdCBpdGVtIG9mIGlu Zm9ybWF0aW9uLuKAnSBhbmQgYW4gZXF1aXZhbGVudCByZXF1aXJlbWVudCBmb3IgUGFydHlWSW5m by4gKFBhZ2UgNTkgb2Y8c3BhbiBjbGFzcz1hcHBsZS1jb252ZXJ0ZWQtc3BhY2U+Jm5ic3A7PC9z cGFuPjxhIGhyZWY9Imh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9kcmFmdHMvODAw LTU2YS9kcmFmdC1zcC04MDAtNTZhLnBkZiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdj b2xvcjpwdXJwbGUnPmh0dHA6Ly9jc3JjLm5pc3QuZ292L3B1YmxpY2F0aW9ucy9kcmFmdHMvODAw LTU2YS9kcmFmdC1zcC04MDAtNTZhLnBkZjwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9YXBwbGUtY29u dmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj4pJm5ic3A7IE15IGludGVycHJldGF0aW9uIG9mIHRo aXMgdGV4dCAob3RoZXJzIG1heSBpbnRlcnByZXQgaXQgZGlmZmVyZW50bHkpIGlzIHRoYXQgUGFy dHlVSW5mbyBhbmQgUGFydHlWSW5mbyBjYW7igJl0IGJlIGVtcHR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPkluc3RlYWQgb2YgdXNpbmcgdGhlIENvbmNhdCBLREYsIGEgbW9yZSBhcHBy b3ByaWF0ZSBjaG9pY2UgbWF5IGJlIHRoZSBLREYgZGVzY3JpYmVkIGluIE5JU1QgU1AgODAwLTU2 QyBhbmQgUkZDIDU4NjkuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwPjxzcGFuIGxhbmc9 RU4tVVM+SXRzIHJlcXVpcmVtZW50cyBhcmUgbm90IGFzIHN0cmljdC4mbmJzcDsgKFNQIDgwMC01 NkMgUGFnZSAxMzog4oCcPC9zcGFuPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MS41cHQnPklmIHRoZSBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUsPHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48aT5Db250ZXh0PHNwYW4gY2xhc3M9YXBwbGUt Y29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2k+PGI+c2hvdWxkPHNwYW4gY2xhc3M9YXBw bGUtY29udmVydGVkLXNwYWNlPiZuYnNwOzwvc3Bhbj48L2I+aW5jbHVkZSB0aGUgaWRlbnRpZmll cnMgb2YgdGhlIHBhcnRpZXMgd2hvIGFyZSBkZXJpdmluZyBhbmQvb3IgdXNpbmcgdGhlIGRlcml2 ZWQga2V5aW5nIG1hdGVyaWFs4oCdKTwvc3Bhbj48c3BhbiBsYW5nPUVOLVVTPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTPkl0IHdvdWxkIGxvb2sgc29tZXRoaW5nIGxpa2UgdGhpczo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V Uz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1VUz5TdGVwIDEgLSBSYW5kb21uZXNzIEV4dHJhY3Rpb246PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+S2V5IERlcml2YXRpb24gS2V5IDo9IEhNQUMoc2FsdCwgWikmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKEhNQUMtU0hBMjU2IHNob3VsZCBzdWZm aWNlIGZvciBhbGwgb2YgdGhlIGN1cnJlbnQgYWxnb3JpdGhtcyk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g bGFuZz1FTi1VUz5TdGVwIDIgLSBFeHBhbnNpb24gU3RlcDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5Vc2UgdGhlIENv dW50ZXIgTW9kZSBLREYgZGVmaW5lZCBpbiBTUCA4MDAtMTA4IG9yIHNlY3Rpb24gMi4zIG9mIFJG QyA1ODY5IHdpdGggdGhlIHNhbWUgSE1BQyBhbGdvcml0aG0gdXNlZCBpbiBzdGVwIDEgdG8gcHJv ZHVjZSBuZWVkZWQga2V5cyBmcm9tIHRoZSBLZXkgRGVyaXZhdGlvbiBLZXkgcHJvZHVjZWQgaW4g c3RlcCAxLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBsYW5nPUVOLVVTPlRoZSBuZWVkZWQga2V5cyB3b3VsZCBkZXBlbmQgb24gdGhlIHZh bHVlcyBvZiBhbGcgYW5kIGVuYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz5JZiBhbGcgaXMgRUNESC1FUytBMTI4S1cg b3IgRUNESC1FUytBMjU2S1csIGEgc2luZ2xlIDEyOCBiaXQgb3IgMjU2IGJpdCBrZXkgaXMgbmVl ZGVkICh1c2VkIHRvIGRlY3J5cHQgdGhlIENNSywgd2hpY2ggbWF5IHRoZW4gbmVlZCB0byBiZSBz cGxpdCBpbnRvIENFSy9DSUspLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPklmIGFsZyBpcyBFQ0RILUVTLCB0aGVuIHRo ZSBuZWVkZWQga2V5cyBkZXBlbmQgb24g4oCcZW5j4oCdOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPklmIGVuYyBpcyBB RVMtR0NNLCBhIDEyOCBiaXQga2V5IG9yIDI1NiBiaXQga2V5IGlzIG5lZWRlZC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1V Uz5JZiBlbmMgaXMgb25lIG9mIHRoZSBBRUFEIEFFUy1DQkMgYWxnb3JpdGhtcyBpbiBkcmFmdC1t Y2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMi0wMSwgYSBrZXkgb2YgRU5DX0tFWV9MRU4gKyBN QUNfS0VZX0xFTiBpcyBuZWVkZWQgYXMgaXTigJlzIHRoZW4gc3BsaXQgaW50byB0d28gYnkgdGhl IEFFQUQgYWxnb3JpdGhtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLVVTPklmIGVuYyBpcyBvbmUgb2YgdGhlIGN1cnJlbnQg Q0JDK0hNQUMgb3B0aW9ucyBpbiBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcy0w OCwgdGhlbiB0d28ga2V5cyBhcmUgbmVlZGVkLCBhIENFSyBhbmQgYSBDSUsuJm5ic3A7IENvdW50 ZXIgTW9kZSBLREYgY291bGQgYmUgaW52b2tlZCB0d2ljZSwgd2l0aCBkaWZmZXJlbnQgbGFiZWxz IGVhY2ggdGltZSwgb3IgQ291bnRlciBNb2RlIEtERiBjb3VsZCBiZSBpbnZva2VkIG9uY2UgdG8g Z2VuZXJhdGUgYSBiaWcga2V5IHdoaWNoIHdvdWxkIHRoZW4gYmUgc3BsaXQgaW50byB0aGUgQ0VL IGFuZCBDSUsuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+UmljaGFyZCBoYXMgYWxyZWFk eSBwb2ludGVkIG91dCB0aGUgaXNzdWVzIHdpdGggdXNpbmcgdGhlIENvbmNhdCBLREYgdG8gZGVy aXZlIHRoZSBDRUsvQ0lLIGZyb20gdGhlIENNSy4mbmJzcDsgSW5zdGVhZCwgb25lIG9wdGlvbiB3 b3VsZCBiZSB0byB1c2UgdGhlIEV4cGFuc2lvbiBTdGVwIGFib3ZlOiAmbmJzcDt1c2UgdGhlIENv dW50ZXIgTW9kZSBLREYgd2l0aCBhbiBITUFDIHRvIGRlcml2ZSBuZWNlc3Nhcnkga2V5cyBmcm9t IHRoZSBDTUsuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+RXZlbiBpZiB3ZSB1c2UgZW5jcnlwdGlvbiBhbGdv cml0aG1zIHRoYXQgY29tYmluZSB0aGUgZW5jcnlwdGlvbiBhbmQgaW50ZWdyaXR5IGtleSBzdWNo IGFzIHRoZSBDQkMrSE1BQyBhbGdvcml0aG1zIGluIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMt aG1hYy1zaGEyLTAxLCB0aGVyZSB3aWxsIHN0aWxsIGJlIGEgbmVlZCB0byB0YWtlIGEgc21hbGxl ciBtYXN0ZXIga2V5IGFuZCBjcmVhdGUgdGhlIGNvbWJpbmVkIGVuY3J5cHRpb24gKyBpbnRlZ3Jp dHkga2V5IGZyb20gaXQuPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9 RU4tVVM+TWlrZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLVVTPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48c3Bh biBsYW5nPUVOLVVTPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5qb3NlIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRm Lm9yZyI+PHNwYW4gc3R5bGU9J2NvbG9yOnB1cnBsZSc+am9zZUBpZXRmLm9yZzwvc3Bhbj48L2E+ PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSdjb2xvcjpwdXJwbGUnPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tVVM+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiJIZWx2ZXRp Y2EiLCJzYW5zLXNlcmlmIic+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+am9zZSBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0 Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vam9zZSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9qb3NlPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1VUz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150B8467A5WSMSG3153Vsrv_-- From bcampbell@pingidentity.com Tue Mar 12 18:34:47 2013 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 198E411E80D1 for ; Tue, 12 Mar 2013 18:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.868 X-Spam-Level: X-Spam-Status: No, score=-5.868 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4QFwyO0VwEOg for ; Tue, 12 Mar 2013 18:34:45 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 749FD21F8C6F for ; Tue, 12 Mar 2013 18:34:45 -0700 (PDT) Received: from mail-oa0-f71.google.com ([209.85.219.71]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUT/XtWWJR8y86zPTSD2n9PI5e9WDP9g6@postini.com; Tue, 12 Mar 2013 18:34:45 PDT Received: by mail-oa0-f71.google.com with SMTP id o6so2682518oag.6 for ; Tue, 12 Mar 2013 18:34:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=Kkb++jl2yZB5H1JLZxnCfDko/jdEC7nHP6iWXvCSvHM=; b=N+kqGl4voAFHIHPbfMYD3fV+gjRZ3v+3MYt3MazS9HqOuHlhozU4RBkBgBFnj35qzu ZQebB1ZAvAWSYsgnsLx9rxjzXs1MY3G+6Fu7jKZGscpQrWu2HrmR8EOsk9GlIaSCTS4V TME2zELbbr5bb5sAVurQB6q/ZfinY3sxV1XoHc2lW+muvnJF0d4qyAloskztIxr7QdBv uMx2Nb3KaGU4myQWixffX0SIIvF69KGXmOjMSK/mKzu3po6fBejIYI6pd/FV7682NoRs iI1OVva7gJ/ugMd5aDzL7jDxR41oh7vhUQKrZNl1NImA5M36jutLBGcMrWmAal/VPNSd Akew== X-Received: by 10.50.213.41 with SMTP id np9mr13749141igc.79.1363138484698; Tue, 12 Mar 2013 18:34:44 -0700 (PDT) X-Received: by 10.50.213.41 with SMTP id np9mr13749139igc.79.1363138484595; Tue, 12 Mar 2013 18:34:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 12 Mar 2013 18:34:14 -0700 (PDT) In-Reply-To: References: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> From: Brian Campbell Date: Tue, 12 Mar 2013 21:34:14 -0400 Message-ID: To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=f46d04462eb6277e4504d7c469f2 X-Gm-Message-State: ALoCoQl332vnQ3eu598U7HrogZV5HrKRPMg1wGK9d6xytXv+SDItCONrJYU4jEssb/coE+OQWEdAw2sbJIYEkq8DlMheJM+rEeROpLl66Lr5Rh3+ygGCBJr2yfGrpY3VfK5BsrKr2pFl Subject: Re: [jose] Proposed resolution of header criticality issue 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, 13 Mar 2013 01:34:47 -0000 --f46d04462eb6277e4504d7c469f2 Content-Type: text/plain; charset=ISO-8859-1 Yeah, I'm with Dick on this one. There will be stuff in the header that helps identify the key but the more general concern of managing and storing keys will not be done by the JOSE library itself but rather by the application using it. And that application will need to have access to headers like "kid" to be able to do that. On Tue, Mar 12, 2013 at 8:24 PM, Dick Hardt wrote: > I expect to look at the header to see the 'kid' so I know what key to > fetch to hand to the library. Does not make sense for the library to store > and manage keys -- I expect the keys are handed to the library as needed. > > > On Tue, Mar 12, 2013 at 4:46 PM, John Bradley wrote: > >> The application wanting to see the whole header is also a valid >> perspective. >> >> I guess the question is if every application should have to create its >> own way to extract the header info or should a lib be expected to make them >> available. >> >> Some of this discussion comes from CMS where the crypto info/header info >> is not exposed to applications. >> >> I think that is not the right thing to do. >> >> If we are going with adding top level claims then we should probably say >> there is an expectation that the header is also available to applications, >> which is what I think you expect. >> >> John B. >> >> On 2013-03-12, at 7:39 PM, Dick Hardt wrote: >> >> > >> > On Mar 12, 2013, at 4:13 PM, John Bradley wrote: >> > >> >> Currently the header has integrity protection. >> > >> > Glad to hear I did that right. >> > >> >> >> >> The proposed changes to the spec allow what you are doing. The thing >> is that a standard JWE library is not going to know about your forwarding >> rules. >> > >> > I would hope that a standard JWE library would ignore my forwarding >> rules. That is done at the protocol layer (which should be obvious since >> the JWE library won't know how to forward) >> > >> > In my libraries, I have a JWT parser that will give me the header and >> the payload if a JWS. Hopefully other libraries will have parsers so that >> the App can make decision about what to do. >> > >> >> My proposal was to add a containing element for all the additional >> claims intended for processing outside of the JWE/JWS crypto library. >> > >> > Or I could just add an app specific claim like I do in the payload. >> > >> >> That reduces namespace collision and allows the library to pass back >> to the application any claims in the header that are not intended for >> JWEJWS. >> > >> > We already have a mechanism for namespace collision in the payload. Why >> invent a new one? >> > >> > btw: I like my parsing implementation just fine -- passing back just >> the claims does not meet my purpose -- I want to see all of the header, and >> see the payload if it is a JWS >> > >> >> >> >> The three alternatives are: >> >> 1 preclude non JWE/S claims in the header (won't work for you) >> >> 2 a dedicated JSON member that contains claims intended for >> applications or external extensions >> >> 3 throw in everything as a top level claim and have applications sniff >> the header looking for what they need. >> > >> > Why not use the same extension mechanism that is being used for the >> payload? Or allow me to put payload properties into the header as well? >> There is no namespace collision since it is a reserved property value. >> > >> >> >> >> The proposal going to the meeting tomorrow is 2 based on it being the >> cleanest way to pass on the additional claims to applications using a >> general purpose JOSE lib. >> > >> > I don't just want the additional claims, I want the full header parsed >> and be able to look at all of it. >> > >> > -- Dick >> >> > > > -- > -- Dick > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d04462eb6277e4504d7c469f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Yeah, I'm with Dick on this one. There will be stuff i= n the header that=20 helps identify the key but the more general concern of managing and=20 storing keys will not be done by the JOSE library itself but rather by=20 the application using it. And that application will need to have access=20 to headers like "kid" to be able to do that.


On Tue, Mar 12, 2013 at 8:24= PM, Dick Hardt <dick.hardt@gmail.com> wrote:
I expect to look at the hea= der to see the 'kid' so I know what key to fetch to hand to the lib= rary. Does not make sense for the library to store and manage keys -- I exp= ect the keys are handed to the library as needed.


On Tue, Mar 12, 2013 at 4:46 PM, John Bradley &= lt;ve7jtb@ve7jtb.com= > wrote:
The application wanting to see the whole header is also a valid perspective= .

I guess the question is if every application should have to create its own = way to extract the header info or should a lib be expected to make them ava= ilable.

Some of this discussion comes from CMS where the crypto info/header info is= not exposed to applications.

I think that is not the right thing to do.

If we are going with adding top level claims then we should probably say th= ere is an expectation that the header is also available to applications, wh= ich is what I think you expect.

John B.

On 2013-03-12, at 7:39 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

>
> On Mar 12, 2013, at 4:13 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> Currently the header has integrity protection.
>
> Glad to hear I did that right.
>
>>
>> The proposed changes to the spec allow what you are doing. =A0 The= thing is that a standard JWE library is not going to know about your forwa= rding rules.
>
> I would hope that a standard JWE library would ignore my forwarding ru= les. That is done at the protocol layer (which should be obvious since the = JWE library won't know how to forward)
>
> In my libraries, I have a JWT parser that will give me the header and = the payload if a JWS. Hopefully other libraries will have parsers so that t= he App can make decision about what to do.
>
>> My proposal was to add a containing element for all the additional= claims intended for processing outside of the JWE/JWS crypto library.
>
> Or I could just add an app specific claim like I do in the payload. >
>> That reduces namespace collision and allows the library to pass ba= ck to the application any claims in the header that are not intended for JW= EJWS.
>
> We already have a mechanism for namespace collision in the payload. Wh= y invent a new one?
>
> btw: I like my parsing implementation just fine -- passing back just t= he claims does not meet my purpose -- I want to see all of the header, and = see the payload if it is a JWS
>
>>
>> The three alternatives are:
>> 1 preclude non JWE/S claims in the header =A0(won't work for y= ou)
>> 2 a dedicated JSON member that contains claims intended for applic= ations or external extensions
>> 3 throw in everything as a top level claim and have applications s= niff the header looking for what they need.
>
> Why not use the same extension mechanism that is being used for the pa= yload? Or allow me to put payload properties into the header as well? There= is no namespace collision since it is a reserved property value.
>
>>
>> The proposal going to the meeting tomorrow is 2 based on it being = the cleanest way to pass on the additional claims to applications using a g= eneral purpose JOSE lib.
>
> I don't just want the additional claims, I want the full header pa= rsed and be able to look at all of it.
>
> -- Dick




<= /div>--
-- Dick

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d04462eb6277e4504d7c469f2-- From James.H.Manger@team.telstra.com Tue Mar 12 19:09:00 2013 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 4F97D11E8113 for ; Tue, 12 Mar 2013 19:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.822 X-Spam-Level: X-Spam-Status: No, score=-0.822 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 702tSK+BLonh for ; Tue, 12 Mar 2013 19:08:59 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 77E4511E80D1 for ; Tue, 12 Mar 2013 19:08:59 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,833,1355058000"; d="scan'208";a="118776994" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipobni.tcif.telstra.com.au with ESMTP; 13 Mar 2013 13:08:54 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7012"; a="68444464" Received: from wsmsg3704.srv.dir.telstra.com ([172.49.40.197]) by ipcani.tcif.telstra.com.au with ESMTP; 13 Mar 2013 13:08:54 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3704.srv.dir.telstra.com ([172.49.40.197]) with mapi; Wed, 13 Mar 2013 13:08:53 +1100 From: "Manger, James H" To: "jose@ietf.org" Date: Wed, 13 Mar 2013 13:08:48 +1100 Thread-Topic: "crit" strings don't have to be field names Thread-Index: Ac4e7R9H1kqa+ob2SUSyRmT72Gsc4AALohOPABw0fkA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B8469AB@WSMSG3153V.srv.dir.telstra.com> References: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> In-Reply-To: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [jose] "crit" strings don't have to be field names 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, 13 Mar 2013 02:09:00 -0000 QXMgd2UgZGVmaW5lIHRoZSAiY3JpdCIgZmllbGQgd2UgZG9uJ3QgbmVlZCB0byB1c2UgZmllbGQg bmFtZXMgYXMgdGhlIGNyaXRpY2FsIHN0cmluZ3MuDQoNCkltcGxlbWVudGF0aW9ucyB3aWxsIGhh dmUgYSBsaXN0IG9mIGNyaXRpY2FsIHN0cmluZ3MgdGhleSB1bmRlcnN0YW5kIChiYXNlZCBvbiB0 aGUgc3BlY3MgdGhhdCBkZWZpbmUgdGhvc2UgY3JpdGljYWwgc3RyaW5ncykgYW5kIHdpbGwgY29u ZmlybSB0aGF0IGFsbCB0aGUgImNyaXQiIHZhbHVlcyBhcmUgaW4gdGhlaXIgbGlzdC4gVGhpcyB3 aWxsIGJlIGEgZGlzdGluY3Qgc3RlcCBmcm9tIHRoZSBvdGhlciBjb2RlIHRoYXQgdXNlcyBzcGVj aWZpYyBmaWVsZHMuDQoNCkZvciBpbnN0YW5jZSwgaWYgd2UgZGVmaW5lZCBhIHNpbXBsZSBLREYg aW5pdGlhbGx5IHRoZW4gbGF0ZXIgc3BlY2lmaWVkIHN1cHBvcnQgZm9yIHRoZSBOSVNUIDgwMC01 NkEgQ29uY2F0IEtERiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVmaW5lIDEgY3JpdGljYWwgc3Ry aW5nICJuaXN0ODAwLTU2QSIsIGluc3RlYWQgb2YgbGlzdGluZyAiUGFydHlVSW5mbyIsICJQYXJ0 eVZJbmZvIiwgIlN1cHBQdWJJbmZvIiwgYW5kICJTdXBwUHJpdmVJbmZvIiBmaWVsZHMgbmFtZXMg aW4gdGhlICJjcml0IiBmaWVsZCAtLSBhbnkgb2Ygd2hpY2ggbWlnaHQgYmUgYWJzZW50IGZyb20g YSBwYXJ0aWN1bGFyIEpPU0UgbWVzc2FnZSBpZiB0aGV5IGhhZCBzb21lIGRlZmF1bHQgdmFsdWUu DQoNCkFub3RoZXIgZXhhbXBsZTogaWYgYSBncm91cCBpbnNpc3RzIG9uIGEgc3Ryb25nIHNpZ25h dHVyZSB2ZXJpZmljYXRpb24gcG9saWN5IChlZyBNVVNUIHVzZSBPQ1NQLCBNVVNUIGhhcmQtZmFp bCBpZiBPQ1NQIGlzIHVuYXZhaWxhYmxlLCBNVVNUIGNoZWNrIENlcnRpZmljYXRlIFRyYW5zcGFy ZW5jeSwgYW5kIE1VU1QgbG9nIHJlc3VsdHMgZm9yIDcgeWVhcnMpIHRoZXJlIGlzIG5vIG5ldyBo ZWFkZXIgZmllbGQgdG8gYWRkIHRvIGEgSldTLCBidXQgaXQgY291bGQgZGVmaW5lIHRoZSBjcml0 aWNhbCBzdHJpbmcgIlN0cm9uZ1NpZzEiLg0KIA0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCiAtLS0t LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IFtqb3NlXSBQcm9wb3Nl ZCByZXNvbHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KPiBGcm9tOiBLYXJlbiBP J0Rvbm9naHVlIDxvZG9ub2dodWVAaXNvYy5vcmc+DQo+IERhdGU6IFR1ZSwgTWFyY2ggMTIsIDIw MTMgMTI6MzEgYW0NCj4gVG86IGpvc2VAaWV0Zi5vcmcNCg0KPiAgMy4gIERlZmluZSBhIG5ldyBo ZWFkZXIgZmllbGQgdGhhdCBsaXN0cyB3aGljaCBhZGRpdGlvbmFsIGZpZWxkcyBub3QNCj4gZGVm aW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFj dGVkIHVwb24NCj4gd2hlbiBwcmVzZW50LiAgRm9yIGluc3RhbmNlLCBhbiBleHBpcmF0aW9uLXRp bWUgZXh0ZW5zaW9uIGZpZWxkIGNvdWxkDQo+IGJlIG1hcmtlZCBhcyBtdXN0LWJlLXVuZGVyc3Rv b2QtYW5kLWFjdGVkLXVwb24uICBPbmUgcG9zc2libGUgbmFtZSBmb3INCj4gdGhpcyB3b3VsZCBi ZSDigJxjcml04oCdIChjcml0aWNhbCkuICBBbiBleGFtcGxlIHVzZSwgYWxvbmcgd2l0aCBhDQo+ IGh5cG90aGV0aWNhbCDigJxleHDigJ0gKGV4cGlyYXRpb24tdGltZSkgZmllbGQgaXM6DQo+IA0K PiAgICB7ImFsZyI6IkVTMjU2IiwNCj4gICAgICJjcml0IjpbImV4cCJdLA0KPiAgICAgImV4cOKA nToxMzYzMjg0MDAwDQo+ICAgIH0NCg0K From trac+jose@trac.tools.ietf.org Tue Mar 12 20:13:55 2013 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 BAB3021F896D for ; Tue, 12 Mar 2013 20:13:55 -0700 (PDT) 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=[AWL=0.000, 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 YMemOpUa2-TN for ; Tue, 12 Mar 2013 20:13:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1210321F8941 for ; Tue, 12 Mar 2013 20:13:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:53055 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFc8S-0004vG-An; Wed, 13 Mar 2013 04:13:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Wed, 13 Mar 2013 03:13:48 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/jose/trac/ticket/12#comment:1 Message-ID: <080.6281ace3b84f0e1856efc6af4a498831@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130313031355.1210321F8941@ietfa.amsl.com> Resent-Date: Tue, 12 Mar 2013 20:13:54 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 03:13:56 -0000 #12: x5c incorrect in JWE Comment (by michael.jones@microsoft.com): I agree that the issues reported by Brian should be corrected. That doesn't constitue a case to remove the functionality entirely. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Wed Mar 13 05:03:10 2013 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 C6B5921F8D57 for ; Wed, 13 Mar 2013 05:03:10 -0700 (PDT) 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 LE3xJO0ylm0q for ; Wed, 13 Mar 2013 05:03:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1A27921F8D43 for ; Wed, 13 Mar 2013 05:03:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:59974 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UFkOY-0000AJ-DN; Wed, 13 Mar 2013 13:02:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com X-Trac-Project: jose Date: Wed, 13 Mar 2013 12:02:58 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/12#comment:2 Message-ID: <080.a744f604a8e1acddefaa722dc1ac2347@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130313120310.1A27921F8D43@ietfa.amsl.com> Resent-Date: Wed, 13 Mar 2013 05:03:09 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 12:03:10 -0000 #12: x5c incorrect in JWE Comment (by bcampbell@pingidentity.com): True, the issues alone don't constitue a case to remove the functionality. But what is the case to *have* the functionality? As written it doesn't work with the currently defined algorithms (which suggests that it's not being used). If those issues are fixed, it provides dubious value for the current algorithms but would preclude it's use for possible future applications where it'd be more meaningful - like for for the sender to provide its own cert chain for use with a ECDH-SS alg. Maybe I'm bike-shedding on this one a bit but it seems silly to have it as a reserved header that doesn't do anything useful as defined but might preclude something useful down the road. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From bcampbell@pingidentity.com Wed Mar 13 06:30:35 2013 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 A2D0621F8995 for ; Wed, 13 Mar 2013 06:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xyg6DpAX2fIt for ; Wed, 13 Mar 2013 06:30:35 -0700 (PDT) Received: from na3sys009aog121.obsmtp.com (na3sys009aog121.obsmtp.com [74.125.149.145]) by ietfa.amsl.com (Postfix) with ESMTP id 1E1D021F8626 for ; Wed, 13 Mar 2013 06:30:35 -0700 (PDT) Received: from mail-ia0-f198.google.com ([209.85.210.198]) (using TLSv1) by na3sys009aob121.postini.com ([74.125.148.12]) with SMTP ID DSNKUUB/eiLp4vwFYvVktOBF/+jDVCRl5D7H@postini.com; Wed, 13 Mar 2013 06:30:35 PDT Received: by mail-ia0-f198.google.com with SMTP id o25so3168700iad.1 for ; Wed, 13 Mar 2013 06:30:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=tF6KGF4UW6mnIf/MzH1f0VVb8Y3AlLhlZqrEyz6SN5k=; b=abN5Wg8S04k1mIguDahowWUH3uKpMH89w1g/G4Dq/7eWOxlBWNLyazT0k59tTMbCJC ilJAx98S423x4Go1Wtt1R/2PtDvgSToRPAfT2tt4n0we9BnCoAkcxoggpc/fWTEHykQj LwOMT9DkaKp7wHSh6KBMimvJfBHVAzmvur5Y/o6DvgK8U1KUtejep0GbGUy/jhwVV2np 5OkmAm41Fn3s9B3pZyGLJwdB26yu++t/tsqTVoKYrVs58WCEaHvtCzvUb94HCt6Luyq0 IQlmLFw/LITrFSaM5zBqxesAJMLoow0w+6hhfpXjeCTyH/xkFG0iSVNJ2RPzRgbstvvP 317A== X-Received: by 10.50.213.41 with SMTP id np9mr15901479igc.79.1363181434539; Wed, 13 Mar 2013 06:30:34 -0700 (PDT) X-Received: by 10.50.213.41 with SMTP id np9mr15901472igc.79.1363181434459; Wed, 13 Mar 2013 06:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Wed, 13 Mar 2013 06:30:04 -0700 (PDT) From: Brian Campbell Date: Wed, 13 Mar 2013 09:30:04 -0400 Message-ID: To: "jose@ietf.org" , Prateek Mishra Content-Type: multipart/alternative; boundary=f46d04462eb62a734904d7ce6918 X-Gm-Message-State: ALoCoQmByq8hOlXqqWB+ZGF0rCMbSYuxAc/SjNGGGixHh+GFRioPoCfaAEZMhJUpgq4UoQSyR3EfW4C37Weu6Cx0DEyBCHz7mAnmgE1T8UoMbNUD4v1As1oswylO63mSdE8WTgqt/0sD Subject: [jose] One JOSE toolkit... 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, 13 Mar 2013 13:30:35 -0000 --f46d04462eb62a734904d7ce6918 Content-Type: text/plain; charset=ISO-8859-1 Parteek expressed concern about a perceived lack of available JOSE implementations at the WG meeting this morning. A few people, including myself, chimed in about implementations. I've not publicized it previously because it's still very much a work in progress but I've got an open source implementation, which is available at: https://bitbucket.org/b_c/jose4j There's no JWE support yet (I've been procrastinating doing that and waiting for JWE to stabilize more) but it should currently provide a fairly complete implementation of JWS and JWK (and the relevant pieces of JWA). --f46d04462eb62a734904d7ce6918 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Parteek expressed concern about a perceived lack of a= vailable JOSE implementations at the WG meeting this morning. A few people,= including myself, chimed in about implementations.

I= 9;ve not publicized it previously because it's still very much a work i= n progress but I've got an open source implementation, which is availab= le at: https://bitbucket.org/b= _c/jose4j

There's no JWE support yet (I've been procrastinatin= g doing that and waiting for JWE to stabilize more) but it should currently= provide a fairly complete implementation of JWS and JWK (and the relevant = pieces of JWA).=A0
--f46d04462eb62a734904d7ce6918-- From sakimura@gmail.com Wed Mar 13 07:32:37 2013 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 1A02521F8CEF for ; Wed, 13 Mar 2013 07:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 sxyXG7wNlKT5 for ; Wed, 13 Mar 2013 07:32:36 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A321F8E49 for ; Wed, 13 Mar 2013 07:32:35 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gw10so1170012lab.41 for ; Wed, 13 Mar 2013 07:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=yT4Uc/hWpQD3yesIk1YePRWG/O9UA3cNjG/E/FXeH08=; b=vfbUH/tOHzEA24fgSMK1IbZ37zY+bwlCXDEc8Lr8Vn9kF0jvs5QRPMUXzJEISQnJl/ T/ChRnLERkvVVl0RN2HisLWMs2tiJi3zQFfp2XVDzplBMzLmJWkjkAMLm4xrrvC81SiP 5XDpEQCs0kRQnqXO1nY5RkOIpSC09pzjMLh/Un71ZTF4crMsBRdW7RHxQX/gZySLc50s e0M/xQcldZWxh/qO9//aiB5rwKhf9DiLovIXm2nSb24PBKG6lSGrWR+Z96xMsEDTzfNf x2zmaGRo75ioQXTSvdOAT+73m3GVLqzYhFO0Wt0akgT7Gd20ijwrcg4PBiN7KFngNbJm ahUw== MIME-Version: 1.0 X-Received: by 10.152.109.112 with SMTP id hr16mr17901254lab.38.1363185154409; Wed, 13 Mar 2013 07:32:34 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Wed, 13 Mar 2013 07:32:34 -0700 (PDT) Date: Wed, 13 Mar 2013 23:32:34 +0900 Message-ID: From: Nat Sakimura To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [jose] Combining the documents and MTI 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, 13 Mar 2013 14:32:37 -0000 In the interest of the time keeping, I did not ask the question in the room but I was wondering whether combining the documents would impact the way MTIs are written. My hope is not but just want it to be clarified. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From sakimura@gmail.com Wed Mar 13 07:40:28 2013 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 665FD21F8A41 for ; Wed, 13 Mar 2013 07:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 tPhR9vuk1Qim for ; Wed, 13 Mar 2013 07:40:27 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 716FB21F8B20 for ; Wed, 13 Mar 2013 07:40:27 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id gf7so992753lbb.4 for ; Wed, 13 Mar 2013 07:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=OUYG0HWEq10Yorn2P+JSSp0chEQcS2mBXDw/DfVOxaI=; b=r0O4CJP/OHtoz2m02Qu8SZ6Hdc7VCv1gJ1oHNQXFjK6elrise+tMgk6aKLPMH0YYIM IWKmuojsTarI7UvP5Dbbl9ipes4Qp/K3/MRwyJsjYQEKlfJYc4lELPM0pPwhHi9SoS34 pzeEnpP99XfL0DgllS9wH3ccPYFrS2PWI0xa9so+KYRwLGftWYOhwh6s2Z8lc4c1Ykyv YmPZPEwL1BV1M4cFyNY5CrSuLDdmx+NH2EKIH0FCFODoYLD2KI+cp0VgCrYPUoGwZ2Jd Q2kwvgsHQ/OxqMRgILlhQbnWixraf+2KTRRfUbLUpWNCl4wdqRzeJTazZNysRtWNOBVU 2MLg== MIME-Version: 1.0 X-Received: by 10.112.41.101 with SMTP id e5mr7526869lbl.120.1363185626364; Wed, 13 Mar 2013 07:40:26 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Wed, 13 Mar 2013 07:40:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 13 Mar 2013 23:40:26 +0900 Message-ID: From: Nat Sakimura To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: Prateek Mishra , "jose@ietf.org" Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 14:40:28 -0000 Here is another one: https://github.com/nov/json-jwt/tree/master/lib/json 2013/3/13 Brian Campbell : > Parteek expressed concern about a perceived lack of available JOSE > implementations at the WG meeting this morning. A few people, including > myself, chimed in about implementations. > > I've not publicized it previously because it's still very much a work in > progress but I've got an open source implementation, which is available at: > https://bitbucket.org/b_c/jose4j > > There's no JWE support yet (I've been procrastinating doing that and waiting > for JWE to stabilize more) but it should currently provide a fairly complete > implementation of JWS and JWK (and the relevant pieces of JWA). > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From jricher@mitre.org Wed Mar 13 08:05:57 2013 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 6385521F8EC5 for ; Wed, 13 Mar 2013 08:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.541 X-Spam-Level: X-Spam-Status: No, score=-6.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 KclgriU2ry4k for ; Wed, 13 Mar 2013 08:05:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1924921F8E77 for ; Wed, 13 Mar 2013 08:05:55 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B3B3D1F03D7; Wed, 13 Mar 2013 11:05:54 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 93F441F0386; Wed, 13 Mar 2013 11:05:54 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 13 Mar 2013 11:05:54 -0400 Message-ID: <51409585.7030109@mitre.org> Date: Wed, 13 Mar 2013 11:04:37 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Nat Sakimura References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: Brian Campbell , "jose@ietf.org" , Prateek Mishra Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 15:05:57 -0000 I'm not sure if it got brought up this morning, but there's also the Nimbus library: https://bitbucket.org/nimbusds/nimbus-jose-jwt -- Justin On 03/13/2013 10:40 AM, Nat Sakimura wrote: > Here is another one: > > https://github.com/nov/json-jwt/tree/master/lib/json > > 2013/3/13 Brian Campbell : >> Parteek expressed concern about a perceived lack of available JOSE >> implementations at the WG meeting this morning. A few people, including >> myself, chimed in about implementations. >> >> I've not publicized it previously because it's still very much a work in >> progress but I've got an open source implementation, which is available at: >> https://bitbucket.org/b_c/jose4j >> >> There's no JWE support yet (I've been procrastinating doing that and waiting >> for JWE to stabilize more) but it should currently provide a fairly complete >> implementation of JWS and JWK (and the relevant pieces of JWA). >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > From mamille2@cisco.com Wed Mar 13 08:16:05 2013 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 7DD3A21F8E21 for ; Wed, 13 Mar 2013 08:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.099 X-Spam-Level: X-Spam-Status: No, score=-11.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 n-2AXpSXMC4J for ; Wed, 13 Mar 2013 08:16:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id DA5A921F8D98 for ; Wed, 13 Mar 2013 08:16:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4260; q=dns/txt; s=iport; t=1363187765; x=1364397365; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hrLSfvPi6LBkdj4PPLhlzkBQcU4vpnBeRbGhvSUZ3G0=; b=PcXUyNAZzsdmpaSXtgwTEWAk0/GSf7WscnBBeE+HkUxzrxFlpoTidg4C C3vJtjvdUN1fl+38jw/27OLt/TbGksRKR1BkF6Brs8mJJ6zD9PROLtoBX G2Fttkn9saUKyzshMExwRljHadw1vshpOF29qzxio0VjHQPGzvtyZnVDO A=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAM6XQFGtJV2d/2dsb2JhbABDh1m9I4FXFnSCKgEBAQMBeQULAgEIIiQCHxElAgQOBQgGh3QDCQa4bQ2JRBeMRYIXMQeCX2EDjzSBKIQajT2FGYMKgig X-IronPort-AV: E=Sophos;i="4.84,837,1355097600"; d="p7s'?scan'208";a="187032581" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 13 Mar 2013 15:16:04 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2DFG4Th012409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Mar 2013 15:16:04 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.02.0318.004; Wed, 13 Mar 2013 10:16:04 -0500 From: "Matt Miller (mamille2)" To: Nat Sakimura Thread-Topic: [jose] Combining the documents and MTI Thread-Index: AQHOH/eedIsoCdJX4kSRv4/Os1phj5ikDzyA Date: Wed, 13 Mar 2013 15:16:03 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.124.141] Content-Type: multipart/signed; boundary="Apple-Mail=_99932B4F-C507-4F70-AF09-47F1710EEEFD"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "" Subject: Re: [jose] Combining the documents and MTI 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, 13 Mar 2013 15:16:05 -0000 --Apple-Mail=_99932B4F-C507-4F70-AF09-47F1710EEEFD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 13, 2013, at 10:32 AM, Nat Sakimura wrote: > In the interest of the time keeping, I did not ask the question in the > room but I was wondering whether combining the documents would impact > the way MTIs are written. My hope is not but just want it to be > clarified. I think it should be possible to explicitly and concisely outline both = the Compact and JSON serializations, as well as the pro's and con's of = each. Personally, I would prefer the JWE/JWS documents didn't discuss = the core operations with the assumption of compact usage, but that's not = a hill for me to even approach for dying on. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_99932B4F-C507-4F70-AF09-47F1710EEEFD Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxMzE1MTYwM1owIwYJKoZIhvcNAQkEMRYEFHFxJA3wc0KLMraDxUJXU1fJwf+5MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAhPLQ6GIpNiwEli4+vaA39nZP+yGmAc1hHj8BEOFrI E6eOr05lLeprQOyOE5u0GY1/TWIZQG2Woz8H1TFErEpE42PMCxLsD8XU4JH54J+owDrS8G77c95J 9eIoWRjBYcp0/1udpNjwPW4wXA13meI9t3WRMSlmKMUZVUl2GytzHynK1FU1f2VrYqTSHYoKYLT/ y9px2aiC8pQSAMiRaOY8HpAi4cy7eBKz9gFjfzjqVbElbZkjBxgVTUsRxJzzYrfRJhr6hKrn2hxo stTWemSKD/ZdoGGtFjmidTrb5IhFNA/pG2dX4eGCbDdwKtXrRGS4EawLtkaM0zp0ZgkM2olwAAAA AAAA --Apple-Mail=_99932B4F-C507-4F70-AF09-47F1710EEEFD-- From ignisvulpis@gmail.com Wed Mar 13 09:16:18 2013 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 09FBD21F8CD8 for ; Wed, 13 Mar 2013 09:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] 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 1Dls3shulG6L for ; Wed, 13 Mar 2013 09:16:10 -0700 (PDT) Received: from mail-vb0-x22c.google.com (mail-vb0-x22c.google.com [IPv6:2607:f8b0:400c:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DAA6621F8D65 for ; Wed, 13 Mar 2013 09:16:09 -0700 (PDT) Received: by mail-vb0-f44.google.com with SMTP id fr13so591851vbb.17 for ; Wed, 13 Mar 2013 09:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nBhawIHBWiDq5ONnhcPcwI0TG7oZyq0I6rhqlw/LDEg=; b=FWEeumw1htiKkEIi7KWiql9Fpz2K8wkRdGOd1fnfJxxGGH0Cc298BR5uKMvjBU1E+E DkrDPQQtOHD/HUsHIfVN6EWOWG4jEv/uyrVPAejfjLKufnZUPNQmcT9fJa8WBQ83ncx9 JXPpaTA66F3SUiIbjducEb5zIF0VmlHQwHz5JxpiKJ+0Gkv82x1ctRqkBl/HXj/tmbMT 49FsW7XxXMVb2SRO1EZ6S/WPw7CviGfZkWszXfeSKieXHfVhV7Ufa2AxQw21gOjD7UWU ShFeQbZxIjHGV4tnlYZPVyGvpI4HKTXCp+FoLJGUxgFY5wpvpw27kgHvmOUMEj66JDvp 2WFg== MIME-Version: 1.0 X-Received: by 10.52.70.33 with SMTP id j1mr3389469vdu.23.1363191369105; Wed, 13 Mar 2013 09:16:09 -0700 (PDT) Received: by 10.220.112.198 with HTTP; Wed, 13 Mar 2013 09:16:09 -0700 (PDT) In-Reply-To: <51409585.7030109@mitre.org> References: <51409585.7030109@mitre.org> Date: Wed, 13 Mar 2013 17:16:09 +0100 Message-ID: From: Axel Nennker To: Justin Richer Content-Type: multipart/alternative; boundary=20cf307d0030515f0c04d7d0b9a5 Cc: Brian Campbell , Nat Sakimura , Prateek Mishra , "jose@ietf.org" Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 16:16:18 -0000 --20cf307d0030515f0c04d7d0b9a5 Content-Type: text/plain; charset=ISO-8859-1 And of course the library which ich the basis for the Nimbus library: http://jsoncrypto.org/ 2013/3/13 Justin Richer > I'm not sure if it got brought up this morning, but there's also the > Nimbus library: > > https://bitbucket.org/**nimbusds/nimbus-jose-jwt > > -- Justin > > > On 03/13/2013 10:40 AM, Nat Sakimura wrote: > >> Here is another one: >> >> https://github.com/nov/json-**jwt/tree/master/lib/json >> >> 2013/3/13 Brian Campbell : >> >>> Parteek expressed concern about a perceived lack of available JOSE >>> implementations at the WG meeting this morning. A few people, including >>> myself, chimed in about implementations. >>> >>> I've not publicized it previously because it's still very much a work in >>> progress but I've got an open source implementation, which is available >>> at: >>> https://bitbucket.org/b_c/**jose4j >>> >>> There's no JWE support yet (I've been procrastinating doing that and >>> waiting >>> for JWE to stabilize more) but it should currently provide a fairly >>> complete >>> implementation of JWS and JWK (and the relevant pieces of JWA). >>> >>> ______________________________**_________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/**listinfo/jose >>> >>> >> >> > ______________________________**_________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/**listinfo/jose > --20cf307d0030515f0c04d7d0b9a5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
And of course the library which ich the basis for the Nimb= us library:
http://jsoncrypto.org/



2013/3/13 Justin Richer <jricher@mitre.org>
I'm not sure if it got brought up this m= orning, but there's also the Nimbus library:

https://bitbucket.org/nimbusds/nimbus-jose-jwt

=A0-- Justin


On 03/13/2013 10:40 AM, Nat Sakimura wrote:
Here is another one:

https://github.com/nov/json-jwt/tree/master/lib/json

2013/3/13 Brian Campbell <bcampbell@pingidentity.com>:
Parteek expressed concern about a perceived lack of available JOSE
implementations at the WG meeting this morning. A few people, including
myself, chimed in about implementations.

I've not publicized it previously because it's still very much a wo= rk in
progress but I've got an open source implementation, which is available= at:
https://bitb= ucket.org/b_c/jose4j

There's no JWE support yet (I've been procrastinating doing that an= d waiting
for JWE to stabilize more) but it should currently provide a fairly complet= e
implementation of JWS and JWK (and the relevant pieces of JWA).

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--20cf307d0030515f0c04d7d0b9a5-- From ignisvulpis@gmail.com Wed Mar 13 09:17:52 2013 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 D96EE21F8DAB for ; Wed, 13 Mar 2013 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 fCdPSlKJlXQ5 for ; Wed, 13 Mar 2013 09:17:51 -0700 (PDT) Received: from mail-ve0-f177.google.com (mail-ve0-f177.google.com [209.85.128.177]) by ietfa.amsl.com (Postfix) with ESMTP id DBFA721F8CD8 for ; Wed, 13 Mar 2013 09:17:50 -0700 (PDT) Received: by mail-ve0-f177.google.com with SMTP id m1so880779ves.8 for ; Wed, 13 Mar 2013 09:17:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZpHfUZAiWulVYZHcrjGcTMPOokePjrHqh3CaBKSPL7A=; b=HvwPDvPg3W+5NLqeHlS/V9Y6eOjsD0c1hj/Dc4hp/ADdyXLfTDsqR1CLDMdmm/eRy1 eJ5MAb0vUdzl1XpUcmWMrLMiTf+vMy9cJASdvcsnyeUWbCIEmlkxJcCJOWkVbH0pvvCc mQSNAbgrJTtjFeh1Rg66wqSae76VNMouERf3yw7QnujpkkIdVkArghsMaFgiXjyYq5wF CpPVi5Qh8KFJZurAdPW8sMl5P2UQ1ij1g5buNmVaiWSw5VVEeXrnpxQizyMXEGA+qPuS /toKlbaRCw884sAj61nJ53Fxnh6gZtEhfQ47Z9ws9BO+8h9DKluGwWIuEsF+hj9z8Vbj Urig== MIME-Version: 1.0 X-Received: by 10.52.26.68 with SMTP id j4mr7143358vdg.116.1363191470367; Wed, 13 Mar 2013 09:17:50 -0700 (PDT) Received: by 10.220.112.198 with HTTP; Wed, 13 Mar 2013 09:17:50 -0700 (PDT) In-Reply-To: References: <51409585.7030109@mitre.org> Date: Wed, 13 Mar 2013 17:17:50 +0100 Message-ID: From: Axel Nennker To: Justin Richer Content-Type: multipart/alternative; boundary=20cf307cfe0a5a60e304d7d0bf07 Cc: Brian Campbell , Nat Sakimura , Prateek Mishra , "jose@ietf.org" Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 16:17:53 -0000 --20cf307cfe0a5a60e304d7d0bf07 Content-Type: text/plain; charset=ISO-8859-1 s/ich/is/ -Axel stupid autocorrection 2013/3/13 Axel Nennker > And of course the library which ich the basis for the Nimbus library: > http://jsoncrypto.org/ > > > > 2013/3/13 Justin Richer > >> I'm not sure if it got brought up this morning, but there's also the >> Nimbus library: >> >> https://bitbucket.org/**nimbusds/nimbus-jose-jwt >> >> -- Justin >> >> >> On 03/13/2013 10:40 AM, Nat Sakimura wrote: >> >>> Here is another one: >>> >>> https://github.com/nov/json-**jwt/tree/master/lib/json >>> >>> 2013/3/13 Brian Campbell : >>> >>>> Parteek expressed concern about a perceived lack of available JOSE >>>> implementations at the WG meeting this morning. A few people, including >>>> myself, chimed in about implementations. >>>> >>>> I've not publicized it previously because it's still very much a work in >>>> progress but I've got an open source implementation, which is available >>>> at: >>>> https://bitbucket.org/b_c/**jose4j >>>> >>>> There's no JWE support yet (I've been procrastinating doing that and >>>> waiting >>>> for JWE to stabilize more) but it should currently provide a fairly >>>> complete >>>> implementation of JWS and JWK (and the relevant pieces of JWA). >>>> >>>> ______________________________**_________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/jose >>>> >>>> >>> >>> >> ______________________________**_________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/**listinfo/jose >> > > --20cf307cfe0a5a60e304d7d0bf07 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
s/ich/is/

-Axel

stupid= autocorrection


2013/3/13 Axel Nennker <ignisvulpis@gmail.com>
And of course the library w= hich ich the basis for the Nimbus library:
http://jsoncrypto.org/



2013/3/13 Justin Richer <jricher@mitr= e.org>
I'm not sure if it got brought up this m= orning, but there's also the Nimbus library:

https://bitbucket.org/nimbusds/nimbus-jose-jwt

=A0-- Justin


On 03/13/2013 10:40 AM, Nat Sakimura wrote:
Here is another one:

https://github.com/nov/json-jwt/tree/master/lib/json

2013/3/13 Brian Campbell <bcampbell@pingidentity.com>:
Parteek expressed concern about a perceived lack of available JOSE
implementations at the WG meeting this morning. A few people, including
myself, chimed in about implementations.

I've not publicized it previously because it's still very much a wo= rk in
progress but I've got an open source implementation, which is available= at:
https://bitb= ucket.org/b_c/jose4j

There's no JWE support yet (I've been procrastinating doing that an= d waiting
for JWE to stabilize more) but it should currently provide a fairly complet= e
implementation of JWS and JWK (and the relevant pieces of JWA).

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--20cf307cfe0a5a60e304d7d0bf07-- From dick.hardt@gmail.com Wed Mar 13 09:28:13 2013 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 9CFF221F8CEF for ; Wed, 13 Mar 2013 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.095 X-Spam-Level: X-Spam-Status: No, score=-3.095 tagged_above=-999 required=5 tests=[AWL=0.504, 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 AoO5PNTon+nM for ; Wed, 13 Mar 2013 09:28:12 -0700 (PDT) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by ietfa.amsl.com (Postfix) with ESMTP id D426E21F8CD8 for ; Wed, 13 Mar 2013 09:28:12 -0700 (PDT) Received: by mail-pb0-f53.google.com with SMTP id un1so1186059pbc.26 for ; Wed, 13 Mar 2013 09:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=H2+a2QF3K6Jyts61kRG0BuAnx28198aMgKsLxMImv10=; b=c1M+quos3CE1lP9erYw0jArqZjb1opuA/RMHmXbZbBxszvJpTopkFRDQNF5uIrVU5e 61Sjzyyduq27yP5a29R5Kk5aUn93IWVCx/gdKcgHw46+CkWun2nwR9hGjCW+xkAGPQiJ DEmSb6IKdcKVOly96IZM0cpK2/XO05W9/xn22oBgItNvPuelzYNSyL1wvLN+dmsy5Rzg p5kXM/rkzJh3R+QclwzkfVw2krxXJ96ljgG9fe1kJtoRpye4DcO0keG/OSvIBoGObTsg 8ghAJoZAwezkFItPAXGNOcN39Bm6h83gbfbQebDlritNpE7ltyWRZWZOyzfyqxpZhlPw 7Opw== X-Received: by 10.68.204.234 with SMTP id lb10mr47354416pbc.64.1363192092624; Wed, 13 Mar 2013 09:28:12 -0700 (PDT) Received: from [10.0.0.80] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id hu2sm30255364pbc.38.2013.03.13.09.28.07 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 09:28:08 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Dick Hardt In-Reply-To: <51409585.7030109@mitre.org> Date: Wed, 13 Mar 2013 09:28:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FA1D6C5-6B3B-4D24-ABA2-E3F5658C3D7E@gmail.com> References: <51409585.7030109@mitre.org> To: Justin Richer X-Mailer: Apple Mail (2.1499) Cc: Brian Campbell , Nat Sakimura , Prateek Mishra , "jose@ietf.org" Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 16:28:13 -0000 I have the makings of a nodejs library that is currently embedded in = another open source project that I will spin out once the spec goal = posts hold still if the Mozilla people don't make their code an npm = module. -- Dick On Mar 13, 2013, at 8:04 AM, Justin Richer wrote: > I'm not sure if it got brought up this morning, but there's also the = Nimbus library: >=20 > https://bitbucket.org/nimbusds/nimbus-jose-jwt >=20 > -- Justin >=20 > On 03/13/2013 10:40 AM, Nat Sakimura wrote: >> Here is another one: >>=20 >> https://github.com/nov/json-jwt/tree/master/lib/json >>=20 >> 2013/3/13 Brian Campbell : >>> Parteek expressed concern about a perceived lack of available JOSE >>> implementations at the WG meeting this morning. A few people, = including >>> myself, chimed in about implementations. >>>=20 >>> I've not publicized it previously because it's still very much a = work in >>> progress but I've got an open source implementation, which is = available at: >>> https://bitbucket.org/b_c/jose4j >>>=20 >>> There's no JWE support yet (I've been procrastinating doing that and = waiting >>> for JWE to stabilize more) but it should currently provide a fairly = complete >>> implementation of JWS and JWK (and the relevant pieces of JWA). >>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From bcampbell@pingidentity.com Wed Mar 13 10:10:14 2013 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 C94FA21F8DB6 for ; Wed, 13 Mar 2013 10:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.592 X-Spam-Level: X-Spam-Status: No, score=-5.592 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, 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 jAcYFzpqWoyE for ; Wed, 13 Mar 2013 10:10:13 -0700 (PDT) Received: from na3sys009aog118.obsmtp.com (na3sys009aog118.obsmtp.com [74.125.149.244]) by ietfa.amsl.com (Postfix) with ESMTP id A027221F8DA2 for ; Wed, 13 Mar 2013 10:10:13 -0700 (PDT) Received: from mail-oa0-f70.google.com ([209.85.219.70]) (using TLSv1) by na3sys009aob118.postini.com ([74.125.148.12]) with SMTP ID DSNKUUCy9bptxAm3ICWQo1NI6Cd0hDnOpuN2@postini.com; Wed, 13 Mar 2013 10:10:13 PDT Received: by mail-oa0-f70.google.com with SMTP id h2so6782228oag.9 for ; Wed, 13 Mar 2013 10:10:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:x-gm-message-state; bh=uWC1CRwYaIst6SsygKdFxk4ykEgt2m71YuroIHedqBw=; b=T5AZUs3snm2Pto+1IasMrHy0tnBNe5A3tYYGW9uDLI7SJy86iIawTzBv0W4f8P07sU f/WIejyOZoivDYFdAdgNG7K8MMrKaAjbTdUXzSMRywL/g58t3sJ3EvOjEntIdoh2yt16 Mc4A/oL4+BPWqv/pPmVuBXD6BA+DamDoqW0F3vAf5+qipyBzQhPQwiC5Y8OoIjxhonAi APYEuI0YM3Vj3ekuEnaHE8DBPnm/ya5xdovB5khRC9J+YNm7aFwZmTDfANEFN/ZiIeZT Oh3B3qdFbeoovsMwVk7Rk9LIPxIv+nRETxt6ks+tb+A18akvv5EvFXFtM4Cc1J3+w7I+ bcaw== X-Received: by 10.43.103.195 with SMTP id dj3mr17018148icc.3.1363194612812; Wed, 13 Mar 2013 10:10:12 -0700 (PDT) X-Received: by 10.43.103.195 with SMTP id dj3mr17018140icc.3.1363194612662; Wed, 13 Mar 2013 10:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Wed, 13 Mar 2013 10:09:42 -0700 (PDT) In-Reply-To: <4FA1D6C5-6B3B-4D24-ABA2-E3F5658C3D7E@gmail.com> References: <51409585.7030109@mitre.org> <4FA1D6C5-6B3B-4D24-ABA2-E3F5658C3D7E@gmail.com> From: Brian Campbell Date: Wed, 13 Mar 2013 13:09:42 -0400 Message-ID: To: "jose@ietf.org" Content-Type: multipart/alternative; boundary=bcaec5171a23a5df5c04d7d17a43 X-Gm-Message-State: ALoCoQnXMcH8iLLEGkpYt5KLgggj3mdWY06iCGmOddBLgaHahrIhs+PjsKAr9Inmi8515cI/FmYIaNSiFguutysIGT9zzBsSjXlea6fPlAFQJC2y8rpeuQ0C4oMGoUsUbdCC2XImuHhz Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 17:10:14 -0000 --bcaec5171a23a5df5c04d7d17a43 Content-Type: text/plain; charset=ISO-8859-1 There's also jsjws, which bills itself as a "pure JavaScript implementation of JSON Web Signature and JWS-JS" http://kjur.github.com/jsjws/ I have no association with it but I have done some basic JWS introp testing between it and my own jose4j lib. On Wed, Mar 13, 2013 at 12:28 PM, Dick Hardt wrote: > I have the makings of a nodejs library that is currently embedded in > another open source project that I will spin out once the spec goal posts > hold still if the Mozilla people don't make their code an npm module. > > -- Dick > > On Mar 13, 2013, at 8:04 AM, Justin Richer wrote: > > > I'm not sure if it got brought up this morning, but there's also the > Nimbus library: > > > > https://bitbucket.org/nimbusds/nimbus-jose-jwt > > > > -- Justin > > > > On 03/13/2013 10:40 AM, Nat Sakimura wrote: > >> Here is another one: > >> > >> https://github.com/nov/json-jwt/tree/master/lib/json > >> > >> 2013/3/13 Brian Campbell : > >>> Parteek expressed concern about a perceived lack of available JOSE > >>> implementations at the WG meeting this morning. A few people, including > >>> myself, chimed in about implementations. > >>> > >>> I've not publicized it previously because it's still very much a work > in > >>> progress but I've got an open source implementation, which is > available at: > >>> https://bitbucket.org/b_c/jose4j > >>> > >>> There's no JWE support yet (I've been procrastinating doing that and > waiting > >>> for JWE to stabilize more) but it should currently provide a fairly > complete > >>> implementation of JWS and JWK (and the relevant pieces of JWA). > >>> > >>> _______________________________________________ > >>> jose mailing list > >>> jose@ietf.org > >>> https://www.ietf.org/mailman/listinfo/jose > >>> > >> > >> > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --bcaec5171a23a5df5c04d7d17a43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There's also jsjws, which bills itself as a "= ;pure JavaScript implementation of JSON Web Signature and JWS-JS"
<= br>http://kjur.github.com/jsjws/<= /a>

I have no association with it but I have done some basic JWS intr= op testing between it and my own jose4j lib.


On Wed, Mar 13, 2013 at 12:28 PM, = Dick Hardt <dick.hardt@gmail.com> wrote:
I have the makings of a nodejs library that = is currently embedded in another open source project that I will spin out o= nce the spec goal posts hold still if the Mozilla people don't make the= ir code an npm module.

-- Dick

On Mar 13, 2013, at 8:04 AM, Justin Richer <jricher@mitre.org> wrote:

> I'm not sure if it got brought up this morning, but there's al= so the Nimbus library:
>
> https://bitbucket.org/nimbusds/nimbus-jose-jwt
>
> -- Justin
>
> On 03/13/2013 10:40 AM, Nat Sakimura wrote:
>> Here is another one:
>>
>> https://github.com/nov/json-jwt/tree/master/lib/json >>
>> 2013/3/13 Brian Campbell <bcampbell@pingidentity.com>:
>>> Parteek expressed concern about a perceived lack of available = JOSE
>>> implementations at the WG meeting this morning. A few people, = including
>>> myself, chimed in about implementations.
>>>
>>> I've not publicized it previously because it's still v= ery much a work in
>>> progress but I've got an open source implementation, which= is available at:
>>> https://bitbucket.org/b_c/jose4j
>>>
>>> There's no JWE support yet (I've been procrastinating = doing that and waiting
>>> for JWE to stabilize more) but it should currently provide a f= airly complete
>>> implementation of JWS and JWK (and the relevant pieces of JWA)= .
>>>
>>> _______________________________________________
>>> jose mailing list
>>> jose@ietf.org
>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>>
>>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


--bcaec5171a23a5df5c04d7d17a43-- From ritou.06@gmail.com Wed Mar 13 10:51:42 2013 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 93D5121F8A08 for ; Wed, 13 Mar 2013 10:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_41=0.6, 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 p-mye1cxtKt4 for ; Wed, 13 Mar 2013 10:51:41 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F521F8DD4 for ; Wed, 13 Mar 2013 10:51:41 -0700 (PDT) Received: by mail-vc0-f175.google.com with SMTP id p1so691275vcq.20 for ; Wed, 13 Mar 2013 10:51:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E8YJ4PDsclGxe2V9EV/Swo2ObGU1we0z2b/G88+DCPY=; b=jbnlOUVw9Y2l4nSRy8eA9vQJXgm1L0/FAq4V6SHal6xXr1OHDIdBFS4FZfkFN6rZaa Y4O/24QwtJua4k5kvLOUbOGYxxdXAUv2P5pBEj/esnhb3k89e7yGwxxrHx7Xr7XC8UQJ kvcIQ/XC95xNn4YvDdFS3hYl1z6EMGvpP15Z2sqEIzVRy6ncTjpIUIJmiRTGOkjfTY43 uq4dNHRT1GLqqUtw1EUVh52MH+hlHhSegm3JF+lbZjwvwFExd+eA+qB0CPUqhop21ZzD vacs6MdfkXbEhu3xPjZf4LQfOIwYdpoBByngve2M7rMvlyxlzVC+SM0jiJTI4C+XUtrk 6QWg== MIME-Version: 1.0 X-Received: by 10.221.2.71 with SMTP id nt7mr6519641vcb.71.1363197101237; Wed, 13 Mar 2013 10:51:41 -0700 (PDT) Received: by 10.59.5.198 with HTTP; Wed, 13 Mar 2013 10:51:41 -0700 (PDT) In-Reply-To: References: <51409585.7030109@mitre.org> <4FA1D6C5-6B3B-4D24-ABA2-E3F5658C3D7E@gmail.com> Date: Thu, 14 Mar 2013 02:51:41 +0900 Message-ID: From: Ryo Ito To: Brian Campbell Content-Type: text/plain; charset=ISO-8859-1 Cc: "jose@ietf.org" Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 17:51:42 -0000 There is perl implementation of JWT. https://metacpan.org/module/JSON::WebToken 2013/3/14 Brian Campbell : > There's also jsjws, which bills itself as a "pure JavaScript implementation > of JSON Web Signature and JWS-JS" > > http://kjur.github.com/jsjws/ > > I have no association with it but I have done some basic JWS introp testing > between it and my own jose4j lib. > > > On Wed, Mar 13, 2013 at 12:28 PM, Dick Hardt wrote: >> >> I have the makings of a nodejs library that is currently embedded in >> another open source project that I will spin out once the spec goal posts >> hold still if the Mozilla people don't make their code an npm module. >> >> -- Dick >> >> On Mar 13, 2013, at 8:04 AM, Justin Richer wrote: >> >> > I'm not sure if it got brought up this morning, but there's also the >> > Nimbus library: >> > >> > https://bitbucket.org/nimbusds/nimbus-jose-jwt >> > >> > -- Justin >> > >> > On 03/13/2013 10:40 AM, Nat Sakimura wrote: >> >> Here is another one: >> >> >> >> https://github.com/nov/json-jwt/tree/master/lib/json >> >> >> >> 2013/3/13 Brian Campbell : >> >>> Parteek expressed concern about a perceived lack of available JOSE >> >>> implementations at the WG meeting this morning. A few people, >> >>> including >> >>> myself, chimed in about implementations. >> >>> >> >>> I've not publicized it previously because it's still very much a work >> >>> in >> >>> progress but I've got an open source implementation, which is >> >>> available at: >> >>> https://bitbucket.org/b_c/jose4j >> >>> >> >>> There's no JWE support yet (I've been procrastinating doing that and >> >>> waiting >> >>> for JWE to stabilize more) but it should currently provide a fairly >> >>> complete >> >>> implementation of JWS and JWK (and the relevant pieces of JWA). >> >>> >> >>> _______________________________________________ >> >>> jose mailing list >> >>> jose@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/jose >> >>> >> >> >> >> >> > >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- ==================== Ryo Ito Email : ritou.06@gmail.com ==================== From rlb@ipv.sx Wed Mar 13 12:46:55 2013 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 442DB21F8E0F for ; Wed, 13 Mar 2013 12:46:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.108 X-Spam-Level: X-Spam-Status: No, score=-0.108 tagged_above=-999 required=5 tests=[AWL=-1.686, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, TRACKER_ID=2.003] 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 7VIzI6ag7-zY for ; Wed, 13 Mar 2013 12:46:44 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id C8C8921F8DC9 for ; Wed, 13 Mar 2013 12:46:43 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id va7so1413321obc.41 for ; Wed, 13 Mar 2013 12:46:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2JXtuKtyBucgH1sJtjt0ru2y7EWbOwa5EtJ4wJQcOjc=; b=RiG6d8h0cg/StBe+2yMhP9gfWRk2EKAaCgCNASa94PEm7XSNhC2JZ2M2+HntzXiXrb dem2WUk2ryGD1yRwhOzsYD7smGFq+vTYmyCDfgGqHPDvKfluovxoj/WToS1eQ3XsUygY X5bvwBgCNW0MrqzQcMFVuyjSYry8OLxRxRgN5WYGlAQ1PhjLI+LCfziepchuuIexUUQE gKHClBqF4nD6vfIZlj0LoyIi7KxWgcAI830OMqZ0eibDJTOuqq85O4UH7S2e16ttX6Xk uqI93KZU3MFdwRSgndKZiFngRAHpQJjdXX8HM7RGX8M2FduNhmaMSG9K00bcXSLDxJ1k MfHw== MIME-Version: 1.0 X-Received: by 10.182.245.33 with SMTP id xl1mr16772368obc.91.1363204003297; Wed, 13 Mar 2013 12:46:43 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 13 Mar 2013 12:46:43 -0700 (PDT) X-Originating-IP: [128.89.254.35] In-Reply-To: <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> Date: Wed, 13 Mar 2013 15:46:43 -0400 Message-ID: From: Richard Barnes To: Mark Watson Content-Type: multipart/alternative; boundary=14dae93a19a35f95a604d7d3aa9e X-Gm-Message-State: ALoCoQmqnizIZ32xTW/8CQJSLMCs9Vi7ORo3wqmQ6S6O90BciB6J/RbkaDfQgLdsJzKjBsd5FP3u Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 13 Mar 2013 19:46:55 -0000 --14dae93a19a35f95a604d7d3aa9e Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would actually be completely ok with that -- if the wrapping in JWE were consistent. But I suspect some folks will balk at the ~65% size increase: // 128-bit raw key XXXXXXXXXXXXXXXX // Wrapped raw key XXXXXXXXXXXXXXXXXXXXXXXX // Base64 of wrapped raw key Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes // JWK of key {"k":"QEhAwEkOEtstCaEEd8sKig"} // Wrapped JWK XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX // Base64 of wrapped JWK +N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solution 2.A, 53 bytes On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson wrote: > Richard, > > Regarding the proposal for a binary-optimized JSON encoding, isn't this > a bit orthogonal to the problem at hand ? > > I understand that this is one area where such a thing would be useful, > but there have been various attempts to define such things in the past > (BSON, ubjson, =85). A big advantage of JSON is that the data is > self-describing, in terms of types: you don't need any external "document > type definition" or "schema" to decode and manipulate a JSON object. > > If you are going to specify something like this, I'd suggest at least > include the member names that have been moved to the binary segment > somewhere. So then a decoder can undo the translation and give back a > regular JSON object with base64-encoded members, without access to this > side-information. > > But I would ask if this trouble is really worth it for the 25% space > saving ? > > =85Mark > > > On Mar 11, 2013, at 7:30 PM, Manger, James H wrote: > > =93A Unified Theory of JOSE Keys=94 > looks quite good.**** > ** ** > It looks like a key is a JSON object with any number of name/value > pairs. For some names, the value is a base64[url]-encoding of binary data= . > **** > ** ** > To wrap a key, its name/value pairs are divided into 3 groups:**** > 1. non-confidential name/value pairs**** > 2. confidential non-binary name/value pairs**** > 3. confidential binary name/value pairs**** > ** ** > The first group are put into the =93kat=94 (key attributes?) field of th= e > output.**** > ** ** > The second group =97 if its not empty =97 becomes the first binary segme= nt > of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the o= utput > indicates the second group is present.**** > ** ** > The third group (in order) become subsequent binary segments of the > plaintext. The names in the third group (and their order) is determined b= y > the type of the key being wrapped (=93kty=94 attribute).**** > ** ** > The plaintext is wrapped (encrypted), then base64url-encoded to give the > =93wk=94 attribute in the output.**** > ** ** > ** ** > Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat=94= . I assume > this is a typo. =93kat=94 would include =93n=94 and =93e=94, but =93d=94 = (the private > exponent) would always be encrypted and hence be inside =93wk=94.**** > ** ** > Q2. Does key wrapping give integrity protection that you might want for > name/value pairs even when they are not confidential. For instance, could > it be useful to include, say, =93e=94 inside =93wk=94 instead of within = =93kat=94? Do > recipients need to check both the first binary segment and =93kat=94 when > looking for any attribute not explicitly listed in the =93encoding rules= =94? > Does the first binary segment take precedence over =93kat=94?**** > ** ** > Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples sh= ow it as > a top-level attribute instead.**** > ** ** > A4. The symmetric key examples don=92t include a key type (=93kty=94). I= s it > implied by something at a higher level (eg a JWE), or is there a default > value meaning =93a shared symmetric secret, with no specific associated > crypto algorithm=94?**** > ** ** > Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be > better for encoding the length of binary segments. 2 bytes (64 KB max) > might be too small, particularly if the binary encoding is used for all > JOSE messages (eg JWE) not just keys.**** > ** ** > ** ** > --**** > James Manger**** > ** ** > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, 11 March 2013 6:29 AM > *To:* Mike Jones > *Cc:* Leif Johansson; jose@ietf.org > *Subject:* Re: [jose] A Unified Theory of JOSE Keys**** > ** ** > So it seems to me that the group has three questions to answer when it > comes to wrapped keys:**** > ** ** > Q1(Encryption): What mechanism will be used to encrypt key material, > possibly containing attributes? **** > Answer 1.A: JWE**** > Answer 1.B: Key wrap, derived from JWE**** > ** ** > Q2(Packing): How should the wrapped key+attributes be expressed?**** > Answer 2.A: JSON format (not packed)**** > Answer 2.B: JSON, with binary parts expressed directly **** > ** ** > JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in > my Unified Theory is 1.B / 2.B. **** > ** ** > For context, I'm working from a few principles here:**** > -- We should not define multiple ways to wrap symmetric keys**** > -- We should not do things that would preclude accreditation under > major security standards (e.g., FIPS)**** > -- We should choose encodings that minimize the size overhead imposed > by the encoding**** > If we agree on these principles, then the answers to the above > questions seem pretty clear.**** > ** ** > It seems to me that Steve's point on Question 1 pretty much decides the > question for B. If we want systems using JOSE to have any hope of gettin= g > accreditation (e.g., under FIPS), then they will have to use standard > mechanisms for protecting keys, even if those keys are packaged with oth= er > attributes. Mike's message misses the point that the key wrap algorithm > isn't actually being used to protect the key itself -- for that you would > use a normal, content-oriented encryption algorithm, in contravention of > the FIPS requirements.**** > ** ** > Question 2 is mostly a question of backward compatibility and > efficiency. If we want to have any hope of being backward-compatible wit= h > JWE key wrapping -- that is, avoiding having two ways to do the same thin= g > -- then we need a way to handle the octets of a key directly, as opposed = to > base64-encoded within a JSON object. That would be option 2.B.**** > ** ** > There are also compactness arguments for 1.B and 2.B. If you do 1.A, > then in addition to the header, you have to carry a separate CMK, IV, and > MAC value. If you're using AES-GCM with a 128-bit key, that's a total of > 44 octets (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key > wrap, the wrapping algorithm adds a maximum of 16 octets to the object. > The difference in case 2 is even greater, because you're talking about > double-base64 encoding, which entails a penalty of 30% of the payload. I= f > you're protecting an AES key, this might only be a few octets, but if > you're protecting a 2048-bit RSA key, then you're talking hundreds of > octets. So if you care about compactness, 1.B and 2.B make a lot more > sense.**** > ** ** > To respond to Mike's specific points:**** > ** ** > > I=92ll note that in JSON Web Encryption, we are already using standard > methods for encrypting key values for the Content Master Key =96 specific= ally > AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key > agreement).**** > > ** ** > However, the actual key you're wrapping is still protected with a > content-oriented algorithm. So you're still violating the FIPS > requirements.**** > **** > ** ** > > What we=92re talking about here, however, is encrypting potentially mor= e > than just key values =96 in this case, key values with associated key use > information, algorithm information, key ID information, and potentially > other attributes. As such, using the JWK JSON representation of this > information as the payload of a standard JWE encryption seems like the > obvious solution, which doesn=92t require inventing anything we don=92t a= lready > have.**** > > ** ** > Absolutely agree that JSON is the right representation. But the key is > still included in that representation, so you need to apply key wrapping > algorithms to it. And, as discussed above, it's a lot more efficient if > you pack the JSON so that the binary isn't double-encoded.**** > **** > > draft-miller-jose-jwe-protected-jwk already describes doing that. I > believe that we should adopt this as a working group document as soon as > the rechartering is complete.**** > > ** ** > That draft has some excellent suggestions for password-based key > wrapping. We should incorporate that into whatever solution we come up > with. But for the reasons discussed above, it's wrong in using JWK for t= he > encapsulation.**** > ** ** > I also disagree that we need a separate document for this. If we're > going to avoid having two ways to wrap keys, this needs to be part of > JWE/JWK.**** > ** ** > --Richard**** > ** ** > > -- Mike**** > > _______________________________________________ > > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > --14dae93a19a35f95a604d7d3aa9e Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I would actually be completely ok with that -- if the wrapping in JWE were = consistent. =A0But I suspect some folks will balk at the ~65% size increase= :

// 128-bit raw key
XXXXXXXXXXXXXXXX
=A0// Wrapped raw key
XXXXXXXXXXXXXXXXXXXXXXXX
// = Base64 of wrapped raw key
Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <--= ---- Solution 2.B, 32 bytes
// JWK of key
{"k"= ;:"QEhAwEkOEtstCaEEd8sKig"}
// Wrapped JWK
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped JWK
+N9iVxLSMs8/wzuK42pd7PClztFxy+AwRT= TyV8ZzSsIO2VIGPxOge <------ Solution 2.A, 53 bytes



On Tue, Mar 12, 2013 at 6:58 = PM, Mark Watson <watsonm@netflix.com> wrote:
Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't= this a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful,= but there have been various attempts to define such things in the past (BS= ON, ubjson, =85). A big advantage of JSON is that the data is self-describi= ng, in terms of types: you don't need any external "document type definition" or "schema" to= decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at le= ast include the member names that have been moved to the binary segment som= ewhere. So then a decoder can undo the translation and give back a regular = JSON object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space s= aving ?

=85Mark


On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

=93A Unified Theory of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.
=A0
It looks like a key is a JSON object with any number of name/value = pairs. For some names, the value is a base64[url]-encoding of binary data.<= u>
=A0
To wrap a key, its name/value pairs are divided into 3 groups:
1.=A0=A0=A0=A0=A0=A0=A0= non-confidential name/value pairs
2.=A0=A0=A0=A0=A0=A0=A0= confidential non-binary name/value pairs
3.=A0=A0=A0=A0=A0=A0=A0= confidential binary name/value pairs
=A0
The first group are put into the =93kat=94 (key attributes?) field = of the output.
=A0
The second group =97 if its not empty =97 becomes the first binary = segment of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in= the output indicates the second group is present.
=A0
The third group (in order) become subsequent binary segments of the= plaintext. The names in the third group (and their order) is determined by= the type of the key being wrapped (=93kty=94 attribute).
=A0
The plaintext is wrapped (encrypted), then base64url-encoded to giv= e the =93wk=94 attribute in the output.
=A0
=A0
Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93k= at=94. I assume this is a typo. =93kat=94 would include =93n=94 and =93e=94= , but =93d=94 (the private exponent) would always be encrypted and hence be inside =93wk=94.
=A0
Q2. Does key wrapping give integrity protection that you might want= for name/value pairs even when they are not confidential. For instance, co= uld it be useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? Do recipients ne= ed to check both the first binary segment and =93kat=94 when looking for an= y attribute not explicitly listed in the =93encoding rules=94? Does the fir= st binary segment take precedence over =93kat=94?
=A0
Q3. Should =93kty=94 (key type) appear within =93kat=94? The exampl= es show it as a top-level attribute instead.
=A0
A4. The symmetric key examples don=92t include a key type (=93kty= =94). Is it implied by something at a higher level (eg a JWE), or is there = a default value meaning =93a shared symmetric secret, with no specific associated crypto algorithm=94?<= u>
=A0
Q5. Using a VARINT (variable-length integer) instead of 2 bytes wou= ld be better for encoding the length of binary segments. 2 bytes (64 KB max= ) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just key= s.
=A0
=A0
--
James Manger
=A0
From:=A0jose-bo= unces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behalf Of=A0Richard Barnes
Sent:=A0Monday, 11 March 2013 6:29 AM
To:=A0Mike Jones
Cc:=A0Leif Johansson;=A0jose@ietf.org
Subject:=A0Re: [jose] A Unified Theory of JOSE Keys<= /u>
=A0
So it seems to me that the group has three questions to answer when it come= s to wrapped keys:
=A0
Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes? =A0
=A0 =A0 Answer 1.A: JWE
=A0 =A0 Answer 1.B: Key wrap, derived from JWE
=A0
Q2(Packing): How should the wrapped key+attributes be expressed?<= /u>
=A0 =A0 Answer 2.A: JSON format (not packed)
=A0 =A0 Answer 2.B: JSON, with binary parts expressed directly=A0=
=A0
JWE-within-JWK represents answer 1.A / 2.A. =A0The solution proposed in my = Unified Theory is 1.B / 2.B. =A0
=A0
For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys<= /div>
-- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by th= e encoding
If we agree on these principles, then the answers to the above questions se= em pretty clear.
=A0
It seems to me that Steve's point on Question 1 pretty much decides the= question for B. =A0If we want systems using JOSE to have any hope of getti= ng accreditation (e.g., under FIPS), then they will have to use standard me= chanisms for protecting keys, even if those keys are =A0packaged with other attributes. =A0Mike's message mi= sses the point that the key wrap algorithm isn't actually being used to= protect the key itself -- for that you would use a normal, content-oriente= d encryption algorithm, in contravention of the FIPS requirements.
=A0
Question 2 is mostly a question of backward compatibility and efficiency. = =A0If we want to have any hope of being backward-compatible with JWE key wr= apping -- that is, avoiding having two ways to do the same thing -- then we= need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object. =A0That= would be option 2.B.
=A0
There are also compactness arguments for 1.B and 2.B. =A0If you do 1.A, the= n in addition to the header, you have to carry a separate CMK, IV, and MAC = value. =A0If you're using AES-GCM with a 128-bit key, that's a tota= l of 44 octets (16 CMK, 16 MAC, 12 IV). =A0In contrast, if you just do AES key wrap, the wrapping algorithm adds a maxim= um of 16 octets to the object. =A0The difference in case 2 is even greater,= because you're talking about double-base64 encoding, which entails a p= enalty of 30% of the payload. =A0If you're protecting an AES key, this might only be a few octets, but if you're = protecting a 2048-bit RSA key, then you're talking hundreds of octets. = =A0So if you care about compactness, 1.B and 2.B make a lot more sense.<= /u>
=A0
To respond to Mike's specific points:
=A0
I=92ll note that in JSON Web Encryption, we are alre= ady using standard methods for encrypting key values for the Content Master= Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement= ).
=A0
However, the actual key you're wrapping is still protected with a conte= nt-oriented algorithm. =A0So you're still violating the FIPS requiremen= ts.
=A0
=A0
What we=92re talking about here, however, is encrypt= ing potentially more than just key values =96 in this case, key values with= associated key use information, algorithm information, key ID information, and potentially other attribute= s.=A0 As such, using the JWK JSON representation of this information as the= payload of a standard JWE encryption seems like the obvious solution, whic= h doesn=92t require inventing anything we don=92t already have.<= /div>
=A0
Absolutely agree that JSON is the right representation. =A0But the key is s= till included in that representation, so you need to apply key wrapping alg= orithms to it. =A0And, as discussed above, it's a lot more efficient if= you pack the JSON so that the binary isn't double-encoded.
=A0=A0
draft-miller-jose-jwe-protected-jwk already describe= s doing that.=A0 I believe that we should adopt this as a working group doc= ument as soon as the rechartering is complete.
=A0
That draft has some excellent suggestions for password-based key wrapping. = =A0We should incorporate that into whatever solution we come up with. =A0Bu= t for the reasons discussed above, it's wrong in using JWK for the enca= psulation.
=A0
I also disagree that we need a separate document for this. =A0If we're = going to avoid having two ways to wrap keys, this needs to be part of JWE/J= WK.
=A0
--Richard
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
_______________________________________________

jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/l= istinfo/jose


--14dae93a19a35f95a604d7d3aa9e-- From vladimir@nimbusds.com Wed Mar 13 12:51:11 2013 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 51F5411E80D2 for ; Wed, 13 Mar 2013 12:51:11 -0700 (PDT) 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=[AWL=-1.000, BAYES_00=-2.599] 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 UkWbCE1cmUIw for ; Wed, 13 Mar 2013 12:51:10 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 3268911E809C for ; Wed, 13 Mar 2013 12:51:09 -0700 (PDT) Received: (qmail 8061 invoked from network); 13 Mar 2013 19:51:08 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 13 Mar 2013 19:50:59 -0000 Received: (qmail 13126 invoked by uid 99); 13 Mar 2013 19:50:59 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.251.217 User-Agent: Workspace Webmail 5.6.33 Message-Id: <20130313125058.cc40c4f3d92d2001859047cd8cabb9ab.9e0db9290a.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: Cc: "jose@ietf.org" Date: Wed, 13 Mar 2013 12:50:58 -0700 Mime-Version: 1.0 Subject: Re: [jose] One JOSE toolkit... 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, 13 Mar 2013 19:51:11 -0000 Yes, Axel has the most complete JOSE algorithm implementation in the=0Aenti= re Java camp and has provided the basis for almost all crypto=0Aclasses in = nimbus-jose-jwt :)=0A=0ACheers,=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov = : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A-------- Original Messag= e --------=0ASubject: Re: [jose] One JOSE toolkit...=0AFrom: Axel Nennker <= ignisvulpis@gmail.com>=0ADate: Wed, March 13, 2013 4:16 pm=0ATo: Justin Ric= her =0ACc: Brian Campbell , = Nat Sakimura=0A, Prateek Mishra ,=0A"jose@ietf.org" =0A=0AAnd of course the library whic= h ich the basis for the Nimbus library:=0Ahttp://jsoncrypto.org/=0A=0A=0A= =0A=0A2013/3/13 Justin Richer =0A I'm not sure if it got= brought up this morning, but there's also the=0ANimbus library:=0A =0A htt= ps://bitbucket.org/nimbusds/nimbus-jose-jwt=0A =0A -- Justin=0A =0A On 03/= 13/2013 10:40 AM, Nat Sakimura wrote:=0A Here is another one:=0A =0A https= ://github.com/nov/json-jwt/tree/master/lib/json=0A =0A 2013/3/13 Brian Camp= bell :=0A Parteek expressed concern about a pe= rceived lack of available JOSE=0A implementations at the WG meeting this mo= rning. A few people, including=0A myself, chimed in about implementations.= =0A =0A I've not publicized it previously because it's still very much a wo= rk=0Ain=0A progress but I've got an open source implementation, which is av= ailable=0Aat:=0A https://bitbucket.org/b_c/jose4j=0A =0A There's no JWE sup= port yet (I've been procrastinating doing that and=0Awaiting=0A for JWE to = stabilize more) but it should currently provide a fairly=0Acomplete=0A impl= ementation of JWS and JWK (and the relevant pieces of JWA).=0A =0A ________= _______________________________________=0A jose mailing list=0A jose@ietf.o= rg=0A https://www.ietf.org/mailman/listinfo/jose=0A =0A =0A =0A =0A _____= __________________________________________=0A jose mailing list=0A jose@iet= f.org=0A https://www.ietf.org/mailman/listinfo/jose=0A =0A=0A=0A=0A=0A_____= __________________________________________=0Ajose mailing list=0Ajose@ietf.= org=0Ahttps://www.ietf.org/mailman/listinfo/jose From ietf@meetecho.com Wed Mar 13 12:52:31 2013 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 7ED3311E80DC for ; Wed, 13 Mar 2013 12:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.665 X-Spam-Level: X-Spam-Status: No, score=-0.665 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 J+Iy2ys7vM5F for ; Wed, 13 Mar 2013 12:52:28 -0700 (PDT) Received: from smtpdg10.aruba.it (smtpdg4.aruba.it [62.149.158.234]) by ietfa.amsl.com (Postfix) with ESMTP id 033B111E80D9 for ; Wed, 13 Mar 2013 12:52:27 -0700 (PDT) Received: from dell-tcastaldi ([130.129.16.136]) by smtpcmd04.ad.aruba.it with bizsmtp id B7sN1l00b2w8SR6017sQL6; Wed, 13 Mar 2013 20:52:25 +0100 Date: Wed, 13 Mar 2013 15:52:21 -0400 (EDT) From: Meetecho Team To: jose@ietf.org Message-ID: <4916061.1.1363204341309.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_0_2614099.1363204341244" Subject: [jose] JOSE session recording available 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, 13 Mar 2013 19:52:31 -0000 ------=_Part_0_2614099.1363204341244 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the JOSE WG session at IETF 86 is available at the following URL: http://ietf86.conf.meetecho.com/index.php/Recorded_Sessions#JOSE In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team This email has been automatically generated by The Meetecho Conferencing System ------=_Part_0_2614099.1363204341244-- From rlb@ipv.sx Wed Mar 13 13:05:13 2013 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 E406311E80AD for ; Wed, 13 Mar 2013 13:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.021 X-Spam-Level: X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[AWL=-0.596, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 pWj9gUfH+ra0 for ; Wed, 13 Mar 2013 13:05:12 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6B611E80A5 for ; Wed, 13 Mar 2013 13:05:12 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id ta14so1445569obb.28 for ; Wed, 13 Mar 2013 13:05:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=L3lOAwC0J9ygqtbFhheUgkbE8RXWOPP/KJ5h6wwBr1g=; b=Y0l1MxO9eQkbW07kAX0P1geWtj1+A17g4F3kB7ZBuECQZbiEuDXo0Sgco3NXc1LXkS OoxkWZR19rtOKS7CDDcbAgMa/JCvj4d+G2s8PFxejHD64Y9LHs5oA/YPz6fQXVS/tzfJ Qn0Uwk6bY7WKTqtMgR2YudoTLCF6gfVQc6v5ADwG795ek3NXzCMwniuPb/2BsCgY5Sld +UMA2C1YL2/2CyPFDNx4Gz9xsdD51luBqbVtAqFlF4RWIlsQpGpyKJTFZM5j1PrS9v1n fgVAmSkw69v2i7tM+jY2KDQu2B4B0WIm6SGlPgfZPGOrY5Exv11uvvrqMJwGY3TMBUYN yRCw== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr16807109oec.126.1363205111828; Wed, 13 Mar 2013 13:05:11 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 13 Mar 2013 13:05:11 -0700 (PDT) X-Originating-IP: [128.89.254.35] In-Reply-To: <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> Date: Wed, 13 Mar 2013 16:05:11 -0400 Message-ID: From: Richard Barnes To: Mark Watson Content-Type: multipart/alternative; boundary=bcaec54fae4872730604d7d3ecff X-Gm-Message-State: ALoCoQmJMtsk4GCJc9xYQYbCFSWJuHEtK+6XlHPntqjrKXM24s6+GlGj8mvTkP4QYEtD97kfDHyP Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 13 Mar 2013 20:05:14 -0000 --bcaec54fae4872730604d7d3ecff Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One other thing to note is that we're effectively *already* *defining* a binary-optimized JSON in the definition of JWS and JWE. Consider the following JSON structure: { "alg": "A128KW", "enc": "A128GCM", "kid": "ceci", "key": "...", "iv": "...", "ciphertext": "...", "mac": "..." } If you apply the algorithm in the slides, with the encoding rules ["key", "iv", "ciphertext", "mac"], and with base64 instead of length/value encoding, then you get a well-formed JWE. My proposal is just to do the same thing, but to concatenate the parts in binary rather than text. On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson wrote: > Richard, > > Regarding the proposal for a binary-optimized JSON encoding, isn't this > a bit orthogonal to the problem at hand ? > > I understand that this is one area where such a thing would be useful, > but there have been various attempts to define such things in the past > (BSON, ubjson, =85). A big advantage of JSON is that the data is > self-describing, in terms of types: you don't need any external "document > type definition" or "schema" to decode and manipulate a JSON object. > > If you are going to specify something like this, I'd suggest at least > include the member names that have been moved to the binary segment > somewhere. So then a decoder can undo the translation and give back a > regular JSON object with base64-encoded members, without access to this > side-information. > > But I would ask if this trouble is really worth it for the 25% space > saving ? > > =85Mark > > > On Mar 11, 2013, at 7:30 PM, Manger, James H wrote: > > =93A Unified Theory of JOSE Keys=94 > looks quite good.**** > ** ** > It looks like a key is a JSON object with any number of name/value > pairs. For some names, the value is a base64[url]-encoding of binary data= . > **** > ** ** > To wrap a key, its name/value pairs are divided into 3 groups:**** > 1. non-confidential name/value pairs**** > 2. confidential non-binary name/value pairs**** > 3. confidential binary name/value pairs**** > ** ** > The first group are put into the =93kat=94 (key attributes?) field of th= e > output.**** > ** ** > The second group =97 if its not empty =97 becomes the first binary segme= nt > of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the o= utput > indicates the second group is present.**** > ** ** > The third group (in order) become subsequent binary segments of the > plaintext. The names in the third group (and their order) is determined b= y > the type of the key being wrapped (=93kty=94 attribute).**** > ** ** > The plaintext is wrapped (encrypted), then base64url-encoded to give the > =93wk=94 attribute in the output.**** > ** ** > ** ** > Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat=94= . I assume > this is a typo. =93kat=94 would include =93n=94 and =93e=94, but =93d=94 = (the private > exponent) would always be encrypted and hence be inside =93wk=94.**** > ** ** > Q2. Does key wrapping give integrity protection that you might want for > name/value pairs even when they are not confidential. For instance, could > it be useful to include, say, =93e=94 inside =93wk=94 instead of within = =93kat=94? Do > recipients need to check both the first binary segment and =93kat=94 when > looking for any attribute not explicitly listed in the =93encoding rules= =94? > Does the first binary segment take precedence over =93kat=94?**** > ** ** > Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples sh= ow it as > a top-level attribute instead.**** > ** ** > A4. The symmetric key examples don=92t include a key type (=93kty=94). I= s it > implied by something at a higher level (eg a JWE), or is there a default > value meaning =93a shared symmetric secret, with no specific associated > crypto algorithm=94?**** > ** ** > Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be > better for encoding the length of binary segments. 2 bytes (64 KB max) > might be too small, particularly if the binary encoding is used for all > JOSE messages (eg JWE) not just keys.**** > ** ** > ** ** > --**** > James Manger**** > ** ** > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, 11 March 2013 6:29 AM > *To:* Mike Jones > *Cc:* Leif Johansson; jose@ietf.org > *Subject:* Re: [jose] A Unified Theory of JOSE Keys**** > ** ** > So it seems to me that the group has three questions to answer when it > comes to wrapped keys:**** > ** ** > Q1(Encryption): What mechanism will be used to encrypt key material, > possibly containing attributes? **** > Answer 1.A: JWE**** > Answer 1.B: Key wrap, derived from JWE**** > ** ** > Q2(Packing): How should the wrapped key+attributes be expressed?**** > Answer 2.A: JSON format (not packed)**** > Answer 2.B: JSON, with binary parts expressed directly **** > ** ** > JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in > my Unified Theory is 1.B / 2.B. **** > ** ** > For context, I'm working from a few principles here:**** > -- We should not define multiple ways to wrap symmetric keys**** > -- We should not do things that would preclude accreditation under > major security standards (e.g., FIPS)**** > -- We should choose encodings that minimize the size overhead imposed > by the encoding**** > If we agree on these principles, then the answers to the above > questions seem pretty clear.**** > ** ** > It seems to me that Steve's point on Question 1 pretty much decides the > question for B. If we want systems using JOSE to have any hope of gettin= g > accreditation (e.g., under FIPS), then they will have to use standard > mechanisms for protecting keys, even if those keys are packaged with oth= er > attributes. Mike's message misses the point that the key wrap algorithm > isn't actually being used to protect the key itself -- for that you would > use a normal, content-oriented encryption algorithm, in contravention of > the FIPS requirements.**** > ** ** > Question 2 is mostly a question of backward compatibility and > efficiency. If we want to have any hope of being backward-compatible wit= h > JWE key wrapping -- that is, avoiding having two ways to do the same thin= g > -- then we need a way to handle the octets of a key directly, as opposed = to > base64-encoded within a JSON object. That would be option 2.B.**** > ** ** > There are also compactness arguments for 1.B and 2.B. If you do 1.A, > then in addition to the header, you have to carry a separate CMK, IV, and > MAC value. If you're using AES-GCM with a 128-bit key, that's a total of > 44 octets (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key > wrap, the wrapping algorithm adds a maximum of 16 octets to the object. > The difference in case 2 is even greater, because you're talking about > double-base64 encoding, which entails a penalty of 30% of the payload. I= f > you're protecting an AES key, this might only be a few octets, but if > you're protecting a 2048-bit RSA key, then you're talking hundreds of > octets. So if you care about compactness, 1.B and 2.B make a lot more > sense.**** > ** ** > To respond to Mike's specific points:**** > ** ** > > I=92ll note that in JSON Web Encryption, we are already using standard > methods for encrypting key values for the Content Master Key =96 specific= ally > AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key > agreement).**** > > ** ** > However, the actual key you're wrapping is still protected with a > content-oriented algorithm. So you're still violating the FIPS > requirements.**** > **** > ** ** > > What we=92re talking about here, however, is encrypting potentially mor= e > than just key values =96 in this case, key values with associated key use > information, algorithm information, key ID information, and potentially > other attributes. As such, using the JWK JSON representation of this > information as the payload of a standard JWE encryption seems like the > obvious solution, which doesn=92t require inventing anything we don=92t a= lready > have.**** > > ** ** > Absolutely agree that JSON is the right representation. But the key is > still included in that representation, so you need to apply key wrapping > algorithms to it. And, as discussed above, it's a lot more efficient if > you pack the JSON so that the binary isn't double-encoded.**** > **** > > draft-miller-jose-jwe-protected-jwk already describes doing that. I > believe that we should adopt this as a working group document as soon as > the rechartering is complete.**** > > ** ** > That draft has some excellent suggestions for password-based key > wrapping. We should incorporate that into whatever solution we come up > with. But for the reasons discussed above, it's wrong in using JWK for t= he > encapsulation.**** > ** ** > I also disagree that we need a separate document for this. If we're > going to avoid having two ways to wrap keys, this needs to be part of > JWE/JWK.**** > ** ** > --Richard**** > ** ** > > -- Mike**** > > _______________________________________________ > > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > --bcaec54fae4872730604d7d3ecff Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One other thing to note is that we're effectively *already* *defining* = a binary-optimized JSON in the definition of JWS and JWE. =A0Consider the f= ollowing JSON structure:

{
=A0 =A0 "alg&q= uot;: "A128KW",
=A0 =A0 "enc": "A128GCM",
=A0 =A0 "= kid": "ceci",
=A0 =A0 "key": "...&q= uot;,
=A0 =A0 "iv": "...",
=A0 =A0 = "ciphertext": "...",
=A0 =A0 "mac": "..."
}

If you apply the algorithm in the slides, with the encoding rules [= "key", "iv", "ciphertext", "mac"], = and with base64 instead of length/value encoding, then you get a well-forme= d JWE.

My proposal is just to do the same thing, but to c= oncatenate the parts in binary rather than text.

<= br>
On Tue, Mar 12, 2013 at 6:58 PM, Mark Wat= son <watsonm@netflix.com> wrote:
Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't= this a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful,= but there have been various attempts to define such things in the past (BS= ON, ubjson, =85). A big advantage of JSON is that the data is self-describi= ng, in terms of types: you don't need any external "document type definition" or "schema" to= decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at le= ast include the member names that have been moved to the binary segment som= ewhere. So then a decoder can undo the translation and give back a regular = JSON object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space s= aving ?

=85Mark


On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

=93A Unified Theory of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.
=A0
It looks like a key is a JSON object with any number of name/value = pairs. For some names, the value is a base64[url]-encoding of binary data.<= u>
=A0
To wrap a key, its name/value pairs are divided into 3 groups:
1.=A0=A0=A0=A0=A0=A0=A0= non-confidential name/value pairs
2.=A0=A0=A0=A0=A0=A0=A0= confidential non-binary name/value pairs
3.=A0=A0=A0=A0=A0=A0=A0= confidential binary name/value pairs
=A0
The first group are put into the =93kat=94 (key attributes?) field = of the output.
=A0
The second group =97 if its not empty =97 becomes the first binary = segment of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in= the output indicates the second group is present.
=A0
The third group (in order) become subsequent binary segments of the= plaintext. The names in the third group (and their order) is determined by= the type of the key being wrapped (=93kty=94 attribute).
=A0
The plaintext is wrapped (encrypted), then base64url-encoded to giv= e the =93wk=94 attribute in the output.
=A0
=A0
Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93k= at=94. I assume this is a typo. =93kat=94 would include =93n=94 and =93e=94= , but =93d=94 (the private exponent) would always be encrypted and hence be inside =93wk=94.
=A0
Q2. Does key wrapping give integrity protection that you might want= for name/value pairs even when they are not confidential. For instance, co= uld it be useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? Do recipients ne= ed to check both the first binary segment and =93kat=94 when looking for an= y attribute not explicitly listed in the =93encoding rules=94? Does the fir= st binary segment take precedence over =93kat=94?
=A0
Q3. Should =93kty=94 (key type) appear within =93kat=94? The exampl= es show it as a top-level attribute instead.
=A0
A4. The symmetric key examples don=92t include a key type (=93kty= =94). Is it implied by something at a higher level (eg a JWE), or is there = a default value meaning =93a shared symmetric secret, with no specific associated crypto algorithm=94?<= u>
=A0
Q5. Using a VARINT (variable-length integer) instead of 2 bytes wou= ld be better for encoding the length of binary segments. 2 bytes (64 KB max= ) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just key= s.
=A0
=A0
--
James Manger
=A0
From:=A0jose-bo= unces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behalf Of=A0Richard Barnes
Sent:=A0Monday, 11 March 2013 6:29 AM
To:=A0Mike Jones
Cc:=A0Leif Johansson;=A0jose@ietf.org
Subject:=A0Re: [jose] A Unified Theory of JOSE Keys<= /u>
=A0
So it seems to me that the group has three questions to answer when it come= s to wrapped keys:
=A0
Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes? =A0
=A0 =A0 Answer 1.A: JWE
=A0 =A0 Answer 1.B: Key wrap, derived from JWE
=A0
Q2(Packing): How should the wrapped key+attributes be expressed?<= /u>
=A0 =A0 Answer 2.A: JSON format (not packed)
=A0 =A0 Answer 2.B: JSON, with binary parts expressed directly=A0=
=A0
JWE-within-JWK represents answer 1.A / 2.A. =A0The solution proposed in my = Unified Theory is 1.B / 2.B. =A0
=A0
For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys<= /div>
-- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by th= e encoding
If we agree on these principles, then the answers to the above questions se= em pretty clear.
=A0
It seems to me that Steve's point on Question 1 pretty much decides the= question for B. =A0If we want systems using JOSE to have any hope of getti= ng accreditation (e.g., under FIPS), then they will have to use standard me= chanisms for protecting keys, even if those keys are =A0packaged with other attributes. =A0Mike's message mi= sses the point that the key wrap algorithm isn't actually being used to= protect the key itself -- for that you would use a normal, content-oriente= d encryption algorithm, in contravention of the FIPS requirements.
=A0
Question 2 is mostly a question of backward compatibility and efficiency. = =A0If we want to have any hope of being backward-compatible with JWE key wr= apping -- that is, avoiding having two ways to do the same thing -- then we= need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object. =A0That= would be option 2.B.
=A0
There are also compactness arguments for 1.B and 2.B. =A0If you do 1.A, the= n in addition to the header, you have to carry a separate CMK, IV, and MAC = value. =A0If you're using AES-GCM with a 128-bit key, that's a tota= l of 44 octets (16 CMK, 16 MAC, 12 IV). =A0In contrast, if you just do AES key wrap, the wrapping algorithm adds a maxim= um of 16 octets to the object. =A0The difference in case 2 is even greater,= because you're talking about double-base64 encoding, which entails a p= enalty of 30% of the payload. =A0If you're protecting an AES key, this might only be a few octets, but if you're = protecting a 2048-bit RSA key, then you're talking hundreds of octets. = =A0So if you care about compactness, 1.B and 2.B make a lot more sense.<= /u>
=A0
To respond to Mike's specific points:
=A0
I=92ll note that in JSON Web Encryption, we are alre= ady using standard methods for encrypting key values for the Content Master= Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement= ).
=A0
However, the actual key you're wrapping is still protected with a conte= nt-oriented algorithm. =A0So you're still violating the FIPS requiremen= ts.
=A0
=A0
What we=92re talking about here, however, is encrypt= ing potentially more than just key values =96 in this case, key values with= associated key use information, algorithm information, key ID information, and potentially other attribute= s.=A0 As such, using the JWK JSON representation of this information as the= payload of a standard JWE encryption seems like the obvious solution, whic= h doesn=92t require inventing anything we don=92t already have.<= /div>
=A0
Absolutely agree that JSON is the right representation. =A0But the key is s= till included in that representation, so you need to apply key wrapping alg= orithms to it. =A0And, as discussed above, it's a lot more efficient if= you pack the JSON so that the binary isn't double-encoded.
=A0=A0
draft-miller-jose-jwe-protected-jwk already describe= s doing that.=A0 I believe that we should adopt this as a working group doc= ument as soon as the rechartering is complete.
=A0
That draft has some excellent suggestions for password-based key wrapping. = =A0We should incorporate that into whatever solution we come up with. =A0Bu= t for the reasons discussed above, it's wrong in using JWK for the enca= psulation.
=A0
I also disagree that we need a separate document for this. =A0If we're = going to avoid having two ways to wrap keys, this needs to be part of JWE/J= WK.
=A0
--Richard
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
_______________________________________________

jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/l= istinfo/jose


--bcaec54fae4872730604d7d3ecff-- From watsonm@netflix.com Wed Mar 13 13:11:27 2013 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 E7DF821F87D0 for ; Wed, 13 Mar 2013 13:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.262 X-Spam-Level: X-Spam-Status: No, score=-9.262 tagged_above=-999 required=5 tests=[AWL=-1.002, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_HI=-8, TRACKER_ID=2.003] 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 Clyc6w6KyHHM for ; Wed, 13 Mar 2013 13:11:25 -0700 (PDT) Received: from exout104.netflix.com (exout104.netflix.com [69.53.237.163]) by ietfa.amsl.com (Postfix) with ESMTP id 1B1F911E80A5 for ; Wed, 13 Mar 2013 13:11:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; bh=PCwIhISRipSDZtRCc0Giwm5Fvzs=; b=M95ORiFvsv+PdBSoTiZbWoE1cJCMTTiuB4Gts8YY9F+9JN+1k224BbBhJ6B140KX4dzkevLM g0IpA8qh6k1RDhNzjMfKAnJhURd5Veeni9vMKsB7VmgfkoROdJ+xLhHzwh52fDGoodx3Dv5H wS54Y5u4D1GlhYAn2JdmCj6brk/eg5og4wCoH6AEjQgQETWws+qpPaWuVtnnfSnY9bqAOmCy bDYWAiC3tNfYI6ZH4kCrXxEjv0WyZPeCn/T7decA1EErNV8HruaVfUwNt58/iMzGx2t7Ekdm ZgdeuN0KCrppPIwXQ3RhHI2tUqzFYkRbRx+Oc6Jcxkj7GxncPR38Gw== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; b=JUjGJ47eY+4BONNyOLCQ3jkbYEnIaENEzAMxbO3QPyBAeQprY3qsRcEsSxLwV0y/IEy0e1jZ 69qtaHcab4ohBy2zQ6YiR+/O8XDifMke6/dQVjaQWr1Drx2vhn15+Eig8gR8tFKjd6hfSYMO UjBEvHN/K+XgwFajpTbQNKxaHwGHYuXAo4o0EypglsiDWiFeFdpWRNagAo1ns4TzFnFa5L8v Ws/z0cJ1F7njvmnega5WGeCryMfL4gI9OaNqI/wKeTrR7h1T/Ei69QI37XY7yUwHmJZ/ODqJ 29P60vvTzFfA6NNasr6jiSgkKLkQo6MipUP5h/A69oP/R9TGxdB6lg== Received: from EXFE104.corp.netflix.com (10.64.32.104) by exout104.netflix.com (10.64.240.74) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 13 Mar 2013 13:11:18 -0700 Received: from EXMB106.corp.netflix.com ([169.254.6.135]) by exfe104.corp.netflix.com ([10.64.32.104]) with mapi id 14.02.0283.003; Wed, 13 Mar 2013 13:11:24 -0700 From: Mark Watson To: Richard Barnes Thread-Topic: [jose] A Unified Theory of JOSE Keys Thread-Index: AQHOHCzC1ChjIIhtSkaPN+ZxIgTDipict+CAgAK/VwCAAAd1gIAABnUAgABC8ICAAggNgIABV4QAgAFcVoCAAAc2gA== Date: Wed, 13 Mar 2013 20:11:23 +0000 Message-ID: <4EEC156B-AB33-4BFF-A6F3-CB39F64F48FB@netflix.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.24.210] Content-Type: multipart/alternative; boundary="_000_4EEC156BAB334BFFA6F3CB39F64F48FBnetflixcom_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 13 Mar 2013 20:11:27 -0000 --_000_4EEC156BAB334BFFA6F3CB39F64F48FBnetflixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 13, 2013, at 12:46 PM, Richard Barnes wrote: I would actually be completely ok with that -- if the wrapping in JWE were = consistent. But I suspect some folks will balk at the ~65% size increase:] IIUC, what you mean by consistent is that JOSE should define a single key w= rapping algorithm, and that this should be used to create the "wk" for JWE = as well as being used 'stand-alone' for other key wrapping applications. Th= is algorithm would have the following inputs and outputs: Inputs - Type of key to be wrapped - Key to be wrapped - Key attributes (optional, possibly split into protected and unprotected) - Type of Key Encryption Key (AES or RSA) - Key Encryption Key Output: - Wrapped key data (binary data) - Key attributes (optional, unprotected ones) Your proposal (roughly, assuming you want it to fall back to exactly what i= s in JWE for the wrapped CMK case) (1) Construct a JWK of the key to be wrapped, including any attributes, but= excluding fields known to be binary according to the key type (2) If the resulting JWK is empty and there is only only binary field for t= he key - the data to be wrapped is that single binary field Otherwise - prepend the JWK with a length field - prepend each binary field from the key with a length field - the data to be wrapped is the concatenation of the above (3) Apply the key wrapping algorithm to the data to be wrapped, using the K= ey Encryption Key This could be modified as follows: (1) Construct a JWK of the key to be wrapped, including any attributes (2) If the resulting JWK contains a single binary field - the data to be wrapped is that single binary field Otherwise - the data to be wrapped is the JWK object (3) Apply the key wrapping algorithm to the data to be wrapped, using the K= ey Encryption Key I don't see that one is more "consistent" than the other: both have a great= big "IF" in step 2 that calls out the simple symmetric key case. =85Mark // 128-bit raw key XXXXXXXXXXXXXXXX // Wrapped raw key XXXXXXXXXXXXXXXXXXXXXXXX // Base64 of wrapped raw key Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes // JWK of key {"k":"QEhAwEkOEtstCaEEd8sKig"} // Wrapped JWK XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX // Base64 of wrapped JWK +N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solution 2.A,= 53 bytes On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson > wrote: Richard, Regarding the proposal for a binary-optimized JSON encoding, isn't this a b= it orthogonal to the problem at hand ? I understand that this is one area where such a thing would be useful, but = there have been various attempts to define such things in the past (BSON, u= bjson, =85). A big advantage of JSON is that the data is self-describing, i= n terms of types: you don't need any external "document type definition" or= "schema" to decode and manipulate a JSON object. If you are going to specify something like this, I'd suggest at least inclu= de the member names that have been moved to the binary segment somewhere. S= o then a decoder can undo the translation and give back a regular JSON obje= ct with base64-encoded members, without access to this side-information. But I would ask if this trouble is really worth it for the 25% space saving= ? =85Mark On Mar 11, 2013, at 7:30 PM, Manger, James H wrote: =93A Unified Theory of JOSE Keys=94 looks quite good. It looks like a key is a JSON object with any number of name/value pairs. F= or some names, the value is a base64[url]-encoding of binary data. To wrap a key, its name/value pairs are divided into 3 groups: 1. non-confidential name/value pairs 2. confidential non-binary name/value pairs 3. confidential binary name/value pairs The first group are put into the =93kat=94 (key attributes?) field of the o= utput. The second group =97 if its not empty =97 becomes the first binary segment = of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the out= put indicates the second group is present. The third group (in order) become subsequent binary segments of the plainte= xt. The names in the third group (and their order) is determined by the typ= e of the key being wrapped (=93kty=94 attribute). The plaintext is wrapped (encrypted), then base64url-encoded to give the = =93wk=94 attribute in the output. Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat=94. I= assume this is a typo. =93kat=94 would include =93n=94 and =93e=94, but = =93d=94 (the private exponent) would always be encrypted and hence be insid= e =93wk=94. Q2. Does key wrapping give integrity protection that you might want for nam= e/value pairs even when they are not confidential. For instance, could it b= e useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat= =94? Do recipients need to check both the first binary segment and =93kat= =94 when looking for any attribute not explicitly listed in the =93encoding= rules=94? Does the first binary segment take precedence over =93kat=94? Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples show = it as a top-level attribute instead. A4. The symmetric key examples don=92t include a key type (=93kty=94). Is i= t implied by something at a higher level (eg a JWE), or is there a default = value meaning =93a shared symmetric secret, with no specific associated cry= pto algorithm=94? Q5. Using a VARINT (variable-length integer) instead of 2 bytes would be be= tter for encoding the length of binary segments. 2 bytes (64 KB max) might = be too small, particularly if the binary encoding is used for all JOSE mess= ages (eg JWE) not just keys. -- James Manger From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, 11 March 2013 6:29 AM To: Mike Jones Cc: Leif Johansson; jose@ietf.org Subject: Re: [jose] A Unified Theory of JOSE Keys So it seems to me that the group has three questions to answer when it come= s to wrapped keys: Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes? Answer 1.A: JWE Answer 1.B: Key wrap, derived from JWE Q2(Packing): How should the wrapped key+attributes be expressed? Answer 2.A: JSON format (not packed) Answer 2.B: JSON, with binary parts expressed directly JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in my Un= ified Theory is 1.B / 2.B. For context, I'm working from a few principles here: -- We should not define multiple ways to wrap symmetric keys -- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS) -- We should choose encodings that minimize the size overhead imposed by th= e encoding If we agree on these principles, then the answers to the above questions se= em pretty clear. It seems to me that Steve's point on Question 1 pretty much decides the que= stion for B. If we want systems using JOSE to have any hope of getting acc= reditation (e.g., under FIPS), then they will have to use standard mechanis= ms for protecting keys, even if those keys are packaged with other attribu= tes. Mike's message misses the point that the key wrap algorithm isn't act= ually being used to protect the key itself -- for that you would use a norm= al, content-oriented encryption algorithm, in contravention of the FIPS req= uirements. Question 2 is mostly a question of backward compatibility and efficiency. = If we want to have any hope of being backward-compatible with JWE key wrapp= ing -- that is, avoiding having two ways to do the same thing -- then we ne= ed a way to handle the octets of a key directly, as opposed to base64-encod= ed within a JSON object. That would be option 2.B. There are also compactness arguments for 1.B and 2.B. If you do 1.A, then = in addition to the header, you have to carry a separate CMK, IV, and MAC va= lue. If you're using AES-GCM with a 128-bit key, that's a total of 44 octe= ts (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key wrap, the = wrapping algorithm adds a maximum of 16 octets to the object. The differen= ce in case 2 is even greater, because you're talking about double-base64 en= coding, which entails a penalty of 30% of the payload. If you're protectin= g an AES key, this might only be a few octets, but if you're protecting a 2= 048-bit RSA key, then you're talking hundreds of octets. So if you care ab= out compactness, 1.B and 2.B make a lot more sense. To respond to Mike's specific points: I=92ll note that in JSON Web Encryption, we are already using standard meth= ods for encrypting key values for the Content Master Key =96 specifically A= ES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agr= eement). However, the actual key you're wrapping is still protected with a content-o= riented algorithm. So you're still violating the FIPS requirements. What we=92re talking about here, however, is encrypting potentially more th= an just key values =96 in this case, key values with associated key use inf= ormation, algorithm information, key ID information, and potentially other = attributes. As such, using the JWK JSON representation of this information= as the payload of a standard JWE encryption seems like the obvious solutio= n, which doesn=92t require inventing anything we don=92t already have. Absolutely agree that JSON is the right representation. But the key is sti= ll included in that representation, so you need to apply key wrapping algor= ithms to it. And, as discussed above, it's a lot more efficient if you pac= k the JSON so that the binary isn't double-encoded. draft-miller-jose-jwe-protected-jwk already describes doing that. I believ= e that we should adopt this as a working group document as soon as the rech= artering is complete. That draft has some excellent suggestions for password-based key wrapping. = We should incorporate that into whatever solution we come up with. But fo= r the reasons discussed above, it's wrong in using JWK for the encapsulatio= n. I also disagree that we need a separate document for this. If we're going = to avoid having two ways to wrap keys, this needs to be part of JWE/JWK. --Richard -- Mike _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4EEC156BAB334BFFA6F3CB39F64F48FBnetflixcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8DDD19E331139040AF988489761C5E57@netflix.com> Content-Transfer-Encoding: quoted-printable
On Mar 13, 2013, at 12:46 PM, Richard Barnes wrote:

I would actually be completely ok with that -- if= the wrapping in JWE were consistent.  But I suspect some folks will b= alk at the ~65% size increase:]

IIUC, what you mean by consistent is that JOSE should define a single = key wrapping algorithm, and that this should be used to create the "wk= " for JWE as well as being used 'stand-alone' for other key wrapping a= pplications. This algorithm would have the following inputs and outputs:

Inputs
- Type of key to be wrapped
- Key to be wrapped
- Key attributes (optional, possibly split into protected and unprotec= ted)
- Type of Key Encryption Key (AES or RSA)
- Key Encryption Key

Output:
- Wrapped key data (binary data)
- Key attributes (optional, unprotected ones)

Your proposal (roughly, assuming you want it to fall back to exactly w= hat is in JWE for the wrapped CMK case)
(1) Construct a JWK of the key to be wrapped, including any attributes= , but excluding fields known to be binary according to the key type
(2) If the resulting JWK is empty and there is only only binary field = for the key
- the = data to be wrapped is that single binary field
Otherw= ise
- prep= end the JWK with a length field
- prep= end each binary field from the key with a length field
- the = data to be wrapped is the concatenation of the above
(3) Apply the key wrapping algorithm to the data to be wrapped, using = the Key Encryption Key

This could be modified as follows:
(1) Construct a JWK of the key to be wrapped, including any attributes=
(2) If the resulting JWK contains a single binary field
- t= he data to be wrapped is that single binary field
Oth= erwise
- t= he data to be wrapped is the JWK object
(3) Apply the key wrapping algorithm to the data to be wrapped, using = the Key Encryption Key

I don't see that one is more "consistent" than the other: bo= th have a great big "IF" in step 2 that calls out the simple symm= etric key case.

=85Mark


// 128-bit raw key
XXXXXXXXXXXXXXXX
 // Wrapped raw key
XXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped raw key
Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes
// JWK of key
{"k":"QEhAwEkOEtstCaEEd8sKig"}
// Wrapped JWK
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped JWK
+N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <----= -- Solution 2.A, 53 bytes



On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson <watsonm@netfli= x.com> wrote:
Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't thi= s a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful,= but there have been various attempts to define such things in the past (BS= ON, ubjson, =85). A big advantage of JSON is that the data is self-describi= ng, in terms of types: you don't need any external "document type definition" or "schema" to= decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at least = include the member names that have been moved to the binary segment somewhe= re. So then a decoder can undo the translation and give back a regular JSON= object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space s= aving ?

=85Mark

On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

=93A Unified Theory of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.
 
It looks like a key is a JSON object with any number of name/value = pairs. For some names, the value is a base64[url]-encoding of binary data.<= u>
 
To wrap a key, its name/value pairs are divided into 3 groups:
1.       <= /span>non-confidential name/value pairs
2.       <= /span>confidential non-binary name/value pairs
3.       <= /span>confidential binary name/value pairs
 
The first group are put into the =93kat=94 (key attributes?) field = of the output.
 
The second group =97 if its not empty =97 becomes the first binary = segment of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in= the output indicates the second group is present.
 
The third group (in order) become subsequent binary segments of the= plaintext. The names in the third group (and their order) is determined by= the type of the key being wrapped (=93kty=94 attribute).
 
The plaintext is wrapped (encrypted), then base64url-encoded to giv= e the =93wk=94 attribute in the output.
 
 
Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93k= at=94. I assume this is a typo. =93kat=94 would include =93n=94 and =93e=94= , but =93d=94 (the private exponent) would always be encrypted and hence be inside =93wk=94.
 
Q2. Does key wrapping give integrity protection that you might want= for name/value pairs even when they are not confidential. For instance, co= uld it be useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? Do recipients need to= check both the first binary segment and =93kat=94 when looking for any att= ribute not explicitly listed in the =93encoding rules=94? Does the first bi= nary segment take precedence over =93kat=94?
 
Q3. Should =93kty=94 (key type) appear within =93kat=94? The exampl= es show it as a top-level attribute instead.
 
A4. The symmetric key examples don=92t include a key type (=93kty= =94). Is it implied by something at a higher level (eg a JWE), or is there = a default value meaning =93a shared symmetric secret, with no specific associated crypto algorithm=94?
 
Q5. Using a VARINT (variable-length integer) instead of 2 bytes wou= ld be better for encoding the length of binary segments. 2 bytes (64 KB max= ) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just key= s.
 
 
--
James Manger
 
From: jose= -bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, 11 March 2013 6:29 AM
To: Mike Jones
Cc: Leif Johansson; jose@ietf.org
Subject: Re: [jose] A Unified Theory of JOSE Keys<= u>
 
So it seems to me that the group has three questions to answer when it come= s to wrapped keys:
 
Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes?  
    Answer 1.A: JWE
    Answer 1.B: Key wrap, derived from JWE
 
Q2(Packing): How should the wrapped key+attributes be expressed?=
    Answer 2.A: JSON format (not packed)
    Answer 2.B: JSON, with binary parts expressed directly <= u>
 
JWE-within-JWK represents answer 1.A / 2.A.  The solution proposed in = my Unified Theory is 1.B / 2.B.  
 
For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys<= /div>
-- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by th= e encoding
If we agree on these principles, then the answers to the above questions se= em pretty clear.
 
It seems to me that Steve's point on Question 1 pretty much decides the que= stion for B.  If we want systems using JOSE to have any hope of gettin= g accreditation (e.g., under FIPS), then they will have to use standard mec= hanisms for protecting keys, even if those keys are  packaged with other attributes.  Mike's message = misses the point that the key wrap algorithm isn't actually being used to p= rotect the key itself -- for that you would use a normal, content-oriented = encryption algorithm, in contravention of the FIPS requirements.
 
Question 2 is mostly a question of backward compatibility and efficiency. &= nbsp;If we want to have any hope of being backward-compatible with JWE key = wrapping -- that is, avoiding having two ways to do the same thing -- then = we need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object.  T= hat would be option 2.B.
 
There are also compactness arguments for 1.B and 2.B.  If you do 1.A, = then in addition to the header, you have to carry a separate CMK, IV, and M= AC value.  If you're using AES-GCM with a 128-bit key, that's a total = of 44 octets (16 CMK, 16 MAC, 12 IV).  In contrast, if you just do AES key wrap, the wrapping algorithm adds a maxim= um of 16 octets to the object.  The difference in case 2 is even great= er, because you're talking about double-base64 encoding, which entails a pe= nalty of 30% of the payload.  If you're protecting an AES key, this might only be a few octets, but if you're prot= ecting a 2048-bit RSA key, then you're talking hundreds of octets.  So= if you care about compactness, 1.B and 2.B make a lot more sense.
 
To respond to Mike's specific points:
 
I=92ll note that in JSON Web Encryption, we are alre= ady using standard methods for encrypting key values for the Content Master= Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).<= span lang=3D"EN-US">
 
However, the actual key you're wrapping is still protected with a content-o= riented algorithm.  So you're still violating the FIPS requirements.
 
 
What we=92re talking about here, however, is encrypt= ing potentially more than just key values =96 in this case, key values with= associated key use information, algorithm information, key ID information, and potentially other attributes.  A= s such, using the JWK JSON representation of this information as the payloa= d of a standard JWE encryption seems like the obvious solution, which doesn= =92t require inventing anything we don=92t already have.
 
Absolutely agree that JSON is the right representation.  But the key i= s still included in that representation, so you need to apply key wrapping = algorithms to it.  And, as discussed above, it's a lot more efficient = if you pack the JSON so that the binary isn't double-encoded.
  
draft-miller-jose-jwe-protected-jwk already describe= s doing that.  I believe that we should adopt this as a working group = document as soon as the rechartering is complete.
 
That draft has some excellent suggestions for password-based key wrapping. =  We should incorporate that into whatever solution we come up with. &n= bsp;But for the reasons discussed above, it's wrong in using JWK for the en= capsulation.
 
I also disagree that we need a separate document for this.  If we're g= oing to avoid having two ways to wrap keys, this needs to be part of JWE/JW= K.
 
--Richard
 
        &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p; -- Mike
_______________________________________________

jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/l= istinfo/jose



--_000_4EEC156BAB334BFFA6F3CB39F64F48FBnetflixcom_-- From rlb@ipv.sx Wed Mar 13 13:12:56 2013 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 94D4D11E816E for ; Wed, 13 Mar 2013 13:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.991 X-Spam-Level: X-Spam-Status: No, score=-0.991 tagged_above=-999 required=5 tests=[AWL=-0.566, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 y6O8ywf8BAWC for ; Wed, 13 Mar 2013 13:12:55 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1411E815F for ; Wed, 13 Mar 2013 13:12:55 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id dn14so1474923obc.18 for ; Wed, 13 Mar 2013 13:12:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=UqXSihslHFdv/PYdYLh/tjmctmGj/2k46evSiaNJqbs=; b=mdfxIIoxWn7j+nDidsUYlg1zqimQnQn4e/flv5/385on8DYUbxPWgco48tcuJqXQzi F+AGsXm5su/eYbZEiHLrE9z5GKGM/JXQoe36BPrg//8yeMh1byGyM1W0Uoo9RTNjMjPu A0Y12Kyof5hdpdkKuH2/WIj5FlxRdnVeAFE8IYz1hjm8yadNesdA9bYHWqiiCVsJMi3P 5G87CnhtGhNkFD6CTIhkMMLMW9CXILI/P6t66Y3F5e3Sdj2L+NqeMPh1o/kxtITmZsau YN8LQcFpEsW5XHvwui3KPK1o7LBZTOS61w+fKQ9sPHS2MsTfSskB7SR1JbGLSa+GDk2M VDeg== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr16737167oea.130.1363205575235; Wed, 13 Mar 2013 13:12:55 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 13 Mar 2013 13:12:55 -0700 (PDT) X-Originating-IP: [128.89.254.35] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B8469AB@WSMSG3153V.srv.dir.telstra.com> References: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B8469AB@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 13 Mar 2013 16:12:55 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8fb20318116f2104d7d408ec X-Gm-Message-State: ALoCoQnzk3i7/rbsNXfx+mqg/PAI98WiPSAeCUG5yxMrzNWGBsjbcL/pMbW4mpmwNQ/Km82/rLag Cc: "jose@ietf.org" Subject: Re: [jose] "crit" strings don't have to be field names 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, 13 Mar 2013 20:12:56 -0000 --e89a8fb20318116f2104d7d408ec Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't really think that there's much benefit to the additional complexity here. You don't need it for the 800-56A case, because that's in the current document, and will thus get real requirements language in the spec. If you do want to group extension fields in this way, you can just group them into an object under a single extension field. For example: { "alg": "foo", "new-thing": { "part1": 42, "part2": "six" }, "crit": ["new-thing"] } On Tue, Mar 12, 2013 at 10:08 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > As we define the "crit" field we don't need to use field names as the > critical strings. > > Implementations will have a list of critical strings they understand > (based on the specs that define those critical strings) and will confirm > that all the "crit" values are in their list. This will be a distinct ste= p > from the other code that uses specific fields. > > For instance, if we defined a simple KDF initially then later specified > support for the NIST 800-56A Concat KDF it would be better to define 1 > critical string "nist800-56A", instead of listing "PartyUInfo", > "PartyVInfo", "SuppPubInfo", and "SuppPriveInfo" fields names in the "cri= t" > field -- any of which might be absent from a particular JOSE message if > they had some default value. > > Another example: if a group insists on a strong signature verification > policy (eg MUST use OCSP, MUST hard-fail if OCSP is unavailable, MUST che= ck > Certificate Transparency, and MUST log results for 7 years) there is no n= ew > header field to add to a JWS, but it could define the critical string > "StrongSig1". > > > -- > James Manger > > -------- Original Message -------- > > Subject: [jose] Proposed resolution of header criticality issue > > From: Karen O'Donoghue > > Date: Tue, March 12, 2013 12:31 am > > To: jose@ietf.org > > > 3. Define a new header field that lists which additional fields not > > defined in the base specifications must be understood and acted upon > > when present. For instance, an expiration-time extension field could > > be marked as must-be-understood-and-acted-upon. One possible name for > > this would be =93crit=94 (critical). An example use, along with a > > hypothetical =93exp=94 (expiration-time) field is: > > > > {"alg":"ES256", > > "crit":["exp"], > > "exp=94:1363284000 > > } > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --e89a8fb20318116f2104d7d408ec Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't really think that there's much benefit to the additional co= mplexity here. =A0You don't need it for the 800-56A case, because that&= #39;s in the current document, and will thus get real requirements language= in the spec. =A0If you do want to group extension fields in this way, you = can just group them into an object under a single extension field. =A0For e= xample:

{
=A0 =A0 "alg": "foo",
<= div>=A0 =A0 "new-thing": {
=A0 =A0 =A0 =A0 "part1&= quot;: 42,
=A0 =A0 =A0 =A0 "part2": "six"
=A0 =A0 },
=A0 =A0 "crit": ["new-thing"]
}



On Tue, Mar 12, 2013 at= 10:08 PM, Manger, James H <James.H.Manger@team.telstra.com<= /a>> wrote:
As we define the "crit" field we d= on't need to use field names as the critical strings.

Implementations will have a list of critical strings they understand (based= on the specs that define those critical strings) and will confirm that all= the "crit" values are in their list. This will be a distinct ste= p from the other code that uses specific fields.

For instance, if we defined a simple KDF initially then later specified sup= port for the NIST 800-56A Concat KDF it would be better to define 1 critica= l string "nist800-56A", instead of listing "PartyUInfo"= , "PartyVInfo", "SuppPubInfo", and "SuppPriveInfo&= quot; fields names in the "crit" field -- any of which might be a= bsent from a particular JOSE message if they had some default value.

Another example: if a group insists on a strong signature verification poli= cy (eg MUST use OCSP, MUST hard-fail if OCSP is unavailable, MUST check Cer= tificate Transparency, and MUST log results for 7 years) there is no new he= ader field to add to a JWS, but it could define the critical string "S= trongSig1".


--
James Manger

=A0-------- Original Message --------
> Subject: [jose] Proposed resolution of header criticality issue
> From: Karen O'Donoghue <o= donoghue@isoc.org>
> Date: Tue, March 12, 2013 12:31 am
> To: jose@ietf.org

> =A03. =A0Define a new header field that lists which additional fields = not
> defined in the base specifications must be understood and acted upon > when present. =A0For instance, an expiration-time extension field coul= d
> be marked as must-be-understood-and-acted-upon. =A0One possible name f= or
> this would be =93crit=94 (critical). =A0An example use, along with a > hypothetical =93exp=94 (expiration-time) field is:
>
> =A0 =A0{"alg":"ES256",
> =A0 =A0 "crit":["exp"],
> =A0 =A0 "exp=94:1363284000
> =A0 =A0}

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--e89a8fb20318116f2104d7d408ec-- From rlb@ipv.sx Wed Mar 13 13:19:16 2013 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 5720D11E8163 for ; Wed, 13 Mar 2013 13:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.037 X-Spam-Level: X-Spam-Status: No, score=0.037 tagged_above=-999 required=5 tests=[AWL=-1.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, TRACKER_ID=2.003] 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 Vqk+9hFhkx0U for ; Wed, 13 Mar 2013 13:19:14 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 728B411E80FB for ; Wed, 13 Mar 2013 13:19:14 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wd20so1441955obb.23 for ; Wed, 13 Mar 2013 13:19:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=YkoxI9bcaTEBsMCD9NhCMM79q421EaMdoz/HFWNgm2M=; b=TiUuBXc3j1U28rlKzXXdXWW0Bq+tXYgmZ1P7xhwf3bXwGjsdMOq+4oXRFEJNuqZk4H zXnOZRtSJ7FczWffxqK5cdrOPxinRSn2GbmdM7i+MmO2h4vpyqL/HjXmifycG4kt3MOB JrhCZOaZsrlZrkVgw59tBPtCzmXmDHyprwSfVzYQOP/s4xB153j6gbW6otoSt3CvJAmb 49gfKJFvc8uPeKEaemJpaVRIAIMg/t4oiYFxI5AkbeKYtsD9Kd7iIamOpUoybMI7tux4 g64o4WfNsf7bT/OZ+s6m0PUVKnpMfsmGHiBBcmNVJR/9jdQczt/YWJ29YEz88P1CmwRT 4Z9w== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr17387707oec.116.1363205953744; Wed, 13 Mar 2013 13:19:13 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 13 Mar 2013 13:19:13 -0700 (PDT) X-Originating-IP: [128.89.254.35] In-Reply-To: <4EEC156B-AB33-4BFF-A6F3-CB39F64F48FB@netflix.com> References: <63519de2d2c44b159bb7dad208368348@BY2PR03MB041.namprd03.prod.outlook.com> <513C9B32.2050502@bbn.com> <513CA173.1020103@mnt.se> <4E1F6AAD24975D4BA5B1680429673943674EBA47@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B7865C8@WSMSG3153V.srv.dir.telstra.com> <0B984978-DAB0-4049-9E36-75FD43D24384@netflix.com> <4EEC156B-AB33-4BFF-A6F3-CB39F64F48FB@netflix.com> Date: Wed, 13 Mar 2013 16:19:13 -0400 Message-ID: From: Richard Barnes To: Mark Watson Content-Type: multipart/alternative; boundary=bcaec5523bb6a3737204d7d41e05 X-Gm-Message-State: ALoCoQmhnbsh/SM8H7187afyjYjeF3HNe6qs8GqGI7j3ecjN2F2xM6qSm4oSYZYlOVJl5gQmjBSJ Cc: "jose@ietf.org" Subject: Re: [jose] A Unified Theory of JOSE Keys 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, 13 Mar 2013 20:19:16 -0000 --bcaec5523bb6a3737204d7d41e05 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I might be able to live with that compromise. It might take a little thinking to say precisely what that "IF" statement is conditioned on, but I think it's doable. I'm going to set about writing a draft for this Real Soon Now, in which I'll try to elaborate a solution along these lines. --Richard On Wed, Mar 13, 2013 at 4:11 PM, Mark Watson wrote: > > On Mar 13, 2013, at 12:46 PM, Richard Barnes wrote: > > I would actually be completely ok with that -- if the wrapping in JWE wer= e > consistent. But I suspect some folks will balk at the ~65% size increase= :] > > > IIUC, what you mean by consistent is that JOSE should define a single > key wrapping algorithm, and that this should be used to create the "wk" f= or > JWE as well as being used 'stand-alone' for other key wrapping > applications. This algorithm would have the following inputs and outputs: > > Inputs > - Type of key to be wrapped > - Key to be wrapped > - Key attributes (optional, possibly split into protected and unprotected= ) > - Type of Key Encryption Key (AES or RSA) > - Key Encryption Key > > Output: > - Wrapped key data (binary data) > - Key attributes (optional, unprotected ones) > > Your proposal (roughly, assuming you want it to fall back to exactly > what is in JWE for the wrapped CMK case) > (1) Construct a JWK of the key to be wrapped, including any attributes, > but excluding fields known to be binary according to the key type > (2) If the resulting JWK is empty and there is only only binary field for > the key > - the data to be wrapped is that single binary field > Otherwise > - prepend the JWK with a length field > - prepend each binary field from the key with a length field > - the data to be wrapped is the concatenation of the above > (3) Apply the key wrapping algorithm to the data to be wrapped, using the > Key Encryption Key > > This could be modified as follows: > (1) Construct a JWK of the key to be wrapped, including any attributes > (2) If the resulting JWK contains a single binary field > - the data to be wrapped is that single binary field > Otherwise > - the data to be wrapped is the JWK object > (3) Apply the key wrapping algorithm to the data to be wrapped, using the > Key Encryption Key > > I don't see that one is more "consistent" than the other: both have a > great big "IF" in step 2 that calls out the simple symmetric key case. > > =85Mark > > > // 128-bit raw key > XXXXXXXXXXXXXXXX > // Wrapped raw key > XXXXXXXXXXXXXXXXXXXXXXXX > // Base64 of wrapped raw key > Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes > // JWK of key > {"k":"QEhAwEkOEtstCaEEd8sKig"} > // Wrapped JWK > XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > // Base64 of wrapped JWK > +N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solution > 2.A, 53 bytes > > > > On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson wrote: > >> Richard, >> >> Regarding the proposal for a binary-optimized JSON encoding, isn't this >> a bit orthogonal to the problem at hand ? >> >> I understand that this is one area where such a thing would be useful, >> but there have been various attempts to define such things in the past >> (BSON, ubjson, =85). A big advantage of JSON is that the data is >> self-describing, in terms of types: you don't need any external "documen= t >> type definition" or "schema" to decode and manipulate a JSON object. >> >> If you are going to specify something like this, I'd suggest at least >> include the member names that have been moved to the binary segment >> somewhere. So then a decoder can undo the translation and give back a >> regular JSON object with base64-encoded members, without access to this >> side-information. >> >> But I would ask if this trouble is really worth it for the 25% space >> saving ? >> >> =85Mark >> >> >> On Mar 11, 2013, at 7:30 PM, Manger, James H wrote: >> >> =93A Unified Theory of JOSE Keys=94 < >> http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.**** >> ** ** >> It looks like a key is a JSON object with any number of name/value >> pairs. For some names, the value is a base64[url]-encoding of binary dat= a. >> **** >> ** ** >> To wrap a key, its name/value pairs are divided into 3 groups:**** >> 1. non-confidential name/value pairs**** >> 2. confidential non-binary name/value pairs**** >> 3. confidential binary name/value pairs**** >> ** ** >> The first group are put into the =93kat=94 (key attributes?) field of t= he >> output.**** >> ** ** >> The second group =97 if its not empty =97 becomes the first binary segm= ent >> of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in the = output >> indicates the second group is present.**** >> ** ** >> The third group (in order) become subsequent binary segments of the >> plaintext. The names in the third group (and their order) is determined = by >> the type of the key being wrapped (=93kty=94 attribute).**** >> ** ** >> The plaintext is wrapped (encrypted), then base64url-encoded to give >> the =93wk=94 attribute in the output.**** >> ** ** >> ** ** >> Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93kat= =94. I >> assume this is a typo. =93kat=94 would include =93n=94 and =93e=94, but = =93d=94 (the >> private exponent) would always be encrypted and hence be inside =93wk=94= .**** >> ** ** >> Q2. Does key wrapping give integrity protection that you might want for >> name/value pairs even when they are not confidential. For instance, coul= d >> it be useful to include, say, =93e=94 inside =93wk=94 instead of within = =93kat=94? Do >> recipients need to check both the first binary segment and =93kat=94 whe= n >> looking for any attribute not explicitly listed in the =93encoding rules= =94? >> Does the first binary segment take precedence over =93kat=94?**** >> ** ** >> Q3. Should =93kty=94 (key type) appear within =93kat=94? The examples s= how it >> as a top-level attribute instead.**** >> ** ** >> A4. The symmetric key examples don=92t include a key type (=93kty=94). = Is it >> implied by something at a higher level (eg a JWE), or is there a default >> value meaning =93a shared symmetric secret, with no specific associated >> crypto algorithm=94?**** >> ** ** >> Q5. Using a VARINT (variable-length integer) instead of 2 bytes would >> be better for encoding the length of binary segments. 2 bytes (64 KB max= ) >> might be too small, particularly if the binary encoding is used for all >> JOSE messages (eg JWE) not just keys.**** >> ** ** >> ** ** >> --**** >> James Manger**** >> ** ** >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On >> Behalf Of *Richard Barnes >> *Sent:* Monday, 11 March 2013 6:29 AM >> *To:* Mike Jones >> *Cc:* Leif Johansson; jose@ietf.org >> *Subject:* Re: [jose] A Unified Theory of JOSE Keys**** >> ** ** >> So it seems to me that the group has three questions to answer when it >> comes to wrapped keys:**** >> ** ** >> Q1(Encryption): What mechanism will be used to encrypt key material, >> possibly containing attributes? **** >> Answer 1.A: JWE**** >> Answer 1.B: Key wrap, derived from JWE**** >> ** ** >> Q2(Packing): How should the wrapped key+attributes be expressed?**** >> Answer 2.A: JSON format (not packed)**** >> Answer 2.B: JSON, with binary parts expressed directly **** >> ** ** >> JWE-within-JWK represents answer 1.A / 2.A. The solution proposed in >> my Unified Theory is 1.B / 2.B. **** >> ** ** >> For context, I'm working from a few principles here:**** >> -- We should not define multiple ways to wrap symmetric keys**** >> -- We should not do things that would preclude accreditation under >> major security standards (e.g., FIPS)**** >> -- We should choose encodings that minimize the size overhead imposed >> by the encoding**** >> If we agree on these principles, then the answers to the above >> questions seem pretty clear.**** >> ** ** >> It seems to me that Steve's point on Question 1 pretty much decides >> the question for B. If we want systems using JOSE to have any hope of >> getting accreditation (e.g., under FIPS), then they will have to use >> standard mechanisms for protecting keys, even if those keys are package= d >> with other attributes. Mike's message misses the point that the key wra= p >> algorithm isn't actually being used to protect the key itself -- for tha= t >> you would use a normal, content-oriented encryption algorithm, in >> contravention of the FIPS requirements.**** >> ** ** >> Question 2 is mostly a question of backward compatibility and >> efficiency. If we want to have any hope of being backward-compatible wi= th >> JWE key wrapping -- that is, avoiding having two ways to do the same thi= ng >> -- then we need a way to handle the octets of a key directly, as opposed= to >> base64-encoded within a JSON object. That would be option 2.B.**** >> ** ** >> There are also compactness arguments for 1.B and 2.B. If you do 1.A, >> then in addition to the header, you have to carry a separate CMK, IV, an= d >> MAC value. If you're using AES-GCM with a 128-bit key, that's a total o= f >> 44 octets (16 CMK, 16 MAC, 12 IV). In contrast, if you just do AES key >> wrap, the wrapping algorithm adds a maximum of 16 octets to the object. >> The difference in case 2 is even greater, because you're talking about >> double-base64 encoding, which entails a penalty of 30% of the payload. = If >> you're protecting an AES key, this might only be a few octets, but if >> you're protecting a 2048-bit RSA key, then you're talking hundreds of >> octets. So if you care about compactness, 1.B and 2.B make a lot more >> sense.**** >> ** ** >> To respond to Mike's specific points:**** >> ** ** >> >> I=92ll note that in JSON Web Encryption, we are already using standard >> methods for encrypting key values for the Content Master Key =96 specifi= cally >> AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key >> agreement).**** >> >> ** ** >> However, the actual key you're wrapping is still protected with a >> content-oriented algorithm. So you're still violating the FIPS >> requirements.**** >> **** >> ** ** >> >> What we=92re talking about here, however, is encrypting potentially mo= re >> than just key values =96 in this case, key values with associated key us= e >> information, algorithm information, key ID information, and potentially >> other attributes. As such, using the JWK JSON representation of this >> information as the payload of a standard JWE encryption seems like the >> obvious solution, which doesn=92t require inventing anything we don=92t = already >> have.**** >> >> ** ** >> Absolutely agree that JSON is the right representation. But the key >> is still included in that representation, so you need to apply key wrapp= ing >> algorithms to it. And, as discussed above, it's a lot more efficient if >> you pack the JSON so that the binary isn't double-encoded.**** >> **** >> >> draft-miller-jose-jwe-protected-jwk already describes doing that. I >> believe that we should adopt this as a working group document as soon as >> the rechartering is complete.**** >> >> ** ** >> That draft has some excellent suggestions for password-based key >> wrapping. We should incorporate that into whatever solution we come up >> with. But for the reasons discussed above, it's wrong in using JWK for = the >> encapsulation.**** >> ** ** >> I also disagree that we need a separate document for this. If we're >> going to avoid having two ways to wrap keys, this needs to be part of >> JWE/JWK.**** >> ** ** >> --Richard**** >> ** ** >> >> -- Mike***= * >> >> _______________________________________________ >> >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> >> > > --bcaec5523bb6a3737204d7d41e05 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I might be able to live with that compromise. =A0It might take a little thi= nking to say precisely what that "IF" statement is conditioned on= , but I think it's doable. =A0I'm going to set about writing a draf= t for this Real Soon Now, in which I'll try to elaborate a solution alo= ng these lines.

--Richard


On We= d, Mar 13, 2013 at 4:11 PM, Mark Watson <watsonm@netflix.com> wrote:

On Mar 13, 2013, at 12:46 PM, Richard Barnes wrote:

I would actually be completely ok with that -- if= the wrapping in JWE were consistent. =A0But I suspect some folks will balk= at the ~65% size increase:]

IIUC, what you mean by consistent is that JOSE should define a single = key wrapping algorithm, and that this should be used to create the "wk= " for JWE as well as being used 'stand-alone' for other key wr= apping applications. This algorithm would have the following inputs and outputs:

Inputs
- Type of key to be wrapped
- Key to be wrapped
- Key attributes (optional, possibly split into protected and unprotec= ted)
- Type of Key Encryption Key (AES or RSA)
- Key Encryption Key

Output:
- Wrapped key data (binary data)
- Key attributes (optional, unprotected ones)

Your proposal (roughly, assuming you want it to fall back to exactly w= hat is in JWE for the wrapped CMK case)
(1) Construct a JWK of the key to be wrapped, including any attributes= , but excluding fields known to be binary according to the key type
(2) If the resulting JWK is empty and there is only only binary field = for the key
- the data to be wrapped i= s that single binary field
Otherwise
- prepend the JWK with a l= ength field
- prepend each binary fiel= d from the key with a length field
- the data to be wrapped i= s the concatenation of the above
(3) Apply the key wrapping algorithm to the data to be wrapped, using = the Key Encryption Key

This could be modified as follows:
(1) Construct a JWK of the key to be wrapped, including any attributes=
(2) If the resulting JWK contains a single binary field
- the data to be wrapped i= s that single binary field
Otherwise
- the data to be wrapped i= s the JWK object
(3) Apply the key wrapping algorithm to the data to be wrapped, using = the Key Encryption Key

I don't see that one is more "consistent" than the other= : both have a great big "IF" in step 2 that calls out the simple = symmetric key case.

=85Mark


// 128-bit raw key
XXXXXXXXXXXXXXXX
=A0// Wrapped raw key
XXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped raw key
Tt/CS0aWHHv9PaKsTQHTIxLt8f8DYP0a <------ Solution 2.B, 32 bytes
// JWK of key
{"k":"QEhAwEkOEtstCaEEd8sKig"}
// Wrapped JWK
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
// Base64 of wrapped JWK
+N9iVxLSMs8/wzuK42pd7PClztFxy+AwRTTyV8ZzSsIO2VIGPxOge <------ Solut= ion 2.A, 53 bytes



On Tue, Mar 12, 2013 at 6:58 PM, Mark Watson <watsonm@netfli= x.com> wrote:
Richard,

Regarding the proposal for a binary-optimized JSON encoding, isn't= this a bit orthogonal to the problem at hand ?

I understand that this is one area where such a thing would be useful,= but there have been various attempts to define such things in the past (BS= ON, ubjson, =85). A big advantage of JSON is that the data is self-describi= ng, in terms of types: you don't need any external "document type definition" or "schema" to= decode and manipulate a JSON object.

If you are going to specify something like this, I'd suggest at le= ast include the member names that have been moved to the binary segment som= ewhere. So then a decoder can undo the translation and give back a regular = JSON object with base64-encoded members, without access to this side-information.

But I would ask if this trouble is really worth it for the 25% space s= aving ?

=85Mark

On Mar 11, 2013, at 7:30 PM, Manger, James H wrote:

=93A Unified Theory of JOSE Keys=94 <http://www.ipv.sx/ietf86/jose-keys.pdf> looks quite good.
=A0
It looks like a key is a JSON object with any number of name/value = pairs. For some names, the value is a base64[url]-encoding of binary data.<= u>
=A0
To wrap a key, its name/value pairs are divided into 3 groups:
1.=A0=A0=A0=A0=A0=A0=A0= non-confidential name/value pairs
2.=A0=A0=A0=A0=A0=A0=A0= confidential non-binary name/value pairs
3.=A0=A0=A0=A0=A0=A0=A0= confidential binary name/value pairs
=A0
The first group are put into the =93kat=94 (key attributes?) field = of the output.
=A0
The second group =97 if its not empty =97 becomes the first binary = segment of the plaintext (as a UTF-8-encoded JSON object). =93wj=94:true in= the output indicates the second group is present.
=A0
The third group (in order) become subsequent binary segments of the= plaintext. The names in the third group (and their order) is determined by= the type of the key being wrapped (=93kty=94 attribute).
=A0
The plaintext is wrapped (encrypted), then base64url-encoded to giv= e the =93wk=94 attribute in the output.
=A0
=A0
Q1. The examples of wrapping an RSA key include =93d=94:=85 in =93k= at=94. I assume this is a typo. =93kat=94 would include =93n=94 and =93e=94= , but =93d=94 (the private exponent) would always be encrypted and hence be inside =93wk=94.
=A0
Q2. Does key wrapping give integrity protection that you might want= for name/value pairs even when they are not confidential. For instance, co= uld it be useful to include, say, =93e=94 inside =93wk=94 instead of within =93kat=94? Do recipients need to= check both the first binary segment and =93kat=94 when looking for any att= ribute not explicitly listed in the =93encoding rules=94? Does the first bi= nary segment take precedence over =93kat=94?
=A0
Q3. Should =93kty=94 (key type) appear within =93kat=94? The exampl= es show it as a top-level attribute instead.
=A0
A4. The symmetric key examples don=92t include a key type (=93kty= =94). Is it implied by something at a higher level (eg a JWE), or is there = a default value meaning =93a shared symmetric secret, with no specific associated crypto algorithm=94?
=A0
Q5. Using a VARINT (variable-length integer) instead of 2 bytes wou= ld be better for encoding the length of binary segments. 2 bytes (64 KB max= ) might be too small, particularly if the binary encoding is used for all JOSE messages (eg JWE) not just key= s.
=A0
=A0
--
James Manger
=A0
From:=A0jose-bo= unces@ietf.org=A0[mailto:jose-bounces@ietf.org]=A0On Behalf Of=A0Richard Barnes
Sent:=A0Monday, 11 March 2013 6:29 AM
To:=A0Mike Jones
Cc:=A0Leif Johansson;=A0jose@ietf.org
Subject:=A0Re: [jose] A Unified Theory of JOSE Keys<= /u>
=A0
So it seems to me that the group has three questions to answer when it come= s to wrapped keys:
=A0
Q1(Encryption): What mechanism will be used to encrypt key material, possib= ly containing attributes? =A0
=A0 =A0 Answer 1.A: JWE
=A0 =A0 Answer 1.B: Key wrap, derived from JWE
=A0
Q2(Packing): How should the wrapped key+attributes be expressed?<= /u>
=A0 =A0 Answer 2.A: JSON format (not packed)
=A0 =A0 Answer 2.B: JSON, with binary parts expressed directly=A0=
=A0
JWE-within-JWK represents answer 1.A / 2.A. =A0The solution proposed in my = Unified Theory is 1.B / 2.B. =A0
=A0
For context, I'm working from a few principles here:
-- We should not define multiple ways to wrap symmetric keys<= /div>
-- We should not do things that would preclude accreditation under major se= curity standards (e.g., FIPS)
-- We should choose encodings that minimize the size overhead imposed by th= e encoding
If we agree on these principles, then the answers to the above questions se= em pretty clear.
=A0
It seems to me that Steve's point on Question 1 pretty much decides the= question for B. =A0If we want systems using JOSE to have any hope of getti= ng accreditation (e.g., under FIPS), then they will have to use standard me= chanisms for protecting keys, even if those keys are =A0packaged with other attributes. =A0Mike's message mi= sses the point that the key wrap algorithm isn't actually being used to= protect the key itself -- for that you would use a normal, content-oriente= d encryption algorithm, in contravention of the FIPS requirements.
=A0
Question 2 is mostly a question of backward compatibility and efficiency. = =A0If we want to have any hope of being backward-compatible with JWE key wr= apping -- that is, avoiding having two ways to do the same thing -- then we= need a way to handle the octets of a key directly, as opposed to base64-encoded within a JSON object. =A0That= would be option 2.B.
=A0
There are also compactness arguments for 1.B and 2.B. =A0If you do 1.A, the= n in addition to the header, you have to carry a separate CMK, IV, and MAC = value. =A0If you're using AES-GCM with a 128-bit key, that's a tota= l of 44 octets (16 CMK, 16 MAC, 12 IV). =A0In contrast, if you just do AES key wrap, the wrapping algorithm adds a maxim= um of 16 octets to the object. =A0The difference in case 2 is even greater,= because you're talking about double-base64 encoding, which entails a p= enalty of 30% of the payload. =A0If you're protecting an AES key, this might only be a few octets, but if you're = protecting a 2048-bit RSA key, then you're talking hundreds of octets. = =A0So if you care about compactness, 1.B and 2.B make a lot more sense.<= /u>
=A0
To respond to Mike's specific points:
=A0
I=92ll note that in JSON Web Encryption, we are alre= ady using standard methods for encrypting key values for the Content Master= Key =96 specifically AES Key Wrap, RSA PKCS #1 1.5, and RSA OAEP (plus supporting ECDH-ES key agreement).<= span lang=3D"EN-US">
=A0
However, the actual key you're wrapping is still protected with a conte= nt-oriented algorithm. =A0So you're still violating the FIPS requiremen= ts.
=A0
=A0
What we=92re talking about here, however, is encrypt= ing potentially more than just key values =96 in this case, key values with= associated key use information, algorithm information, key ID information, and potentially other attributes.=A0 As s= uch, using the JWK JSON representation of this information as the payload o= f a standard JWE encryption seems like the obvious solution, which doesn=92= t require inventing anything we don=92t already have.
=A0
Absolutely agree that JSON is the right representation. =A0But the key is s= till included in that representation, so you need to apply key wrapping alg= orithms to it. =A0And, as discussed above, it's a lot more efficient if= you pack the JSON so that the binary isn't double-encoded.
=A0=A0
draft-miller-jose-jwe-protected-jwk already describe= s doing that.=A0 I believe that we should adopt this as a working group doc= ument as soon as the rechartering is complete.<= u>
=A0
That draft has some excellent suggestions for password-based key wrapping. = =A0We should incorporate that into whatever solution we come up with. =A0Bu= t for the reasons discussed above, it's wrong in using JWK for the enca= psulation.
=A0
I also disagree that we need a separate document for this. =A0If we're = going to avoid having two ways to wrap keys, this needs to be part of JWE/J= WK.
=A0
--Richard
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mike
_______________________________________________




--bcaec5523bb6a3737204d7d41e05-- From James.H.Manger@team.telstra.com Wed Mar 13 15:46:15 2013 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 B8E1B21F8735 for ; Wed, 13 Mar 2013 15:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.828 X-Spam-Level: X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 xLsSBPmfGrLG for ; Wed, 13 Mar 2013 15:46:15 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2530821F8712 for ; Wed, 13 Mar 2013 15:46:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,840,1355058000"; d="scan'208,217";a="123776441" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 14 Mar 2013 09:46:12 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7013"; a="118712155" Received: from wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) by ipccvi.tcif.telstra.com.au with ESMTP; 14 Mar 2013 09:46:12 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3707.srv.dir.telstra.com ([172.49.40.81]) with mapi; Thu, 14 Mar 2013 09:46:11 +1100 From: "Manger, James H" To: Richard Barnes Date: Thu, 14 Mar 2013 09:46:06 +1100 Thread-Topic: [jose] "crit" strings don't have to be field names Thread-Index: Ac4gJygKdIVcBJWJQr27KBGLXUyPPQAEj4Vg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B847455@WSMSG3153V.srv.dir.telstra.com> References: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B8469AB@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B847455WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] "crit" strings don't have to be field names 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, 13 Mar 2013 22:46:15 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B847455WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSB0cnlpbmcgdG8gc2ltcGxpZnkgdGhlIOKAnGNyaXTigJ0gZmllbGQsIG5vdCBjb21wbGlj YXRlIGl0Lg0KDQpUaGUgQ29uY2F0IEtERiBwYXJhZ3JhcGggd2FzIG9ubHkgaW50ZW5kZWQgYXMg YSB2YWd1ZWx5IHJlYWxpc3RpYyBleGFtcGxlIG9mIGhvdyBhIGNyaXRpY2FsIHN0cmluZyBjb3Vs ZCBiZSB1c2VkLiBNeSBlbWFpbCB3YXMgTk9UIGEgcmVxdWVzdCB0byBjaGFuZ2UgaG93IEpPU0Ug Y3VycmVudGx5IHVzZXMgQ29uY2F0IEtERi4NCg0KV2hlbiBhbiBpbXBsZW1lbnRhdGlvbiBzZWVz IGFuIHVua25vd24gc3RyaW5nIGluIOKAnGNyaXTigJ0gaXMgaGFzIHRvIHN0b3AuIFRoZSBydWxl IGNhbiBhbmQgc2hvdWxkIGJlIHRoYXQgc2ltcGxlLg0KDQpJIGRvbuKAmXQgd2FudCBzb21lIGlt cGxlbWVudGF0aW9ucyBhbHNvIGNoZWNraW5nIHRoYXQgYSBoZWFkZXIgZmllbGQgd2l0aCBhbiB1 bmtub3duIGNyaXRpY2FsIHN0cmluZ+KAmXMgbmFtZSBpcyBwcmVzZW50IGJlZm9yZSB0aGV5IHJl amVjdCBhIEpPU0UgbWVzc2FnZS4gSSBkb27igJl0IHdhbnQgc29tZSBpbXBsZW1lbnRhdGlvbnMg bGlzdGluZyBmaWVsZCBuYW1lcyBmcm9tIHRoZSDigJxiYXNlIHNwZWNz4oCdLCBzdWNoIGFzIOKA nGFsZ+KAnSwgYXMgY3JpdGljYWwgc3RyaW5ncy4gTGlua2luZyBjcml0aWNhbCBzdHJpbmdzIHRv IGZpZWxkIG5hbWVzIGNhbiBvbmx5IGFkZCBpbGwtZGVmaW5lZCBub24taW50ZXJvcGVyYWJsZSBj b3JuZXIgY2FzZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogUmljaGFyZCBCYXJuZXMg W21haWx0bzpybGJAaXB2LnN4XQ0KU2VudDogVGh1cnNkYXksIDE0IE1hcmNoIDIwMTMgNzoxMyBB TQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb am9zZV0gImNyaXQiIHN0cmluZ3MgZG9uJ3QgaGF2ZSB0byBiZSBmaWVsZCBuYW1lcw0KDQpJIGRv bid0IHJlYWxseSB0aGluayB0aGF0IHRoZXJlJ3MgbXVjaCBiZW5lZml0IHRvIHRoZSBhZGRpdGlv bmFsIGNvbXBsZXhpdHkgaGVyZS4gIFlvdSBkb24ndCBuZWVkIGl0IGZvciB0aGUgODAwLTU2QSBj YXNlLCBiZWNhdXNlIHRoYXQncyBpbiB0aGUgY3VycmVudCBkb2N1bWVudCwgYW5kIHdpbGwgdGh1 cyBnZXQgcmVhbCByZXF1aXJlbWVudHMgbGFuZ3VhZ2UgaW4gdGhlIHNwZWMuICBJZiB5b3UgZG8g d2FudCB0byBncm91cCBleHRlbnNpb24gZmllbGRzIGluIHRoaXMgd2F5LCB5b3UgY2FuIGp1c3Qg Z3JvdXAgdGhlbSBpbnRvIGFuIG9iamVjdCB1bmRlciBhIHNpbmdsZSBleHRlbnNpb24gZmllbGQu ICBGb3IgZXhhbXBsZToNCg0Kew0KICAgICJhbGciOiAiZm9vIiwNCiAgICAibmV3LXRoaW5nIjog ew0KICAgICAgICAicGFydDEiOiA0MiwNCiAgICAgICAgInBhcnQyIjogInNpeCINCiAgICB9LA0K ICAgICJjcml0IjogWyJuZXctdGhpbmciXQ0KfQ0KDQoNCk9uIFR1ZSwgTWFyIDEyLCAyMDEzIGF0 IDEwOjA4IFBNLCBNYW5nZXIsIEphbWVzIEggPEphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5j b208bWFpbHRvOkphbWVzLkguTWFuZ2VyQHRlYW0udGVsc3RyYS5jb20+PiB3cm90ZToNCkFzIHdl IGRlZmluZSB0aGUgImNyaXQiIGZpZWxkIHdlIGRvbid0IG5lZWQgdG8gdXNlIGZpZWxkIG5hbWVz IGFzIHRoZSBjcml0aWNhbCBzdHJpbmdzLg0KDQpJbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIGEg bGlzdCBvZiBjcml0aWNhbCBzdHJpbmdzIHRoZXkgdW5kZXJzdGFuZCAoYmFzZWQgb24gdGhlIHNw ZWNzIHRoYXQgZGVmaW5lIHRob3NlIGNyaXRpY2FsIHN0cmluZ3MpIGFuZCB3aWxsIGNvbmZpcm0g dGhhdCBhbGwgdGhlICJjcml0IiB2YWx1ZXMgYXJlIGluIHRoZWlyIGxpc3QuIFRoaXMgd2lsbCBi ZSBhIGRpc3RpbmN0IHN0ZXAgZnJvbSB0aGUgb3RoZXIgY29kZSB0aGF0IHVzZXMgc3BlY2lmaWMg ZmllbGRzLg0KDQpGb3IgaW5zdGFuY2UsIGlmIHdlIGRlZmluZWQgYSBzaW1wbGUgS0RGIGluaXRp YWxseSB0aGVuIGxhdGVyIHNwZWNpZmllZCBzdXBwb3J0IGZvciB0aGUgTklTVCA4MDAtNTZBIENv bmNhdCBLREYgaXQgd291bGQgYmUgYmV0dGVyIHRvIGRlZmluZSAxIGNyaXRpY2FsIHN0cmluZyAi bmlzdDgwMC01NkEiLCBpbnN0ZWFkIG9mIGxpc3RpbmcgIlBhcnR5VUluZm8iLCAiUGFydHlWSW5m byIsICJTdXBwUHViSW5mbyIsIGFuZCAiU3VwcFByaXZlSW5mbyIgZmllbGRzIG5hbWVzIGluIHRo ZSAiY3JpdCIgZmllbGQgLS0gYW55IG9mIHdoaWNoIG1pZ2h0IGJlIGFic2VudCBmcm9tIGEgcGFy dGljdWxhciBKT1NFIG1lc3NhZ2UgaWYgdGhleSBoYWQgc29tZSBkZWZhdWx0IHZhbHVlLg0KDQpB bm90aGVyIGV4YW1wbGU6IGlmIGEgZ3JvdXAgaW5zaXN0cyBvbiBhIHN0cm9uZyBzaWduYXR1cmUg dmVyaWZpY2F0aW9uIHBvbGljeSAoZWcgTVVTVCB1c2UgT0NTUCwgTVVTVCBoYXJkLWZhaWwgaWYg T0NTUCBpcyB1bmF2YWlsYWJsZSwgTVVTVCBjaGVjayBDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3ks IGFuZCBNVVNUIGxvZyByZXN1bHRzIGZvciA3IHllYXJzKSB0aGVyZSBpcyBubyBuZXcgaGVhZGVy IGZpZWxkIHRvIGFkZCB0byBhIEpXUywgYnV0IGl0IGNvdWxkIGRlZmluZSB0aGUgY3JpdGljYWwg c3RyaW5nICJTdHJvbmdTaWcxIi4NCg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCiAtLS0tLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IFtqb3NlXSBQcm9wb3NlZCByZXNv bHV0aW9uIG9mIGhlYWRlciBjcml0aWNhbGl0eSBpc3N1ZQ0KPiBGcm9tOiBLYXJlbiBPJ0Rvbm9n aHVlIDxvZG9ub2dodWVAaXNvYy5vcmc8bWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZz4+DQo+IERh dGU6IFR1ZSwgTWFyY2ggMTIsIDIwMTMgMTI6MzEgYW0NCj4gVG86IGpvc2VAaWV0Zi5vcmc8bWFp bHRvOmpvc2VAaWV0Zi5vcmc+DQoNCj4gIDMuICBEZWZpbmUgYSBuZXcgaGVhZGVyIGZpZWxkIHRo YXQgbGlzdHMgd2hpY2ggYWRkaXRpb25hbCBmaWVsZHMgbm90DQo+IGRlZmluZWQgaW4gdGhlIGJh c2Ugc3BlY2lmaWNhdGlvbnMgbXVzdCBiZSB1bmRlcnN0b29kIGFuZCBhY3RlZCB1cG9uDQo+IHdo ZW4gcHJlc2VudC4gIEZvciBpbnN0YW5jZSwgYW4gZXhwaXJhdGlvbi10aW1lIGV4dGVuc2lvbiBm aWVsZCBjb3VsZA0KPiBiZSBtYXJrZWQgYXMgbXVzdC1iZS11bmRlcnN0b29kLWFuZC1hY3RlZC11 cG9uLiAgT25lIHBvc3NpYmxlIG5hbWUgZm9yDQo+IHRoaXMgd291bGQgYmUg4oCcY3JpdOKAnSAo Y3JpdGljYWwpLiAgQW4gZXhhbXBsZSB1c2UsIGFsb25nIHdpdGggYQ0KPiBoeXBvdGhldGljYWwg 4oCcZXhw4oCdIChleHBpcmF0aW9uLXRpbWUpIGZpZWxkIGlzOg0KPg0KPiAgICB7ImFsZyI6IkVT MjU2IiwNCj4gICAgICJjcml0IjpbImV4cCJdLA0KPiAgICAgImV4cOKAnToxMzYzMjg0MDAwDQo+ ICAgIH0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9qb3NlDQoNCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B847455WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgYW0gdHJ5aW5nIHRvIHNpbXBs aWZ5IHRoZSDigJxjcml04oCdIGZpZWxkLCBub3QgY29tcGxpY2F0ZSBpdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx RjQ5N0QnPlRoZSBDb25jYXQgS0RGIHBhcmFncmFwaCB3YXMgb25seSBpbnRlbmRlZCBhcyBhIHZh Z3VlbHkgcmVhbGlzdGljIGV4YW1wbGUgb2YgaG93IGEgY3JpdGljYWwgc3RyaW5nIGNvdWxkIGJl IHVzZWQuIE15IGVtYWlsIHdhcyBOT1QgYSByZXF1ZXN0IHRvIGNoYW5nZSBob3cgSk9TRSBjdXJy ZW50bHkgdXNlcyBDb25jYXQgS0RGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+V2hlbiBhbiBpbXBsZW1l bnRhdGlvbiBzZWVzIGFuIHVua25vd24gc3RyaW5nIGluIOKAnGNyaXTigJ0gaXMgaGFzIHRvIHN0 b3AuIFRoZSBydWxlIGNhbiBhbmQgc2hvdWxkIGJlIHRoYXQgc2ltcGxlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+SSBkb27igJl0IHdhbnQgc29tZSBpbXBsZW1lbnRhdGlvbnMgYWxzbyBjaGVja2luZyB0 aGF0IGEgaGVhZGVyIGZpZWxkIHdpdGggYW4gdW5rbm93biBjcml0aWNhbCBzdHJpbmfigJlzIG5h bWUgaXMgcHJlc2VudCBiZWZvcmUgdGhleSByZWplY3QgYSBKT1NFIG1lc3NhZ2UuIEkgZG9u4oCZ dCB3YW50IHNvbWUgaW1wbGVtZW50YXRpb25zIGxpc3RpbmcgZmllbGQgbmFtZXMgZnJvbSB0aGUg 4oCcYmFzZSBzcGVjc+KAnSwgc3VjaCBhcyDigJxhbGfigJ0sIGFzIGNyaXRpY2FsIHN0cmluZ3Mu IExpbmtpbmcgY3JpdGljYWwgc3RyaW5ncyB0byBmaWVsZCBuYW1lcyBjYW4gb25seSBhZGQgaWxs LWRlZmluZWQgbm9uLWludGVyb3BlcmFibGUgY29ybmVyIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6IzFGNDk3RCc+SmFtZXMgTWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxw IGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiJz4gUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XSA8YnI+ PGI+U2VudDo8L2I+IFRodXJzZGF5LCAxNCBNYXJjaCAyMDEzIDc6MTMgQU08YnI+PGI+VG86PC9i PiBNYW5nZXIsIEphbWVzIEg8YnI+PGI+Q2M6PC9iPiBqb3NlQGlldGYub3JnPGJyPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW2pvc2VdICZxdW90O2NyaXQmcXVvdDsgc3RyaW5ncyBkb24ndCBoYXZlIHRv IGJlIGZpZWxkIG5hbWVzPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SSBkb24n dCByZWFsbHkgdGhpbmsgdGhhdCB0aGVyZSdzIG11Y2ggYmVuZWZpdCB0byB0aGUgYWRkaXRpb25h bCBjb21wbGV4aXR5IGhlcmUuICZuYnNwO1lvdSBkb24ndCBuZWVkIGl0IGZvciB0aGUgODAwLTU2 QSBjYXNlLCBiZWNhdXNlIHRoYXQncyBpbiB0aGUgY3VycmVudCBkb2N1bWVudCwgYW5kIHdpbGwg dGh1cyBnZXQgcmVhbCByZXF1aXJlbWVudHMgbGFuZ3VhZ2UgaW4gdGhlIHNwZWMuICZuYnNwO0lm IHlvdSBkbyB3YW50IHRvIGdyb3VwIGV4dGVuc2lvbiBmaWVsZHMgaW4gdGhpcyB3YXksIHlvdSBj YW4ganVzdCBncm91cCB0aGVtIGludG8gYW4gb2JqZWN0IHVuZGVyIGEgc2luZ2xlIGV4dGVuc2lv biBmaWVsZC4gJm5ic3A7Rm9yIGV4YW1wbGU6PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1N c29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+ezxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAm bmJzcDsgJnF1b3Q7YWxnJnF1b3Q7OiAmcXVvdDtmb28mcXVvdDssPG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7ICZuYnNwOyAmcXVvdDtuZXctdGhpbmcm cXVvdDs6IHs8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7cGFydDEmcXVvdDs6IDQyLDxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmcXVvdDtwYXJ0MiZxdW90OzogJnF1b3Q7c2l4JnF1b3Q7PG86cD48L286cD48L3A+PC9k aXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7ICZuYnNwOyB9LDxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Y3JpdCZx dW90OzogWyZxdW90O25ldy10aGluZyZxdW90O108bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD59PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFR1ZSwgTWFyIDEyLCAyMDEzIGF0IDEwOjA4IFBNLCBN YW5nZXIsIEphbWVzIEggJmx0OzxhIGhyZWY9Im1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRl bHN0cmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BcyB3ZSBk ZWZpbmUgdGhlICZxdW90O2NyaXQmcXVvdDsgZmllbGQgd2UgZG9uJ3QgbmVlZCB0byB1c2UgZmll bGQgbmFtZXMgYXMgdGhlIGNyaXRpY2FsIHN0cmluZ3MuPGJyPjxicj5JbXBsZW1lbnRhdGlvbnMg d2lsbCBoYXZlIGEgbGlzdCBvZiBjcml0aWNhbCBzdHJpbmdzIHRoZXkgdW5kZXJzdGFuZCAoYmFz ZWQgb24gdGhlIHNwZWNzIHRoYXQgZGVmaW5lIHRob3NlIGNyaXRpY2FsIHN0cmluZ3MpIGFuZCB3 aWxsIGNvbmZpcm0gdGhhdCBhbGwgdGhlICZxdW90O2NyaXQmcXVvdDsgdmFsdWVzIGFyZSBpbiB0 aGVpciBsaXN0LiBUaGlzIHdpbGwgYmUgYSBkaXN0aW5jdCBzdGVwIGZyb20gdGhlIG90aGVyIGNv ZGUgdGhhdCB1c2VzIHNwZWNpZmljIGZpZWxkcy48YnI+PGJyPkZvciBpbnN0YW5jZSwgaWYgd2Ug ZGVmaW5lZCBhIHNpbXBsZSBLREYgaW5pdGlhbGx5IHRoZW4gbGF0ZXIgc3BlY2lmaWVkIHN1cHBv cnQgZm9yIHRoZSBOSVNUIDgwMC01NkEgQ29uY2F0IEtERiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8g ZGVmaW5lIDEgY3JpdGljYWwgc3RyaW5nICZxdW90O25pc3Q4MDAtNTZBJnF1b3Q7LCBpbnN0ZWFk IG9mIGxpc3RpbmcgJnF1b3Q7UGFydHlVSW5mbyZxdW90OywgJnF1b3Q7UGFydHlWSW5mbyZxdW90 OywgJnF1b3Q7U3VwcFB1YkluZm8mcXVvdDssIGFuZCAmcXVvdDtTdXBwUHJpdmVJbmZvJnF1b3Q7 IGZpZWxkcyBuYW1lcyBpbiB0aGUgJnF1b3Q7Y3JpdCZxdW90OyBmaWVsZCAtLSBhbnkgb2Ygd2hp Y2ggbWlnaHQgYmUgYWJzZW50IGZyb20gYSBwYXJ0aWN1bGFyIEpPU0UgbWVzc2FnZSBpZiB0aGV5 IGhhZCBzb21lIGRlZmF1bHQgdmFsdWUuPGJyPjxicj5Bbm90aGVyIGV4YW1wbGU6IGlmIGEgZ3Jv dXAgaW5zaXN0cyBvbiBhIHN0cm9uZyBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIHBvbGljeSAoZWcg TVVTVCB1c2UgT0NTUCwgTVVTVCBoYXJkLWZhaWwgaWYgT0NTUCBpcyB1bmF2YWlsYWJsZSwgTVVT VCBjaGVjayBDZXJ0aWZpY2F0ZSBUcmFuc3BhcmVuY3ksIGFuZCBNVVNUIGxvZyByZXN1bHRzIGZv ciA3IHllYXJzKSB0aGVyZSBpcyBubyBuZXcgaGVhZGVyIGZpZWxkIHRvIGFkZCB0byBhIEpXUywg YnV0IGl0IGNvdWxkIGRlZmluZSB0aGUgY3JpdGljYWwgc3RyaW5nICZxdW90O1N0cm9uZ1NpZzEm cXVvdDsuPGJyPjxicj48YnI+LS08YnI+SmFtZXMgTWFuZ2VyPGJyPjxicj4mbmJzcDstLS0tLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0tPGJyPiZndDsgU3ViamVjdDogW2pvc2VdIFByb3Bv c2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNyaXRpY2FsaXR5IGlzc3VlPGJyPiZndDsgRnJvbTog S2FyZW4gTydEb25vZ2h1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZyI+ b2Rvbm9naHVlQGlzb2Mub3JnPC9hPiZndDs8YnI+Jmd0OyBEYXRlOiBUdWUsIE1hcmNoIDEyLCAy MDEzIDEyOjMxIGFtPGJyPiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5q b3NlQGlldGYub3JnPC9hPjxicj48YnI+Jmd0OyAmbmJzcDszLiAmbmJzcDtEZWZpbmUgYSBuZXcg aGVhZGVyIGZpZWxkIHRoYXQgbGlzdHMgd2hpY2ggYWRkaXRpb25hbCBmaWVsZHMgbm90PGJyPiZn dDsgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVjaWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2Qg YW5kIGFjdGVkIHVwb248YnI+Jmd0OyB3aGVuIHByZXNlbnQuICZuYnNwO0ZvciBpbnN0YW5jZSwg YW4gZXhwaXJhdGlvbi10aW1lIGV4dGVuc2lvbiBmaWVsZCBjb3VsZDxicj4mZ3Q7IGJlIG1hcmtl ZCBhcyBtdXN0LWJlLXVuZGVyc3Rvb2QtYW5kLWFjdGVkLXVwb24uICZuYnNwO09uZSBwb3NzaWJs ZSBuYW1lIGZvcjxicj4mZ3Q7IHRoaXMgd291bGQgYmUg4oCcY3JpdOKAnSAoY3JpdGljYWwpLiAm bmJzcDtBbiBleGFtcGxlIHVzZSwgYWxvbmcgd2l0aCBhPGJyPiZndDsgaHlwb3RoZXRpY2FsIOKA nGV4cOKAnSAoZXhwaXJhdGlvbi10aW1lKSBmaWVsZCBpczo8YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNw OyAmbmJzcDt7JnF1b3Q7YWxnJnF1b3Q7OiZxdW90O0VTMjU2JnF1b3Q7LDxicj4mZ3Q7ICZuYnNw OyAmbmJzcDsgJnF1b3Q7Y3JpdCZxdW90OzpbJnF1b3Q7ZXhwJnF1b3Q7XSw8YnI+Jmd0OyAmbmJz cDsgJm5ic3A7ICZxdW90O2V4cOKAnToxMzYzMjg0MDAwPGJyPiZndDsgJm5ic3A7ICZuYnNwO308 YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pmpvc2UgbWFpbGluZyBsaXN0PGJyPjxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3Nl QGlldGYub3JnPC9hPjxicj48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0 bWw+ --_000_255B9BB34FB7D647A506DC292726F6E1150B847455WSMSG3153Vsrv_-- From James.H.Manger@team.telstra.com Wed Mar 13 22:31:19 2013 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 667EF21F8E71 for ; Wed, 13 Mar 2013 22:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.833 X-Spam-Level: X-Spam-Status: No, score=-0.833 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 ub8Z4bAMjLXH for ; Wed, 13 Mar 2013 22:31:18 -0700 (PDT) Received: from ipxbno.tcif.telstra.com.au (ipxbno.tcif.telstra.com.au [203.35.82.204]) by ietfa.amsl.com (Postfix) with ESMTP id 5522F21F8EDB for ; Wed, 13 Mar 2013 22:31:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,842,1355058000"; d="scan'208,217";a="119018022" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipobni.tcif.telstra.com.au with ESMTP; 14 Mar 2013 16:31:14 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7013"; a="120391424" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipcbni.tcif.telstra.com.au with ESMTP; 14 Mar 2013 16:31:14 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Thu, 14 Mar 2013 16:31:14 +1100 From: "Manger, James H" To: "jose@ietf.org" Date: Thu, 14 Mar 2013 16:31:13 +1100 Thread-Topic: [jose] "crit" strings don't have to be field names Thread-Index: Ac4gJygKdIVcBJWJQr27KBGLXUyPPQAEj4VgAA1kZXA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B8FAAFD@WSMSG3153V.srv.dir.telstra.com> References: <3E6B6F2D-3932-4BDC-81E1-F8CDA0F5077C@team.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B8469AB@WSMSG3153V.srv.dir.telstra.com> <255B9BB34FB7D647A506DC292726F6E1150B847455@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B847455@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B8FAAFDWSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] "crit" strings don't have to be field names 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, 14 Mar 2013 05:31:19 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B8FAAFDWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXMganVzdCBsaXN0ZW5pbmcgdG8gc29tZSBvZiB0aGUgSUVURiA4NiBKT1NFIHNlc3Npb24u DQpPbmUgaXNzdWUgd2FzIHdoYXQgd291bGQgImNyaXQiOlsiYXNkIl0gbWVhbj8gKHdoZXJlIOKA nGFzZOKAnSBpcyBhIHRvcC1sZXZlbCBidWNrZXQgZm9yIGFwcC1zcGVjaWZpYyBkYXRhIHRoYXQg YSBKT1NFIGxpYnJhcnkgY2FuIGlnbm9yZSkNClRoZSBtb3JlIGdlbmVyYWwgaXNzdWUgaXMgd2hl dGhlciBvbmx5IHRvcC1sZXZlbCBmaWVsZHMgY2FuIGJlIG1hcmtlZCBjcml0aWNhbD8NCg0KSSBo b3BlIHdlIGRvbuKAmXQgdHJ5IHRvIGFuc3dlciB0aGF0LiBUaWdodGx5IGNvdXBsaW5nIG91ciBj aG9pY2Ugb2YgSlNPTiBzdHJ1Y3R1cmUgKGllIHdoYXQgaXMgYXQgdGhlIHRvcCBsZXZlbCkgdG8g d2hhdCBjYW4gYmUgY3JpdGljYWwgaXMgdW5uZWNlc3NhcnkuDQoNCkZvciBpbnN0YW5jZSwgYSBn b29kIGNoYW5nZSB0byB0aGUgSk9TRSBzdHJ1Y3R1cmUgd291bGQgYmUgdG9wLWxldmVsIG9iamVj dHMgKGVnIG5hbWVkIOKAnG/igJ0gYW5kIOKAnHLigJ0pIHRvIGdyb3VwIGZpZWxkcyBhYm91dCB0 aGUgb3JpZ2luYXRvciBhbmQgcmVjaXBpZW50IHJlc3BlY3RpdmVseSAoZWcgaXQgd291bGQgbWFr ZSBpdCBjbGVhciB3aG9zZSBrZXkgYSDigJxraWTigJ0gdmFsdWUgcmVmZXJyZWQgdG87IHlvdSBj b3VsZCBldmVuIGlkZW50aWZ5IGVhY2ggcGFydHnigJlzIGtleSBieSBpbmNsdWRpbmcgdHdvIOKA nGtpZOKAnSBmaWVsZHMsIHsuLi4sIm8iOnsia2lkIjoibXlrZXkxIn0sInIiOnsia2lkIjoieW91 cmtleTMifX0pLg0KSXQgd291bGQgYmUgYW5ub3lpbmcgaWYgYWRkaW5nIHN1Y2ggc3RydWN0dXJl IGhhZCB1bmludGVuZGVkIGltcGFjdHMgb24gd2hhdCBjb3VsZCBvciBjb3VsZG7igJl0IGJlIG1h cmtlZCBjcml0aWNhbC4NCg0KU28gbGV04oCZcyBkZWZpbmUg4oCcY3JpdOKAnSBhcyBhIGxpc3Qg b2YgY3JpdGljYWwgc3RyaW5ncywgd2l0aG91dCBtZW50aW9uaW5nIGZpZWxkIG5hbWVzLCB0byBh dm9pZCBhIGJ1bmNoIG9mIHVubmVjZXNzYXJ5IGhhc3NsZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg0KRnJvbTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgTWFuZ2VyLCBKYW1lcyBIDQpTZW50OiBUaHVyc2RheSwgMTQgTWFy Y2ggMjAxMyA5OjQ2IEFNDQpUbzogUmljaGFyZCBCYXJuZXMNCkNjOiBqb3NlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW2pvc2VdICJjcml0IiBzdHJpbmdzIGRvbid0IGhhdmUgdG8gYmUgZmllbGQg bmFtZXMNCg0KSSBhbSB0cnlpbmcgdG8gc2ltcGxpZnkgdGhlIOKAnGNyaXTigJ0gZmllbGQsIG5v dCBjb21wbGljYXRlIGl0Lg0KDQpUaGUgQ29uY2F0IEtERiBwYXJhZ3JhcGggd2FzIG9ubHkgaW50 ZW5kZWQgYXMgYSB2YWd1ZWx5IHJlYWxpc3RpYyBleGFtcGxlIG9mIGhvdyBhIGNyaXRpY2FsIHN0 cmluZyBjb3VsZCBiZSB1c2VkLiBNeSBlbWFpbCB3YXMgTk9UIGEgcmVxdWVzdCB0byBjaGFuZ2Ug aG93IEpPU0UgY3VycmVudGx5IHVzZXMgQ29uY2F0IEtERi4NCg0KV2hlbiBhbiBpbXBsZW1lbnRh dGlvbiBzZWVzIGFuIHVua25vd24gc3RyaW5nIGluIOKAnGNyaXTigJ0gaXMgaGFzIHRvIHN0b3Au IFRoZSBydWxlIGNhbiBhbmQgc2hvdWxkIGJlIHRoYXQgc2ltcGxlLg0KDQpJIGRvbuKAmXQgd2Fu dCBzb21lIGltcGxlbWVudGF0aW9ucyBhbHNvIGNoZWNraW5nIHRoYXQgYSBoZWFkZXIgZmllbGQg d2l0aCBhbiB1bmtub3duIGNyaXRpY2FsIHN0cmluZ+KAmXMgbmFtZSBpcyBwcmVzZW50IGJlZm9y ZSB0aGV5IHJlamVjdCBhIEpPU0UgbWVzc2FnZS4gSSBkb27igJl0IHdhbnQgc29tZSBpbXBsZW1l bnRhdGlvbnMgbGlzdGluZyBmaWVsZCBuYW1lcyBmcm9tIHRoZSDigJxiYXNlIHNwZWNz4oCdLCBz dWNoIGFzIOKAnGFsZ+KAnSwgYXMgY3JpdGljYWwgc3RyaW5ncy4gTGlua2luZyBjcml0aWNhbCBz dHJpbmdzIHRvIGZpZWxkIG5hbWVzIGNhbiBvbmx5IGFkZCBpbGwtZGVmaW5lZCBub24taW50ZXJv cGVyYWJsZSBjb3JuZXIgY2FzZXMuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0KRnJvbTogUmljaGFy ZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XQ0KU2VudDogVGh1cnNkYXksIDE0IE1hcmNoIDIw MTMgNzoxMyBBTQ0KVG86IE1hbmdlciwgSmFtZXMgSA0KQ2M6IGpvc2VAaWV0Zi5vcmc8bWFpbHRv Ompvc2VAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW2pvc2VdICJjcml0IiBzdHJpbmdzIGRvbid0 IGhhdmUgdG8gYmUgZmllbGQgbmFtZXMNCg0KSSBkb24ndCByZWFsbHkgdGhpbmsgdGhhdCB0aGVy ZSdzIG11Y2ggYmVuZWZpdCB0byB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGhlcmUuICBZb3Ug ZG9uJ3QgbmVlZCBpdCBmb3IgdGhlIDgwMC01NkEgY2FzZSwgYmVjYXVzZSB0aGF0J3MgaW4gdGhl IGN1cnJlbnQgZG9jdW1lbnQsIGFuZCB3aWxsIHRodXMgZ2V0IHJlYWwgcmVxdWlyZW1lbnRzIGxh bmd1YWdlIGluIHRoZSBzcGVjLiAgSWYgeW91IGRvIHdhbnQgdG8gZ3JvdXAgZXh0ZW5zaW9uIGZp ZWxkcyBpbiB0aGlzIHdheSwgeW91IGNhbiBqdXN0IGdyb3VwIHRoZW0gaW50byBhbiBvYmplY3Qg dW5kZXIgYSBzaW5nbGUgZXh0ZW5zaW9uIGZpZWxkLiAgRm9yIGV4YW1wbGU6DQoNCnsNCiAgICAi YWxnIjogImZvbyIsDQogICAgIm5ldy10aGluZyI6IHsNCiAgICAgICAgInBhcnQxIjogNDIsDQog ICAgICAgICJwYXJ0MiI6ICJzaXgiDQogICAgfSwNCiAgICAiY3JpdCI6IFsibmV3LXRoaW5nIl0N Cn0NCg0KDQpPbiBUdWUsIE1hciAxMiwgMjAxMyBhdCAxMDowOCBQTSwgTWFuZ2VyLCBKYW1lcyBI IDxKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tPG1haWx0bzpKYW1lcy5ILk1hbmdlckB0 ZWFtLnRlbHN0cmEuY29tPj4gd3JvdGU6DQpBcyB3ZSBkZWZpbmUgdGhlICJjcml0IiBmaWVsZCB3 ZSBkb24ndCBuZWVkIHRvIHVzZSBmaWVsZCBuYW1lcyBhcyB0aGUgY3JpdGljYWwgc3RyaW5ncy4N Cg0KSW1wbGVtZW50YXRpb25zIHdpbGwgaGF2ZSBhIGxpc3Qgb2YgY3JpdGljYWwgc3RyaW5ncyB0 aGV5IHVuZGVyc3RhbmQgKGJhc2VkIG9uIHRoZSBzcGVjcyB0aGF0IGRlZmluZSB0aG9zZSBjcml0 aWNhbCBzdHJpbmdzKSBhbmQgd2lsbCBjb25maXJtIHRoYXQgYWxsIHRoZSAiY3JpdCIgdmFsdWVz IGFyZSBpbiB0aGVpciBsaXN0LiBUaGlzIHdpbGwgYmUgYSBkaXN0aW5jdCBzdGVwIGZyb20gdGhl IG90aGVyIGNvZGUgdGhhdCB1c2VzIHNwZWNpZmljIGZpZWxkcy4NCg0KRm9yIGluc3RhbmNlLCBp ZiB3ZSBkZWZpbmVkIGEgc2ltcGxlIEtERiBpbml0aWFsbHkgdGhlbiBsYXRlciBzcGVjaWZpZWQg c3VwcG9ydCBmb3IgdGhlIE5JU1QgODAwLTU2QSBDb25jYXQgS0RGIGl0IHdvdWxkIGJlIGJldHRl ciB0byBkZWZpbmUgMSBjcml0aWNhbCBzdHJpbmcgIm5pc3Q4MDAtNTZBIiwgaW5zdGVhZCBvZiBs aXN0aW5nICJQYXJ0eVVJbmZvIiwgIlBhcnR5VkluZm8iLCAiU3VwcFB1YkluZm8iLCBhbmQgIlN1 cHBQcml2ZUluZm8iIGZpZWxkcyBuYW1lcyBpbiB0aGUgImNyaXQiIGZpZWxkIC0tIGFueSBvZiB3 aGljaCBtaWdodCBiZSBhYnNlbnQgZnJvbSBhIHBhcnRpY3VsYXIgSk9TRSBtZXNzYWdlIGlmIHRo ZXkgaGFkIHNvbWUgZGVmYXVsdCB2YWx1ZS4NCg0KQW5vdGhlciBleGFtcGxlOiBpZiBhIGdyb3Vw IGluc2lzdHMgb24gYSBzdHJvbmcgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiBwb2xpY3kgKGVnIE1V U1QgdXNlIE9DU1AsIE1VU1QgaGFyZC1mYWlsIGlmIE9DU1AgaXMgdW5hdmFpbGFibGUsIE1VU1Qg Y2hlY2sgQ2VydGlmaWNhdGUgVHJhbnNwYXJlbmN5LCBhbmQgTVVTVCBsb2cgcmVzdWx0cyBmb3Ig NyB5ZWFycykgdGhlcmUgaXMgbm8gbmV3IGhlYWRlciBmaWVsZCB0byBhZGQgdG8gYSBKV1MsIGJ1 dCBpdCBjb3VsZCBkZWZpbmUgdGhlIGNyaXRpY2FsIHN0cmluZyAiU3Ryb25nU2lnMSIuDQoNCg0K LS0NCkphbWVzIE1hbmdlcg0KDQogLS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLQ0K PiBTdWJqZWN0OiBbam9zZV0gUHJvcG9zZWQgcmVzb2x1dGlvbiBvZiBoZWFkZXIgY3JpdGljYWxp dHkgaXNzdWUNCj4gRnJvbTogS2FyZW4gTydEb25vZ2h1ZSA8b2Rvbm9naHVlQGlzb2Mub3JnPG1h aWx0bzpvZG9ub2dodWVAaXNvYy5vcmc+Pg0KPiBEYXRlOiBUdWUsIE1hcmNoIDEyLCAyMDEzIDEy OjMxIGFtDQo+IFRvOiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KDQo+ICAz LiAgRGVmaW5lIGEgbmV3IGhlYWRlciBmaWVsZCB0aGF0IGxpc3RzIHdoaWNoIGFkZGl0aW9uYWwg ZmllbGRzIG5vdA0KPiBkZWZpbmVkIGluIHRoZSBiYXNlIHNwZWNpZmljYXRpb25zIG11c3QgYmUg dW5kZXJzdG9vZCBhbmQgYWN0ZWQgdXBvbg0KPiB3aGVuIHByZXNlbnQuICBGb3IgaW5zdGFuY2Us IGFuIGV4cGlyYXRpb24tdGltZSBleHRlbnNpb24gZmllbGQgY291bGQNCj4gYmUgbWFya2VkIGFz IG11c3QtYmUtdW5kZXJzdG9vZC1hbmQtYWN0ZWQtdXBvbi4gIE9uZSBwb3NzaWJsZSBuYW1lIGZv cg0KPiB0aGlzIHdvdWxkIGJlIOKAnGNyaXTigJ0gKGNyaXRpY2FsKS4gIEFuIGV4YW1wbGUgdXNl LCBhbG9uZyB3aXRoIGENCj4gaHlwb3RoZXRpY2FsIOKAnGV4cOKAnSAoZXhwaXJhdGlvbi10aW1l KSBmaWVsZCBpczoNCj4NCj4gICAgeyJhbGciOiJFUzI1NiIsDQo+ICAgICAiY3JpdCI6WyJleHAi XSwNCj4gICAgICJleHDigJ06MTM2MzI4NDAwMA0KPiAgICB9DQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1haWxpbmcgbGlzdA0Kam9zZUBp ZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vam9zZQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150B8FAAFDWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGku TXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPjwvaGVhZD48Ym9keSBsYW5nPUVOLUFVIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+ PGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6 IzFGNDk3RCc+SSB3YXMganVzdCBsaXN0ZW5pbmcgdG8gc29tZSBvZiB0aGUgSUVURiA4NiBKT1NF IHNlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPk9uZSBpc3N1ZSB3YXMgd2hhdCB3b3VsZCAmcXVvdDtjcml0JnF1b3Q7 OlsmcXVvdDthc2QmcXVvdDtdIG1lYW4/ICh3aGVyZSDigJxhc2TigJ0gaXMgYSB0b3AtbGV2ZWwg YnVja2V0IGZvciBhcHAtc3BlY2lmaWMgZGF0YSB0aGF0IGEgSk9TRSBsaWJyYXJ5IGNhbiBpZ25v cmUpPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPlRoZSBtb3JlIGdlbmVyYWwgaXNzdWUgaXMgd2hldGhlciBvbmx5IHRvcC1sZXZl bCBmaWVsZHMgY2FuIGJlIG1hcmtlZCBjcml0aWNhbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkkgaG9w ZSB3ZSBkb27igJl0IHRyeSB0byBhbnN3ZXIgdGhhdC4gVGlnaHRseSBjb3VwbGluZyBvdXIgY2hv aWNlIG9mIEpTT04gc3RydWN0dXJlIChpZSB3aGF0IGlzIGF0IHRoZSB0b3AgbGV2ZWwpIHRvIHdo YXQgY2FuIGJlIGNyaXRpY2FsIGlzIHVubmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Rm9y IGluc3RhbmNlLCBhIGdvb2QgY2hhbmdlIHRvIHRoZSBKT1NFIHN0cnVjdHVyZSB3b3VsZCBiZSB0 b3AtbGV2ZWwgb2JqZWN0cyAoZWcgbmFtZWQg4oCcb+KAnSBhbmQg4oCccuKAnSkgdG8gZ3JvdXAg ZmllbGRzIGFib3V0IHRoZSBvcmlnaW5hdG9yIGFuZCByZWNpcGllbnQgcmVzcGVjdGl2ZWx5IChl ZyBpdCB3b3VsZCBtYWtlIGl0IGNsZWFyIHdob3NlIGtleSBhIOKAnGtpZOKAnSB2YWx1ZSByZWZl cnJlZCB0bzsgeW91IGNvdWxkIGV2ZW4gaWRlbnRpZnkgZWFjaCBwYXJ0eeKAmXMga2V5IGJ5IGlu Y2x1ZGluZyB0d28g4oCca2lk4oCdIGZpZWxkcywgey4uLiwmcXVvdDtvJnF1b3Q7OnsmcXVvdDtr aWQmcXVvdDs6JnF1b3Q7bXlrZXkxJnF1b3Q7fSwmcXVvdDtyJnF1b3Q7OnsmcXVvdDtraWQmcXVv dDs6JnF1b3Q7eW91cmtleTMmcXVvdDt9fSkuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IHdvdWxkIGJlIGFubm95aW5nIGlm IGFkZGluZyBzdWNoIHN0cnVjdHVyZSBoYWQgdW5pbnRlbmRlZCBpbXBhY3RzIG9uIHdoYXQgY291 bGQgb3IgY291bGRu4oCZdCBiZSBtYXJrZWQgY3JpdGljYWwuPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5T byBsZXTigJlzIGRlZmluZSDigJxjcml04oCdIGFzIGEgbGlzdCBvZiBjcml0aWNhbCBzdHJpbmdz LCB3aXRob3V0IG1lbnRpb25pbmcgZmllbGQgbmFtZXMsIHRvIGF2b2lkIGEgYnVuY2ggb2YgdW5u ZWNlc3NhcnkgaGFzc2xlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXY+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+LS08bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SmFtZXMg TWFuZ2VyPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxl PSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj bSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9RU4t VVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3Jn XSA8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hbmdlciwgSmFtZXMgSDxicj48Yj5TZW50OjwvYj4gVGh1 cnNkYXksIDE0IE1hcmNoIDIwMTMgOTo0NiBBTTxicj48Yj5Ubzo8L2I+IFJpY2hhcmQgQmFybmVz PGJyPjxiPkNjOjwvYj4gam9zZUBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gUmU6IFtqb3Nl XSAmcXVvdDtjcml0JnF1b3Q7IHN0cmluZ3MgZG9uJ3QgaGF2ZSB0byBiZSBmaWVsZCBuYW1lczxv OnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ SSBhbSB0cnlpbmcgdG8gc2ltcGxpZnkgdGhlIOKAnGNyaXTigJ0gZmllbGQsIG5vdCBjb21wbGlj YXRlIGl0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIENvbmNhdCBLREYgcGFyYWdyYXBoIHdhcyBv bmx5IGludGVuZGVkIGFzIGEgdmFndWVseSByZWFsaXN0aWMgZXhhbXBsZSBvZiBob3cgYSBjcml0 aWNhbCBzdHJpbmcgY291bGQgYmUgdXNlZC4gTXkgZW1haWwgd2FzIE5PVCBhIHJlcXVlc3QgdG8g Y2hhbmdlIGhvdyBKT1NFIGN1cnJlbnRseSB1c2VzIENvbmNhdCBLREYuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz5XaGVuIGFuIGltcGxlbWVudGF0aW9uIHNlZXMgYW4gdW5rbm93biBzdHJpbmcgaW4g4oCc Y3JpdOKAnSBpcyBoYXMgdG8gc3RvcC4gVGhlIHJ1bGUgY2FuIGFuZCBzaG91bGQgYmUgdGhhdCBz aW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGRvbuKAmXQgd2FudCBzb21lIGltcGxlbWVudGF0 aW9ucyBhbHNvIGNoZWNraW5nIHRoYXQgYSBoZWFkZXIgZmllbGQgd2l0aCBhbiB1bmtub3duIGNy aXRpY2FsIHN0cmluZ+KAmXMgbmFtZSBpcyBwcmVzZW50IGJlZm9yZSB0aGV5IHJlamVjdCBhIEpP U0UgbWVzc2FnZS4gSSBkb27igJl0IHdhbnQgc29tZSBpbXBsZW1lbnRhdGlvbnMgbGlzdGluZyBm aWVsZCBuYW1lcyBmcm9tIHRoZSDigJxiYXNlIHNwZWNz4oCdLCBzdWNoIGFzIOKAnGFsZ+KAnSwg YXMgY3JpdGljYWwgc3RyaW5ncy4gTGlua2luZyBjcml0aWNhbCBzdHJpbmdzIHRvIGZpZWxkIG5h bWVzIGNhbiBvbmx5IGFkZCBpbGwtZGVmaW5lZCBub24taW50ZXJvcGVyYWJsZSBjb3JuZXIgY2Fz ZXMuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMg c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi Jz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBSaWNoYXJkIEJhcm5lcyBbPGEg aHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giPm1haWx0bzpybGJAaXB2LnN4PC9hPl0gPGJyPjxiPlNl bnQ6PC9iPiBUaHVyc2RheSwgMTQgTWFyY2ggMjAxMyA3OjEzIEFNPGJyPjxiPlRvOjwvYj4gTWFu Z2VyLCBKYW1lcyBIPGJyPjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmci Pmpvc2VAaWV0Zi5vcmc8L2E+PGJyPjxiPlN1YmplY3Q6PC9iPiBSZTogW2pvc2VdICZxdW90O2Ny aXQmcXVvdDsgc3RyaW5ncyBkb24ndCBoYXZlIHRvIGJlIGZpZWxkIG5hbWVzPG86cD48L286cD48 L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+SSBkb24ndCByZWFsbHkgdGhpbmsgdGhhdCB0aGVyZSdz IG11Y2ggYmVuZWZpdCB0byB0aGUgYWRkaXRpb25hbCBjb21wbGV4aXR5IGhlcmUuICZuYnNwO1lv dSBkb24ndCBuZWVkIGl0IGZvciB0aGUgODAwLTU2QSBjYXNlLCBiZWNhdXNlIHRoYXQncyBpbiB0 aGUgY3VycmVudCBkb2N1bWVudCwgYW5kIHdpbGwgdGh1cyBnZXQgcmVhbCByZXF1aXJlbWVudHMg bGFuZ3VhZ2UgaW4gdGhlIHNwZWMuICZuYnNwO0lmIHlvdSBkbyB3YW50IHRvIGdyb3VwIGV4dGVu c2lvbiBmaWVsZHMgaW4gdGhpcyB3YXksIHlvdSBjYW4ganVzdCBncm91cCB0aGVtIGludG8gYW4g b2JqZWN0IHVuZGVyIGEgc2luZ2xlIGV4dGVuc2lvbiBmaWVsZC4gJm5ic3A7Rm9yIGV4YW1wbGU6 PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48 L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ezxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxk aXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyAmbmJzcDsgJnF1b3Q7YWxnJnF1b3Q7OiAmcXVv dDtmb28mcXVvdDssPG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7ICZuYnNwOyAmcXVvdDtuZXctdGhpbmcmcXVvdDs6IHs8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1 b3Q7cGFydDEmcXVvdDs6IDQyLDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtwYXJ0MiZxdW90OzogJnF1 b3Q7c2l4JnF1b3Q7PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7ICZuYnNwOyB9LDxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPiZuYnNwOyAmbmJzcDsgJnF1b3Q7Y3JpdCZxdW90OzogWyZxdW90O25ldy10aGluZyZxdW90 O108bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD59PG86cD48L286 cD48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox Mi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFR1 ZSwgTWFyIDEyLCAyMDEzIGF0IDEwOjA4IFBNLCBNYW5nZXIsIEphbWVzIEggJmx0OzxhIGhyZWY9 Im1haWx0bzpKYW1lcy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIiB0YXJnZXQ9Il9ibGFuayI+ SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5BcyB3ZSBkZWZpbmUgdGhlICZxdW90O2NyaXQmcXVvdDsg ZmllbGQgd2UgZG9uJ3QgbmVlZCB0byB1c2UgZmllbGQgbmFtZXMgYXMgdGhlIGNyaXRpY2FsIHN0 cmluZ3MuPGJyPjxicj5JbXBsZW1lbnRhdGlvbnMgd2lsbCBoYXZlIGEgbGlzdCBvZiBjcml0aWNh bCBzdHJpbmdzIHRoZXkgdW5kZXJzdGFuZCAoYmFzZWQgb24gdGhlIHNwZWNzIHRoYXQgZGVmaW5l IHRob3NlIGNyaXRpY2FsIHN0cmluZ3MpIGFuZCB3aWxsIGNvbmZpcm0gdGhhdCBhbGwgdGhlICZx dW90O2NyaXQmcXVvdDsgdmFsdWVzIGFyZSBpbiB0aGVpciBsaXN0LiBUaGlzIHdpbGwgYmUgYSBk aXN0aW5jdCBzdGVwIGZyb20gdGhlIG90aGVyIGNvZGUgdGhhdCB1c2VzIHNwZWNpZmljIGZpZWxk cy48YnI+PGJyPkZvciBpbnN0YW5jZSwgaWYgd2UgZGVmaW5lZCBhIHNpbXBsZSBLREYgaW5pdGlh bGx5IHRoZW4gbGF0ZXIgc3BlY2lmaWVkIHN1cHBvcnQgZm9yIHRoZSBOSVNUIDgwMC01NkEgQ29u Y2F0IEtERiBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZGVmaW5lIDEgY3JpdGljYWwgc3RyaW5nICZx dW90O25pc3Q4MDAtNTZBJnF1b3Q7LCBpbnN0ZWFkIG9mIGxpc3RpbmcgJnF1b3Q7UGFydHlVSW5m byZxdW90OywgJnF1b3Q7UGFydHlWSW5mbyZxdW90OywgJnF1b3Q7U3VwcFB1YkluZm8mcXVvdDss IGFuZCAmcXVvdDtTdXBwUHJpdmVJbmZvJnF1b3Q7IGZpZWxkcyBuYW1lcyBpbiB0aGUgJnF1b3Q7 Y3JpdCZxdW90OyBmaWVsZCAtLSBhbnkgb2Ygd2hpY2ggbWlnaHQgYmUgYWJzZW50IGZyb20gYSBw YXJ0aWN1bGFyIEpPU0UgbWVzc2FnZSBpZiB0aGV5IGhhZCBzb21lIGRlZmF1bHQgdmFsdWUuPGJy Pjxicj5Bbm90aGVyIGV4YW1wbGU6IGlmIGEgZ3JvdXAgaW5zaXN0cyBvbiBhIHN0cm9uZyBzaWdu YXR1cmUgdmVyaWZpY2F0aW9uIHBvbGljeSAoZWcgTVVTVCB1c2UgT0NTUCwgTVVTVCBoYXJkLWZh aWwgaWYgT0NTUCBpcyB1bmF2YWlsYWJsZSwgTVVTVCBjaGVjayBDZXJ0aWZpY2F0ZSBUcmFuc3Bh cmVuY3ksIGFuZCBNVVNUIGxvZyByZXN1bHRzIGZvciA3IHllYXJzKSB0aGVyZSBpcyBubyBuZXcg aGVhZGVyIGZpZWxkIHRvIGFkZCB0byBhIEpXUywgYnV0IGl0IGNvdWxkIGRlZmluZSB0aGUgY3Jp dGljYWwgc3RyaW5nICZxdW90O1N0cm9uZ1NpZzEmcXVvdDsuPGJyPjxicj48YnI+LS08YnI+SmFt ZXMgTWFuZ2VyPGJyPjxicj4mbmJzcDstLS0tLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tLS0t PGJyPiZndDsgU3ViamVjdDogW2pvc2VdIFByb3Bvc2VkIHJlc29sdXRpb24gb2YgaGVhZGVyIGNy aXRpY2FsaXR5IGlzc3VlPGJyPiZndDsgRnJvbTogS2FyZW4gTydEb25vZ2h1ZSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOm9kb25vZ2h1ZUBpc29jLm9yZyI+b2Rvbm9naHVlQGlzb2Mub3JnPC9hPiZndDs8 YnI+Jmd0OyBEYXRlOiBUdWUsIE1hcmNoIDEyLCAyMDEzIDEyOjMxIGFtPGJyPiZndDsgVG86IDxh IGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj48YnI+Jmd0 OyAmbmJzcDszLiAmbmJzcDtEZWZpbmUgYSBuZXcgaGVhZGVyIGZpZWxkIHRoYXQgbGlzdHMgd2hp Y2ggYWRkaXRpb25hbCBmaWVsZHMgbm90PGJyPiZndDsgZGVmaW5lZCBpbiB0aGUgYmFzZSBzcGVj aWZpY2F0aW9ucyBtdXN0IGJlIHVuZGVyc3Rvb2QgYW5kIGFjdGVkIHVwb248YnI+Jmd0OyB3aGVu IHByZXNlbnQuICZuYnNwO0ZvciBpbnN0YW5jZSwgYW4gZXhwaXJhdGlvbi10aW1lIGV4dGVuc2lv biBmaWVsZCBjb3VsZDxicj4mZ3Q7IGJlIG1hcmtlZCBhcyBtdXN0LWJlLXVuZGVyc3Rvb2QtYW5k LWFjdGVkLXVwb24uICZuYnNwO09uZSBwb3NzaWJsZSBuYW1lIGZvcjxicj4mZ3Q7IHRoaXMgd291 bGQgYmUg4oCcY3JpdOKAnSAoY3JpdGljYWwpLiAmbmJzcDtBbiBleGFtcGxlIHVzZSwgYWxvbmcg d2l0aCBhPGJyPiZndDsgaHlwb3RoZXRpY2FsIOKAnGV4cOKAnSAoZXhwaXJhdGlvbi10aW1lKSBm aWVsZCBpczo8YnI+Jmd0Ozxicj4mZ3Q7ICZuYnNwOyAmbmJzcDt7JnF1b3Q7YWxnJnF1b3Q7OiZx dW90O0VTMjU2JnF1b3Q7LDxicj4mZ3Q7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7Y3JpdCZxdW90Ozpb JnF1b3Q7ZXhwJnF1b3Q7XSw8YnI+Jmd0OyAmbmJzcDsgJm5ic3A7ICZxdW90O2V4cOKAnToxMzYz Mjg0MDAwPGJyPiZndDsgJm5ic3A7ICZuYnNwO308YnI+PGJyPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmpvc2UgbWFpbGluZyBsaXN0PGJyPjxhIGhy ZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj48YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2U8L2E+PG86cD48L286 cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_255B9BB34FB7D647A506DC292726F6E1150B8FAAFDWSMSG3153Vsrv_-- From rlb@ipv.sx Thu Mar 14 06:25:42 2013 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 A84EA11E80FD for ; Thu, 14 Mar 2013 06:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.769 X-Spam-Level: X-Spam-Status: No, score=-0.769 tagged_above=-999 required=5 tests=[AWL=2.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nHcg6VZm3QRc for ; Thu, 14 Mar 2013 06:25:28 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFC9921F8FC4 for ; Thu, 14 Mar 2013 06:25:23 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id h2so2254707oag.38 for ; Thu, 14 Mar 2013 06:25:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=CKgFU/CFE6KGa1xTmf+wtGHV/SCt2kw1VV1FibOiuDo=; b=lsuM8kNSSKxRf1lA+28xtH8ZpS29UYbfbHrLpsqJnGahdE6A/zg7wZyEXou6pH6S8e 0MmBNV/CqL2CnZx/3Lcnhmcw4D89qHMSvWMFgJqbkVmOUG46q202FF6jdpIF3ZJ98gJO 0E3TJoL6f6zq/KcLlG4LIqE0jS8ookrikUOA74bBnQt0SRqb4S0ltQbf8SxXaLmUOaEG D+Ljkq3gye73o78eYawyWozRhzKfH10aeNEk+Jpmvz6RbZLFgInaibuFZADysSMoEe5I MdxG6/LYfhYOijGVqd9qmBOGUfn0IoXw2lADC9Xwt+vFWLLjpNcUaPKHkogvWKPukaUx oQUw== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr1045743oec.125.1363267520503; Thu, 14 Mar 2013 06:25:20 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Thu, 14 Mar 2013 06:25:20 -0700 (PDT) X-Originating-IP: [128.89.254.54] In-Reply-To: References: Date: Thu, 14 Mar 2013 09:25:20 -0400 Message-ID: From: Richard Barnes To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=bcaec54b48124b316504d7e27415 X-Gm-Message-State: ALoCoQnN7UURb89ud7oqbh5J2bHgRmP8nhNI/+dNVHRjQmvkuFnYw/jFNpOBy8Gadgkx0V2WKAoK Cc: Nat Sakimura , "" Subject: Re: [jose] Combining the documents and MTI 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, 14 Mar 2013 13:25:42 -0000 --bcaec54b48124b316504d7e27415 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Mar 13, 2013 at 11:16 AM, Matt Miller (mamille2) wrote: > > On Mar 13, 2013, at 10:32 AM, Nat Sakimura > wrote: > > > In the interest of the time keeping, I did not ask the question in the > > room but I was wondering whether combining the documents would impact > > the way MTIs are written. My hope is not but just want it to be > > clarified. > > > I think it should be possible to explicitly and concisely outline both the > Compact and JSON serializations, as well as the pro's and con's of each. > Personally, I would prefer the JWE/JWS documents didn't discuss the core > operations with the assumption of compact usage, but that's not a hill for > me to even approach for dying on. > +1 Go ahead and combine them. We can have the discussion later about whether we have an MTI. --Richard --bcaec54b48124b316504d7e27415 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Mar 13, 2013 at 11:16 AM, Matt Miller (mamille2) = <mamille2@cisco.= com> wrote:

On Mar 13, 2013, at 10:32 AM, Nat Sakimura <sakimura@gmail.com>
=A0wrote:

> In the interest of the time keeping, I did not ask the question in the=
> room but I was wondering whether combining the documents would impact<= br> > the way MTIs are written. My hope is not but just want it to be
> clarified.


I think it should be possible to explicitly and concisely outline bot= h the Compact and JSON serializations, as well as the pro's and con'= ;s of each. =A0Personally, I would prefer the JWE/JWS documents didn't = discuss the core operations with the assumption of compact usage, but that&= #39;s not a hill for me to even approach for dying on.

+1=A0

Go ahead an= d combine them. =A0We can have the discussion later about whether we have a= n MTI.

--Richard=A0
--bcaec54b48124b316504d7e27415-- From rlb@ipv.sx Thu Mar 14 06:36:25 2013 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 EBF0C1F0D09 for ; Thu, 14 Mar 2013 06:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.065 X-Spam-Level: X-Spam-Status: No, score=0.065 tagged_above=-999 required=5 tests=[AWL=0.490, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 gIUYdwYggHok for ; Thu, 14 Mar 2013 06:36:25 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6D91F0D08 for ; Thu, 14 Mar 2013 06:36:25 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id un3so2150848obb.38 for ; Thu, 14 Mar 2013 06:36:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=PeJAhMG5jxFHUfYBMg3vbEsdogIXb4h+EQ5Vrg5tH7U=; b=UJ3MI4DEzQoSrac25xu++0YG7nxrEHAaeEJUEYbZ4GvaOicjj5BOpsm5fo1r301bA2 KslU5vzSQpGTCuz7s8zBWaxnpnmK0ZJ3Al1WkXqZiCDDdmOCEeFfdbVu1xZkYY1WcCb4 6Lf67T5HM09yqlD4i61cVKSr1Lzkn8pGEuYDJ/IDFi0xdZggLqnlCfW3RWjHozXhT/mV HDv0BPFAf602J36RaJ5W3ILk53A4LGhZD2io/wMj/N5/uWomzgo1fCxD8Qbqx1n1N1IF FMSPdtVeKzZIXsYvEMGa0HOtgIIuL/EWw9efCV6nPJITg3+fSVKJG3DdACouo9+d42m6 gPVA== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr1065794oec.125.1363268184901; Thu, 14 Mar 2013 06:36:24 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Thu, 14 Mar 2013 06:36:24 -0700 (PDT) X-Originating-IP: [128.89.254.54] Date: Thu, 14 Mar 2013 09:36:24 -0400 Message-ID: From: Richard Barnes To: jose@ietf.org Content-Type: multipart/alternative; boundary=bcaec54b4812e50d1004d7e29bf5 X-Gm-Message-State: ALoCoQnegX0u4WS08el/GJb+wHDEN35t4WD3fGYpM0MOAAlaXrzz+5FOhA95upEJh6Pg7o3Ed8lw Subject: [jose] MTI algorithms 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, 14 Mar 2013 13:36:26 -0000 --bcaec54b4812e50d1004d7e29bf5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I noted yesterday a concern that many things that should be counted as JOSE implementations could actually be ruled out if we have MTI algorithms. The concern arises from the fact that JOSE libraries are built on crypto libraries -- they are not crypto libraries, and thus they don't necessarily control what algorithms are available. The WebCrypto example is one flavor of this: If I write a JOSE library that uses WebCrypto, then I have *no* *idea* what algorithms will be available when my library is run in a browser. Since I can't guarantee that MTI algorithms will be available, I can't be counted as a JOSE implementation. This is not just a WebCrypto issue. It could appear just as easily if I link against OpenSSL, which has famously varied support for things like ECC. Or if I use PKCS#11 to talk to smart cards -- who knows whether the smart card that's inserted right now has an RSA engine? Given these scenarios, the MUST in the MUST IMPLEMENT would be a "Schr=F6dinger's MUST" -- a library's compliance can't be determined until it's run. This does not seem like a useful requirement. I also don't accept the notion that the IESG will not accept a document without an MTI algorithm suite. (And not just because of recent events.) In addition to the argument above, there's history; namely, that CMS doesn't have any MTIs. Much like several other questions in this group, this is a layering question. JOSE is not a crypto spec, and it's not an application. It's an encoding of crypto parameters, which is used by applications. So our focus here should be on clear expression of the relevant parameters, in a way that is useful to applications -- not on trying to force application behaviors. --bcaec54b4812e50d1004d7e29bf5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I noted yesterday a concern that many things that should be counted as JOSE= implementations could actually be ruled out if we have MTI algorithms. =A0=

The concern arises from the fact that JOSE libraries ar= e built on crypto libraries -- they are not crypto libraries, and thus they= don't necessarily control what algorithms are available. =A0The WebCry= pto example is one flavor of this: If I write a JOSE library that uses WebC= rypto, then I have *no* *idea* what algorithms will be available when my li= brary is run in a browser. =A0Since I can't guarantee that MTI algorith= ms will be available, I can't be counted as a JOSE implementation. =A0T= his is not just a WebCrypto issue. =A0It could appear just as easily if I l= ink against OpenSSL, which has famously varied support for things like ECC.= =A0Or if I use PKCS#11 to talk to smart cards -- who knows whether the sma= rt card that's inserted right now has an RSA engine?

Given these scenarios, the MUST in the MUST IMPLEMENT w= ould be a "Schr=F6dinger's MUST" -- a library's complianc= e can't be determined until it's run. =A0This does not seem like a = useful requirement.

I also don't accept the notion that the IESG will n= ot accept a document without an MTI algorithm suite. =A0(And not just becau= se of recent events.) =A0In addition to the argument above, there's his= tory; namely, that CMS doesn't have any MTIs.

Much like several other questions in this group, this i= s a layering question. =A0JOSE is not a crypto spec, and it's not an ap= plication. =A0It's an encoding of crypto parameters, which is used by a= pplications. =A0So our focus here should be on clear expression of the rele= vant parameters, in a way that is useful to applications -- not on trying t= o force application behaviors.
--bcaec54b4812e50d1004d7e29bf5-- From mamille2@cisco.com Thu Mar 14 06:48:27 2013 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 E9B1811E813F for ; Thu, 14 Mar 2013 06:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 lhEjBJHqbJTu for ; Thu, 14 Mar 2013 06:48:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 8F00111E812F for ; Thu, 14 Mar 2013 06:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4000; q=dns/txt; s=iport; t=1363268903; x=1364478503; h=from:to:subject:date:message-id:mime-version; bh=nXwfDdaj2fUBrJLUPO9YkwK1bO5vfqmDHE2RxXWUcSk=; b=lCX0IvBIpldq5J3nBPtjLcCSyHrSrGscOd0qZSSJP0hjAvWIyoIuH8eE J+b21h6OhaEM63TbTKBDKW00TA5vkfr1XaQhfDSorYZzFUyfbhWn7RKXx ZD3d1Jd+c+7LL8HwWCNqoCBJGGUC6j/4XZLrZorKh4r5ajZnLbTW8/Hpu M=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFACLUQVGtJV2c/2dsb2JhbABDh2SsCpELgWEWdIIsAQSBCwEqJjAnBBMIBogGoBChJo5fgxdhA482gSiWfIMKgig X-IronPort-AV: E=Sophos;i="4.84,845,1355097600"; d="p7s'?scan'208";a="187433301" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 14 Mar 2013 13:48:14 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2EDmERq011852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 14 Mar 2013 13:48:14 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Thu, 14 Mar 2013 08:48:03 -0500 From: "Matt Miller (mamille2)" To: "" Thread-Topic: Rolling PKIX into JWK Thread-Index: AQHOILqMA29glkFWZUOgI7llc9nICg== Date: Thu, 14 Mar 2013 13:48:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.147.16] Content-Type: multipart/signed; boundary="Apple-Mail=_A8860D3F-D2DC-4574-B904-DED3619457A9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [jose] Rolling PKIX into JWK 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, 14 Mar 2013 13:48:28 -0000 --Apple-Mail=_A8860D3F-D2DC-4574-B904-DED3619457A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [hoping this topic is the least controversial...] In some IRL discussions on moving forward on PKIX in JWK, I've been = convinced the concerns are mostly the same regardless of how the PKIX is = packaged. Given that, I would suggest we make "x5c" an optional field = of JWK, rather than defining a new JWK type. I can propose various text = additions after this meeting. Thoughts? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_A8860D3F-D2DC-4574-B904-DED3619457A9 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxNDEzNDgwMFowIwYJKoZIhvcNAQkEMRYEFPz0ccbykG2eXejQ7cWpD8+SXRANMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCjYaFJIcnbg1n7fgnWjdKOLFHjch4LAPWvGnDiC7VD BAwMGb4nGeobgLkU47lVtn0UOG7d/ycgxdx+KXsz/D5GEXxyXrdeNAlenzRw+sQ4J7ylSZKGbJPX ROUE/001GTpjfJ/6Figf7DxqkkJnF1f1yih0E8yfr2a6WdsZNEd5M8UWLUyIEdmJECk4hpQvKxaj junV0B3SaL1S3rRBo28LZ+BieLV+NPv06nGOW1ZP47Fk8o8NCtgsUKKms9MNQZ5YVWLxJJB23xVA x+wweHHxSFZaRjqWFWZFSg6WIYg61TZY944iijvh8yqjc89G1rOGRD8FY33bwavlyAiUGGCAAAAA AAAA --Apple-Mail=_A8860D3F-D2DC-4574-B904-DED3619457A9-- From leifj@mnt.se Thu Mar 14 06:54:15 2013 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 172DE21F8E46 for ; Thu, 14 Mar 2013 06:54:15 -0700 (PDT) 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 XmYjUrclQ78u for ; Thu, 14 Mar 2013 06:54:14 -0700 (PDT) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 67EE021F8CF7 for ; Thu, 14 Mar 2013 06:54:14 -0700 (PDT) Received: by mail-pb0-f48.google.com with SMTP id wy12so2229831pbc.7 for ; Thu, 14 Mar 2013 06:54:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=LmQKIXzrFZPi5BlaWoumNlyvSUX6jf2osb/i2Sl+DgI=; b=WrA1WSwWbLgUIHlSNdrArvspE0lr7bTwo5HeSqYSXZoNU4MZunalmmUeeI8us/AJ+C kJJ9t5Ju3e+soaJFTJgplehW/fOevRZAYgRIIZrxOfkFN4mHUpdYycKLQMIdiH4/zsv4 ihqlOV1vrHl2zjnNig+D0RbBo958cl/7E2SLouh0mhmj3pfIh1VAG+BLkR5mWgtO99U5 enDQiEW8p2oXeRV3e6kV1yDX0ULn6a9n7A8TDuXWlC+bXmG0OQVkeOPF8r+I1q3wcm9q Fua3kCCNV+Kkx6zpAB2zrKpYxydHYT067nNm+5tErDrOqRWmg/g3zTCgjaQ4CV1AqAzV PukA== X-Received: by 10.68.189.137 with SMTP id gi9mr6117048pbc.118.1363269253643; Thu, 14 Mar 2013 06:54:13 -0700 (PDT) Received: from ?IPv6:2001:df8:0:8:a950:65d9:b202:f2ff? ([2001:df8:0:8:a950:65d9:b202:f2ff]) by mx.google.com with ESMTPS id vq9sm3372238pbc.36.2013.03.14.06.54.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 06:54:12 -0700 (PDT) Message-ID: <5141D681.2090404@mnt.se> Date: Thu, 14 Mar 2013 14:54:09 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkBHdEx5EIEQ61f3bpBStHU1rUV8t5fSZIdL4br+2JrR+24io0ihDp3KhbiMrYKijhCD69a Subject: Re: [jose] MTI algorithms 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, 14 Mar 2013 13:54:15 -0000 On 03/14/2013 02:36 PM, Richard Barnes wrote: > I noted yesterday a concern that many things that should be counted as > JOSE implementations could actually be ruled out if we have MTI > algorithms. > > Richard I think you're overcomplicating things. Yes, in principle you're right about the WebCrypto example and yes you might be right about CMS (although that was some time ago) but you have to ask yourself is this really worth picking a fight over? Cheers Leif From rlb@ipv.sx Thu Mar 14 06:57:45 2013 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 39E5111E8125 for ; Thu, 14 Mar 2013 06:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.257 X-Spam-Level: X-Spam-Status: No, score=-0.257 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 Uypn89ord8cL for ; Thu, 14 Mar 2013 06:57:42 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E230E11E811E for ; Thu, 14 Mar 2013 06:57:38 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id dn14so2149918obc.4 for ; Thu, 14 Mar 2013 06:57:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=o15Q1rUGLTbO+W4czPleHjv/b3nG7K6zra/iN0nvguk=; b=TIOSfTY0HsThFA27hCUg6Rw0MkTyG3G1zpDGh8MXIsjt9aTKrGCJAed+caDHi11qAn rC+zhfAhAAdRo4BbcKn40ofsDNqnD+MiVK4ScaXw5dPNl6P2dgLs4/PXUeZNNPrTxKw/ yrtWsogtxxOIZAakNyrs6YFRjBddnoDzzpg1e1yXfZH/ueILcWUoNRKY6K4NnGheME/k X4qq6XOfM4pKKSjc7HTonWZ3nciePF919LIaXVWtr8ZpaiBGGHosRVCCrOHk0JYcnpsY t7wdqLqu0lQbT4maEDjNb2ck/bFG6Clra+GKZflS5F6zmaqv6WxsKCeoBMTRg+1uNN/R nAcg== MIME-Version: 1.0 X-Received: by 10.182.59.20 with SMTP id v20mr1152070obq.80.1363269458308; Thu, 14 Mar 2013 06:57:38 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Thu, 14 Mar 2013 06:57:38 -0700 (PDT) X-Originating-IP: [128.89.254.54] In-Reply-To: <5141D681.2090404@mnt.se> References: <5141D681.2090404@mnt.se> Date: Thu, 14 Mar 2013 09:57:38 -0400 Message-ID: From: Richard Barnes To: Leif Johansson Content-Type: multipart/alternative; boundary=14dae93a0db1cbd7e204d7e2e7ee X-Gm-Message-State: ALoCoQmiNdy4REis1Is8KPUM+vifwHaJMQQ2rIKkG4HmcKBn/hgWnUBJyXh8riXNbPSjXedh+hzE Cc: jose@ietf.org Subject: Re: [jose] MTI algorithms 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, 14 Mar 2013 13:57:46 -0000 --14dae93a0db1cbd7e204d7e2e7ee Content-Type: text/plain; charset=ISO-8859-1 > > I noted yesterday a concern that many things that should be counted as > > JOSE implementations could actually be ruled out if we have MTI > > algorithms. > > > > > Richard I think you're overcomplicating things. > > Yes, in principle you're right about the WebCrypto example and yes you > might be > right about CMS (although that was some time ago) but you have to ask > yourself > is this really worth picking a fight over? > > Cheers Leif > I'm not going to go to the mat on this. I just wanted to state clearly why I think the MTI idea is so vacuous. --Richard --14dae93a0db1cbd7e204d7e2e7ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I noted yesterday a concern that many things that should be counted as=
> JOSE implementations could actually be ruled out if we have MTI
> algorithms.
>
>
Richard I think you're overcomplicating things.

Yes, in principle you're right about the WebCrypto example and yes you<= br> might be
right about CMS (although that was some time ago) but you have to ask
yourself
is this really worth picking a fight over?

=A0 =A0 =A0 =A0 Cheers Leif

I'm not= going to go to the mat on this. =A0I just wanted to state clearly why I th= ink the MTI idea is so vacuous.

--Richard=A0
=
--14dae93a0db1cbd7e204d7e2e7ee-- From leifj@mnt.se Thu Mar 14 06:58:50 2013 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 153C111E8113 for ; Thu, 14 Mar 2013 06:58:38 -0700 (PDT) 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=[AWL=-0.001, 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 b39pf5m+7NwV for ; Thu, 14 Mar 2013 06:58:36 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 24EBB21F8EA2 for ; Thu, 14 Mar 2013 06:58:34 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so2257833pbc.15 for ; Thu, 14 Mar 2013 06:58:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type:x-gm-message-state; bh=FVL9AGm0PylOzG7ZUTr+spNUyf09PIhC3aer3/i7F7U=; b=W8LfMI3ljA7kNVM2GwZ/jFHOMhJ033BGWOchL+IdYOOsfZarGlYwz/+cZwYjvcT6e/ YTKMjXb62/+jgsR1w/XW6UigqeXUP02wxMJ4PvYDk6ZfKaizsaVeNeM7VzsRpEG/QDsb 0i6iCcodsMAkh5cphsFkk9WDk9vzudkvub+ppsDlsZ6bKSZB7koSDQ0XmGPRbKdvUtNX 05DrdpyTqCzqoxQvfIgHrZHwdDsWPAs3bpYbNyiJ5/Q6O3FGYafyet3kKQ91GnBHw7iL 9d0lDAwxXxdvJt68Pzk1fMD8eLs1rsVRfEJaqBjvzxkN4jM9FxcRNchRsUYI//E2maqb fnMw== X-Received: by 10.68.225.138 with SMTP id rk10mr5894536pbc.146.1363269513781; Thu, 14 Mar 2013 06:58:33 -0700 (PDT) Received: from ?IPv6:2001:df8:0:8:a950:65d9:b202:f2ff? ([2001:df8:0:8:a950:65d9:b202:f2ff]) by mx.google.com with ESMTPS id ax3sm3389169pbd.42.2013.03.14.06.58.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 14 Mar 2013 06:58:33 -0700 (PDT) Message-ID: <5141D786.5040308@mnt.se> Date: Thu, 14 Mar 2013 14:58:30 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Richard Barnes References: <5141D681.2090404@mnt.se> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060301040306010004030100" X-Gm-Message-State: ALoCoQkXU+2lt+gfJt3efzoPDgjiHD6XTcvhpQNilvTY7eYj/Poct3oZLLI3/bEvFac8lhaRYqPw Cc: jose@ietf.org Subject: Re: [jose] MTI algorithms 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, 14 Mar 2013 13:58:50 -0000 This is a multi-part message in MIME format. --------------060301040306010004030100 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 03/14/2013 02:57 PM, Richard Barnes wrote: > > > I noted yesterday a concern that many things that should be > counted as > > JOSE implementations could actually be ruled out if we have MTI > > algorithms. > > > > > Richard I think you're overcomplicating things. > > Yes, in principle you're right about the WebCrypto example and yes you > might be > right about CMS (although that was some time ago) but you have to ask > yourself > is this really worth picking a fight over? > > Cheers Leif > > > I'm not going to go to the mat on this. I just wanted to state > clearly why I think the MTI idea is so vacuous. > > --Richard I think we've all felt that way once or twice. I know I have. --------------060301040306010004030100 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 03/14/2013 02:57 PM, Richard Barnes wrote:

> I noted yesterday a concern that many things that should be counted as
> JOSE implementations could actually be ruled out if we have MTI
> algorithms.
>
>
Richard I think you're overcomplicating things.

Yes, in principle you're right about the WebCrypto example and yes you
might be
right about CMS (although that was some time ago) but you have to ask
yourself
is this really worth picking a fight over?

        Cheers Leif

I'm not going to go to the mat on this.  I just wanted to state clearly why I think the MTI idea is so vacuous.

--Richard 
I think we've all felt that way once or twice. I know I have.
--------------060301040306010004030100-- From bcampbell@pingidentity.com Thu Mar 14 07:12:07 2013 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 EC8D821F87F9 for ; Thu, 14 Mar 2013 07:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Tp1KuiupLndV for ; Thu, 14 Mar 2013 07:12:04 -0700 (PDT) Received: from na3sys009aog110.obsmtp.com (na3sys009aog110.obsmtp.com [74.125.149.203]) by ietfa.amsl.com (Postfix) with ESMTP id A91E421F8DD7 for ; Thu, 14 Mar 2013 07:11:58 -0700 (PDT) Received: from mail-ob0-f198.google.com ([209.85.214.198]) (using TLSv1) by na3sys009aob110.postini.com ([74.125.148.12]) with SMTP ID DSNKUUHapNDQOobCZj++IMlIlwxO39b2yckL@postini.com; Thu, 14 Mar 2013 07:11:58 PDT Received: by mail-ob0-f198.google.com with SMTP id dn14so11869148obc.9 for ; Thu, 14 Mar 2013 07:11:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=CKzuM/B+uRc6MQTtNVqKGwbQoBh3rw4M/7xr4opZhMY=; b=bF7WMqei52x8RL9ppp8opxU4IL0nA8JZnYQI1vsTWktPHPSWEwTWmOn6PnDnr8PPC3 DynzuF7c0NlhdnghdZQeAOtv5E0Vdn+BNatGu5forIlAsVPOPJsNNzTly8mmcW3nzA2T DWu+2ijJK8FVwuYKfH4dTO5ggVVZf+MuD5LZ34X8cADoKVuWpA9xwB81QZfTvxfaI5mE ALKlD8+TyvAISHnf/L6QuiPi1PbpzfElhLFwke/zzCvtlj4XHnZapu9+Fh19r03Z9O/J b3hLVs3EXBDuLhbR7embwElMH7ee/7SzacxZdt6em84Ffz9blX7mh3bE03ckWB5Pj99H CkWQ== X-Received: by 10.42.122.66 with SMTP id m2mr2122399icr.15.1363270307743; Thu, 14 Mar 2013 07:11:47 -0700 (PDT) X-Received: by 10.42.122.66 with SMTP id m2mr2122392icr.15.1363270307661; Thu, 14 Mar 2013 07:11:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Thu, 14 Mar 2013 07:11:17 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Thu, 14 Mar 2013 10:11:17 -0400 Message-ID: To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=20cf3003bbb66beb3304d7e31a4b X-Gm-Message-State: ALoCoQl8TMYsDDCmJDwxA8PD51ne1WcZS47BTr67qGDARQHQ1CsWIv2j+1PMIN9Sxk1rCYwtFkJhsmqKxhRpIb3OUmA/jWAddjFhYgf8RJPVmtU3bBidkVrMjm5ZPPB4wrZnXGFcbAbq Cc: "" Subject: Re: [jose] Rolling PKIX into JWK 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, 14 Mar 2013 14:12:08 -0000 --20cf3003bbb66beb3304d7e31a4b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've personally come to prefer the PKIX key type approach (maybe because I've done some downstream work with it). However, similar to what Matt said yesterday, I'd just like to have the general functionality available so I'm okay with either way of doing it (as long as it gets done). BTW, I mentioned the related work on key publication and rotation in OpenID Connect yesterday, which is in =A74 at http://openid.net/specs/openid-connect-messages-1_0.html#sigenc.key if anyone is interested in taking a look at it (it's not very long!). On Thu, Mar 14, 2013 at 9:48 AM, Matt Miller (mamille2) wrote: > [hoping this topic is the least controversial...] > > In some IRL discussions on moving forward on PKIX in JWK, I've been > convinced the concerns are mostly the same regardless of how the PKIX is > packaged. Given that, I would suggest we make "x5c" an optional field of > JWK, rather than defining a new JWK type. I can propose various text > additions after this meeting. > > > Thoughts? > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --20cf3003bbb66beb3304d7e31a4b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I've personally come to prefer the PKIX key type = approach (maybe because I've done some downstream work with it).=A0 How= ever, similar to what Matt said yesterday, I'd just like to have the ge= neral functionality available so I'm okay with either way of doing it (= as long as it gets done).

BTW, I mentioned the related work on key publication and rotation= in OpenID Connect yesterday, which is in =A74 at http://openid.net/sp= ecs/openid-connect-messages-1_0.html#sigenc.key if anyone is interested= in taking a look at it (it's not very long!).


On Thu,= Mar 14, 2013 at 9:48 AM, Matt Miller (mamille2) <mamille2@cisco.com&= gt; wrote:
[hoping this topic is the least controversia= l...]

In some IRL discussions on moving forward on PKIX in JWK, I've been con= vinced the concerns are mostly the same regardless of how the PKIX is packa= ged. =A0Given that, I would suggest we make "x5c" an optional fie= ld of JWK, rather than defining a new JWK type. =A0I can propose various te= xt additions after this meeting.


Thoughts?

- m&m

Matt Miller < mamille2@cisco.com >
Cisco Systems, Inc.


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--20cf3003bbb66beb3304d7e31a4b-- From Jeff.Hodges@KingsMountain.com Thu Mar 14 08:17:06 2013 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 764D311E8292 for ; Thu, 14 Mar 2013 08:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 ZlvvUsXVZnVb for ; Thu, 14 Mar 2013 08:17:01 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 97F5B11E828D for ; Thu, 14 Mar 2013 08:17:01 -0700 (PDT) Received: (qmail 5717 invoked by uid 0); 14 Mar 2013 15:16:40 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy12.bluehost.com with SMTP; 14 Mar 2013 15:16:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=wT8yywc3Cn/uPdBDwejoErkKJYZuuQX0iD/QX3EtdVM=; b=wRLYy53LIUX2aZ7klyPLEvd8fIo7t85S+j2vtY1Zcz0o3SkDJbMEhHd8sxudkOTPmr4l/kKzR2eDhUHzTf5MWWvOGzlYgnHK0bLB2kulU59o5RtFYzSyoX4eBimg5BS1; Received: from [130.129.19.55] (port=40198) by box514.bluehost.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UG9tY-0000i2-2N; Thu, 14 Mar 2013 09:16:40 -0600 Message-ID: <5141E9D6.6030003@KingsMountain.com> Date: Thu, 14 Mar 2013 08:16:38 -0700 From: =JeffH User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: IETF JOSE WG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.19.55 authed with jeff.hodges+kingsmountain.com} Cc: Juraj Somorovsky Subject: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 15:17:06 -0000 back on Fri, 6 Jul 2012 Mike Jones said: > > Looking at this again, it seems to me that because JWE provides integr= ity > protection for the algorithm, it should be impossible for you to repla= ce > "RSA-OAEP" with "RSA1_5" in the header because then the integrity chec= k will > fail. Thus, the attack that you describe below is prevented by the in= tegrity > protection of the header. > > Hence, correct JWE implementations do no provide the OAEP decryption o= racle > that you describe. However if I'm missing something, please point it = out to > me, since if there's an issue, I'd like to understand it and how to mi= tigate > it. just fyi/fwiw...apologies if this has already been followed up on, but I = didn't=20 find further discussion of this after the above-quoted msg... Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks"= paper=20 [1] is now out, and it may help answer the above questions. There's also = Kenny=20 Patterson's talk [2] from the recent Workshop on Real-World Cryptography.= It seems, from an admittedly cursory glance at both=20 draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, tha= t=20 perhaps there should be more implementation advice and security considera= tions=20 in (at least) the -json-web-algorithms spec. Here's some excerpts from the paper for context... ... In the public-key setting, we show how the well-known attack of Bleichenb= acher=20 [13] gives rise to a BC [Backwards Compatibility] attack that allows an a= ttacker to decrypt ciphertexts of PKCS#1 v2.0 encryption in both XML Encryption [= 27] and=20 JSON Web Encryption [42], and to forge signatures for arbitrary messages = in XML=20 Signature [30] and JSON Web Signature [41]. The attack principle is descr= ibed in=20 Section 4. We furthermore report on our experimental results, executed ag= ainst=20 the Java implementation of JSON Web Encryption and JSON Web Signature Nim= bus-JWT=20 [53], in Section 5.3. ... Platform for Experimental Analysis: We investigate the practicality and=20 performance of our attacks on JWE and JWS by applying them to the Nimbus-= JWT=20 library [53]. Nimbus-JWT is a Java implementation of JSON Web Encryption = (JWE)=20 and JSON Web Signature (JWS), developed by NimbusDS to support their Clou= d=20 Identity management portfolio. Even though Nimbus-JWT claims to implement version 02 of the JWE standard= draft,=20 it still supports usage of AESCBC (without MAC), which was available in v= ersion=20 01, but not in version 02 or any subsequent versions. ... 5.2.3 Evaluation We evaluated performance of our attacks against both WSS4J and Nimbus-JWT= =2E We=20 =EF=AC=81rst used the libraries to generate valid messages containing AES= -GCM=20 ciphertexts. Then we modi=EF=AC=81ed the algorithm parameters in the mess= ages, forcing=20 the receiver to process the ciphertexts using AES-CBC, and executed the a= ttack=20 described in Algorithm 1. The required ciphertext validity oracles were b= ased on=20 error messages generated by the libraries. ... Experimental Results. In order to assess the practicability and performan= ce of=20 the attack, we implemented Bleichenbacher=E2=80=99s attack on XML Encrypt= ion [13, 38]=20 and applied it to the Nimbus-JWT library. The PKCS#1 v1.5 validity oracle= was=20 provided by exceptions thrown by this library.11 ... 11 In practice one would instead use the more elaborate attack techniques= of [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid. ... [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based= on the=20 RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in Crypt= ology =E2=80=93=20 CRYPTO=E2=80=9998, volume 1462 of Lecture Notes in Computer Science, page= s 1=E2=80=9312.=20 Springer, Aug. 1998. [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2=80=99s a= ttack strikes=20 again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung,= =20 editors, Computer Security - ESORICS 2012 - 17th European Symposium on Re= search=20 in Computer Security, Pisa, Italy, September 10-14, 2012. Proceedings, LN= CS.=20 Springer, 2012. [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012.=20 https://bitbucket.org/nimbusds/nimbus-jwt. ### [1] One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/0= 8/BackwardsCompatibilityAttacks.pdf [2] Key Reuse: Theory and Practice http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf HTH, =3DJeffH From Michael.Jones@microsoft.com Thu Mar 14 08:49:18 2013 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 F117111E810D for ; Thu, 14 Mar 2013 08:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.201 X-Spam-Level: X-Spam-Status: No, score=0.201 tagged_above=-999 required=5 tests=[AWL=2.200, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] 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 vbUN0MpNLZ4B for ; Thu, 14 Mar 2013 08:49:15 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id C872921F90B9 for ; Thu, 14 Mar 2013 08:49:14 -0700 (PDT) Received: from BL2FFO11FD019.protection.gbl (10.173.161.204) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.620.12; Thu, 14 Mar 2013 15:49:11 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD019.mail.protection.outlook.com (10.173.161.37) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Thu, 14 Mar 2013 15:49:11 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 14 Mar 2013 15:48:50 +0000 From: Mike Jones To: =JeffH , IETF JOSE WG Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: AQHOIMcJuSsbRYdr2ECpwvNyOzG9WZilVKfw Date: Thu, 14 Mar 2013 15:48:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5141E9D6.6030003@KingsMountain.com> In-Reply-To: <5141E9D6.6030003@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.34] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(51704002)(243025002)(189002)(13464002)(377454001)(46102001)(47446002)(74502001)(50466001)(4396001)(66066001)(54356001)(20776003)(55846006)(74662001)(69226001)(76482001)(49866001)(47976001)(80022001)(31966008)(79102001)(47776003)(51856001)(77982001)(63696002)(16406001)(23676001)(59766001)(33656001)(47736001)(54316002)(5343655001)(44976002)(56816002)(56776001)(50986001)(53806001)(65816001)(15202345001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB040; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0785459C39 Cc: Juraj Somorovsky Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 15:49:19 -0000 SSBiZWxpZXZlIHRoYXQgdGhlc2UgYXR0YWNrcyBhcmUgb25seSBwb3NzaWJsZSBvbiBlbmNyeXB0 aW9uIHdpdGhvdXQgaW50ZWdyaXR5LCB3aGljaCBpbiB0dXJuIHdhcyBvbmx5IHBvc3NpYmxlLCBi ZWNhdXNlIE5pbWJ1cy1KV1QgY29udGludWVkIHRvIGltcGxlbWVudCBlbmNyeXB0aW9uIGFsZ29y aXRobXMgd2l0aG91dCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4gIFNvbWVvbmUgc2hvdWxkIHBsZWFz ZSBjb3JyZWN0IG1lIGlmIEknbSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBzaXR1YXRpb24uDQoNCkFz IG1vc3Qgb2YgeW91IGtub3csIEpXRSBub3cgb25seSBhbGxvd3MgYXV0aGVudGljYXRlZCBlbmNy eXB0aW9uIGFsZ29yaXRobXMgdG8gYmUgdXNlZCwgZm9yIHJlYXNvbnMgZXhhY3RseSBzdWNoIGFz IHRoZXNlLg0KDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogam9zZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgPUplZmZIDQpTZW50OiBUaHVyc2RheSwgTWFyY2ggMTQsIDIwMTMgODoxNyBB TQ0KVG86IElFVEYgSk9TRSBXRw0KQ2M6IEp1cmFqIFNvbW9yb3Zza3kNClN1YmplY3Q6IFtqb3Nl XSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhdHRhY2sgb24gSldUIGltcGxzICh3YXM6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTAyLnR4dCkNCg0KYmFj ayBvbiBGcmksIDYgSnVsIDIwMTIgIE1pa2UgSm9uZXMgc2FpZDoNCiA+DQogPiBMb29raW5nIGF0 IHRoaXMgYWdhaW4sIGl0IHNlZW1zIHRvIG1lIHRoYXQgYmVjYXVzZSBKV0UgcHJvdmlkZXMgaW50 ZWdyaXR5ICA+IHByb3RlY3Rpb24gZm9yIHRoZSBhbGdvcml0aG0sIGl0IHNob3VsZCBiZSBpbXBv c3NpYmxlIGZvciB5b3UgdG8gcmVwbGFjZSAgPiAiUlNBLU9BRVAiIHdpdGggIlJTQTFfNSIgaW4g dGhlIGhlYWRlciBiZWNhdXNlIHRoZW4gdGhlIGludGVncml0eSBjaGVjayB3aWxsICA+IGZhaWwu ICBUaHVzLCB0aGUgYXR0YWNrIHRoYXQgeW91IGRlc2NyaWJlIGJlbG93IGlzIHByZXZlbnRlZCBi eSB0aGUgaW50ZWdyaXR5ICA+IHByb3RlY3Rpb24gb2YgdGhlIGhlYWRlci4NCiA+DQogPiBIZW5j ZSwgY29ycmVjdCBKV0UgaW1wbGVtZW50YXRpb25zIGRvIG5vIHByb3ZpZGUgdGhlIE9BRVAgZGVj cnlwdGlvbiBvcmFjbGUgID4gdGhhdCB5b3UgZGVzY3JpYmUuICBIb3dldmVyIGlmIEknbSBtaXNz aW5nIHNvbWV0aGluZywgcGxlYXNlIHBvaW50IGl0IG91dCB0byAgPiBtZSwgc2luY2UgaWYgdGhl cmUncyBhbiBpc3N1ZSwgSSdkIGxpa2UgdG8gdW5kZXJzdGFuZCBpdCBhbmQgaG93IHRvIG1pdGln YXRlICA+IGl0Lg0KDQpqdXN0IGZ5aS9md2l3Li4uYXBvbG9naWVzIGlmIHRoaXMgaGFzIGFscmVh ZHkgYmVlbiBmb2xsb3dlZCB1cCBvbiwgYnV0IEkgZGlkbid0IGZpbmQgZnVydGhlciBkaXNjdXNz aW9uIG9mIHRoaXMgYWZ0ZXIgdGhlIGFib3ZlLXF1b3RlZCBtc2cuLi4NCg0KSnVyYWogU29tb3Jv dnNreSBldCBhbCdzIE5EU1MtMjAxMyAiQmFja3dhcmRzIENvbXBhdGliaWxpdHkgKEJDKSBhdHRh Y2tzIiBwYXBlciBbMV0gaXMgbm93IG91dCwgYW5kIGl0IG1heSBoZWxwIGFuc3dlciB0aGUgYWJv dmUgcXVlc3Rpb25zLiBUaGVyZSdzIGFsc28gS2VubnkgUGF0dGVyc29uJ3MgdGFsayBbMl0gZnJv bSB0aGUgcmVjZW50IFdvcmtzaG9wIG9uIFJlYWwtV29ybGQgQ3J5cHRvZ3JhcGh5Lg0KDQpJdCBz ZWVtcywgZnJvbSBhbiBhZG1pdHRlZGx5IGN1cnNvcnkgZ2xhbmNlIGF0IGJvdGggZHJhZnQtaWV0 Zi1qb3NlLWpzb24td2ViLWFsZ29yaXRobXMgKC0wOCkgYW5kIHRoZSBhYm92ZSBwYXBlci9zbGlk ZXMsIHRoYXQgcGVyaGFwcyB0aGVyZSBzaG91bGQgYmUgbW9yZSBpbXBsZW1lbnRhdGlvbiBhZHZp Y2UgYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGluIChhdCBsZWFzdCkgdGhlIC1qc29uLXdl Yi1hbGdvcml0aG1zIHNwZWMuDQoNCkhlcmUncyBzb21lIGV4Y2VycHRzIGZyb20gdGhlIHBhcGVy IGZvciBjb250ZXh0Li4uDQogICAgICAgICAgICAgICAgLi4uDQpJbiB0aGUgcHVibGljLWtleSBz ZXR0aW5nLCB3ZSBzaG93IGhvdyB0aGUgd2VsbC1rbm93biBhdHRhY2sgb2YgQmxlaWNoZW5iYWNo ZXIgWzEzXSBnaXZlcyByaXNlIHRvIGEgQkMgW0JhY2t3YXJkcyBDb21wYXRpYmlsaXR5XSBhdHRh Y2sgdGhhdCBhbGxvd3MgYW4gYXR0YWNrZXIgdG8gZGVjcnlwdCBjaXBoZXJ0ZXh0cyBvZiBQS0NT IzEgdjIuMCBlbmNyeXB0aW9uIGluIGJvdGggWE1MIEVuY3J5cHRpb24gWzI3XSBhbmQgSlNPTiBX ZWIgRW5jcnlwdGlvbiBbNDJdLCBhbmQgdG8gZm9yZ2Ugc2lnbmF0dXJlcyBmb3IgYXJiaXRyYXJ5 IG1lc3NhZ2VzIGluIFhNTCBTaWduYXR1cmUgWzMwXSBhbmQgSlNPTiBXZWIgU2lnbmF0dXJlIFs0 MV0uIFRoZSBhdHRhY2sgcHJpbmNpcGxlIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuIFdlIGZ1 cnRoZXJtb3JlIHJlcG9ydCBvbiBvdXIgZXhwZXJpbWVudGFsIHJlc3VsdHMsIGV4ZWN1dGVkIGFn YWluc3QgdGhlIEphdmEgaW1wbGVtZW50YXRpb24gb2YgSlNPTiBXZWIgRW5jcnlwdGlvbiBhbmQg SlNPTiBXZWIgU2lnbmF0dXJlIE5pbWJ1cy1KV1QgWzUzXSwgaW4gU2VjdGlvbiA1LjMuDQogICAg ICAgICAgICAgICAgLi4uDQoNClBsYXRmb3JtIGZvciBFeHBlcmltZW50YWwgQW5hbHlzaXM6IFdl IGludmVzdGlnYXRlIHRoZSBwcmFjdGljYWxpdHkgYW5kIHBlcmZvcm1hbmNlIG9mIG91ciBhdHRh Y2tzIG9uIEpXRSBhbmQgSldTIGJ5IGFwcGx5aW5nIHRoZW0gdG8gdGhlIE5pbWJ1cy1KV1QgbGli cmFyeSBbNTNdLiBOaW1idXMtSldUIGlzIGEgSmF2YSBpbXBsZW1lbnRhdGlvbiBvZiBKU09OIFdl YiBFbmNyeXB0aW9uIChKV0UpIGFuZCBKU09OIFdlYiBTaWduYXR1cmUgKEpXUyksIGRldmVsb3Bl ZCBieSBOaW1idXNEUyB0byBzdXBwb3J0IHRoZWlyIENsb3VkIElkZW50aXR5IG1hbmFnZW1lbnQg cG9ydGZvbGlvLg0KDQpFdmVuIHRob3VnaCBOaW1idXMtSldUIGNsYWltcyB0byBpbXBsZW1lbnQg dmVyc2lvbiAwMiBvZiB0aGUgSldFIHN0YW5kYXJkIGRyYWZ0LCBpdCBzdGlsbCBzdXBwb3J0cyB1 c2FnZSBvZiBBRVNDQkMgKHdpdGhvdXQgTUFDKSwgd2hpY2ggd2FzIGF2YWlsYWJsZSBpbiB2ZXJz aW9uIDAxLCBidXQgbm90IGluIHZlcnNpb24gMDIgb3IgYW55IHN1YnNlcXVlbnQgdmVyc2lvbnMu DQogICAgICAgICAgICAgICAgLi4uDQoNCjUuMi4zIEV2YWx1YXRpb24NCg0KV2UgZXZhbHVhdGVk IHBlcmZvcm1hbmNlIG9mIG91ciBhdHRhY2tzIGFnYWluc3QgYm90aCBXU1M0SiBhbmQgTmltYnVz LUpXVC4gV2Ug76yBcnN0IHVzZWQgdGhlIGxpYnJhcmllcyB0byBnZW5lcmF0ZSB2YWxpZCBtZXNz YWdlcyBjb250YWluaW5nIEFFUy1HQ00gY2lwaGVydGV4dHMuIFRoZW4gd2UgbW9kae+sgWVkIHRo ZSBhbGdvcml0aG0gcGFyYW1ldGVycyBpbiB0aGUgbWVzc2FnZXMsIGZvcmNpbmcgdGhlIHJlY2Vp dmVyIHRvIHByb2Nlc3MgdGhlIGNpcGhlcnRleHRzIHVzaW5nIEFFUy1DQkMsIGFuZCBleGVjdXRl ZCB0aGUgYXR0YWNrIGRlc2NyaWJlZCBpbiBBbGdvcml0aG0gMS4gVGhlIHJlcXVpcmVkIGNpcGhl cnRleHQgdmFsaWRpdHkgb3JhY2xlcyB3ZXJlIGJhc2VkIG9uIGVycm9yIG1lc3NhZ2VzIGdlbmVy YXRlZCBieSB0aGUgbGlicmFyaWVzLg0KICAgICAgICAgICAgICAgIC4uLg0KDQpFeHBlcmltZW50 YWwgUmVzdWx0cy4gSW4gb3JkZXIgdG8gYXNzZXNzIHRoZSBwcmFjdGljYWJpbGl0eSBhbmQgcGVy Zm9ybWFuY2Ugb2YgdGhlIGF0dGFjaywgd2UgaW1wbGVtZW50ZWQgQmxlaWNoZW5iYWNoZXLigJlz IGF0dGFjayBvbiBYTUwgRW5jcnlwdGlvbiBbMTMsIDM4XSBhbmQgYXBwbGllZCBpdCB0byB0aGUg TmltYnVzLUpXVCBsaWJyYXJ5LiBUaGUgUEtDUyMxIHYxLjUgdmFsaWRpdHkgb3JhY2xlIHdhcyBw cm92aWRlZCBieSBleGNlcHRpb25zIHRocm93biBieSB0aGlzIGxpYnJhcnkuMTENCiAgICAgICAg ICAgICAgICAuLi4NCg0KMTEgSW4gcHJhY3RpY2Ugb25lIHdvdWxkIGluc3RlYWQgdXNlIHRoZSBt b3JlIGVsYWJvcmF0ZSBhdHRhY2sgdGVjaG5pcXVlcyBvZiBbMzhdIHRvIGRldGVybWluZSB3aGV0 aGVyIGEgZ2l2ZW4gY2lwaGVydGV4dCBpcyBQS0NTIzEgdjEuNSB2YWxpZC4NCiAgICAgICAgICAg ICAgICAuLi4NCg0KWzEzXSBELiBCbGVpY2hlbmJhY2hlci4gQ2hvc2VuIGNpcGhlcnRleHQgYXR0 YWNrcyBhZ2FpbnN0IHByb3RvY29scyBiYXNlZCBvbiB0aGUgUlNBIGVuY3J5cHRpb24gc3RhbmRh cmQgUEtDUyMxLiBJbiBILiBLcmF3Y3p5aywgZWRpdG9yLCBBZHZhbmNlcyBpbiBDcnlwdG9sb2d5 IOKAkyBDUllQVE/igJk5OCwgdm9sdW1lIDE0NjIgb2YgTGVjdHVyZSBOb3RlcyBpbiBDb21wdXRl ciBTY2llbmNlLCBwYWdlcyAx4oCTMTIuIA0KU3ByaW5nZXIsIEF1Zy4gMTk5OC4NCg0KWzM4XSBU LiBKYWdlciwgUy4gU2NoaW56ZWwsIGFuZCBKLiBTb21vcm92c2t5LiBCbGVpY2hlbmJhY2hlcuKA mXMgYXR0YWNrIHN0cmlrZXMNCmFnYWluOiBicmVha2luZyBQS0NTIzEgdjEuNSBpbiBYTUwgRW5j cnlwdGlvbi4gSW4gUy4gRm9yZXN0aSBhbmQgTS4gWXVuZywgZWRpdG9ycywgQ29tcHV0ZXIgU2Vj dXJpdHkgLSBFU09SSUNTIDIwMTIgLSAxN3RoIEV1cm9wZWFuIFN5bXBvc2l1bSBvbiBSZXNlYXJj aCBpbiBDb21wdXRlciBTZWN1cml0eSwgUGlzYSwgSXRhbHksIFNlcHRlbWJlciAxMC0xNCwgMjAx Mi4gUHJvY2VlZGluZ3MsIExOQ1MuIA0KU3ByaW5nZXIsIDIwMTIuDQoNCls1M10gTmltYnVzIERp cmVjdG9yeSBTZXJ2aWNlcy4gTmltYnVzIEpTT04gV2ViIFRva2VuLCBNYXkgMjAxMi4gDQpodHRw czovL2JpdGJ1Y2tldC5vcmcvbmltYnVzZHMvbmltYnVzLWp3dC4NCg0KIyMjDQoNClsxXSBPbmUg QmFkIEFwcGxlOiBCYWNrd2FyZHMgQ29tcGF0aWJpbGl0eSBBdHRhY2tzIG9uDQogIFN0YXRlLW9m LXRoZS1BcnQgQ3J5cHRvZ3JhcGh5DQpodHRwOi8vd3d3Lm5kcy5ydWhyLXVuaS1ib2NodW0uZGUv bWVkaWEvbmRzL3Zlcm9lZmZlbnRsaWNodW5nZW4vMjAxMy8wMy8wOC9CYWNrd2FyZHNDb21wYXRp YmlsaXR5QXR0YWNrcy5wZGYNCg0KWzJdIEtleSBSZXVzZTogVGhlb3J5IGFuZCBQcmFjdGljZQ0K aHR0cDovL2NyeXB0by5zdGFuZm9yZC5lZHUvUmVhbFdvcmxkQ3J5cHRvL3NsaWRlcy9rZW5ueS5w ZGYNCg0KDQpIVEgsDQoNCj1KZWZmSA0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCmpvc2UgbWFpbGluZyBsaXN0DQpqb3NlQGlldGYub3JnDQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg== From odonoghue@isoc.org Thu Mar 14 09:04:21 2013 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 4A74C21F90E2 for ; Thu, 14 Mar 2013 09:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 ivpleT0J-UyQ for ; Thu, 14 Mar 2013 09:04:20 -0700 (PDT) Received: from smtp134.ord.emailsrvr.com (smtp134.ord.emailsrvr.com [173.203.6.134]) by ietfa.amsl.com (Postfix) with ESMTP id D352C21F90DF for ; Thu, 14 Mar 2013 09:04:20 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.ord1a.emailsrvr.com (SMTP Server) with ESMTP id 7889F19809E for ; Thu, 14 Mar 2013 12:04:20 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp13.relay.ord1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 4B06E198108 for ; Thu, 14 Mar 2013 12:04:20 -0400 (EDT) Message-ID: <5141F506.5000900@isoc.org> Date: Thu, 14 Mar 2013 12:04:22 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130216 Thunderbird/17.0.3 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] JOSE WG summary for IETF86 X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:04:21 -0000 The JOSE WG met on Wednesday at 9:00 am EST. The four core documents (JWA, JWE, JWK, and JWS) were all updated and discussed as a set. The remaining open issues were discussed and either closed or definitive steps identified to resolve them. Updated drafts are expected in the near future with one more round of updates addressing the remaining issues expected prior to WGLC. In addition, drafts on use cases, JSON serialization, JSON Private and Symmetric keys were adopted pending approval of the updated charter. Drafts on using JSON to protect keys and a JSON Web Key for PKIX certs were discussed, and a presentation on a unified view for keys was discussed. An updated charter has been forwarded to the AD for IESG review/approval. From bcampbell@pingidentity.com Thu Mar 14 09:39:37 2013 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 B665E11E8135 for ; Thu, 14 Mar 2013 09:39:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.676 X-Spam-Level: X-Spam-Status: No, score=-5.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 OoU8kSTv7IQk for ; Thu, 14 Mar 2013 09:39:33 -0700 (PDT) Received: from na3sys009aog130.obsmtp.com (na3sys009aog130.obsmtp.com [74.125.149.143]) by ietfa.amsl.com (Postfix) with ESMTP id 90C2321F8D19 for ; Thu, 14 Mar 2013 09:39:33 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob130.postini.com ([74.125.148.12]) with SMTP ID DSNKUUH9RKz8OurtweaMdHXeb2oS+5W3TQKq@postini.com; Thu, 14 Mar 2013 09:39:33 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so12628102obb.10 for ; Thu, 14 Mar 2013 09:39:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=ye5MSzdYXiuiDUfHulQVS30uS65ju9Jd+hzEiAcjFw0=; b=J9BCloC4MoZhw1I5Rv457fzeekSTtf0Pxs9dRNBNlcma3yxAeEmVl/isjXW7LXK/8w ynYDRSaJ2vJaqn1XXJ8/s3Ra2DZbHSLNv4ggGuFx/WJFulnHVEnkzlFuUH3bUsf/Thxg 2U8cVPzqXIhBaTWzb5hWlil6u26HlBx97fJpLzkE87khmLgGaOyJfA4wAAH1mDQQ7BZC BjEtz1UzNowI/Ypil98cSlhyb+gz6Y+m9p+qO5Gy3n/vjQqgm9U9Tkx0h0nPs6Ko7APY B3QcIWz4G4il0QVtfFinID2MHOjr/ZYuTZ/4PbzVN80qrqge/iq32rYJbd+2E9IOWfom LtZA== X-Received: by 10.50.213.41 with SMTP id np9mr2765999igc.79.1363279154828; Thu, 14 Mar 2013 09:39:14 -0700 (PDT) X-Received: by 10.50.213.41 with SMTP id np9mr2765975igc.79.1363279154570; Thu, 14 Mar 2013 09:39:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Thu, 14 Mar 2013 09:38:44 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> From: Brian Campbell Date: Thu, 14 Mar 2013 12:38:44 -0400 Message-ID: To: Mike Jones Content-Type: multipart/alternative; boundary=f46d04462eb6bd05ac04d7e529ce X-Gm-Message-State: ALoCoQnLQPZiIrimHM5cF98SRYFBruznAe5fn0rshl/oFMpkzZuD/WWBgU6i8EeDbWbXZeItj012VV/hz+9gyhAl63s4HiQbdzbdpeOFlslqSwtfi+ROZxVk0DB+4UKs5uZlxjb/WSMS Cc: IETF JOSE WG , =JeffH , Juraj Somorovsky Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 16:39:37 -0000 --f46d04462eb6bd05ac04d7e529ce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable But the integrity protected encryption happens using the key that's been wrapped/encrypted using "RSA-OAEP" or "RSA1_5". That key needs to be unwrapped/decrypted before any of the integrity checks even come into play, which is where the attack takes place. So I don't see how the AEAD (or composite AEAD like) algorithms help for preventing Bleichenbacher attacks on RSA1_5 or BC attacks on RSA-OAEP to RSA1_5? (the general disclaimer correcting me, if I'm wrong, applies) On Thu, Mar 14, 2013 at 11:48 AM, Mike Jones w= rote: > I believe that these attacks are only possible on encryption without > integrity, which in turn was only possible, because Nimbus-JWT continued = to > implement encryption algorithms without integrity protection. Someone > should please correct me if I'm misunderstanding the situation. > > As most of you know, JWE now only allows authenticated encryption > algorithms to be used, for reasons exactly such as these. > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > =3DJeffH > Sent: Thursday, March 14, 2013 8:17 AM > To: IETF JOSE WG > Cc: Juraj Somorovsky > Subject: [jose] backwards compatibility attack on JWT impls (was: I-D > Action: draft-ietf-jose-json-web-algorithms-02.txt) > > back on Fri, 6 Jul 2012 Mike Jones said: > > > > Looking at this again, it seems to me that because JWE provides > integrity > protection for the algorithm, it should be impossible for yo= u > to replace > "RSA-OAEP" with "RSA1_5" in the header because then the > integrity check will > fail. Thus, the attack that you describe below i= s > prevented by the integrity > protection of the header. > > > > Hence, correct JWE implementations do no provide the OAEP decryption > oracle > that you describe. However if I'm missing something, please > point it out to > me, since if there's an issue, I'd like to understand = it > and how to mitigate > it. > > just fyi/fwiw...apologies if this has already been followed up on, but I > didn't find further discussion of this after the above-quoted msg... > > Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" > paper [1] is now out, and it may help answer the above questions. There's > also Kenny Patterson's talk [2] from the recent Workshop on Real-World > Cryptography. > > It seems, from an admittedly cursory glance at both > draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, tha= t > perhaps there should be more implementation advice and security > considerations in (at least) the -json-web-algorithms spec. > > Here's some excerpts from the paper for context... > ... > In the public-key setting, we show how the well-known attack of > Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] attack > that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 encryption = in > both XML Encryption [27] and JSON Web Encryption [42], and to forge > signatures for arbitrary messages in XML Signature [30] and JSON Web > Signature [41]. The attack principle is described in Section 4. We > furthermore report on our experimental results, executed against the Java > implementation of JSON Web Encryption and JSON Web Signature Nimbus-JWT > [53], in Section 5.3. > ... > > Platform for Experimental Analysis: We investigate the practicality and > performance of our attacks on JWE and JWS by applying them to the > Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON Web > Encryption (JWE) and JSON Web Signature (JWS), developed by NimbusDS to > support their Cloud Identity management portfolio. > > Even though Nimbus-JWT claims to implement version 02 of the JWE standard > draft, it still supports usage of AESCBC (without MAC), which was availab= le > in version 01, but not in version 02 or any subsequent versions. > ... > > 5.2.3 Evaluation > > We evaluated performance of our attacks against both WSS4J and Nimbus-JWT= . > We =EF=AC=81rst used the libraries to generate valid messages containing = AES-GCM > ciphertexts. Then we modi=EF=AC=81ed the algorithm parameters in the mess= ages, > forcing the receiver to process the ciphertexts using AES-CBC, and execut= ed > the attack described in Algorithm 1. The required ciphertext validity > oracles were based on error messages generated by the libraries. > ... > > Experimental Results. In order to assess the practicability and > performance of the attack, we implemented Bleichenbacher=E2=80=99s attack= on XML > Encryption [13, 38] and applied it to the Nimbus-JWT library. The PKCS#1 > v1.5 validity oracle was provided by exceptions thrown by this library.11 > ... > > 11 In practice one would instead use the more elaborate attack techniques > of [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid. > ... > > [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based > on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances i= n > Cryptology =E2=80=93 CRYPTO=E2=80=9998, volume 1462 of Lecture Notes in C= omputer Science, > pages 1=E2=80=9312. > Springer, Aug. 1998. > > [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2=80=99s a= ttack > strikes > again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung, > editors, Computer Security - ESORICS 2012 - 17th European Symposium on > Research in Computer Security, Pisa, Italy, September 10-14, 2012. > Proceedings, LNCS. > Springer, 2012. > > [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. > https://bitbucket.org/nimbusds/nimbus-jwt. > > ### > > [1] One Bad Apple: Backwards Compatibility Attacks on > State-of-the-Art Cryptography > > http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/0= 8/BackwardsCompatibilityAttacks.pdf > > [2] Key Reuse: Theory and Practice > http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf > > > HTH, > > =3DJeffH > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d04462eb6bd05ac04d7e529ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
But the integrity protected encryption happens using the k= ey that's been wrapped/encrypted using "RSA-OAEP" or "RS= A1_5".=C2=A0 That key needs to be unwrapped/decrypted before any of th= e integrity checks even come into play, which is where the attack takes pla= ce. So I don't see how the AEAD (or composite AEAD like) algorithms hel= p for preventing Bleichenbacher attacks on RSA1_5 or BC attacks on RSA-OAEP= to RSA1_5?

(the general disclaimer correcting me, if I'm wrong, applies)<= br>


On Thu, Mar 14, 2013 at 11:48 AM, Mike Jones <Michael.Jones@mi= crosoft.com> wrote:
I believe that these attacks are only possib= le on encryption without integrity, which in turn was only possible, becaus= e Nimbus-JWT continued to implement encryption algorithms without integrity= protection. =C2=A0Someone should please correct me if I'm misunderstan= ding the situation.

As most of you know, JWE now only allows authenticated encryption algorithm= s to be used, for reasons exactly such as these.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike

-----Original Message-----
From: jose-bounces@ietf.org [m= ailto:jose-bounces@ietf.org] O= n Behalf Of =3DJeffH
Sent: Thursday, March 14, 2013 8:17 AM
To: IETF JOSE WG
Cc: Juraj Somorovsky
Subject: [jose] backwards compatibility attack on JWT impls (was: I-D Actio= n: draft-ietf-jose-json-web-algorithms-02.txt)

back on Fri, 6 Jul 2012 =C2=A0Mike Jones said:
=C2=A0>
=C2=A0> Looking at this again, it seems to me that because JWE provides = integrity =C2=A0> protection for the algorithm, it should be impossible = for you to replace =C2=A0> "RSA-OAEP" with "RSA1_5" = in the header because then the integrity check will =C2=A0> fail. =C2=A0= Thus, the attack that you describe below is prevented by the integrity =C2= =A0> protection of the header.
=C2=A0>
=C2=A0> Hence, correct JWE implementations do no provide the OAEP decryp= tion oracle =C2=A0> that you describe. =C2=A0However if I'm missing = something, please point it out to =C2=A0> me, since if there's an is= sue, I'd like to understand it and how to mitigate =C2=A0> it.

just fyi/fwiw...apologies if this has already been followed up on, but I di= dn't find further discussion of this after the above-quoted msg...

Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) a= ttacks" paper [1] is now out, and it may help answer the above questio= ns. There's also Kenny Patterson's talk [2] from the recent Worksho= p on Real-World Cryptography.

It seems, from an admittedly cursory glance at both draft-ietf-jose-json-we= b-algorithms (-08) and the above paper/slides, that perhaps there should be= more implementation advice and security considerations in (at least) the -= json-web-algorithms spec.

Here's some excerpts from the paper for context...
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
In the public-key setting, we show how the well-known attack of Bleichenbac= her [13] gives rise to a BC [Backwards Compatibility] attack that allows an= attacker to decrypt ciphertexts of PKCS#1 v2.0 encryption in both XML Encr= yption [27] and JSON Web Encryption [42], and to forge signatures for arbit= rary messages in XML Signature [30] and JSON Web Signature [41]. The attack= principle is described in Section 4. We furthermore report on our experime= ntal results, executed against the Java implementation of JSON Web Encrypti= on and JSON Web Signature Nimbus-JWT [53], in Section 5.3.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

Platform for Experimental Analysis: We investigate the practicality and per= formance of our attacks on JWE and JWS by applying them to the Nimbus-JWT l= ibrary [53]. Nimbus-JWT is a Java implementation of JSON Web Encryption (JW= E) and JSON Web Signature (JWS), developed by NimbusDS to support their Clo= ud Identity management portfolio.

Even though Nimbus-JWT claims to implement version 02 of the JWE standard d= raft, it still supports usage of AESCBC (without MAC), which was available = in version 01, but not in version 02 or any subsequent versions.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

5.2.3 Evaluation

We evaluated performance of our attacks against both WSS4J and Nimbus-JWT. = We =EF=AC=81rst used the libraries to generate valid messages containing AE= S-GCM ciphertexts. Then we modi=EF=AC=81ed the algorithm parameters in the = messages, forcing the receiver to process the ciphertexts using AES-CBC, an= d executed the attack described in Algorithm 1. The required ciphertext val= idity oracles were based on error messages generated by the libraries.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

Experimental Results. In order to assess the practicability and performance= of the attack, we implemented Bleichenbacher=E2=80=99s attack on XML Encry= ption [13, 38] and applied it to the Nimbus-JWT library. The PKCS#1 v1.5 va= lidity oracle was provided by exceptions thrown by this library.11
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

11 In practice one would instead use the more elaborate attack techniques o= f [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...

[13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based o= n the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in C= ryptology =E2=80=93 CRYPTO=E2=80=9998, volume 1462 of Lecture Notes in Comp= uter Science, pages 1=E2=80=9312.
Springer, Aug. 1998.

[38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2=80=99s att= ack strikes
again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung, e= ditors, Computer Security - ESORICS 2012 - 17th European Symposium on Resea= rch in Computer Security, Pisa, Italy, September 10-14, 2012. Proceedings, = LNCS.
Springer, 2012.

[53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012.
htt= ps://bitbucket.org/nimbusds/nimbus-jwt.

###

[1] One Bad Apple: Backwards Compatibility Attacks on
=C2=A0 State-of-the-Art Cryptography
http://www.= nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCo= mpatibilityAttacks.pdf

[2] Key Reuse: Theory and Practice
http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf<= /a>


HTH,

=3DJeffH



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d04462eb6bd05ac04d7e529ce-- From rlb@ipv.sx Thu Mar 14 10:48:08 2013 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 C597D11E815B for ; Thu, 14 Mar 2013 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.313 X-Spam-Level: X-Spam-Status: No, score=-1.313 tagged_above=-999 required=5 tests=[AWL=-0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_110=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 dBeVquQERkVv for ; Thu, 14 Mar 2013 10:48:06 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9140D11E814D for ; Thu, 14 Mar 2013 10:48:06 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so2555120oag.21 for ; Thu, 14 Mar 2013 10:48:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=iVNDJ+twLfsT6O9ifDVIrb7d+AgaPmK/Dz5lYcmohJw=; b=k3r79On07wNHl480N12oATwTFse2ZJIlfB+aJ/xLhzRBAWikXeS8cWwFVGtwAqTwS7 uwe/ezzsr82aeUVgeXdvc0em5aK+P67ZUKasi3m2bNFEA3W7q1sk+GGWs9S/q+IP8s1t fq1hKJXCpO9UuPCTTcyGdizSgUXSggRxzBDv7TfCCG9DrlzqzPjb5CX0NZL1xYwgeE7/ 8PGhSIcNUpVhHsjWnqXvQYcbfzvUggpmObhLYb1QKujgzrnAUgvNNDIU59lZcPzDB7Uj RRNm9rmqW0JIaYcHExEuTAxsp9CbasS17ALoQxjartG66NiVw06ZTSX6vsX57DwjSAfQ ZtGg== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr1567956oea.130.1363283285898; Thu, 14 Mar 2013 10:48:05 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Thu, 14 Mar 2013 10:48:05 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> Date: Thu, 14 Mar 2013 13:48:05 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8fb20318fc135804d7e61fa1 X-Gm-Message-State: ALoCoQlLziX0yBz+9zxp4C1YH3veON5tRluQoavgyb1sNZrhgu3lsffC/p621e3UKr//+WpLgBI5 Cc: John Bradley , Mike Jones , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 14 Mar 2013 17:48:08 -0000 --e89a8fb20318fc135804d7e61fa1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On JS binary: The future is now, in most major browsers. -----BEGIN----- var x =3D new Uint8Array([1,2,3,4]); var y =3D new Uint8Array([5,6,7,8]); // Concatenate var z =3D new Uint8Array( x.byteLength + y.byteLength ); z.set(x, 0); z.set(y, x.byteLength); // z =3D=3D [1,2,3,4,5,6,7,8] -----END----- For example: GCM implementation in javascript: On Tue, Mar 12, 2013 at 8:58 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > +1 for using the McGrew draft and RFC 5116 interface.**** > > ** ** > > The JOSE-specific A128CBC+HS256 algorithm looks like a valiant attempt to > hide some of the binary processing involved with crypto =96 which has alw= ays > been defined on bytes, not text. But the result is a poor chimera.**** > > ** ** > > For instance, JWE includes the IV as part of the additional authenticated > data (AAD). No other AEAD system is defined like this. Everywhere else th= e > IV/nonce and AAD are separate. I hope that doesn=92t adversely affect the > crypto properties, but it does raise questions about whether it is > important for some crypto reason.**** > > ** ** > > Every AEAD algorithm treats the AAD and ciphertext as bytes arrays with n= o > restrictions on their content (only restrictions on their length). Hence > they use some binary packing when processing both to calculate an integri= ty > check. EXCEPT the JOSE-specific AEAD algorithms (A128CBC+HS256 and > A256CBC+HS512). They force base64url-encoding **inside** the AEAD > algorithm so they can use a text dot =93.=94 as a separator.**** > > ** ** > > While A128CBC+HS256 is implemented by hand in JOSE-specific code using AE= S > and HMAC primitives the problems with this chimera are mainly hidden. > However, I don=92t believe any generic AEAD interface can ever handle thi= s > JOSE-specific algorithm efficiently.**** > > ** ** > > The =93extra work=94 of adopting the AEAD encoding/decoding conventions i= s: > concatenating byte arrays; and taking a known-length prefix and suffix fr= om > a byte array. You cannot get much simpler. It can only be an annoyance fo= r > a language that is not byte-array-friendly, but even such a language will > have to handle byte arrays at some point to interface with crypto.**** > > ** ** > > Even using the McGrew draft then separating the output into > IV/ciphertext/MAC to re-package as a JOSE message would be better than th= e > JOSE-specific A128CBC+HS256 and A256CBC+HS512.**** > > ** ** > > P.S. I think ECMAScript edition 6 is introducing support for byte arrays > so even hassle handling bytes in JavaScript should fade.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Mike Jones > *Sent:* Wednesday, 13 March 2013 8:06 AM > *To:* Peck, Michael A; John Bradley > *Cc:* Richard Barnes; jose@ietf.org > > *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving > CEK/CIK from CMK**** > > ** ** > > Possibly using the McGrew draft had been discussed before, but there was > strong push-back on it. It would change more than the CBC/HMAC > representation =96 it would change all the JWE representations, as it wou= ld > remove the Initialization Vector and Integrity Value fields, and instead > require all implementations to implement and apply the AEAD binary encodi= ng > and decoding conventions. Note that this would change AES-GCM too =96 no= t > just AES-CBC/HMAC.**** > > ** ** > > If commonly available crypto libraries implemented algorithms using the > AEAD encoding conventions I would have no problem with this. But in fact= , > they don=92t. I don=92t know of a single library in the attached set of > surveyed implementations that do. Thus, adopting the AEAD > encoding/decoding conventions would create extra work for all > implementations in practice =96 not make things simpler. It would only b= e > simpler if the existing crypto libraries implemented this standard > interface.**** > > ** ** > > We should therefore steer clear of this.**** > > ** ** > > Best wishes,*= * > ** > > -- Mike**** > > ** ** > > P.S. Jim Schaad also points out that CMS doesn=92t use the RFC 5116 > interface either.**** > > ** ** > > *From:* Peck, Michael A [mailto:mpeck@mitre.org ] > *Sent:* Tuesday, March 12, 2013 2:02 PM > *To:* John Bradley; Mike Jones > *Cc:* Richard Barnes; jose@ietf.org > *Subject:* RE: [jose] Concat KDF issues with ECDH-ES and for deriving > CEK/CIK from CMK**** > > ** ** > > I think that #2 actually reduces complexity for implementers.**** > > They can implement the RFC 5116 interface once (or eventually just invoke > a crypto library that implements it for them) =96 then use that > implementation for all protocols that use the RFC 5116 interface, not jus= t > JOSE, and know that the details of authenticated encryption have been tak= en > care of. **** > > ** ** > > Mike**** > > ** ** > > ** ** > > *From:* John Bradley [mailto:ve7jtb@ve7jtb.com ] > *Sent:* Tuesday, March 12, 2013 4:49 PM > *To:* Mike Jones > *Cc:* Richard Barnes; Peck, Michael A; jose@ietf.org > *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving > CEK/CIK from CMK**** > > ** ** > > Yes I have the recommendation to change from using a KDF to generate the > CEK and CIK from the CMK to concatenating the CEK and CIK together as in > the McGrew draft.**** > > ** ** > > I don't yet have a slide on the new/old issue of concatenating the tag to > the message body vs sending it in a separate field. **** > > ** ** > > If people want me to I can add it as well. Though I thought that was a > closed issue. **** > > ** ** > > John B.**** > > ** ** > > On 2013-03-12, at 4:19 PM, Mike Jones wrote= : > **** > > ** ** > > As previously extensively discussed, the McGrew draft does two things =96 > one helpful and one not:**** > > **** > > 1. It specifies using a key that is actually the concatenation of an > AES-CBC key and an HMAC SHA-2 key, rather than use of a KDF. That=92s go= od, > as it=92s simple for implementers.**** > > **** > > 2. It specifies that the initialization vector and integrity value be > concatenated with other values in particular ways, and conversely, how to > extract them when decrypting. That=92s not good, as it adds complexity f= or > implementers =96 especially when JWEs already utilize a straightforward > representation for these values, which doesn=92t require the binary > concatenation and extraction conventions specified by McGrew.**** > > **** > > I know that John Bradley is going to ask the question tomorrow whether we > should change to doing the first for our composite CBC+HMAC algorithms. = I > believe that doing the second would be counterproductive.**** > > **** > > -- Mike**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf O= f > *Richard Barnes > *Sent:* Tuesday, March 12, 2013 1:00 PM > *To:* Peck, Michael A > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving > CEK/CIK from CMK**** > > **** > > Actually, for everything but key agreement, we can just > use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys. We should not > be specifying key expansion here when we can avoid it.**** > > **** > > --Richard**** > > **** > > **** > > On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A wrote:= * > *** > > draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of > Concat KDF on the shared secret Z established by ECDH-ES.**** > > **** > > The draft allows for an empty PartyUInfo and PartyVInfo but that may not > be allowed by NIST SP 800-56A (where the Concat KDF is defined).**** > > The current (March 2007) version of NIST SP 800-56A requires =93At a > minimum, *PartyUInfo **shall *include *ID**U*, the identifier of party *U= *.=94 > and an equivalent requirement for PartyVInfo. (Page 46 of > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Ma= r08-2007.pdf > )**** > > The August 2012 draft update to NIST SP 800-56A requires =93At a minimum, > PartyUInfo shall include IDu, an identifier for party U, as a distinct it= em > of information.=94 and an equivalent requirement for PartyVInfo. (Page 59= of > http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) > My interpretation of this text (others may interpret it differently) is > that PartyUInfo and PartyVInfo can=92t be empty.**** > > **** > > Instead of using the Concat KDF, a more appropriate choice may be the KDF > described in NIST SP 800-56C and RFC 5869.**** > > Its requirements are not as strict. (SP 800-56C Page 13: =93If the > information is available, *Context **should *include the identifiers of > the parties who are deriving and/or using the derived keying material=94)= *** > * > > **** > > It would look something like this:**** > > **** > > Step 1 - Randomness Extraction:**** > > Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should suffice > for all of the current algorithms)**** > > **** > > Step 2 - Expansion Step:**** > > Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869 > with the same HMAC algorithm used in step 1 to produce needed keys from t= he > Key Derivation Key produced in step 1.**** > > The needed keys would depend on the values of alg and enc.**** > > If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit > key is needed (used to decrypt the CMK, which may then need to be split > into CEK/CIK).**** > > If alg is ECDH-ES, then the needed keys depend on =93enc=94:**** > > If enc is AES-GCM, a 128 bit key or 256 bit key is needed.**** > > If enc is one of the AEAD AES-CBC algorithms in > draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LE= N > is needed as it=92s then split into two by the AEAD algorithm.**** > > If enc is one of the current CBC+HMAC options in > draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK a= nd > a CIK. Counter Mode KDF could be invoked twice, with different labels ea= ch > time, or Counter Mode KDF could be invoked once to generate a big key whi= ch > would then be split into the CEK and CIK.**** > > **** > > Richard has already pointed out the issues with using the Concat KDF to > derive the CEK/CIK from the CMK. Instead, one option would be to use the > Expansion Step above: use the Counter Mode KDF with an HMAC to derive > necessary keys from the CMK. **** > > Even if we use encryption algorithms that combine the encryption and > integrity key such as the CBC+HMAC algorithms in > draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to tak= e > a smaller master key and create the combined encryption + integrity key > from it.**** > > **** > > **** > > Mike**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --e89a8fb20318fc135804d7e61fa1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On JS binary: The future is now, in most major browsers.

-----BEGIN-----
var x =3D new Uint8Array([1,2,3,4]);
va= r y =3D new Uint8Array([5,6,7,8]);
// Concatenate
var z= =3D new Uint8Array( x.byteLength + y.byteLength );
z.set(x, 0);<= /div>
z.set(y, x.byteLength);
// z =3D=3D [1,2,3,4,5,6,7,8]
<= div>-----END-----

For example: GCM implementation = in javascript:


On Tue, Mar 12, 2013 at 8:58 PM, Ma= nger, James H <James.H.Manger@team.telstra.com> wrote:

+1 for using = the McGrew draft and RFC 5116 interface.

=A0<= /p>

The JOSE-specific A128= CBC+HS256 algorithm looks like a valiant attempt to hide some of the binary= processing involved with crypto =96 which has always been defined on bytes= , not text. But the result is a poor chimera.

=A0<= /p>

For instance, JWE incl= udes the IV as part of the additional authenticated data (AAD). No other AE= AD system is defined like this. Everywhere else the IV/nonce and AAD are se= parate. I hope that doesn=92t adversely affect the crypto properties, but i= t does raise questions about whether it is important for some crypto reason= .

=A0<= /p>

Every AEAD algorithm t= reats the AAD and ciphertext as bytes arrays with no restrictions on their = content (only restrictions on their length). Hence they use some binary pac= king when processing both to calculate an integrity check. EXCEPT the JOSE-= specific AEAD algorithms (A128CBC+HS256 and A256CBC+HS512). They force base= 64url-encoding *inside* the AEAD algorithm so they can use a text do= t =93.=94 as a separator.

=A0<= /p>

While A128CBC+HS256 is= implemented by hand in JOSE-specific code using AES and HMAC primitives th= e problems with this chimera are mainly hidden. However, I don=92t believe = any generic AEAD interface can ever handle this JOSE-specific algorithm eff= iciently.

=A0<= /p>

The =93extra work=94 o= f adopting the AEAD encodi= ng/decoding conventions is: concatenating byte arrays; and taking a known-l= ength prefix and suffix from a byte array. You cannot get much simpler. It = can only be an annoyance for a language that is not byte-array-friendly, bu= t even such a language will have to handle byte arrays at some point to int= erface with crypto.<= /p>

=A0<= /p>

Even using the McGrew = draft then separating the output into IV/ciphertext/MAC to re-package as a = JOSE message would be better than the JOSE-specific A128CBC+HS256 and A256C= BC+HS512.

=A0<= /p>

P.S. I think ECMAScrip= t edition 6 is introducing support for byte arrays so even hassle handling = bytes in JavaScript should fade.

=A0<= /p>

--<= /span>

James Manger

= =A0

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] <= b>On Behalf Of Mike Jones
Sent: Wednesday, 13 March 2013 8:06 AM
To: Peck, Michael A= ; John Bradley
Cc: Richard Barnes; jose@ietf.org

Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving= CEK/CIK from CMK

<= /u>=A0

Possibly using the McGrew draft had been discussed before, but there= was strong push-back on it.=A0 It would change more than the CBC/HMAC repr= esentation =96 it would change all the JWE representations, as it would rem= ove the Initialization Vector and Integrity Value fields, and instead requi= re all implementations to implement and apply the AEAD binary encoding and = decoding conventions.=A0 Note that this would change AES-GCM too =96 not ju= st AES-CBC/HMAC.

=A0=

If commonly available crypto libraries implemented algorithms using= the AEAD encoding conventions I would have no problem with this.=A0 But in= fact, they don=92t.=A0 I don=92t know of a single library in the attached = set of surveyed implementations that do.=A0 Thus, adopting the AEAD encodin= g/decoding conventions would create extra work for all implementations in p= ractice =96 not make things simpler.=A0 It would only be simpler if the exi= sting crypto libraries implemented this standard interface.

=A0=

We should therefore steer clear of this.

=A0=

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Best wishes,

=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 -- Mike

=A0=

P.S.=A0 Jim Schaad also points out that CMS doesn=92t use the RFC 5= 116 interface either.

=A0=

From: Peck, Michael A [mailto:mpeck@mitre.org]
Sent: Tuesday, March 12, 2013 2:02 PM
To: John Bradley; Mi= ke Jones
Cc: Richard Barnes; jose@ietf.org
Subject: RE: [jose] Concat KDF i= ssues with ECDH-ES and for deriving CEK/CIK from CMK

=A0

I= think that #2 actually reduces complexity for implementers.<= /span>

They can i= mplement the RFC 5116 interface once (or eventually just invoke a crypto li= brary that implements it for them) =96 then use that implementation for all= protocols that use the RFC 5116 interface, not just JOSE, and know that th= e details of authenticated encryption have been taken care of.

=A0=

Mike

=A0=

=A0

From: John Bradley [mailto:ve7jtb@ve7jtb.com]
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; jose@ietf.org
Subject: Re: [jose] Concat KD= F issues with ECDH-ES and for deriving CEK/CIK from CMK

=A0

Yes I have the recomme= ndation to change from using a KDF to generate the CEK and CIK from the CMK= to concatenating the CEK and CIK together as in the McGrew draft.

=A0

I don't yet ha= ve a slide on the new/old issue of concatenating the tag to the message bod= y vs sending it in a separate field. =A0=A0

=A0

If people wa= nt me to I can add it as well. =A0Though I thought that was a closed issue.= =A0

=A0

John B.

= =A0

On 2013-03-12, at 4:1= 9 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:=

= =A0

As previously extensively discussed, the McGrew= draft does two things =96 one helpful and one not:

=A0

1.=A0 It specifies using a key th= at is actually the concatenation of an AES-CBC key and an HMAC SHA-2 key, r= ather than use of a KDF.=A0 That=92s good, as it=92s simple for implementer= s.

=A0

2.=A0 It specifies that the initi= alization vector and integrity value be concatenated with other values in p= articular ways, and conversely, how to extract them when decrypting.=A0 Tha= t=92s not good, as it adds complexity for implementers =96 especially when = JWEs already utilize a straightforward representation for these values, whi= ch doesn=92t require the binary concatenation and extraction conventions sp= ecified by McGrew.

=A0

I know that John Bradley is going= to ask the question tomorrow whether we should change to doing the first f= or our composite CBC+HMAC algorithms.=A0 I believe that doing the second wo= uld be counterproductive.<= /p>

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 -- Mi= ke

=A0

From:=A0jose-bounces@ietf.org [mailto:jose-bounces@ietf.org]=A0On Behalf O= f=A0Richard Barnes
Sent:=A0Tuesday, March 12, 2013 1:00 PM
To:=A0Peck, Michael A
Cc:=A0jose@ietf.org
Subject:=A0Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/= CIK from CMK

=A0

Actually, fo= r everything but key agreement, we can just use=A0draft-mcgrew-aead-aes-cbc= -hmac-sha2, with larger keys. =A0We should not be specifying key expansion = here when we can avoid it.

=A0

--Richard

=A0

=A0

O= n Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <mpeck@mitre.org<= /span>> wrote:

draft-ietf-jose= -json-web-algorithms-08 section 4.7.1 describes the use of Concat KDF on th= e shared secret Z established by ECDH-ES.

=A0

The draft allows for an= empty PartyUInfo and PartyVInfo but that may not be allowed by NIST SP 800= -56A (where the Concat KDF is defined).

The current (March 2= 007) version of NIST SP 800-56A requires =93At a minimum,=A0PartyUInfo=A0= shall=A0include=A0IDU, the identifier of party=A0U.=94 and an equivalent requirement for PartyVInfo. (Page 46 of<= a href=3D"http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revi= sion1_Mar08-2007.pdf" target=3D"_blank">http:/= /csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007= .pdf=A0)<= /span>

The August 2012 draf= t update to NIST SP 800-56A requires =93At a minimum, PartyUInfo shall incl= ude IDu, an identifier for party U, as a distinct item of information.=94 a= nd an equivalent requirement for PartyVInfo. (Page 59 of=A0http://csrc.nist.gov/pub= lications/drafts/800-56a/draft-sp-800-56a.pdf=A0)= =A0 My interpretation of this text (others may interpret it differently) is= that PartyUInfo and PartyVInfo can=92t be empty.

=A0

Instead of u= sing the Concat KDF, a more appropriate choice may be the KDF described in = NIST SP 800-56C and RFC 5869.

Its requirements are not as strict.=A0 (SP 80= 0-56C Page 13: =93If= the information is available,=A0Context=A0should=A0include the identifiers of the parties who ar= e deriving and/or using the derived keying material=94)

=A0

It would look some= thing like this:

= =A0

Step 1 - Randomness = Extraction:

Key Derivation Key :=3D HMAC(salt, Z)=A0=A0=A0=A0=A0=A0=A0= =A0 (HMAC-SHA256 should suffice for all of the current algorithms)

=A0

Step 2 - Exp= ansion Step:

Use the Counter Mode KDF defined in SP 800-108 or section = 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to produce need= ed keys from the Key Derivation Key produced in step 1.

The needed keys woul= d depend on the values of alg and enc.

<= p class=3D"MsoNormal">If alg is ECDH-ES+A128KW or ECDH= -ES+A256KW, a single 128 bit or 256 bit key is needed (used to decrypt the = CMK, which may then need to be split into CEK/CIK).

If alg is ECDH-ES, t= hen the needed keys depend on =93enc=94:

If enc is AES-GCM, a 128 bit k= ey or 256 bit key is needed.

If enc is one of the= AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key o= f ENC_KEY_LEN + MAC_KEY_LEN is needed as it=92s then split into two by the = AEAD algorithm.

If enc is one of the= current CBC+HMAC options in draft-ietf-jose-json-web-algorithms-08, then t= wo keys are needed, a CEK and a CIK.=A0 Counter Mode KDF could be invoked t= wice, with different labels each time, or Counter Mode KDF could be invoked= once to generate a big key which would then be split into the CEK and CIK.=

=A0

Richard has = already pointed out the issues with using the Concat KDF to derive the CEK/= CIK from the CMK.=A0 Instead, one option would be to use the Expansion Step= above: =A0use the Counter Mode KDF with an HMAC to derive necessary keys f= rom the CMK.=A0

Even if we use encry= ption algorithms that combine the encryption and integrity key such as the = CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will s= till be a need to take a smaller master key and create the combined encrypt= ion + integrity key from it.

=A0

=A0

Mike=

=A0

<= span lang=3D"EN-US">
_______________________________________________
= jose mailing list
jose@ietf.org
https://www.iet= f.org/mailman/listinfo/jose

=A0

__= _____________________________________________
jose mailing list
jos= e@ietf.org
https://www.ietf.org/mailman/listinfo/jose

=A0


<= /div> --e89a8fb20318fc135804d7e61fa1-- From Michael.Jones@microsoft.com Thu Mar 14 10:57:11 2013 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 B3B5811E80E7 for ; Thu, 14 Mar 2013 10:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.832 X-Spam-Level: X-Spam-Status: No, score=-0.832 tagged_above=-999 required=5 tests=[AWL=1.767, BAYES_00=-2.599] 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 nuoS6yYJgFnZ for ; Thu, 14 Mar 2013 10:57:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4DB7621F8CFE for ; Thu, 14 Mar 2013 10:57:06 -0700 (PDT) Received: from BN1AFFO11FD026.protection.gbl (10.58.52.203) by BN1AFFO11HUB005.protection.gbl (10.58.52.115) with Microsoft SMTP Server (TLS) id 15.0.641.9; Thu, 14 Mar 2013 17:56:56 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD026.mail.protection.outlook.com (10.58.52.86) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Thu, 14 Mar 2013 17:56:56 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.132]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Thu, 14 Mar 2013 17:56:43 +0000 From: Mike Jones To: Juraj Somorovsky Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: AQHOINLXhTumGPPo10aSXnUUAEnOSpilb8qw Date: Thu, 14 Mar 2013 17:56:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675110FD@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5141FDC1.5000102@rub.de> In-Reply-To: <5141FDC1.5000102@rub.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(47776003)(73894001)(79102001)(54356001)(56816002)(66066001)(4396001)(65816001)(56776001)(59766001)(46102001)(47446002)(55846006)(77982001)(16406001)(47736001)(54316002)(50466001)(53806001)(74502001)(51856001)(50986001)(63696002)(49866001)(80022001)(33656001)(20776003)(621065001)(23676001)(76482001)(69226001)(47976001)(74662001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BN1AFFO11HUB005; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0785459C39 Cc: Tibor Jager , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 17:57:12 -0000 SGkgSnVyYWosDQoNClRoYW5rcyBmb3IgbG9va2luZyBhdCB0aGUgc2VjdXJpdHkgY2hhcmFjdGVy aXN0aWNzIG9mIEpXRS4NCg0KSSBkb24ndCB0aGluayB0aGF0IGVpdGhlciBvZiB5b3VyIHNjZW5h cmlvcyAoYSkgb3IgKGIpIGFwcGx5IHRvIEpXRS4NCg0KRm9yIChhKSwgYSBzZXJ2ZXIgaW1wbGVt ZW50aW5nIEpXRSB3aWxsIG5vdCBhY2NlcHQgdW5zaWduZWQgKHJlYWxseSwgbm9uLWludGVncml0 eS1wcm90ZWN0ZWQpIHJlcXVlc3RzIGJlY2F1c2UgZW5jcnlwdGlvbiBhbGdvcml0aG1zIG5vdCBw cm92aWRpbmcgaW50ZWdyaXR5IHByb3RlY3Rpb24gbWF5IG5vdCBiZSB1c2VkLg0KDQpGb3IgKGIp LCBpdCBkb2Vzbid0IG1hdHRlciBpZiB0aGUgYXR0YWNrZXIgaGFzIGEgdmFsaWQgcHVibGljIGtl eSB0aGF0IHRoZSBzZXJ2ZXIgd291bGQgYWNjZXB0IGZvciBzaWduYXR1cmVzLCBiZWNhdXNlIHRo ZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiBhcHBsaWVkIHRvIEpXRSBpcyBub3Qgc2ltcGx5IGEgc2Vw YXJhdGUgc2lnbmF0dXJlIGFwcGxpZWQgYWZ0ZXIgdGhlIGZhY3QuICBUaGUgSldFJ3MgY29udGVu dHMgYXJlIHByb3RlY3RlZCB1c2luZyBhIHJhbmRvbWx5IGdlbmVyYXRlZCBrZXkgdGhhdCBpcyBl bmNyeXB0ZWQgYnkgdGhlIGtleSB3cmFwcGluZyBzdGVwLiAgVW5sZXNzIHRoZSBhdHRhY2tlciBh bHJlYWR5IHBvc3Nlc3MgdGhlIGtleSB0byBkZWNyeXB0IHRoZSBlbmNyeXB0ZWQga2V5ICh0aGUg b2JqZWN0aXZlIG9mIHRoZSBhdHRhY2sgaW4gdGhlIGZpcnN0IHBsYWNlISksIGhlIGNhbid0IGxl YXJuIHdoYXQga2V5IHdhcyB1c2VkIHRvIGFwcGx5IHRoZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwg YW5kIHdpdGhvdXQgdGhhdCBrZXksIHRoZSBhdHRhY2tlciBjYW4ndCBhcHBseSBhIGRpZmZlcmVu dCBzaWduYXR1cmUuDQoNClRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgImVuYyIgcGFyYW1ldGVyIGlu IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1lbmNy eXB0aW9uLTA4I3NlY3Rpb24tNC4xLjIgYmVnaW5zIHdpdGg6DQogICBUaGUgImVuYyIgKGVuY3J5 cHRpb24gbWV0aG9kKSBoZWFkZXIgcGFyYW1ldGVyIGlkZW50aWZpZXMgdGhlIGJsb2NrDQogICBl bmNyeXB0aW9uIGFsZ29yaXRobSB1c2VkIHRvIGVuY3J5cHQgdGhlIFBsYWludGV4dCB0byBwcm9k dWNlIHRoZQ0KICAgQ2lwaGVydGV4dC4gIFRoaXMgYWxnb3JpdGhtIE1VU1QgYmUgYW4gQXV0aGVu dGljYXRlZCBFbmNyeXB0aW9uDQogICBhbGdvcml0aG0gd2l0aCBhIHNwZWNpZmllZCBrZXkgbGVu Z3RoLg0KDQpJZiB5b3UgdGhpbmsgdGhhdCdzIG5vdCBjbGVhciBlbm91Z2gsIHdlIGNvdWxkIGNl cnRhaW5seSBzYXkgbW9yZSAtIHBhcnRpY3VsYXJseSBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJh dGlvbnMgc2VjdGlvbi4gIFN1Z2dlc3RlZCB0ZXh0IHdvdWxkIGJlIG1vcmUgdGhhbiB3ZWxjb21l ZC4NCg0KQWxzbywgcmVzcG9uZGluZyB0byBCcmlhbidzIHNjZW5hcmlvLCBJIGJlbGlldmUgdGhh dCB0aGUgYXR0YWNrIG9uIFJTQSBQS0NTICMxIDEuNSByZXF1aXJlcyB0aGUgYWJpbGl0eSBmb3Ig dGhlIGF0dGFja2VyIHRvIHN1Ym1pdCB2YWxpZCBtb2RpZmllZCBtZXNzYWdlcyB0byB0aGUgc2Vy dmVyLiAgQmVjYXVzZSB0aGUgSldFIG1lc3NhZ2VzIGFyZSBpbnRlZ3JpdHktcHJvdGVjdGVkIHVz aW5nIGEgd3JhcHBlZCBrZXksIHRoZSByZWFzb25pbmcgb2YgKGIpIGFib3ZlIGFwcGxpZXMgaW4g dGhpcyBjYXNlIHRvby4gIFNwZWNpZmljYWxseSwgd2l0aG91dCBrbm93aW5nIHRoZSBSU0Ega2V5 IGluIHRoZSBmaXJzdCBwbGFjZSwgaXQncyBub3QgcG9zc2libGUgdG8gbGVhcm4gdGhlIGtleSB1 c2VkIHRvIHByb3ZpZGUgdGhlIGludGVncml0eSBjaGVjaywgYW5kIHNvIG5vdCBwb3NzaWJsZSB0 byBjcmVhdGUgbW9kaWZpZWQgbWVzc2FnZXMgdGhhdCBwYXNzIHRoZSBpbnRlZ3JpdHkgY2hlY2su DQoNCkJ1dCBieSBhbGwgbWVhbnMsIGlmIGFueSBvZiBteSByZWFzb25pbmcgaXMgd3Jvbmcgb3Ig aW5jb21wbGV0ZSwgcGxlYXNlIGRvIHBvaW50IGl0IG91dCENCg0KCQkJCVRoYW5rcyBhZ2Fpbiwg SnVyYWosDQoJCQkJLS0gTWlrZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog SnVyYWogU29tb3JvdnNreSBbbWFpbHRvOmp1cmFqLnNvbW9yb3Zza3lAcnViLmRlXSANClNlbnQ6 IFRodXJzZGF5LCBNYXJjaCAxNCwgMjAxMyA5OjQyIEFNDQpUbzogTWlrZSBKb25lcw0KQ2M6ID1K ZWZmSDsgSUVURiBKT1NFIFdHOyBUaWJvciBKYWdlcg0KU3ViamVjdDogUmU6IFtqb3NlXSBiYWNr d2FyZHMgY29tcGF0aWJpbGl0eSBhdHRhY2sgb24gSldUIGltcGxzICh3YXM6IEktRCBBY3Rpb246 IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0aG1zLTAyLnR4dCkNCg0KSGkgSmVmZiwg aGkgTWlrZSwNCg0KSSBhbSBzb3JyeSwgaXQgc2VlbXMgdGhhdCBJIGhhdmUgdG90YWxseSBtaXNz ZWQgeW91ciBwcmV2aW91cyBlbWFpbC4gSSB0cnkgdG8gYW5zd2VyIHNvbWUgb2YgeW91ciBxdWVz dGlvbnMuLi4NCg0KT24gMDMvMTQvMjAxMyAwNDo0OCBQTSwgTWlrZSBKb25lcyB3cm90ZToNCj4g SSBiZWxpZXZlIHRoYXQgdGhlc2UgYXR0YWNrcyBhcmUgb25seSBwb3NzaWJsZSBvbiBlbmNyeXB0 aW9uIHdpdGhvdXQgaW50ZWdyaXR5LCB3aGljaCBpbiB0dXJuIHdhcyBvbmx5IHBvc3NpYmxlLCBi ZWNhdXNlIE5pbWJ1cy1KV1QgY29udGludWVkIHRvIGltcGxlbWVudCBlbmNyeXB0aW9uIGFsZ29y aXRobXMgd2l0aG91dCBpbnRlZ3JpdHkgcHJvdGVjdGlvbi4gIFNvbWVvbmUgc2hvdWxkIHBsZWFz ZSBjb3JyZWN0IG1lIGlmIEknbSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBzaXR1YXRpb24uDQpUaGVz ZSBhdHRhY2tzIHdlcmUgYmFzaWNhbGx5IHBvc3NpYmxlIGJlY2F1c2U6DQoxKSBOaW1idXMtSldU IGFsbG93ZWQgdXMgdG8gdXNlIEFFUy1DQkMuIEFzIHdlIGV4cGxpY2l0bHkgc3RhdGUgaW4gb3Vy IHBhcGVyLCB0aGlzIGlzIG5vdCBwcm9ibGVtIG9mIHRoZSBqb3NlIHNwZWNpZmljYXRpb24gYXMg aXQgZm9yYmlkcyBBRVMtQ0JDIGluIHRoZSBuZXdlciB2ZXJzaW9ucw0KDQoyKSBXZSB3ZXJlIGFi bGUgdG8gZm9yY2UgdGhlIE5pbWJ1cy1KV1QgZnJhbWV3b3JrIHRvIGRlY3J5cHQgUlNBLU9BRVAg Y2lwaGVydGV4dHMgd2l0aCBSU0ExXzUuIFlvdSBhcmUgcmlnaHQsIGluIG91ciBzY2VuYXJpb3Ms IHRoZSBIZWFkZXJzIHdlcmUgbm90IHNpZ25lZCBhbmQgdGh1cyB3ZSB3ZXJlIGFibGUgdG8gc3dp dGNoIGZyb20gUlNBLU9BRVAgdG8gUlNBMV81Lg0KSG93ZXZlciwgaWYgSSB0YWtlIGEgbG9vayBh dCB0aGUgSlNPTiBXZWIgRW5jcnlwdGlvbiBzdGFuZGFyZCwgdGhlcmUgaXMgbm90IGV4cGxpY2l0 bHkgd3JpdHRlbiB0aGF0IHRoZSBtZXNzYWdlcyBtdXN0IGJlIHNpZ25lZC4gQW5kIGV2ZW4gaWYg dGhlIG1lc3NhZ2VzIHdvdWxkIGJlIHNpZ25lZCwgdGhlcmUgY291bGQgc3RpbGwgZXhpc3Qgc2Nl bmFyaW9zIHdoZXJlIGl0IGlzIHBvc3NpYmxlIHRvIGFwcGx5IHRoZXNlIGF0dGFja3MuIFNlZSBi ZWxvdy4NCj4gDQo+IEFzIG1vc3Qgb2YgeW91IGtub3csIEpXRSBub3cgb25seSBhbGxvd3MgYXV0 aGVudGljYXRlZCBlbmNyeXB0aW9uIGFsZ29yaXRobXMgdG8gYmUgdXNlZCwgZm9yIHJlYXNvbnMg ZXhhY3RseSBzdWNoIGFzIHRoZXNlLg0KSXQgaXMgZ3JlYXQgdGhhdCB5b3UgcmVtb3ZlZCBBRVMt Q0JDLiBSU0ExXzUgZW5jcnlwdGlvbiBpcyBzdGlsbCBob3dldmVyIGluIHRoZSBzdGFuZGFyZC4N Cj4gDQo+IAkJCQktLSBNaWtlDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiANCj4gT2YgPUplZmZIDQo+IFNlbnQ6IFRodXJzZGF5LCBNYXJjaCAxNCwgMjAx MyA4OjE3IEFNDQo+IFRvOiBJRVRGIEpPU0UgV0cNCj4gQ2M6IEp1cmFqIFNvbW9yb3Zza3kNCj4g U3ViamVjdDogW2pvc2VdIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGF0dGFjayBvbiBKV1QgaW1w bHMgKHdhczogSS1EIA0KPiBBY3Rpb246IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1hbGdvcml0 aG1zLTAyLnR4dCkNCj4gDQo+IGJhY2sgb24gRnJpLCA2IEp1bCAyMDEyICBNaWtlIEpvbmVzIHNh aWQ6DQo+ICA+DQo+ICA+IExvb2tpbmcgYXQgdGhpcyBhZ2FpbiwgaXQgc2VlbXMgdG8gbWUgdGhh dCBiZWNhdXNlIEpXRSBwcm92aWRlcyBpbnRlZ3JpdHkgID4gcHJvdGVjdGlvbiBmb3IgdGhlIGFs Z29yaXRobSwgaXQgc2hvdWxkIGJlIGltcG9zc2libGUgZm9yIHlvdSB0byByZXBsYWNlICA+ICJS U0EtT0FFUCIgd2l0aCAiUlNBMV81IiBpbiB0aGUgaGVhZGVyIGJlY2F1c2UgdGhlbiB0aGUgaW50 ZWdyaXR5IGNoZWNrIHdpbGwgID4gZmFpbC4gIFRodXMsIHRoZSBhdHRhY2sgdGhhdCB5b3UgZGVz Y3JpYmUgYmVsb3cgaXMgcHJldmVudGVkIGJ5IHRoZSBpbnRlZ3JpdHkgID4gcHJvdGVjdGlvbiBv ZiB0aGUgaGVhZGVyLg0KPiAgPg0KPiAgPiBIZW5jZSwgY29ycmVjdCBKV0UgaW1wbGVtZW50YXRp b25zIGRvIG5vIHByb3ZpZGUgdGhlIE9BRVAgZGVjcnlwdGlvbiBvcmFjbGUgID4gdGhhdCB5b3Ug ZGVzY3JpYmUuICBIb3dldmVyIGlmIEknbSBtaXNzaW5nIHNvbWV0aGluZywgcGxlYXNlIHBvaW50 IGl0IG91dCB0byAgPiBtZSwgc2luY2UgaWYgdGhlcmUncyBhbiBpc3N1ZSwgSSdkIGxpa2UgdG8g dW5kZXJzdGFuZCBpdCBhbmQgaG93IHRvIG1pdGlnYXRlICA+IGl0Lg0KWWVzLCB0aGlzIGlzIHRy dWUsIGlmIHRoZSBhdHRhY2tlciBpcyBub3QgYWJsZSB0byBjcmVhdGUgdmFsaWQgc2lnbmF0dXJl cyBBTkQgaGUgaXMgbm90IGFibGUgdG8gZm9yY2UgdGhlIHNlcnZlciB0byBwcm9jZXNzIHVuc2ln bmVkIGVsZW1lbnRzLiBIb3dldmVyLCB0aGVyZSBhcmUgZmV3IHNjZW5hcmlvcywgd2hlcmUgdGhl IGF0dGFja3MgY291bGQgc3RpbGwgYmUgYXBwbGllZC4NCg0KSSBhbSBub3QgdGhhdCBmYW1pbGlh ciB3aXRoIGFsbCB0aGUgSlNPTiBzY2VuYXJpb3MgYnV0IEkgYXNzdW1lIHRoYXQgdGhleSBhcmUg dmVyeSBjbG9zZSB0byB0aGUgc2NlbmFyaW9zIHdoZXJlIFhNTCBTZWN1cml0eSBpcyBhcHBsaWVk Lg0KVGh1cywgSSB3b3VsZCBzYXkgaXQgaXMgcG9zc2libGUgdG8gYXNzdW1lIHRoZSBmb2xsb3dp bmcgc2NlbmFyaW9zOg0KDQphKSBJZiB0aGUgc2VydmVyIGlzIG5vdCBjb3JyZWN0bHkgY29uZmln dXJlZCwgaXQgY291bGQgYWNjZXB0IHVuc2lnbmVkIHJlcXVlc3RzIEpTT04gZWxlbWVudHMuIFRo dXMsIHRoZSBhdHRhY2tlciBjb3VsZCBzaW1wbHkgZXh0cmFjdCB0aGUgc2lnbmF0dXJlIG9yIGNy ZWF0ZSBhbiBhZGRpdGlvbmFsIGVuY3J5cHRpb24gZWxlbWVudC4NCg0KYikgaW4gc29tZSBQdWJs aWMtS2V5IHNjZW5hcmlvcywgdGhlIGF0dGFja2VyIHdpbGwgaGF2ZSBhIHZhbGlkIGtleSB0byBz aWduIGhpcyBKU09OIHJlcXVlc3RzLiBJbiB0aGF0IGNhc2UsIGhlIGlzIGFibGUgdG86DQogIDEp IHRha2UgYW4gUlNBX09BRVAgcmVxdWVzdCBmcm9tIGhpcyB2aWN0aW0NCiAgMikgZXh0cmFjdCB0 aGUgc2lnbmF0dXJlIGZyb20gdGhpcyByZXF1ZXN0DQogIDMpIHJlcGxhY2UgdGhlIGFsZ29yaXRo bSAoUlNBX09BRVAgLT4gUlNBMV81KSBhbmQNCiAgNCkgcmVzaWduIHRoZSByZXF1ZXN0IHdpdGgg aGlzIG93biBrZXkuDQpBZnRlcndhcmRzLCBoZSBjb3VsZCBzZW5kIHRoZSByZXF1ZXN0IHRvIHRo ZSBzZXJ2ZXIgYW5kIGZvcmNlIGl0IHRvIHByb2Nlc3MgUlNBMV81DQoNClBsZWFzZSBzZWUgb3Vy IHBhcGVyIGZvciBtb3JlIGRldGFpbHMgKFNlY3Rpb24gNCk6DQpodHRwOi8vd3d3Lm5kcy5ydWhy LXVuaS1ib2NodW0uZGUvcmVzZWFyY2gvcHVibGljYXRpb25zL2JyZWFraW5nLXhtbC1lbmNyeXB0 aW9uLWNvdW50ZXJtZWFzdXJlcy8NCg0KDQpJdCBkZXNjcmliZXMgc29tZSB0ZWNobmlxdWVzIGhv dyB0byBhcHBseSBzdWNoIGF0dGFja3Mgb24gc2lnbmVkIHN5bW1ldHJpY2FsbHkgZW5jcnlwdGVk IFhNTCBkb2N1bWVudHMuDQo+IA0KPiBqdXN0IGZ5aS9md2l3Li4uYXBvbG9naWVzIGlmIHRoaXMg aGFzIGFscmVhZHkgYmVlbiBmb2xsb3dlZCB1cCBvbiwgYnV0IEkgZGlkbid0IGZpbmQgZnVydGhl ciBkaXNjdXNzaW9uIG9mIHRoaXMgYWZ0ZXIgdGhlIGFib3ZlLXF1b3RlZCBtc2cuLi4NCj4gDQo+ IEp1cmFqIFNvbW9yb3Zza3kgZXQgYWwncyBORFNTLTIwMTMgIkJhY2t3YXJkcyBDb21wYXRpYmls aXR5IChCQykgYXR0YWNrcyIgcGFwZXIgWzFdIGlzIG5vdyBvdXQsIGFuZCBpdCBtYXkgaGVscCBh bnN3ZXIgdGhlIGFib3ZlIHF1ZXN0aW9ucy4gVGhlcmUncyBhbHNvIEtlbm55IFBhdHRlcnNvbidz IHRhbGsgWzJdIGZyb20gdGhlIHJlY2VudCBXb3Jrc2hvcCBvbiBSZWFsLVdvcmxkIENyeXB0b2dy YXBoeS4NCj4gDQo+IEl0IHNlZW1zLCBmcm9tIGFuIGFkbWl0dGVkbHkgY3Vyc29yeSBnbGFuY2Ug YXQgYm90aCBkcmFmdC1pZXRmLWpvc2UtanNvbi13ZWItYWxnb3JpdGhtcyAoLTA4KSBhbmQgdGhl IGFib3ZlIHBhcGVyL3NsaWRlcywgdGhhdCBwZXJoYXBzIHRoZXJlIHNob3VsZCBiZSBtb3JlIGlt cGxlbWVudGF0aW9uIGFkdmljZSBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgaW4gKGF0IGxl YXN0KSB0aGUgLWpzb24td2ViLWFsZ29yaXRobXMgc3BlYy4NCkFncmVlZC4gU29tZSBvZiB0aGVz ZSBhdHRhY2tzIGFyZSBlLmcuIGV4cGxpY2l0bHkgaGFuZGxlZCBpbiB0aGUgWE1MIEVuY3J5cHRp b24gc3BlY2lmaWNhdGlvbjoNCmh0dHA6Ly93d3cudzMub3JnL1RSL3htbGVuYy1jb3JlMS8jc2Vj LWNob3Nlbi1jaXBoZXJ0ZXh0LWF0dGFja3MNCg0KWW91IGNvdWxkIGluY2x1ZGUgc2ltaWxhciBz ZWN0aW9ucyBpbiB5b3VyIHNwZWMuIElmIHlvdSB3b3VsZCBuZWVkIHNvbWUgaGVscCwganVzdCBs ZXQgdXMga25vdy4NCg0KVGhhbmtzDQpKdXJhag0K From jricher@mitre.org Thu Mar 14 11:03:26 2013 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 072FC11E8129 for ; Thu, 14 Mar 2013 11:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=4.700, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, 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 sgOfLhyYbceO for ; Thu, 14 Mar 2013 11:03:25 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D8F8411E8146 for ; Thu, 14 Mar 2013 11:03:24 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3FF3A2260059; Thu, 14 Mar 2013 14:03:24 -0400 (EDT) Received: from IMCCAS04.MITRE.ORG (imccas04.mitre.org [129.83.29.81]) by smtpksrv1.mitre.org (Postfix) with ESMTP id E82432260045; Thu, 14 Mar 2013 14:03:23 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS04.MITRE.ORG (129.83.29.81) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 14 Mar 2013 14:03:23 -0400 Message-ID: <5142109D.7010507@mitre.org> Date: Thu, 14 Mar 2013 14:02:05 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Mike Jones References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [129.83.31.58] Cc: IETF JOSE WG , =JeffH , Juraj Somorovsky Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 18:03:26 -0000 Also, the Nimbus-JWT library has been deprecated in favor of Nimbus-JOSE-JWT: https://bitbucket.org/nimbusds/nimbus-jose-jwt/ The new library is tracking the JOSE specs even more closely, and I'd be very interested to hear if the attack is still possible against the new library. -- Justin On 03/14/2013 11:48 AM, Mike Jones wrote: > I believe that these attacks are only possible on encryption without integrity, which in turn was only possible, because Nimbus-JWT continued to implement encryption algorithms without integrity protection. Someone should please correct me if I'm misunderstanding the situation. > > As most of you know, JWE now only allows authenticated encryption algorithms to be used, for reasons exactly such as these. > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of =JeffH > Sent: Thursday, March 14, 2013 8:17 AM > To: IETF JOSE WG > Cc: Juraj Somorovsky > Subject: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) > > back on Fri, 6 Jul 2012 Mike Jones said: > > > > Looking at this again, it seems to me that because JWE provides integrity > protection for the algorithm, it should be impossible for you to replace > "RSA-OAEP" with "RSA1_5" in the header because then the integrity check will > fail. Thus, the attack that you describe below is prevented by the integrity > protection of the header. > > > > Hence, correct JWE implementations do no provide the OAEP decryption oracle > that you describe. However if I'm missing something, please point it out to > me, since if there's an issue, I'd like to understand it and how to mitigate > it. > > just fyi/fwiw...apologies if this has already been followed up on, but I didn't find further discussion of this after the above-quoted msg... > > Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" paper [1] is now out, and it may help answer the above questions. There's also Kenny Patterson's talk [2] from the recent Workshop on Real-World Cryptography. > > It seems, from an admittedly cursory glance at both draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, that perhaps there should be more implementation advice and security considerations in (at least) the -json-web-algorithms spec. > > Here's some excerpts from the paper for context... > ... > In the public-key setting, we show how the well-known attack of Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 encryption in both XML Encryption [27] and JSON Web Encryption [42], and to forge signatures for arbitrary messages in XML Signature [30] and JSON Web Signature [41]. The attack principle is described in Section 4. We furthermore report on our experimental results, executed against the Java implementation of JSON Web Encryption and JSON Web Signature Nimbus-JWT [53], in Section 5.3. > ... > > Platform for Experimental Analysis: We investigate the practicality and performance of our attacks on JWE and JWS by applying them to the Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON Web Encryption (JWE) and JSON Web Signature (JWS), developed by NimbusDS to support their Cloud Identity management portfolio. > > Even though Nimbus-JWT claims to implement version 02 of the JWE standard draft, it still supports usage of AESCBC (without MAC), which was available in version 01, but not in version 02 or any subsequent versions. > ... > > 5.2.3 Evaluation > > We evaluated performance of our attacks against both WSS4J and Nimbus-JWT. We ï¬rst used the libraries to generate valid messages containing AES-GCM ciphertexts. Then we modiï¬ed the algorithm parameters in the messages, forcing the receiver to process the ciphertexts using AES-CBC, and executed the attack described in Algorithm 1. The required ciphertext validity oracles were based on error messages generated by the libraries. > ... > > Experimental Results. In order to assess the practicability and performance of the attack, we implemented Bleichenbacher’s attack on XML Encryption [13, 38] and applied it to the Nimbus-JWT library. The PKCS#1 v1.5 validity oracle was provided by exceptions thrown by this library.11 > ... > > 11 In practice one would instead use the more elaborate attack techniques of [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid. > ... > > [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in Cryptology – CRYPTO’98, volume 1462 of Lecture Notes in Computer Science, pages 1–12. > Springer, Aug. 1998. > > [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher’s attack strikes > again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung, editors, Computer Security - ESORICS 2012 - 17th European Symposium on Research in Computer Security, Pisa, Italy, September 10-14, 2012. Proceedings, LNCS. > Springer, 2012. > > [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. > https://bitbucket.org/nimbusds/nimbus-jwt. > > ### > > [1] One Bad Apple: Backwards Compatibility Attacks on > State-of-the-Art Cryptography > http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCompatibilityAttacks.pdf > > [2] Key Reuse: Theory and Practice > http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf > > > HTH, > > =JeffH > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From sakimura@gmail.com Thu Mar 14 20:26:43 2013 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 EBF4F11E81A6 for ; Thu, 14 Mar 2013 20:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, NO_RELAYS=-0.001] 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 bqhATRBZPYek for ; Thu, 14 Mar 2013 20:26:43 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id DF63511E81A3 for ; Thu, 14 Mar 2013 20:26:42 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo13so3298622lab.38 for ; Thu, 14 Mar 2013 20:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=bwDUfRzD1GS1xDSdkLuQNRkjuBfzE2BINMylWVcFfmA=; b=gGb+xD+WM1XvUqQ6YZEFjmG4e913YT5cinZPpc3/QCOmoLoap911ee859CqHvzVcOA +HXhSgdNHGb73Hl+cFjUjENnNQup6e/FiSdBXmZj9w8jYj5jRbtONmCJP49WajKMgZQx 8slKrkAicMz3NznXKZSp9CO1kc8J7+1vOJO/oo76bHkmhwX9pheTmcMWYyCb8DMwIReQ 9RVrMTjOw63Wrhp/EVAIufLlSx0+sCiVfEZOVW35MkFHrQa9WAI7ISZLxq8itWFygsNU Dnti4n2N/yJrD4xbxDU6gdH1qq9efXn97TfqY+/XH5ZqeXSKpXQiHz3ErJyQyVdqIUWb mgJA== MIME-Version: 1.0 X-Received: by 10.152.87.177 with SMTP id az17mr2681170lab.2.1363318001678; Thu, 14 Mar 2013 20:26:41 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 14 Mar 2013 20:26:41 -0700 (PDT) Date: Fri, 15 Mar 2013 12:26:41 +0900 Message-ID: From: Nat Sakimura To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [jose] JWS Comments 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, 15 Mar 2013 03:26:44 -0000 FYI, here is a set of comments that I provided on JWS to Mike couple of days ago. Just for the record so that you guys knows that Mike was not doing the edits ad lib. 2. Terminology - JSON Web Signature (JWS) ---------------------------------------------- Currently, it states that JWS is: A data structure representing a digitally signed or MACed message. The structure consists of three parts: the JWS Header, the JWS Payload, and the JWS Signature value. It is false. It should be A data structure representing a digitally signed or MACed message. The structure consists of three parts: the Encoded JWS Header, the Encoded JWS Payload, and the Encoded JWS Signature value. JWS Payload --------------------- Change "The bytes to be secured" to "The byte array to be secured" OR "The sequence of octets to be secured2. "the bytes" does not seem to work very well here as it literally would mean some number of integer. Also, it is better not use "a.k.a." as it is not a defined acronym. For an English native speaker, it would be fine, but for people with English as second or third language, it may become a stumbling point. Header Parameter Name ----------------------------- We seem to be mixing the JSON terminology and something that is not. For example, "The name of a member of the JWS Header" should be "The string of a member of the JWS Header" in JSON terminology, while 'member' is a JSON terminology. I agree that 'name' is much better term than 'string', but we probably should define it if we use it. 4.1.1. "alg" Header Parameter -------------------------------------- The second sentence is very long and hard to read. It probably is better to be split. It was kind of hard for me to parse, so non-native English speaker probably would have a hard time reading it. 4.1.8 "cty" Header Parameter -------------------------------------- It talks about 'JWT' case. It probably would be more illustrative if we add other cases, such as JPEG as well. 5.1 - 5 Reduce repitition -------------------------------------- Do we need to repeat the definition of JWS Secured Input here? Just stating: Compute the JWS Signature in the manner defined for teh paritcular algorithm being used over the JWS Secured Input. would seem sufficient. 5.1 - 5 replace 'JSON Header' with 'JWS Header' The paragraph is using "JSON Header". Is it not "JWS Header"? 5.1 - 7 --------- Let us not conflate the creation of the JWS and compact serialization. Step 7 should stop at the creation of JWS, and a new step 8 should describe the compact serialization. 5.2 - 7 ---------- I think we can delete what goes into parenthesis. We do not have to repeat. -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en From James.H.Manger@team.telstra.com Thu Mar 14 23:43:37 2013 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 AC4EB21F8BBA for ; Thu, 14 Mar 2013 23:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 CLMUPb9mS5Dh for ; Thu, 14 Mar 2013 23:43:35 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id E97D221F865D for ; Thu, 14 Mar 2013 23:43:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,849,1355058000"; d="scan'208";a="119745122" Received: from unknown (HELO ipcbni.tcif.telstra.com.au) ([10.97.216.204]) by ipocni.tcif.telstra.com.au with ESMTP; 15 Mar 2013 17:43:32 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7014"; a="120740418" Received: from wsmsg3753.srv.dir.telstra.com ([172.49.40.174]) by ipcbni.tcif.telstra.com.au with ESMTP; 15 Mar 2013 17:43:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3753.srv.dir.telstra.com ([172.49.40.174]) with mapi; Fri, 15 Mar 2013 17:43:32 +1100 From: "Manger, James H" To: "Matt Miller (mamille2)" , "" Date: Fri, 15 Mar 2013 17:43:29 +1100 Thread-Topic: Rolling PKIX into JWK Thread-Index: AQHOILqMA29glkFWZUOgI7llc9nICpimRb5g Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 06:43:37 -0000 SSBhZ3JlZSwgYSBjZXJ0aWZpY2F0ZSBhcyBhbiBvcHRpb25hbCBmaWVsZCBvZiBhbnkgSldLIHNv dW5kcyBsaWtlIGEgZGVjZW50IGFwcHJvYWNoLg0KDQpQdXR0aW5nIGEgd2hvbGUgY2VydCBjaGFp biBpbiBvbmUgSldLIGlzIG5vdCBpZGVhbC4NCkVhY2ggY2VydCBpcyBhYm91dCAxIGtleSBzbyBy ZWFsbHkgc2hvdWxkIGJlIGluIGl0cyBvd24gSldLLg0KT3RoZXJ3aXNlIHlvdSB3aWxsIGR1cGxp Y2F0ZSB0aGUgY2hhaW4gb2YgaW50ZXJtZWRpYXRlIENBIGNlcnRzIGluIGVhY2ggSldLIGluIGEg c2V0Lg0KDQpJdCBtaWdodCBiZSB1c2VmdWwgdG8gZGVmaW5lIGEgaXNzdWVyIGtleS1pZCBmaWVs ZCAoImlzc2tpZCIpLiBBIEpXSyBjb3VsZCBpbmNsdWRlIGEgY2VydCBmb3IgaXRzIG93biBrZXkg YW5kICh3aXRoICJpc3NraWQiKSBhIGxpbmsgdG8gdGhlIG5leHQgY2VydCBhbG9uZyB0aGUgY2hh aW4uIFRoYXQgbWFrZXMgaXQgcXVpY2stbi1lYXN5IHRvIGJ1aWxkIGEgY2hhaW4gZnJvbSB0aGUg SldLcyBpbiBhIHNldC4NCg0KSXQgd291bGQgYWxzbyBoZWxwIGlmIEpXS3MgaW4gYSBzZXQgd2hl cmUgaGVsZCBpbiBhIG9iamVjdC9kaWN0aW9uYXJ5L2Fzc29jaWF0aXZlLWFycmF5IHdpdGggdGhl IGtpZCBhcyB0aGUgbmFtZS4gVGhhdCB3b3VsZCBiZSBiZXR0ZXIgdGhhbiB1c2luZyBhbiBhcnJh eSBvZiBKV0tzIHdpdGggbm8gZGVmaW5lZCBtZWFuaW5nIGZvciB0aGUgb3JkZXIuDQoNCi0tDQpK YW1lcyBNYW5nZXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3Nl LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZg0KPiBNYXR0IE1pbGxlciAobWFtaWxsZTIpDQo+IFNlbnQ6IEZyaWRheSwgMTUgTWFyY2gg MjAxMyAxMjo0OCBBTQ0KPiBUbzogPGpvc2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFtqb3NlXSBS b2xsaW5nIFBLSVggaW50byBKV0sNCj4gDQo+IFtob3BpbmcgdGhpcyB0b3BpYyBpcyB0aGUgbGVh c3QgY29udHJvdmVyc2lhbC4uLl0NCj4gDQo+IEluIHNvbWUgSVJMIGRpc2N1c3Npb25zIG9uIG1v dmluZyBmb3J3YXJkIG9uIFBLSVggaW4gSldLLCBJJ3ZlIGJlZW4NCj4gY29udmluY2VkIHRoZSBj b25jZXJucyBhcmUgbW9zdGx5IHRoZSBzYW1lIHJlZ2FyZGxlc3Mgb2YgaG93IHRoZSBQS0lYDQo+ IGlzIHBhY2thZ2VkLiAgR2l2ZW4gdGhhdCwgSSB3b3VsZCBzdWdnZXN0IHdlIG1ha2UgIng1YyIg YW4gb3B0aW9uYWwNCj4gZmllbGQgb2YgSldLLCByYXRoZXIgdGhhbiBkZWZpbmluZyBhIG5ldyBK V0sgdHlwZS4gIEkgY2FuIHByb3Bvc2UNCj4gdmFyaW91cyB0ZXh0IGFkZGl0aW9ucyBhZnRlciB0 aGlzIG1lZXRpbmcuDQo+IA0KPiANCj4gVGhvdWdodHM/DQo+IA0KPiAtIG0mbQ0KPiANCj4gTWF0 dCBNaWxsZXIgPCBtYW1pbGxlMkBjaXNjby5jb20gPg0KPiBDaXNjbyBTeXN0ZW1zLCBJbmMuDQoN Cg== From James.H.Manger@team.telstra.com Thu Mar 14 23:52:53 2013 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 C74C021F9099 for ; Thu, 14 Mar 2013 23:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 yz0NfLGA6apm for ; Thu, 14 Mar 2013 23:52:53 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id D9CE821F8EF6 for ; Thu, 14 Mar 2013 23:52:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,849,1355058000"; d="scan'208";a="128178667" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipoani.tcif.telstra.com.au with ESMTP; 15 Mar 2013 17:52:32 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7014"; a="121388222" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccni.tcif.telstra.com.au with ESMTP; 15 Mar 2013 17:52:32 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Fri, 15 Mar 2013 17:52:32 +1100 From: "Manger, James H" To: "Matt Miller (mamille2)" , "" Date: Fri, 15 Mar 2013 17:52:31 +1100 Thread-Topic: Rolling PKIX into JWK Thread-Index: AQHOILqMA29glkFWZUOgI7llc9nICpimRb5ggAAKesA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B9AE09E@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 06:52:53 -0000 SSBkb24ndCBtaW5kIGJlaW5nIGFibGUgdG8gcHV0IGEgd2hvbGUgY2VydCBjaGFpbiBpbiBvbmUg SldLLCBidXQgY2xpZW50cyB0aGF0IGdldCBhIHNldCBvZiBKV0tzIChlZyBieSBkZXJlZmVyZW5j aW5nIGEgImprdSIgVVJJKSBzaG91bGQgYWxzbyBjb3BlIGlmIHRoZSBlYWNoIGNlcnQgb2YgdGhl IGNoYWluIGlzIGluIGl0cyBvd24gSldLIGluIHRoZSBzZXQuDQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGpvc2UtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IE1h bmdlciwgSmFtZXMgSA0KPiBTZW50OiBGcmlkYXksIDE1IE1hcmNoIDIwMTMgNTo0MyBQTQ0KPiBU bzogTWF0dCBNaWxsZXIgKG1hbWlsbGUyKTsgPGpvc2VAaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJl OiBbam9zZV0gUm9sbGluZyBQS0lYIGludG8gSldLDQo+IA0KPiBJIGFncmVlLCBhIGNlcnRpZmlj YXRlIGFzIGFuIG9wdGlvbmFsIGZpZWxkIG9mIGFueSBKV0sgc291bmRzIGxpa2UgYQ0KPiBkZWNl bnQgYXBwcm9hY2guDQo+IA0KPiBQdXR0aW5nIGEgd2hvbGUgY2VydCBjaGFpbiBpbiBvbmUgSldL IGlzIG5vdCBpZGVhbC4NCj4gRWFjaCBjZXJ0IGlzIGFib3V0IDEga2V5IHNvIHJlYWxseSBzaG91 bGQgYmUgaW4gaXRzIG93biBKV0suDQo+IE90aGVyd2lzZSB5b3Ugd2lsbCBkdXBsaWNhdGUgdGhl IGNoYWluIG9mIGludGVybWVkaWF0ZSBDQSBjZXJ0cyBpbiBlYWNoDQo+IEpXSyBpbiBhIHNldC4N Cj4gDQo+IEl0IG1pZ2h0IGJlIHVzZWZ1bCB0byBkZWZpbmUgYSBpc3N1ZXIga2V5LWlkIGZpZWxk ICgiaXNza2lkIikuIEEgSldLDQo+IGNvdWxkIGluY2x1ZGUgYSBjZXJ0IGZvciBpdHMgb3duIGtl eSBhbmQgKHdpdGggImlzc2tpZCIpIGEgbGluayB0byB0aGUNCj4gbmV4dCBjZXJ0IGFsb25nIHRo ZSBjaGFpbi4gVGhhdCBtYWtlcyBpdCBxdWljay1uLWVhc3kgdG8gYnVpbGQgYSBjaGFpbg0KPiBm cm9tIHRoZSBKV0tzIGluIGEgc2V0Lg0KPiANCj4gSXQgd291bGQgYWxzbyBoZWxwIGlmIEpXS3Mg aW4gYSBzZXQgd2hlcmUgaGVsZCBpbiBhDQo+IG9iamVjdC9kaWN0aW9uYXJ5L2Fzc29jaWF0aXZl LWFycmF5IHdpdGggdGhlIGtpZCBhcyB0aGUgbmFtZS4gVGhhdA0KPiB3b3VsZCBiZSBiZXR0ZXIg dGhhbiB1c2luZyBhbiBhcnJheSBvZiBKV0tzIHdpdGggbm8gZGVmaW5lZCBtZWFuaW5nIGZvcg0K PiB0aGUgb3JkZXIuDQo+IA0KPiAtLQ0KPiBKYW1lcyBNYW5nZXINCj4gDQo+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZg0KPiA+IE1hdHQgTWlsbGVy IChtYW1pbGxlMikNCj4gPiBTZW50OiBGcmlkYXksIDE1IE1hcmNoIDIwMTMgMTI6NDggQU0NCj4g PiBUbzogPGpvc2VAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogW2pvc2VdIFJvbGxpbmcgUEtJWCBp bnRvIEpXSw0KPiA+DQo+ID4gW2hvcGluZyB0aGlzIHRvcGljIGlzIHRoZSBsZWFzdCBjb250cm92 ZXJzaWFsLi4uXQ0KPiA+DQo+ID4gSW4gc29tZSBJUkwgZGlzY3Vzc2lvbnMgb24gbW92aW5nIGZv cndhcmQgb24gUEtJWCBpbiBKV0ssIEkndmUgYmVlbg0KPiA+IGNvbnZpbmNlZCB0aGUgY29uY2Vy bnMgYXJlIG1vc3RseSB0aGUgc2FtZSByZWdhcmRsZXNzIG9mIGhvdyB0aGUgUEtJWA0KPiA+IGlz IHBhY2thZ2VkLiAgR2l2ZW4gdGhhdCwgSSB3b3VsZCBzdWdnZXN0IHdlIG1ha2UgIng1YyIgYW4g b3B0aW9uYWwNCj4gPiBmaWVsZCBvZiBKV0ssIHJhdGhlciB0aGFuIGRlZmluaW5nIGEgbmV3IEpX SyB0eXBlLiAgSSBjYW4gcHJvcG9zZQ0KPiA+IHZhcmlvdXMgdGV4dCBhZGRpdGlvbnMgYWZ0ZXIg dGhpcyBtZWV0aW5nLg0KPiA+DQo+ID4NCj4gPiBUaG91Z2h0cz8NCj4gPg0KPiA+IC0gbSZtDQo+ ID4NCj4gPiBNYXR0IE1pbGxlciA8IG1hbWlsbGUyQGNpc2NvLmNvbSA+DQo+ID4gQ2lzY28gU3lz dGVtcywgSW5jLg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gam9zZSBtYWlsaW5nIGxpc3QNCj4gam9zZUBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg== From bew@cisco.com Fri Mar 15 09:02:39 2013 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 026CA21F8803; Fri, 15 Mar 2013 09:02:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 i6mdtqJn8vSz; Fri, 15 Mar 2013 09:02:38 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 636D421F87EA; Fri, 15 Mar 2013 09:02:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=810; q=dns/txt; s=iport; t=1363363357; x=1364572957; h=from:content-transfer-encoding:subject:message-id:date: to:mime-version; bh=ha6RSLJEZDJEYxfk/4Yyx3vnhywEXMFDjgy5rKJqh6k=; b=LxQDfJplWHE34m/6OI/ZvJbL8h4wJMstOJfFOxie+uZsUGDvSi6wt606 N9lnQ2/c3b9fdzNYnMPTUixp8x0X2QgayAX0R49n6OM4GMBg8Ma9lvcOA 8WGXnmRHyUzMq/PygO5BG8RdRMH7NS1Oo/ZMMbcEb1VpXkDQ0qsf8c91Z E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAI1EQ1GrRDoG/2dsb2JhbABDh2y/FxZ0gi+COhuICg3DBpF7YQOWW4V9iwWDJiA X-IronPort-AV: E=Sophos;i="4.84,850,1355097600"; d="scan'208";a="73044972" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 15 Mar 2013 16:00:59 +0000 Received: from [10.21.119.81] ([10.21.119.81]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r2FG0qA2029693; Fri, 15 Mar 2013 16:00:58 GMT From: Brian Weis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Date: Fri, 15 Mar 2013 11:42:52 -0400 To: jose@ietf.org, cfrg@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [jose] Use of authenticated encryption for key wrapping 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, 15 Mar 2013 16:02:39 -0000 Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." So if one considers that to be good enough advice, AES-GCM would indeed = be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. Brian=20= From Michael.Jones@microsoft.com Fri Mar 15 09:15:45 2013 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 6F3C821F86CB for ; Fri, 15 Mar 2013 09:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.936 X-Spam-Level: X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.663, BAYES_00=-2.599] 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 Yb7B0LvAyT45 for ; Fri, 15 Mar 2013 09:15:44 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id 6D26121F8654 for ; Fri, 15 Mar 2013 09:15:39 -0700 (PDT) Received: from BL2FFO11FD002.protection.gbl (10.173.161.203) by BL2FFO11HUB026.protection.gbl (10.173.161.50) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:15:36 +0000 Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD002.mail.protection.outlook.com (10.173.160.102) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:15:36 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:14:48 +0000 From: Mike Jones To: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Thread-Topic: Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIY/+XkwMmtTxxUOFp1D/v1T3ZZim6+BA Date: Fri, 15 Mar 2013 16:14:48 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> In-Reply-To: <51433B12.1020703@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(13464002)(51704002)(164054002)(189002)(199002)(59766001)(5343655001)(4396001)(79102001)(77982001)(50466001)(69226001)(65816001)(46102001)(49866001)(20776003)(33656001)(46406002)(50986001)(76482001)(551544001)(47446002)(16406001)(80022001)(512954001)(74662001)(63696002)(54316002)(74502001)(23726001)(15202345001)(47736001)(56776001)(44976002)(66066001)(31966008)(47976001)(55846006)(51856001)(5343635001)(53806001)(56816002)(47776003)(54356001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB026; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 16:15:45 -0000 [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]=20 Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000).=20 Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > To: "cfrg@irtf.org" > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > =09 > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > =09 > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was=20 > scrubbed... > URL:=20 > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > From rlb@ipv.sx Fri Mar 15 09:43:18 2013 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 53AEE21F86DE for ; Fri, 15 Mar 2013 09:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.435 X-Spam-Level: X-Spam-Status: No, score=-0.435 tagged_above=-999 required=5 tests=[AWL=-0.010, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 QXwAyPjsb89C for ; Fri, 15 Mar 2013 09:43:17 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EA97A21F8881 for ; Fri, 15 Mar 2013 09:43:15 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id uz6so3396510obc.20 for ; Fri, 15 Mar 2013 09:43:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GNyai0NY0ud8mJSWozwZJkyGPhLhn3SEduTa9Bs/FD8=; b=aIKvrKDbH8ebT1ZX6CtDBuBeKc0qQqVc90FcZZLAHxlT3qrawDZNrfNQcmg4SmNPW0 KmPD7xPapI52RxFqY8sQbKOYq0R9RLQ3tYUswEpIGMTLf199OPS4RT1/k8v3S0o3XyK2 0UnPW1tiAP33hfG6LVL6Uq3gRkvu7nEwXZLER4N7OQnWp1VAEtHqqYrx3Y7V5yJmWBDq gzpULkYGmbx0L5GNvaDTlUzGmKx6ja6R56uEE/FQ4VoP0Xo8otYJvf3QCTnFOQQ2Dmwm jT53ouqgjm1F+kEuz+Bn9Tg23pYu8LzDtZNwvWK0dLg6TigpyZEXZtfzMsIWh1o2gvAR sI3A== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr3097159oea.130.1363365794408; Fri, 15 Mar 2013 09:43:14 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 09:43:14 -0700 (PDT) X-Originating-IP: [128.89.254.149] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 15 Mar 2013 12:43:14 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb20318e0001104d7f95560 X-Gm-Message-State: ALoCoQm33H2TDVPRYy0Q3rEhw2POloBoasK/4JgY/wQ0fbff5j0paqf3MLrIJm1DIyANx8g4GvWP Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 16:43:18 -0000 --e89a8fb20318e0001104d7f95560 Content-Type: text/plain; charset=ISO-8859-1 So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrapping algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones wrote: > [Adding JOSE mailing list to the thread] > > For clarification, PBKDF2 is not the only algorithm that could be used to > wrap keys in this scheme. This draft *adds* PBKDF2 to the set of > algorithms already specified for use with encryption in the JSON Web > Algorithms (JWA) specification ( > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In > particular, other algorithms such as AES Key Wrap and AES GCM are also > present there. > > I'll let others who are experts in PBKDF2 and password-based encryption > respond to Yaron's specific comment. > > -- Mike > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Friday, March 15, 2013 8:16 AM > To: cfrg@irtf.org; Mike Jones > Subject: Re: Draft describing encrypting JWK key representations, with JWE > > Hi Mike, > > I'm probably missing something, but I'm worried about the security of this > scheme (though I do appreciate the usability/convenience of passwords). > > PBKDF2 is meant to make dictionary attacks on stored passwords harder, as > a second line defense, once the server has been breached. Using it to > encrypt data and then sending the data on the wire, makes the data > vulnerable to this same dictionary attack (in this case the effort comes to > the space of all possible passwords - say 1 million - times 1000). > Moreover, this also puts the password itself in danger. > > Thanks, > Yaron > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 15 Mar 2013 14:10:32 +0000 > > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > > with JWE > > Message-ID: > > > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > > microsoft.com> > > > > Content-Type: text/plain; charset="us-ascii" > > > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > > > This also adds password-based encryption to the algorithm registry. > > > > -- Mike > > > > -------------- next part -------------- An HTML attachment was > > scrubbed... > > URL: > > > 24/attachment.htm> > > > > ------------------------------ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > > > End of Cfrg Digest, Vol 95, Issue 3 > > *********************************** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --e89a8fb20318e0001104d7f95560 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm?

--Richard



On Fri, Mar 15, 2013 at 12:14 PM, Mi= ke Jones <Michael.Jones@microsoft.com> wrote:
[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. =A0This draft *adds* PBKDF2 to the set of algorith= ms already specified for use with encryption in the JSON Web Algorithms (JW= A) specification (http://tools.ietf.org/html/draft-iet= f-jose-json-web-algorithms-08). =A0In particular, other algorithms such= as AES Key Wrap and AES GCM are also present there.

I'll let others who are experts in PBKDF2 and password-based encryption= respond to Yaron's specific comment.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf= .ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security = of this scheme (though I do appreciate the usability/convenience of passwor= ds).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
=A0 =A0 =A0 =A0 Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Mi= chael.Jones@microsoft.com>
> To: "cfrg@irtf.org" <= ;cfrg@irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations > =A0 =A0 =A0 with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.co= rp.
> microsoft.com&g= t;
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-= protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--e89a8fb20318e0001104d7f95560-- From Michael.Jones@microsoft.com Fri Mar 15 09:49:24 2013 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 1A57F21F8511 for ; Fri, 15 Mar 2013 09:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1h7lTy-xx6Q6 for ; Fri, 15 Mar 2013 09:49:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0209.outbound.protection.outlook.com [207.46.163.209]) by ietfa.amsl.com (Postfix) with ESMTP id C9BEF21F84F9 for ; Fri, 15 Mar 2013 09:49:22 -0700 (PDT) Received: from BL2FFO11FD010.protection.gbl (10.173.161.200) by BL2FFO11HUB018.protection.gbl (10.173.160.110) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 16:49:14 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD010.mail.protection.outlook.com (10.173.161.16) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 16:49:14 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 16:48:51 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIZw3PQRi1iNdgk2MdX9lp+JWfJim9Wcw Date: Fri, 15 Mar 2013 16:48:50 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(164054002)(13464002)(51704002)(24454001)(199002)(377454001)(49866001)(51856001)(16236675001)(31966008)(20776003)(56816002)(76482001)(66066001)(5343655001)(16601075001)(5343635001)(50986001)(55846006)(16297215001)(65816001)(47446002)(46102001)(4396001)(74502001)(54356001)(74662001)(54316002)(56776001)(79102001)(53806001)(47976001)(80022001)(512954001)(44976002)(63696002)(47736001)(33656001)(59766001)(16406001)(77982001)(69226001)(551544001)(15202345001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB018; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 16:49:24 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's up to the working group. I'm actually hoping that experts on the li= sts will respond to Yaron's comments before we make a decision on whether P= BKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part= of one, the PBKDF2 definition would end up in the algorithms registry eith= er way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That’s up to the wo= rking group.  I’m actually hoping that experts on the lists will= respond to Yaron’s comments before we make a decision on whether PBK= DF2 as specified is an appropriate key wrapping algorithm or not.

 <= /p>

Assuming that the content= in Matt’s draft eventually becomes an RFC or part of one, the PBKDF2= definition would end up in the algorithms registry either way, even if it’s not part of the JWA spec itself.

 <= /p>

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

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / J= WA, as a new key wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme.  This draft *adds* PBKDF2 to the set of algor= ithms already specified for use with encryption in the JSON Web Algorithms = (JWA) specification (http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are= also present there.

I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment.

                     = ;           -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf= .ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Mi= chael.Jones@microsoft.com>
> To: "cfrg@irtf.org" <= ;cfrg@irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations >       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14M= BXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
>                     =                      = ;                    -- M= ike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367526789TK5EX14MBXC284r_-- From rlb@ipv.sx Fri Mar 15 09:49:50 2013 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 DA1D221F8454 for ; Fri, 15 Mar 2013 09:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=1.267, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 UBaMOzFP1gwX for ; Fri, 15 Mar 2013 09:49:50 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46821F8536 for ; Fri, 15 Mar 2013 09:49:48 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so3559066oag.39 for ; Fri, 15 Mar 2013 09:49:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=KWoiAk4o6OVJlVqZ3xjGUQ9Zzfh1gNVIkrGVanJvVb0=; b=aaX3E8V+pgSnlraUiAxn8qgaiUizp/PpXuK8auzu1cRSBKKftAoTsBTYtyctEk95CI FdtS7iNSJwlIrEsBh2+OMips12iUrQnyTafC9Tf602IFxRh7s9hjqaEfBA6Ck8cYES5H V1XmROqvtim8Hr+WSUJYbTi9EgLsEWzF/VDgaj9fLN9pLFQBP/NnpPLo9ftM5FzgEV28 ysczFOaPn1kc+8FZP419LAzE6fMkOCMCimKeai9j4uJSyngOZOdtHnz4WwoYwnAe/P7T gtu1j5QVeH6ngBS/XhtE3TQqmqFjRfsQS0PvnVFUspTHTwB5TKNIusrJ4Ign81vuBGie 2jGg== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr3239871oec.116.1363366188127; Fri, 15 Mar 2013 09:49:48 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 09:49:48 -0700 (PDT) X-Originating-IP: [128.89.254.149] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 15 Mar 2013 12:49:48 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=bcaec5523bb657aa8e04d7f96d41 X-Gm-Message-State: ALoCoQnIMTCt0iBNZ6HyV9GFZum+4lBImnfdI3dDA1gvXQBKQhPq0tpY8RwdOUsoJzVW1Y1cpD4Y Cc: "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 16:49:51 -0000 --bcaec5523bb657aa8e04d7f96d41 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > I agree, a certificate as an optional field of any JWK sounds like a > decent approach. > +1, although it's not mutually exclusive with having a "PKIX" key type. > Putting a whole cert chain in one JWK is not ideal. > Each cert is about 1 key so really should be in its own JWK. > Otherwise you will duplicate the chain of intermediate CA certs in each > JWK in a set. > > It might be useful to define a issuer key-id field ("isskid"). A JWK could > include a cert for its own key and (with "isskid") a link to the next cert > along the chain. That makes it quick-n-easy to build a chain from the JWKs > in a set. > > It would also help if JWKs in a set where held in a > object/dictionary/associative-array with the kid as the name. That would be > better than using an array of JWKs with no defined meaning for the order. > This proposal seems much, much worse than having a cert chain in one JWK. If you're going to have all the public keys as JWKs, you might as well just re-invent X.509 in JWK, in which case you would probably use JWS over JWK, which solves the "isskid" problem using the "kid" in the JWS. The benefit of having the cert chain is that you don't have to re-invent X.509, you just pass the cert chain to your existing X.509 library. In other words, let's have the trust chain be fully X.509 or fully JOSE, even if it starts from a JWK. --Richard > > -- > James Manger > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Matt Miller (mamille2) > > Sent: Friday, 15 March 2013 12:48 AM > > To: > > Subject: [jose] Rolling PKIX into JWK > > > > [hoping this topic is the least controversial...] > > > > In some IRL discussions on moving forward on PKIX in JWK, I've been > > convinced the concerns are mostly the same regardless of how the PKIX > > is packaged. Given that, I would suggest we make "x5c" an optional > > field of JWK, rather than defining a new JWK type. I can propose > > various text additions after this meeting. > > > > > > Thoughts? > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --bcaec5523bb657aa8e04d7f96d41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H <James.H.Ma= nger@team.telstra.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> I agree, a certificate as an optional field of any JWK sounds like a decent= approach.

+1, although it's not mu= tually exclusive with having a "PKIX" key type.
=A0
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK= in a set.

It might be useful to define a issuer key-id field ("isskid"). A = JWK could include a cert for its own key and (with "isskid") a li= nk to the next cert along the chain. That makes it quick-n-easy to build a = chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/assoc= iative-array with the kid as the name. That would be better than using an a= rray of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cert chai= n in one JWK. =A0If you're going to have all the public keys as JWKs, y= ou might as well just re-invent X.509 in JWK, in which case you would proba= bly use JWS over JWK, which solves the "isskid" problem using the= "kid" in the JWS. =A0The benefit of having the cert chain is tha= t you don't have to re-invent X.509, you just pass the cert chain to yo= ur existing X.509 library. =A0

In other words, let's have the trust chain be fully= X.509 or fully JOSE, even if it starts from a JWK. =A0

--Richard


=A0

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.org>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've bee= n
> convinced the concerns are mostly the same regardless of how the PKIX<= br> > is packaged. =A0Given that, I would suggest we make "x5c" an= optional
> field of JWK, rather than defining a new JWK type. =A0I can propose > various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.= com >
> Cisco Systems, Inc.

_______________________= ________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--bcaec5523bb657aa8e04d7f96d41-- From rlb@ipv.sx Fri Mar 15 09:53:04 2013 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 0712C21F85A0 for ; Fri, 15 Mar 2013 09:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.531 X-Spam-Level: X-Spam-Status: No, score=-0.531 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 UNmywxm3-m-j for ; Fri, 15 Mar 2013 09:53:03 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id C071921F8598 for ; Fri, 15 Mar 2013 09:53:01 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id ef5so3374745obb.39 for ; Fri, 15 Mar 2013 09:53:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wCBkIiS8EpvLNC7IutvEHAGZn6QL/7uMbYV15g6kkck=; b=bDSkwSB9pfFzjxbdLFQwToclFdV1/bX3i2fVUZCx74bffCW2FgdpBb7qVKZqOD17iA x7gXrdx4/ayNctC/qdWEF5wBCxXCX/TbTtd8sYc3RzTQ7ggpVElyrNmlZgkaTETzoq/F dUd7A51/mzCT5mjRZM7pdDhza+NXECIbE9APMKeoTU0Bd1bEq4hq/LXvL0gieyOKKuBm jt9roLNPNj7gVfb6vUpNwTKK+Y5XUqp4QSbtoNlTzb4DYaC2uX4p9eL/+vXaXm+NF+ey gDHzPIMKx2Z16VVBOLr0Ufb8+YpKFiHlVVbigEPiCHuw9ZIDzaVe2E0Oz0sHEgkmm9V7 zmGg== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr3244942oec.116.1363366380696; Fri, 15 Mar 2013 09:53:00 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 09:53:00 -0700 (PDT) X-Originating-IP: [128.89.254.149] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> Date: Fri, 15 Mar 2013 12:53:00 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec5523bb6d1fbcb04d7f9786f X-Gm-Message-State: ALoCoQnNM32GGl95s8E7036dro5aiUthyDv7IANRgfRd0EsyWB3ILxZPKNEChZtv8pSvP0gJrWfR Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 16:53:04 -0000 --bcaec5523bb6d1fbcb04d7f9786f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., having a high number of iterations. We might want to make some recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones w= rote: > That=92s up to the working group. I=92m actually hoping that experts on= the > lists will respond to Yaron=92s comments before we make a decision on whe= ther > PBKDF2 as specified is an appropriate key wrapping algorithm or not.**** > > ** ** > > Assuming that the content in Matt=92s draft eventually becomes an RFC or > part of one, the PBKDF2 definition would end up in the algorithms registr= y > either way, even if it=92s not part of the JWA spec itself.**** > > ** ** > > Cheers,**** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 15, 2013 9:43 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org > *Subject:* Re: [jose] Draft describing encrypting JWK key > representations, with JWE**** > > ** ** > > So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key > wrapping algorithm?**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > ** ** > > On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote:**** > > [Adding JOSE mailing list to the thread] > > For clarification, PBKDF2 is not the only algorithm that could be used to > wrap keys in this scheme. This draft *adds* PBKDF2 to the set of > algorithms already specified for use with encryption in the JSON Web > Algorithms (JWA) specification ( > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In > particular, other algorithms such as AES Key Wrap and AES GCM are also > present there. > > I'll let others who are experts in PBKDF2 and password-based encryption > respond to Yaron's specific comment. > > -- Mike > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] > Sent: Friday, March 15, 2013 8:16 AM > To: cfrg@irtf.org; Mike Jones > Subject: Re: Draft describing encrypting JWK key representations, with JW= E > > Hi Mike, > > I'm probably missing something, but I'm worried about the security of thi= s > scheme (though I do appreciate the usability/convenience of passwords). > > PBKDF2 is meant to make dictionary attacks on stored passwords harder, as > a second line defense, once the server has been breached. Using it to > encrypt data and then sending the data on the wire, makes the data > vulnerable to this same dictionary attack (in this case the effort comes = to > the space of all possible passwords - say 1 million - times 1000). > Moreover, this also puts the password itself in danger. > > Thanks, > Yaron > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 15 Mar 2013 14:10:32 +0000 > > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > > with JWE > > Message-ID: > > > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp.%0= b>> > microsoft.com> > > > > Content-Type: text/plain; charset=3D"us-ascii" > > > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > > > This also adds password-based encryption to the algorithm registry. > > > > -- Mike > > > > -------------- next part -------------- An HTML attachment was > > scrubbed... > > URL: > > > 24/attachment.htm> > > > > ------------------------------ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > > > End of Cfrg Digest, Vol 95, Issue 3 > > *********************************** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --bcaec5523bb6d1fbcb04d7f9786f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Do I count as an expert? =A0:)

As I understand it, PBDKF= 2 is completely fine for key protection. =A0PBKDF2 has mechanisms to mitiga= te the dictionary attack risks, e.g., having a high number of iterations. W= e might want to make some recommendations as to how you set those parameter= s. And the actual key wrapping is done with something like AES-KW, so that = step is fine.

So I would be completely fine with adding this to JWE /= JWA. =A0We should do this.

--Richard


On Fri, Mar 15, 2013 at 12:= 48 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:

That=92s up to the workin= g group. =A0I=92m actually hoping that experts on the lists will respond to= Yaron=92s comments before we make a decision on whether PBKDF2 as specified is an appropriate key wrapping algorithm or not.

=A0<= /p>

Assuming that the content= in Matt=92s draft eventually becomes an RFC or part of one, the PBKDF2 def= inition would end up in the algorithms registry either way, even if it=92s not part of the JWA spec itself.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Cheers,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jos= e@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

=A0

So, Mike, would you be OK with adding PBE to JWE / J= WA, as a new key wrapping algorithm?

=A0

--Richard

=A0

=A0

=A0

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. =A0This draft *adds* PBKDF2 to the set of algorith= ms already specified for use with encryption in the JSON Web Algorithms (JW= A) specification (http://tools.ietf.org/html/draft-iet= f-jose-json-web-algorithms-08). =A0In particular, other algorithms such as AES Key Wrap and AES GCM are al= so present there.

I'll let others who are experts in PBKDF2 and password-based encryption= respond to Yaron's specific comment.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; M= ike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security = of this scheme (though I do appreciate the usability/convenience of passwor= ds).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
=A0 =A0 =A0 =A0 Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf= .org" <cfrg@= irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations > =A0 =A0 =A0 with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394= 367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0-- Mike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--bcaec5523bb6d1fbcb04d7f9786f-- From ve7jtb@ve7jtb.com Fri Mar 15 09:58:58 2013 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 092ED21F858B for ; Fri, 15 Mar 2013 09:58:58 -0700 (PDT) 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 kKJoJKKG+yyK for ; Fri, 15 Mar 2013 09:58:55 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id D6D5321F8883 for ; Fri, 15 Mar 2013 09:57:58 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4078422pbb.32 for ; Fri, 15 Mar 2013 09:57:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=IrRE2RQI8Pd9Mbtd0tyvA3aU1TVwxM8dg3YncpMCT0I=; b=Qrnz4I06L24+eyU7vZ4aV+AUPcVSx9GagOVbh7mX3IqQqYrJGf8aDDIKBAaOC8RKEJ OIZgkM7/XylW4uhzwRWGP9a+nAybaQNtG3oBvhXoCrUjxKdPL1159t6TvPCpPQ8vm7/a YTUu7LyqoLVb3PaGe3oGpwKN7xR1dPatt84gMpUQgn2Tx3J27g0fO6I++dxaI14Ap5YM gFzpSKG3xPDPbOt3G6ovPxu2FvYin/uEWI6T8X0cMhZqgsN4q+2ooVSDopVAWYrtFyW4 hoJ7MBLh7R3r40Y7cX3SjnW7fAB/PCH9vc1/ha7CxmR5ZYtuOG5sxj6Lii6s/FPbSAia AWlQ== X-Received: by 10.68.223.138 with SMTP id qu10mr17820104pbc.89.1363366675132; Fri, 15 Mar 2013 09:57:55 -0700 (PDT) Received: from dhcp-543c.meeting.ietf.org (dhcp-543c.meeting.ietf.org. [130.129.84.60]) by mx.google.com with ESMTPS id ax3sm9600527pbd.42.2013.03.15.09.57.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 09:57:52 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5FA65C53-F30B-4DCB-9159-67F9258A2B98"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 15 Mar 2013 12:57:48 -0400 Message-Id: <40C9C629-E2B9-4612-A86F-61482A176FF2@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> To: Richard Barnes X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQmC3wpKtTI3hAqN/wTIrOnbx556sgQXIr8J97qtKuqGumafh5neuH/MAAtsF57Zs9qdhunW Cc: "Manger, James H" , "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 16:58:58 -0000 --Apple-Mail=_5FA65C53-F30B-4DCB-9159-67F9258A2B98 Content-Type: multipart/alternative; boundary="Apple-Mail=_C5AD5F50-092D-4A44-AFEC-E51D8D95DF33" --Apple-Mail=_C5AD5F50-092D-4A44-AFEC-E51D8D95DF33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Agreed, having the cert chain in the x5u is optional, having it for = validation if you want that trust chain is not a problem. Trying to = optimize that for size is going to be too complicated. John B. On 2013-03-15, at 12:49 PM, Richard Barnes wrote: > On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H = wrote: > I agree, a certificate as an optional field of any JWK sounds like a = decent approach. >=20 > +1, although it's not mutually exclusive with having a "PKIX" key = type. > =20 > Putting a whole cert chain in one JWK is not ideal. > Each cert is about 1 key so really should be in its own JWK. > Otherwise you will duplicate the chain of intermediate CA certs in = each JWK in a set. >=20 > It might be useful to define a issuer key-id field ("isskid"). A JWK = could include a cert for its own key and (with "isskid") a link to the = next cert along the chain. That makes it quick-n-easy to build a chain = from the JWKs in a set. >=20 > It would also help if JWKs in a set where held in a = object/dictionary/associative-array with the kid as the name. That would = be better than using an array of JWKs with no defined meaning for the = order. >=20 > This proposal seems much, much worse than having a cert chain in one = JWK. If you're going to have all the public keys as JWKs, you might as = well just re-invent X.509 in JWK, in which case you would probably use = JWS over JWK, which solves the "isskid" problem using the "kid" in the = JWS. The benefit of having the cert chain is that you don't have to = re-invent X.509, you just pass the cert chain to your existing X.509 = library. =20 >=20 > In other words, let's have the trust chain be fully X.509 or fully = JOSE, even if it starts from a JWK. =20 >=20 > --Richard >=20 >=20 > =20 >=20 > -- > James Manger >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > > Matt Miller (mamille2) > > Sent: Friday, 15 March 2013 12:48 AM > > To: > > Subject: [jose] Rolling PKIX into JWK > > > > [hoping this topic is the least controversial...] > > > > In some IRL discussions on moving forward on PKIX in JWK, I've been > > convinced the concerns are mostly the same regardless of how the = PKIX > > is packaged. Given that, I would suggest we make "x5c" an optional > > field of JWK, rather than defining a new JWK type. I can propose > > various text additions after this meeting. > > > > > > Thoughts? > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_C5AD5F50-092D-4A44-AFEC-E51D8D95DF33 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Agreed,  having the cert chain in the x5u is optional,  having it for validation if you want that trust chain is not a problem.   Trying to optimize that for size is going to be too complicated.

John B.

On 2013-03-15, at 12:49 PM, Richard Barnes <rlb@ipv.sx> wrote:

On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
I agree, a certificate as an optional field of any JWK sounds like a decent approach.

+1, although it's not mutually exclusive with having a "PKIX" key type.
 
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK in a set.

It might be useful to define a issuer key-id field ("isskid"). A JWK could include a cert for its own key and (with "isskid") a link to the next cert along the chain. That makes it quick-n-easy to build a chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/associative-array with the kid as the name. That would be better than using an array of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cert chain in one JWK.  If you're going to have all the public keys as JWKs, you might as well just re-invent X.509 in JWK, in which case you would probably use JWS over JWK, which solves the "isskid" problem using the "kid" in the JWS.  The benefit of having the cert chain is that you don't have to re-invent X.509, you just pass the cert chain to your existing X.509 library.  

In other words, let's have the trust chain be fully X.509 or fully JOSE, even if it starts from a JWK.  

--Richard


 

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.org>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've been
> convinced the concerns are mostly the same regardless of how the PKIX
> is packaged.  Given that, I would suggest we make "x5c" an optional
> field of JWK, rather than defining a new JWK type.  I can propose
> various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--Apple-Mail=_C5AD5F50-092D-4A44-AFEC-E51D8D95DF33-- --Apple-Mail=_5FA65C53-F30B-4DCB-9159-67F9258A2B98 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE1MTY1NzQ5WjAjBgkqhkiG9w0BCQQxFgQU2qdZUPJZ 2fqoXRh1m0iy1vwJRhQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAEsGn6s/IM0XOegTQyy55NXap1I0lZ/KpFmgmrk1b 464pp1q3kdcIWvUXW8aW0bMA4TZ/cTy5TKvA+CPqR55syq2d9/Btjr8a1hkoGMHnRhXSlIBZB3Lk wUUBUFCShKmZUIX0RWN2cHSwQxIpZRYCQ0RgkJBBnz8lHV5b87ooFNAy58CmQ/s8UuCHkAlcUsUe h0J3Ef82cj/LJ8pNeZragsCTK3B+dEXHye9q46lj+TuwYRifVXxh1ZQFIl9NuLbmYKl80DloD8Sv Q2IEbbjuo8oLL806ge0Ypwubvfz7l0LHITukaLKyQ0UpNNepow8g537qLWlgcbq7Remq9GE4UQAA AAAAAA== --Apple-Mail=_5FA65C53-F30B-4DCB-9159-67F9258A2B98-- From mpeck@mitre.org Fri Mar 15 09:59:08 2013 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 1A55F21F86A5 for ; Fri, 15 Mar 2013 09:59:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 OSwjGleMEWTM for ; Fri, 15 Mar 2013 09:59:01 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 572B221F85C9 for ; Fri, 15 Mar 2013 09:58:59 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 8FCA4226009F; Fri, 15 Mar 2013 12:58:46 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7E6E51F0478; Fri, 15 Mar 2013 12:58:46 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Fri, 15 Mar 2013 12:58:46 -0400 From: "Peck, Michael A" To: Richard Barnes , Mike Jones Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIY/+XkwMmtTxxUOFp1D/v1T3ZZim6+BAgABMbQCAAAGRAIAAASoA//+9NLA= Date: Fri, 15 Mar 2013 16:58:46 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFD5DFCIMCMBX04MITREOR_" MIME-Version: 1.0 Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 16:59:10 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFD5DFCIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 NIST Special Publication 800-132 provides recommendations for the parameter= s that the group may find useful. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf It may also be worth thinking about using PBKDF2 instead of the "dir" (Dire= ct Encryption with a Shared Symmetric Key) mechanism described in draft-iet= f-jose-json-web-algorithms-08 section 4.6. The shared symmetric key would = be used as the PBKDF2 "password", and this would force a new key to be used= for each encryption, rather than the current "dir" approach of using the s= ame encryption key repeatedly. Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Friday, March 15, 2013 12:53 PM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 h= as mechanisms to mitigate the dictionary attack risks, e.g., having a high = number of iterations. We might want to make some recommendations as to how = you set those parameters. And the actual key wrapping is done with somethin= g like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do = this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > wrote: That's up to the working group. I'm actually hoping that experts on the li= sts will respond to Yaron's comments before we make a decision on whether P= BKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part= of one, the PBKDF2 definition would end up in the algorithms registry eith= er way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B4C063947CD794BB6FF90C78BAE9B321EFD5DFCIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

NIST Special Publication = 800-132 provides recommendations for the parameters that the group may find= useful.

http://csrc.nist.gov/publ= ications/nistpubs/800-132/nist-sp800-132.pdf

 <= /p>

It may also be worth thin= king about using PBKDF2 instead of the “dir” (Direct Encryption= with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-w= eb-algorithms-08 section 4.6.  The shared symmetric key would be used as the PBKDF2 &#= 8220;password”, and this would force a new key to be used for each en= cryption, rather than the current “dir” approach of using the s= ame encryption key repeatedly.

 <= /p>

Mike

 <= /p>

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

Do I count as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for ke= y protection.  PBKDF2 has mechanisms to mitigate the dictionary attack= risks, e.g., having a high number of iterations. We might want to make som= e recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW= , so that step is fine.

 

So I would be completely fine with adding this to JW= E / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

That’s up to the working group. &= nbsp;I’m actually hoping that experts on the lists will respond to Ya= ron’s comments before we make a decision on whether PBKDF2 as specified is an ap= propriate key wrapping algorithm or not.

 

Assuming that the content in Matt’= ;s draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it’s not= part of the JWA spec itself.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   Cheers,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / JWA, as a new k= ey wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme.  This draft *adds* PBKDF2 to the set of algor= ithms already specified for use with encryption in the JSON Web Algorithms = (JWA) specification (http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are= also present there.

I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment.

                     = ;           -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; M= ike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf= .org" <cfrg@= irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations >       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394= 367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
>                     =                      = ;                    -- M= ike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFD5DFCIMCMBX04MITREOR_-- From rlb@ipv.sx Fri Mar 15 10:11:22 2013 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 47ACC21F8783 for ; Fri, 15 Mar 2013 10:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.868 X-Spam-Level: X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=0.508, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 pnP7D4Ph5li5 for ; Fri, 15 Mar 2013 10:11:21 -0700 (PDT) Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by ietfa.amsl.com (Postfix) with ESMTP id B3EC721F8548 for ; Fri, 15 Mar 2013 10:11:20 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id o6so3705419oag.32 for ; Fri, 15 Mar 2013 10:11:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=dcaLCY0vwTU6SJ2pzkHRRYTuScfTS8Rz9Wy6HiVDECI=; b=Wn0sACJXsiKVbK3s0izwj7ULwtTon8Zn7bBfpsbY0IVReeftmktDoHgzdQzpMrxnHZ MSOPRETjQraDSinpdBtoExQ4gwwvav0NzbrW8XeIH7nlJq/yrQd/LNsewB4XS22uU6N3 vKU4P3lmcQiK3XX922wRm3hYSmIJrDOzCT3a5inFjWo0hOFvg3tgpm8GeRXqmw/pSTsF au7dN98L7zU6zFpBQq8rsSFu6+RM7JIv93DJDHkTTIKam/sSCDDUevmYInfkU7GfKMZP h5ijKOqKjkFdpXGz3GUPW1o2+/UcQFmGYA8Er0s1kYtAOzIwhQW6j9FCmvq0W6ETSBVZ nj9w== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr3151304oea.130.1363367479546; Fri, 15 Mar 2013 10:11:19 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 10:11:19 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 15 Mar 2013 13:11:19 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=e89a8fb20318511fa604d7f9baca X-Gm-Message-State: ALoCoQmADPwHLup9JCvKek06z9EqofA3dAYH53EpiyguQ3J8mdSnFfrYz0/XwZijadQiVCTw0nVB Cc: "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 17:11:22 -0000 --e89a8fb20318511fa604d7f9baca Content-Type: text/plain; charset=ISO-8859-1 Just to clarify, what I'm suggesting is to have "x5c" as an attribute for JWK, with the same syntax as in JWS. As Brian suggested in his slides. IF we want to go down the path of having "chained" JWKs, the syntax would be something like the following: "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing key. IF we build something like this, it would be used in the same manner as "x5c", as an attribute of a JWK. However, I think designing such a thing would be a significant deviation from our charter, so we would need to recharter or even form a new WG (PKIJ?) --Richard On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes wrote: > On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: > >> I agree, a certificate as an optional field of any JWK sounds like a >> decent approach. >> > > +1, although it's not mutually exclusive with having a "PKIX" key type. > > >> Putting a whole cert chain in one JWK is not ideal. >> Each cert is about 1 key so really should be in its own JWK. >> Otherwise you will duplicate the chain of intermediate CA certs in each >> JWK in a set. >> >> It might be useful to define a issuer key-id field ("isskid"). A JWK >> could include a cert for its own key and (with "isskid") a link to the next >> cert along the chain. That makes it quick-n-easy to build a chain from the >> JWKs in a set. >> >> It would also help if JWKs in a set where held in a >> object/dictionary/associative-array with the kid as the name. That would be >> better than using an array of JWKs with no defined meaning for the order. >> > > This proposal seems much, much worse than having a cert chain in one JWK. > If you're going to have all the public keys as JWKs, you might as well > just re-invent X.509 in JWK, in which case you would probably use JWS over > JWK, which solves the "isskid" problem using the "kid" in the JWS. The > benefit of having the cert chain is that you don't have to re-invent X.509, > you just pass the cert chain to your existing X.509 library. > > In other words, let's have the trust chain be fully X.509 or fully JOSE, > even if it starts from a JWK. > > --Richard > > > > >> >> -- >> James Manger >> >> > -----Original Message----- >> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> > Matt Miller (mamille2) >> > Sent: Friday, 15 March 2013 12:48 AM >> > To: >> > Subject: [jose] Rolling PKIX into JWK >> > >> > [hoping this topic is the least controversial...] >> > >> > In some IRL discussions on moving forward on PKIX in JWK, I've been >> > convinced the concerns are mostly the same regardless of how the PKIX >> > is packaged. Given that, I would suggest we make "x5c" an optional >> > field of JWK, rather than defining a new JWK type. I can propose >> > various text additions after this meeting. >> > >> > >> > Thoughts? >> > >> > - m&m >> > >> > Matt Miller < mamille2@cisco.com > >> > Cisco Systems, Inc. >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > --e89a8fb20318511fa604d7f9baca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Just to clarify, what I'm suggesting is to have "x5c" as an a= ttribute for JWK, with the same syntax as in JWS. =A0As Brian suggested in = his slides.

IF we want to go down the path of having &qu= ot;chained" JWKs, the syntax would be something like the following:
"jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ]
= Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing= key. =A0IF we build something like this, it would be used in the same mann= er as "x5c", as an attribute of a JWK. =A0However, I think design= ing such a thing would be a significant deviation from our charter, so we w= ould need to recharter or even form a new WG (PKIJ?)

--Richard



On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <rlb@ipv.sx= > wrote:
On Fri, Mar 15, 2013 at 2:= 43 AM, Manger, James H <James.H.Manger@team.telstra.com&= gt; wrote:
I agree, a certificate as an optional field of any JWK sounds like a decent= approach.

+1, although it's = not mutually exclusive with having a "PKIX" key type.
=A0
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK= in a set.

It might be useful to define a issuer key-id field ("isskid"). A = JWK could include a cert for its own key and (with "isskid") a li= nk to the next cert along the chain. That makes it quick-n-easy to build a = chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/assoc= iative-array with the kid as the name. That would be better than using an a= rray of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cer= t chain in one JWK. =A0If you're going to have all the public keys as J= WKs, you might as well just re-invent X.509 in JWK, in which case you would= probably use JWS over JWK, which solves the "isskid" problem usi= ng the "kid" in the JWS. =A0The benefit of having the cert chain = is that you don't have to re-invent X.509, you just pass the cert chain= to your existing X.509 library. =A0

In other words, let's have the trust chain be fully= X.509 or fully JOSE, even if it starts from a JWK. =A0

--Richard
=


=A0

--
James Manger

> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.o= rg>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've bee= n
> convinced the concerns are mostly the same regardless of how the PKIX<= br> > is packaged. =A0Given that, I would suggest we make "x5c" an= optional
> field of JWK, rather than defining a new JWK type. =A0I can propose > various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8fb20318511fa604d7f9baca-- From rlb@ipv.sx Fri Mar 15 10:13:20 2013 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 A846921F8824 for ; Fri, 15 Mar 2013 10:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=0.681, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 TF1lph-BJIGJ for ; Fri, 15 Mar 2013 10:13:18 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) by ietfa.amsl.com (Postfix) with ESMTP id F31C821F878F for ; Fri, 15 Mar 2013 10:13:12 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id i18so3699269oag.1 for ; Fri, 15 Mar 2013 10:13:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=PGJXn3LvWRtWfcSuycRNr8EzhvdXFQPkQA9U//C/kdw=; b=VobQfqqTRKqu876zK6zNmNLEFRgITcbC0iqX+9qqGinc403XG7iqCcKFhff9ZkExYD z6HIX9aJ7+VP/pefslnMpvUlSihQJA1g+uY+7QVC7gWDgxYjt9tsx1m3i05bwRutGXys ZCGp6tHH305Uo9wlKts0GKtNaw4VnYRB3kPF5HcKFHHzX7txKGwfbrfEBSmLLSbzELMg RUN3OByXaNz2G+pWwGaQ3+OILkbIqK/AwNSokD8PoiR49NQVP0+72yKs32XedpFIDCQz AVriRXuZ6dJCtzDbtn/sIu+Mi1aHuVweY2PT/Im/FJylX2mgEOgIAfvXcCeFo03npE2J +J8w== MIME-Version: 1.0 X-Received: by 10.60.171.50 with SMTP id ar18mr3207723oec.24.1363367591316; Fri, 15 Mar 2013 10:13:11 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 10:13:11 -0700 (PDT) X-Originating-IP: [130.129.20.81] In-Reply-To: <397B382EC2E6D9479F9A5D6D050FB70747A87334@WO-SFOEXCH-02.wideorbit.com> References: <5141D681.2090404@mnt.se> <5141D786.5040308@mnt.se> <397B382EC2E6D9479F9A5D6D050FB70747A87334@WO-SFOEXCH-02.wideorbit.com> Date: Fri, 15 Mar 2013 13:13:11 -0400 Message-ID: From: Richard Barnes To: Steffen Yount Content-Type: multipart/alternative; boundary=bcaec550af3afa926b04d7f9c08a X-Gm-Message-State: ALoCoQm3nNRYyDQbr677VffymsCFKK2a+asZ36QEPn5IH5iG+g8IiQdFcPUiSapaleg73pt4kr5K Cc: Leif Johansson , "jose@ietf.org" Subject: Re: [jose] MTI algorithms 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, 15 Mar 2013 17:13:20 -0000 --bcaec550af3afa926b04d7f9c08a Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you're going to do that, you might as well punt entirely, since an application could define its own "JOSE crypto profile". Which would be fine with me; I think it's the applications that should be defining this stuff anyway. --Richard On Thu, Mar 14, 2013 at 3:46 PM, Steffen Yount wrote= : > Would it be better to keep MTI out of the jose container specs, by > declaring jose crypto profiles separately, where jose libraries that want > to claim =93jose compliance=94 would have to meet the MTIs as defined in = those > jose crypto profiles?**** > > ** ** > > **** > > ** ** > > ** ** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Leif Johansson > *Sent:* Thursday, March 14, 2013 6:59 AM > *To:* Richard Barnes > *Cc:* jose@ietf.org > *Subject:* Re: [jose] MTI algorithms**** > > ** ** > > On 03/14/2013 02:57 PM, Richard Barnes wrote:**** > > ** ** > > > I noted yesterday a concern that many things that should be counted as > > JOSE implementations could actually be ruled out if we have MTI > > algorithms. > > > >**** > > Richard I think you're overcomplicating things. > > Yes, in principle you're right about the WebCrypto example and yes you > might be > right about CMS (although that was some time ago) but you have to ask > yourself > is this really worth picking a fight over? > > Cheers Leif**** > > ** ** > > I'm not going to go to the mat on this. I just wanted to state clearly > why I think the MTI idea is so vacuous.**** > > ** ** > > --Richard **** > > I think we've all felt that way once or twice. I know I have.**** > --bcaec550af3afa926b04d7f9c08a Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable If you're going to do that, you might as well punt entirely, since an a= pplication could define its own "JOSE crypto profile". =A0Which w= ould be fine with me; I think it's the applications that should be defi= ning this stuff anyway.
--Richard


On Thu, Mar 14, 2013= at 3:46 PM, Steffen Yount <syount@wideorbit.com> wrote:<= br>

Would it be better to keep = MTI out of the jose container specs, by declaring jose crypto profiles sepa= rately, where jose libraries that want to claim =93jose compliance=94 would have to meet the MTIs as defined in those jose crypto profiles?

=A0

=A0=A0=

=A0

=A0

=A0

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Leif Johansson
Sent: Thursday, March 14, 2013 6:59 AM
To: Richard Barnes
Cc: jose@ietf.org=
Subject: Re: [jose] MTI algorithms

=A0

On 03/14/2013 02:57 PM, Richard Barnes wrote:=

=A0

> I noted yesterday a concern that many things th= at should be counted as
> JOSE implementations could actually be ruled out if we have MTI
> algorithms.
>
>

Richard I think you're overcomplicating things.<= br>
Yes, in principle you're right about the WebCrypto example and yes you<= br> might be
right about CMS (although that was some time ago) but you have to ask
yourself
is this really worth picking a fight over?

=A0 =A0 =A0 =A0 Cheers Leif

=A0

I'm not going to go to the mat on this. =A0I jus= t wanted to state clearly why I think the MTI idea is so vacuous.=

=A0

--Richard=A0

I think we've all felt that way once or twice. I= know I have.


--bcaec550af3afa926b04d7f9c08a-- From Michael.Jones@microsoft.com Fri Mar 15 10:15:17 2013 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 4129D21F8824 for ; Fri, 15 Mar 2013 10:15:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.157 X-Spam-Level: X-Spam-Status: No, score=-2.157 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Hq9WDDcl7QGq for ; Fri, 15 Mar 2013 10:15:09 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0243.outbound.protection.outlook.com [207.46.163.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8784121F8794 for ; Fri, 15 Mar 2013 10:15:09 -0700 (PDT) Received: from BL2FFO11FD017.protection.gbl (10.173.161.204) by BL2FFO11HUB028.protection.gbl (10.173.161.52) with Microsoft SMTP Server (TLS) id 15.0.641.9; Fri, 15 Mar 2013 17:15:07 +0000 Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD017.mail.protection.outlook.com (10.173.161.35) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Fri, 15 Mar 2013 17:15:06 +0000 Received: from TK5EX14MBXC284.redmond.corp.microsoft.com ([169.254.1.29]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0318.003; Fri, 15 Mar 2013 17:14:36 +0000 From: Mike Jones To: "Peck, Michael A" , Richard Barnes Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: Ac4hoJESkbPUau2CRd2Y+GZP3Ym7fQ== Date: Fri, 15 Mar 2013 17:14:36 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367527A20@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.36] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51914002)(377454001)(13464002)(51704002)(243025002)(124975001)(164054002)(24454001)(189002)(199002)(59766001)(5343655001)(4396001)(79102001)(77982001)(69226001)(46102001)(65816001)(20776003)(49866001)(76482001)(33656001)(50986001)(551544001)(80022001)(16406001)(74662001)(512954001)(47446002)(63696002)(54316002)(74502001)(15202345001)(56776001)(47736001)(44976002)(16601075001)(47976001)(66066001)(31966008)(55846006)(5343635001)(51856001)(53806001)(16236675001)(56816002)(16297215001)(54356001)(563064004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB028; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 078693968A Cc: Yaron Sheffer , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 17:15:17 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for the pointer to the NIST draft, Mike. I agree that having PBKDF2 would give applications additional choices, as y= ou suggest. As background for those of you who weren't at the JOSE WG meeting, I took a= n action item there to produce a security analysis of the direct encryption= mode. (I intend to consult experts on Microsoft's crypto board, among oth= ers. And CFRG input on that would obviously be great too!) I suspect that= the Security Considerations text arising from that will contain statements= about appropriately limiting the number of times a shared symmetric key is= used. Single use is clearly fine. Using a key forever certainly isn't in= most contexts. Are there references on appropriate limits on reuse of symmetric keys that = experts on this thread could point me to, since the direct encryption topic= came up? Thanks all, -- Mike From: Peck, Michael A [mailto:mpeck@mitre.org] Sent: Friday, March 15, 2013 9:59 AM To: Richard Barnes; Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: RE: [jose] Draft describing encrypting JWK key representations, wi= th JWE +1 NIST Special Publication 800-132 provides recommendations for the parameter= s that the group may find useful. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf It may also be worth thinking about using PBKDF2 instead of the "dir" (Dire= ct Encryption with a Shared Symmetric Key) mechanism described in draft-iet= f-jose-json-web-algorithms-08 section 4.6. The shared symmetric key would = be used as the PBKDF2 "password", and this would force a new key to be used= for each encryption, rather than the current "dir" approach of using the s= ame encryption key repeatedly. Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 12:53 PM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 h= as mechanisms to mitigate the dictionary attack risks, e.g., having a high = number of iterations. We might want to make some recommendations as to how = you set those parameters. And the actual key wrapping is done with somethin= g like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do = this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > wrote: That's up to the working group. I'm actually hoping that experts on the li= sts will respond to Yaron's comments before we make a decision on whether P= BKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part= of one, the PBKDF2 definition would end up in the algorithms registry eith= er way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, wi= th JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrappi= ng algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms= already specified for use with encryption in the JSON Web Algorithms (JWA)= specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorit= hms-08). In particular, other algorithms such as AES Key Wrap and AES GCM = are also present there. I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of = all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > > To: "cfrg@irtf.org" > > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset=3D"us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for the pointer to= the NIST draft, Mike.

 <= /p>

I agree that having PBKDF= 2 would give applications additional choices, as you suggest.

 <= /p>

As background for those o= f you who weren’t at the JOSE WG meeting, I took an action item there= to produce a security analysis of the direct encryption mode.  (I intend to consult experts on Microsoft’s crypto board, among othe= rs.  And CFRG input on that would obviously be great too!)  I sus= pect that the Security Considerations text arising from that will contain s= tatements about appropriately limiting the number of times a shared symmetric key is used.  Single use is clearly fine.=   Using a key forever certainly isn’t in most contexts.

 <= /p>

Are there references on a= ppropriate limits on reuse of symmetric keys that experts on this thread co= uld point me to, since the direct encryption topic came up?

 <= /p>

    &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     Thanks all,

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

 <= /p>

From: Peck, Mi= chael A [mailto:mpeck@mitre.org]
Sent: Friday, March 15, 2013 9:59 AM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: RE: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

+1<= /p>

 <= /p>

NIST Special Publication = 800-132 provides recommendations for the parameters that the group may find= useful.

http://csrc.nist.g= ov/publications/nistpubs/800-132/nist-sp800-132.pdf

 <= /p>

It may also be worth thin= king about using PBKDF2 instead of the “dir” (Direct Encryption= with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-w= eb-algorithms-08 section 4.6.  The shared symmetric key would be used as the PBKDF2 &#= 8220;password”, and this would force a new key to be used for each en= cryption, rather than the current “dir” approach of using the s= ame encryption key repeatedly.

 <= /p>

Mike

 <= /p>

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

Do I count as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for ke= y protection.  PBKDF2 has mechanisms to mitigate the dictionary attack= risks, e.g., having a high number of iterations. We might want to make som= e recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW= , so that step is fine.

 

So I would be completely fine with adding this to JW= E / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones= @microsoft.com> wrote:

That’s up to the working group. &= nbsp;I’m actually hoping that experts on the lists will respond to Ya= ron’s comments before we make a decision on whether PBKDF2 as specified is an ap= propriate key wrapping algorithm or not.

 

Assuming that the content in Matt’= ;s draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it’s not= part of the JWA spec itself.

 

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   Cheers,

      &nb= sp;            =             &nb= sp;            =             &nb= sp;   -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representati= ons, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / JWA, as a new k= ey wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to w= rap keys in this scheme.  This draft *adds* PBKDF2 to the set of algor= ithms already specified for use with encryption in the JSON Web Algorithms = (JWA) specification (http://tools.ietf.org/html/draft-= ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are= also present there.

I'll let others who are experts in PBKDF2 and password-based encryption res= pond to Yaron's specific comment.

                     = ;           -- Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; M= ike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE<= br>
Hi Mike,

I'm probably missing something, but I'm worried about the security of this = scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a= second line defense, once the server has been breached. Using it to encryp= t data and then sending the data on the wire, makes the data vulnerable to = this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 = million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf= .org" <cfrg@= irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations >       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394= 367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry. >
>                     =                      = ;                    -- M= ike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg= /attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B168042967394367527A20TK5EX14MBXC284r_-- From ve7jtb@ve7jtb.com Fri Mar 15 10:21:43 2013 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 268B021F8915 for ; Fri, 15 Mar 2013 10:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6] 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 jnL5FOjTFpvy for ; Fri, 15 Mar 2013 10:21:42 -0700 (PDT) Received: from mail-pd0-f178.google.com (mail-pd0-f178.google.com [209.85.192.178]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF921F8836 for ; Fri, 15 Mar 2013 10:21:42 -0700 (PDT) Received: by mail-pd0-f178.google.com with SMTP id u10so271778pdi.37 for ; Fri, 15 Mar 2013 10:21:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=NJZ0txpfHC7Up0L2q19J8e6PSlp2eSc+06OHy4PJ4Pc=; b=iM4fV8BNGPhbFXTT/TqokYRJ9VT5YDlO9ra1neD0oEtk2wCzYPE0jB5rPbZ+LS9GOg liDa9z/Vj7ILryWjhMFC80F10YUiDMRA2/fxgZ26ShHpUyc+xZW0ZOxkfEa1yablyFtq t1RK6vrlysUVp36x9oaNCC44Iosm3Mi9AQXtHHagvl7CiwKXQ/SMeaB3w2g7OGLIfgDm 90U0sJoM66MxZZRjmBPz9+zv4mmdcOSUKDSMm8cr+fksTTxiDuDw55I9W1t+kCUaPadV 0H7jVt9bCm+gc4My4O1anNSAlWEpMAvOdMYbrb77EP8ixPZNFf4M68HI3LS8v0BxrUVA 5Pag== X-Received: by 10.68.75.109 with SMTP id b13mr18106614pbw.25.1363368101807; Fri, 15 Mar 2013 10:21:41 -0700 (PDT) Received: from dhcp-543c.meeting.ietf.org (dhcp-543c.meeting.ietf.org. [130.129.84.60]) by mx.google.com with ESMTPS id tm1sm9711488pbc.11.2013.03.15.10.21.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 10:21:39 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_FDD005BA-F546-4AA2-936B-FF071AF5F534"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 15 Mar 2013 13:21:35 -0400 Message-Id: <3DD8D563-AA25-4D2A-BEE5-0F7484C2066E@ve7jtb.com> References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> To: Richard Barnes X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnQ7ZE961oHGDeJ0d19dboSxWSZ45G67ODw35vJbuLvsd15vkT5qrYUcoj1zO5+v8bK0cMR Cc: "Manger, James H" , "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 17:21:43 -0000 --Apple-Mail=_FDD005BA-F546-4AA2-936B-FF071AF5F534 Content-Type: multipart/alternative; boundary="Apple-Mail=_647B0E3F-A0D0-47F2-B96D-72C9D6938415" --Apple-Mail=_647B0E3F-A0D0-47F2-B96D-72C9D6938415 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Chained JWK is a rathole I would prefer not to go down. Yes to x5c & x5u as attributes of JWK. John B. On 2013-03-15, at 1:11 PM, Richard Barnes wrote: > Just to clarify, what I'm suggesting is to have "x5c" as an attribute = for JWK, with the same syntax as in JWS. As Brian suggested in his = slides. >=20 > IF we want to go down the path of having "chained" JWKs, the syntax = would be something like the following: > "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] > Where jws(kx, ky) indicates a JWS with ky as the body and kx as the = signing key. IF we build something like this, it would be used in the = same manner as "x5c", as an attribute of a JWK. However, I think = designing such a thing would be a significant deviation from our = charter, so we would need to recharter or even form a new WG (PKIJ?) >=20 > --Richard >=20 >=20 >=20 > On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes wrote: > On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H = wrote: > I agree, a certificate as an optional field of any JWK sounds like a = decent approach. >=20 > +1, although it's not mutually exclusive with having a "PKIX" key = type. > =20 > Putting a whole cert chain in one JWK is not ideal. > Each cert is about 1 key so really should be in its own JWK. > Otherwise you will duplicate the chain of intermediate CA certs in = each JWK in a set. >=20 > It might be useful to define a issuer key-id field ("isskid"). A JWK = could include a cert for its own key and (with "isskid") a link to the = next cert along the chain. That makes it quick-n-easy to build a chain = from the JWKs in a set. >=20 > It would also help if JWKs in a set where held in a = object/dictionary/associative-array with the kid as the name. That would = be better than using an array of JWKs with no defined meaning for the = order. >=20 > This proposal seems much, much worse than having a cert chain in one = JWK. If you're going to have all the public keys as JWKs, you might as = well just re-invent X.509 in JWK, in which case you would probably use = JWS over JWK, which solves the "isskid" problem using the "kid" in the = JWS. The benefit of having the cert chain is that you don't have to = re-invent X.509, you just pass the cert chain to your existing X.509 = library. =20 >=20 > In other words, let's have the trust chain be fully X.509 or fully = JOSE, even if it starts from a JWK. =20 >=20 > --Richard >=20 >=20 > =20 >=20 > -- > James Manger >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > > Matt Miller (mamille2) > > Sent: Friday, 15 March 2013 12:48 AM > > To: > > Subject: [jose] Rolling PKIX into JWK > > > > [hoping this topic is the least controversial...] > > > > In some IRL discussions on moving forward on PKIX in JWK, I've been > > convinced the concerns are mostly the same regardless of how the = PKIX > > is packaged. Given that, I would suggest we make "x5c" an optional > > field of JWK, rather than defining a new JWK type. I can propose > > various text additions after this meeting. > > > > > > Thoughts? > > > > - m&m > > > > Matt Miller < mamille2@cisco.com > > > Cisco Systems, Inc. >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_647B0E3F-A0D0-47F2-B96D-72C9D6938415 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1 Chained JWK is a rathole I would prefer not to go down.

Yes to x5c & x5u as attributes of JWK.

John B.
On 2013-03-15, at 1:11 PM, Richard Barnes <rlb@ipv.sx> wrote:

Just to clarify, what I'm suggesting is to have "x5c" as an attribute for JWK, with the same syntax as in JWS.  As Brian suggested in his slides.

IF we want to go down the path of having "chained" JWKs, the syntax would be something like the following:
"jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ]
Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing key.  IF we build something like this, it would be used in the same manner as "x5c", as an attribute of a JWK.  However, I think designing such a thing would be a significant deviation from our charter, so we would need to recharter or even form a new WG (PKIJ?)

--Richard



On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <rlb@ipv.sx> wrote:
On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
I agree, a certificate as an optional field of any JWK sounds like a decent approach.

+1, although it's not mutually exclusive with having a "PKIX" key type.
 
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK in a set.

It might be useful to define a issuer key-id field ("isskid"). A JWK could include a cert for its own key and (with "isskid") a link to the next cert along the chain. That makes it quick-n-easy to build a chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/associative-array with the kid as the name. That would be better than using an array of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cert chain in one JWK.  If you're going to have all the public keys as JWKs, you might as well just re-invent X.509 in JWK, in which case you would probably use JWS over JWK, which solves the "isskid" problem using the "kid" in the JWS.  The benefit of having the cert chain is that you don't have to re-invent X.509, you just pass the cert chain to your existing X.509 library.  

In other words, let's have the trust chain be fully X.509 or fully JOSE, even if it starts from a JWK.  

--Richard


 

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.org>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've been
> convinced the concerns are mostly the same regardless of how the PKIX
> is packaged.  Given that, I would suggest we make "x5c" an optional
> field of JWK, rather than defining a new JWK type.  I can propose
> various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--Apple-Mail=_647B0E3F-A0D0-47F2-B96D-72C9D6938415-- --Apple-Mail=_FDD005BA-F546-4AA2-936B-FF071AF5F534 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE1MTcyMTM2WjAjBgkqhkiG9w0BCQQxFgQUBQVGhaCY m0HSk1QlYC3SwrrBg7wwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAY0sEaEqcu/pyJy7EPtJPiP4/R4D362oPt469s0Zx r9Umbkumfm5pl3F+RadALZDiYn9xadtzVBvtje3Ywa89a/U5qpCHcAzQY8pSjokMDME/gFw6cLHF /KF7wXYylKlg2SML4vtyWxxsTPFEXOBKch/iphEvLvnhT05ceZVG0FIKj+rj0wabmsM3y4gQ5CdB hPcAUvG11IA1fxhiDn9cjgpKdCrA1DCX4OgWCGuH1r7T59kOVNK9aREDAgIUxhe5YwugOmlBErMm BBTorm06yJEIR79oR72uPIVsKPD/9tJElmOgr9tQHpjLlXssee0zGIxzZdzJSs0vY6wcWTYl2QAA AAAAAA== --Apple-Mail=_FDD005BA-F546-4AA2-936B-FF071AF5F534-- From mpeck@mitre.org Fri Mar 15 10:55:47 2013 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 A28F921F8959 for ; Fri, 15 Mar 2013 10:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 F5PNL-Z4k6EJ for ; Fri, 15 Mar 2013 10:55:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 6566721F8910 for ; Fri, 15 Mar 2013 10:55:46 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0BEC31F03F4; Fri, 15 Mar 2013 13:55:46 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id EDE5C1F03F2; Fri, 15 Mar 2013 13:55:45 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Fri, 15 Mar 2013 13:55:46 -0400 From: "Peck, Michael A" To: Yaron Sheffer Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIaVNCf0r3dt6lkWnLIyRUNEE4ZinB6HA Date: Fri, 15 Mar 2013 17:55:45 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> In-Reply-To: <51435D7A.7050800@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.52] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Richard Barnes , Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 17:55:47 -0000 I'll try to clarify (and hopefully not dig a deeper hole). JWE currently provides a "dir" mechanism allowing a symmetric key previousl= y agreed to out of band to be used for content encryption. All of the other JWE mechanisms use a fresh symmetric key for each encrypti= on. My suggestion was that instead of directly using the pre-shared symmetric k= ey to encrypt content, if JWE makes the PBKDF2 mechanism available the symm= etric key could be used as the PBKDF2 "password", resulting in a fresh key = generated for each content encryption. In this particular case the passwor= d input to PBKDF2 would hopefully be very random - I would think there woul= d be no more risk than using the pre-shared key directly, rather less risk. General password considerations are a different matter. Passwords have lot= s of issues but if we're stuck with them we should at least advise how to d= o the best we can. Mike >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >Sent: Friday, March 15, 2013 1:42 PM >To: Peck, Michael A >Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key representations, w= ith >JWE > >Hi Mike and Mike, > >The NIST SP is about using PBKDF2 for storage encryption (which I'm not >thrilled with, either). Not for sending the encrypted blob over the >wire, for an attacker to intercept and decrypt off-line. And if we read >the NIST document, let's adopt the whole thing - quoting from sec. A.1: >"Passwords shorter than 10 characters are usually considered to be >weak." Are we going to make this recommendation too? Well I guess not. > >*Please* do not mix passwords with cryptographic keys. If the WG goes >through the risk vs. benefit analysis and decides to have a >password-based mechanism, fine. But please leave the shared-key >mechanism as-is. It's important that readers of JOSE specs are very >clear about the difference between randomly generated keys and >user-memorable (or even -generated) passwords. > >Let's be clear: even a single use of a user-generated password for >on-the-wire encryption is risky. So-called key rotation of actual >cryptographic keys is a whole different matter. > >Thanks, > Yaron > > >On 03/15/2013 06:58 PM, Peck, Michael A wrote: >> +1 >> >> NIST Special Publication 800-132 provides recommendations for the >> parameters that the group may find useful. >> >> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >> >> It may also be worth thinking about using PBKDF2 instead of the "dir" >> (Direct Encryption with a Shared Symmetric Key) mechanism described in >> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >> symmetric key would be used as the PBKDF2 "password", and this would >> force a new key to be used for each encryption, rather than the current >> "dir" approach of using the same encryption key repeatedly. >> >> Mike >> >> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *Richard Barnes >> *Sent:* Friday, March 15, 2013 12:53 PM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >> *Subject:* Re: [jose] Draft describing encrypting JWK key >> representations, with JWE >> >> Do I count as an expert? :) >> >> As I understand it, PBDKF2 is completely fine for key protection. >> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >> having a high number of iterations. We might want to make some >> recommendations as to how you set those parameters. And the actual key >> wrapping is done with something like AES-KW, so that step is fine. >> >> So I would be completely fine with adding this to JWE / JWA. We should >> do this. >> >> --Richard >> >> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >> > >wrote: >> >> That's up to the working group. I'm actually hoping that experts on the >> lists will respond to Yaron's comments before we make a decision on >> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >not. >> >> Assuming that the content in Matt's draft eventually becomes an RFC or >> part of one, the PBKDF2 definition would end up in the algorithms >> registry either way, even if it's not part of the JWA spec itself. >> >> Cheers, >> >> -- Mike >> >> *From:*jose-bounces@ietf.org >> [mailto:jose-bounces@ietf.org ] *On >Behalf >> Of *Richard Barnes >> *Sent:* Friday, March 15, 2013 9:43 AM >> *To:* Mike Jones >> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >> >> *Subject:* Re: [jose] Draft describing encrypting JWK key >> representations, with JWE >> >> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >> wrapping algorithm? >> >> --Richard >> >> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >> > >wrote: >> >> [Adding JOSE mailing list to the thread] >> >> For clarification, PBKDF2 is not the only algorithm that could be used >> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >> algorithms already specified for use with encryption in the JSON Web >> Algorithms (JWA) specification >> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >> particular, other algorithms such as AES Key Wrap and AES GCM are also >> present there. >> >> I'll let others who are experts in PBKDF2 and password-based encryption >> respond to Yaron's specific comment. >> >> -- Mike >> >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >> ] >> Sent: Friday, March 15, 2013 8:16 AM >> To: cfrg@irtf.org ; Mike Jones >> Subject: Re: Draft describing encrypting JWK key representations, with J= WE >> >> Hi Mike, >> >> I'm probably missing something, but I'm worried about the security of >> this scheme (though I do appreciate the usability/convenience of >passwords). >> >> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >> as a second line defense, once the server has been breached. Using it to >> encrypt data and then sending the data on the wire, makes the data >> vulnerable to this same dictionary attack (in this case the effort comes >> to the space of all possible passwords - say 1 million - times 1000). >> Moreover, this also puts the password itself in danger. >> >> Thanks, >> Yaron >> >> > >> > ------------------------------ >> > >> > Message: 5 >> > Date: Fri, 15 Mar 2013 14:10:32 +0000 >> > From: Mike Jones > > >> > To: "cfrg@irtf.org " > > >> > Subject: [Cfrg] Draft describing encrypting JWK key representations >> > with JWE >> > Message-ID: >> > >> > ><4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >d.corp. >> >edmond.corp.%0b>> >> microsoft.com > >> > >> > Content-Type: text/plain; charset=3D"us-ascii" >> > >> > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >> > >> > This also adds password-based encryption to the algorithm registry. >> > >> > -- Mike >> > >> > -------------- next part -------------- An HTML attachment was >> > scrubbed... >> > URL: >> > archive/web/cfrg/attachments/20130315/02e36b >> > 24/attachment.htm> >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > Cfrg mailing list >> > Cfrg@irtf.org >> > http://www.irtf.org/mailman/listinfo/cfrg >> > >> > >> > End of Cfrg Digest, Vol 95, Issue 3 >> > *********************************** >> > >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> From ietf@augustcellars.com Fri Mar 15 11:08:00 2013 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 CE4F321F867A for ; Fri, 15 Mar 2013 11:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 T9vLwCMi5pMm for ; Fri, 15 Mar 2013 11:08:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2619F21F8618 for ; Fri, 15 Mar 2013 11:08:00 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 7E46A2CA2D; Fri, 15 Mar 2013 11:07:58 -0700 (PDT) From: "Jim Schaad" To: "'John Bradley'" , "'Dick Hardt'" References: <4D7DC99B-7C9B-4416-8F05-720BDB9B03DD@gmail.com> <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> In-Reply-To: <315A8748-3CD9-4AED-A297-7263D2F9812C@ve7jtb.com> Date: Fri, 15 Mar 2013 14:07:23 -0400 Message-ID: <07b601ce21a7$f399efd0$dacdcf70$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI+V6UeFde8Tf0J/GCTtcrSNTZUWQGaH1GEAYCOF0sBfB4rAwEPw+2vAfJWBhMCPEFsfpd390Cg Content-Language: en-us Cc: 'Anthony Nadalin' , 'Karen O'Donoghue' , 'Richard Barnes' , 'Mike Jones' , 'Tim Bray' , 'jose' , 'James H Manger' Subject: Re: [jose] Proposed resolution of header criticality issue 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, 15 Mar 2013 18:08:00 -0000 I cannot speak to all CMS implementations, however all of the header information was exposed in everyone that I either wrote or have used todate. Jim > -----Original Message----- > From: John Bradley [mailto:ve7jtb@ve7jtb.com] > Sent: Tuesday, March 12, 2013 7:47 PM > To: Dick Hardt > Cc: Richard Barnes; Anthony Nadalin; Jim Schaad; Mike Jones; James H > Manger; Tim Bray; jose; Karen O'Donoghue > Subject: Re: [jose] Proposed resolution of header criticality issue > > The application wanting to see the whole header is also a valid perspective. > > I guess the question is if every application should have to create its own way > to extract the header info or should a lib be expected to make them > available. > > Some of this discussion comes from CMS where the crypto info/header info > is not exposed to applications. > > I think that is not the right thing to do. > > If we are going with adding top level claims then we should probably say > there is an expectation that the header is also available to applications, > which is what I think you expect. > > John B. > > On 2013-03-12, at 7:39 PM, Dick Hardt wrote: > > > > > On Mar 12, 2013, at 4:13 PM, John Bradley wrote: > > > >> Currently the header has integrity protection. > > > > Glad to hear I did that right. > > > >> > >> The proposed changes to the spec allow what you are doing. The thing is > that a standard JWE library is not going to know about your forwarding rules. > > > > I would hope that a standard JWE library would ignore my forwarding > rules. That is done at the protocol layer (which should be obvious since the > JWE library won't know how to forward) > > > > In my libraries, I have a JWT parser that will give me the header and the > payload if a JWS. Hopefully other libraries will have parsers so that the App > can make decision about what to do. > > > >> My proposal was to add a containing element for all the additional claims > intended for processing outside of the JWE/JWS crypto library. > > > > Or I could just add an app specific claim like I do in the payload. > > > >> That reduces namespace collision and allows the library to pass back to > the application any claims in the header that are not intended for JWEJWS. > > > > We already have a mechanism for namespace collision in the payload. > Why invent a new one? > > > > btw: I like my parsing implementation just fine -- passing back just the > claims does not meet my purpose -- I want to see all of the header, and see > the payload if it is a JWS > > > >> > >> The three alternatives are: > >> 1 preclude non JWE/S claims in the header (won't work for you) > >> 2 a dedicated JSON member that contains claims intended for > applications or external extensions > >> 3 throw in everything as a top level claim and have applications sniff the > header looking for what they need. > > > > Why not use the same extension mechanism that is being used for the > payload? Or allow me to put payload properties into the header as well? > There is no namespace collision since it is a reserved property value. > > > >> > >> The proposal going to the meeting tomorrow is 2 based on it being the > cleanest way to pass on the additional claims to applications using a general > purpose JOSE lib. > > > > I don't just want the additional claims, I want the full header parsed and > be able to look at all of it. > > > > -- Dick From ietf@augustcellars.com Fri Mar 15 11:10:17 2013 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 F33DC21F8696 for ; Fri, 15 Mar 2013 11:10:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.848 X-Spam-Level: X-Spam-Status: No, score=-2.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_44=0.6, 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 SNPd1N1lThRc for ; Fri, 15 Mar 2013 11:10:15 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id E11FD21F887F for ; Fri, 15 Mar 2013 11:10:09 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 8D0A72CA33; Fri, 15 Mar 2013 11:10:08 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , "'Mike Jones'" , "'Peck, Michael A'" , "'John Bradley'" References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 15 Mar 2013 14:09:34 -0400 Message-ID: <07b701ce21a8$40b502f0$c21f08d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07B8_01CE2186.B9A8BA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIfUvokC2KN1bP9hZD3WzbTW1wpuwJJuz3QAMb1EvwBDVdg+AMdMmNBAgT8d5gCo7yYCJelipLg Content-Language: en-us Cc: 'Richard Barnes' , jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 15 Mar 2013 18:10:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07B8_01CE2186.B9A8BA20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Manger, James H Sent: Tuesday, March 12, 2013 8:59 PM To: Mike Jones; Peck, Michael A; John Bradley Cc: Richard Barnes; jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK =20 +1 for using the McGrew draft and RFC 5116 interface. =20 The JOSE-specific A128CBC+HS256 algorithm looks like a valiant attempt = to hide some of the binary processing involved with crypto =E2=80=93 = which has always been defined on bytes, not text. But the result is a = poor chimera. =20 For instance, JWE includes the IV as part of the additional = authenticated data (AAD). No other AEAD system is defined like this. = Everywhere else the IV/nonce and AAD are separate. I hope that = doesn=E2=80=99t adversely affect the crypto properties, but it does = raise questions about whether it is important for some crypto reason. =20 [JLS] For this algorithm it is absolutely vital that the IV be = protected. Since the authentication is computed on the post encrypted = text not the pre-encyrpted text, a decryption could never be able to = correctly determine that the IV passed in was correct if it is not = validated!!!!!! =20 Every AEAD algorithm treats the AAD and ciphertext as bytes arrays with = no restrictions on their content (only restrictions on their length). = Hence they use some binary packing when processing both to calculate an = integrity check. EXCEPT the JOSE-specific AEAD algorithms (A128CBC+HS256 = and A256CBC+HS512). They force base64url-encoding *inside* the AEAD = algorithm so they can use a text dot =E2=80=9C.=E2=80=9D as a separator. =20 While A128CBC+HS256 is implemented by hand in JOSE-specific code using = AES and HMAC primitives the problems with this chimera are mainly = hidden. However, I don=E2=80=99t believe any generic AEAD interface can = ever handle this JOSE-specific algorithm efficiently. =20 The =E2=80=9Cextra work=E2=80=9D of adopting the AEAD encoding/decoding = conventions is: concatenating byte arrays; and taking a known-length = prefix and suffix from a byte array. You cannot get much simpler. It can = only be an annoyance for a language that is not byte-array-friendly, but = even such a language will have to handle byte arrays at some point to = interface with crypto. =20 Even using the McGrew draft then separating the output into = IV/ciphertext/MAC to re-package as a JOSE message would be better than = the JOSE-specific A128CBC+HS256 and A256CBC+HS512. =20 P.S. I think ECMAScript edition 6 is introducing support for byte arrays = so even hassle handling bytes in JavaScript should fade. =20 -- James Manger =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Mike Jones Sent: Wednesday, 13 March 2013 8:06 AM To: Peck, Michael A; John Bradley Cc: Richard Barnes; jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK =20 Possibly using the McGrew draft had been discussed before, but there was = strong push-back on it. It would change more than the CBC/HMAC = representation =E2=80=93 it would change all the JWE representations, as = it would remove the Initialization Vector and Integrity Value fields, = and instead require all implementations to implement and apply the AEAD = binary encoding and decoding conventions. Note that this would change = AES-GCM too =E2=80=93 not just AES-CBC/HMAC. =20 If commonly available crypto libraries implemented algorithms using the = AEAD encoding conventions I would have no problem with this. But in = fact, they don=E2=80=99t. I don=E2=80=99t know of a single library in = the attached set of surveyed implementations that do. Thus, adopting = the AEAD encoding/decoding conventions would create extra work for all = implementations in practice =E2=80=93 not make things simpler. It would = only be simpler if the existing crypto libraries implemented this = standard interface. =20 We should therefore steer clear of this. =20 Best wishes, -- Mike =20 P.S. Jim Schaad also points out that CMS doesn=E2=80=99t use the RFC = 5116 interface either. =20 From: Peck, Michael A [mailto:mpeck@mitre.org]=20 Sent: Tuesday, March 12, 2013 2:02 PM To: John Bradley; Mike Jones Cc: Richard Barnes; jose@ietf.org Subject: RE: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK =20 I think that #2 actually reduces complexity for implementers. They can implement the RFC 5116 interface once (or eventually just = invoke a crypto library that implements it for them) =E2=80=93 then use = that implementation for all protocols that use the RFC 5116 interface, = not just JOSE, and know that the details of authenticated encryption = have been taken care of.=20 =20 Mike =20 =20 From: John Bradley [mailto:ve7jtb@ve7jtb.com]=20 Sent: Tuesday, March 12, 2013 4:49 PM To: Mike Jones Cc: Richard Barnes; Peck, Michael A; jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK =20 Yes I have the recommendation to change from using a KDF to generate the = CEK and CIK from the CMK to concatenating the CEK and CIK together as in = the McGrew draft. =20 I don't yet have a slide on the new/old issue of concatenating the tag = to the message body vs sending it in a separate field. =20 =20 If people want me to I can add it as well. Though I thought that was a = closed issue. =20 =20 John B. =20 On 2013-03-12, at 4:19 PM, Mike Jones = wrote: =20 As previously extensively discussed, the McGrew draft does two things = =E2=80=93 one helpful and one not: =20 1. It specifies using a key that is actually the concatenation of an = AES-CBC key and an HMAC SHA-2 key, rather than use of a KDF. = That=E2=80=99s good, as it=E2=80=99s simple for implementers. =20 2. It specifies that the initialization vector and integrity value be = concatenated with other values in particular ways, and conversely, how = to extract them when decrypting. That=E2=80=99s not good, as it adds = complexity for implementers =E2=80=93 especially when JWEs already = utilize a straightforward representation for these values, which = doesn=E2=80=99t require the binary concatenation and extraction = conventions specified by McGrew. =20 I know that John Bradley is going to ask the question tomorrow whether = we should change to doing the first for our composite CBC+HMAC = algorithms. I believe that doing the second would be counterproductive. =20 -- Mike =20 From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Richard Barnes Sent: Tuesday, March 12, 2013 1:00 PM To: Peck, Michael A Cc: jose@ietf.org Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving = CEK/CIK from CMK =20 Actually, for everything but key agreement, we can just use = draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys. We should not be = specifying key expansion here when we can avoid it. =20 --Richard =20 =20 On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A < = mpeck@mitre.org> wrote: draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use = of Concat KDF on the shared secret Z established by ECDH-ES. =20 The draft allows for an empty PartyUInfo and PartyVInfo but that may not = be allowed by NIST SP 800-56A (where the Concat KDF is defined). The current (March 2007) version of NIST SP 800-56A requires =E2=80=9CAt = a minimum, PartyUInfo shall include IDU, the identifier of party = U.=E2=80=9D and an equivalent requirement for PartyVInfo. (Page 46 of = = http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Ma= r08-2007.pdf ) The August 2012 draft update to NIST SP 800-56A requires =E2=80=9CAt a = minimum, PartyUInfo shall include IDu, an identifier for party U, as a = distinct item of information.=E2=80=9D and an equivalent requirement for = PartyVInfo. (Page 59 of = = http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf ) = My interpretation of this text (others may interpret it differently) is = that PartyUInfo and PartyVInfo can=E2=80=99t be empty. =20 Instead of using the Concat KDF, a more appropriate choice may be the = KDF described in NIST SP 800-56C and RFC 5869. Its requirements are not as strict. (SP 800-56C Page 13: =E2=80=9CIf = the information is available, Context should include the identifiers of = the parties who are deriving and/or using the derived keying = material=E2=80=9D) =20 It would look something like this: =20 Step 1 - Randomness Extraction: Key Derivation Key :=3D HMAC(salt, Z) (HMAC-SHA256 should = suffice for all of the current algorithms) =20 Step 2 - Expansion Step: Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC = 5869 with the same HMAC algorithm used in step 1 to produce needed keys = from the Key Derivation Key produced in step 1. The needed keys would depend on the values of alg and enc. If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit = key is needed (used to decrypt the CMK, which may then need to be split = into CEK/CIK). If alg is ECDH-ES, then the needed keys depend on =E2=80=9Cenc=E2=80=9D: If enc is AES-GCM, a 128 bit key or 256 bit key is needed. If enc is one of the AEAD AES-CBC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + = MAC_KEY_LEN is needed as it=E2=80=99s then split into two by the AEAD = algorithm. If enc is one of the current CBC+HMAC options in = draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK = and a CIK. Counter Mode KDF could be invoked twice, with different = labels each time, or Counter Mode KDF could be invoked once to generate = a big key which would then be split into the CEK and CIK. =20 Richard has already pointed out the issues with using the Concat KDF to = derive the CEK/CIK from the CMK. Instead, one option would be to use = the Expansion Step above: use the Counter Mode KDF with an HMAC to = derive necessary keys from the CMK.=20 Even if we use encryption algorithms that combine the encryption and = integrity key such as the CBC+HMAC algorithms in = draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to = take a smaller master key and create the combined encryption + integrity = key from it. =20 =20 Mike =20 _______________________________________________ jose mailing list jose@ietf.org = https://www.ietf.org/mailman/listinfo/jose =20 _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose =20 ------=_NextPart_000_07B8_01CE2186.B9A8BA20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Manger, James H
Sent: Tuesday, March 12, 2013 8:59 = PM
To: Mike Jones; Peck, Michael A; John Bradley
Cc: = Richard Barnes; jose@ietf.org
Subject: Re: [jose] Concat KDF = issues with ECDH-ES and for deriving CEK/CIK from = CMK

 

+1 for using the McGrew draft and RFC 5116 = interface.

 

The JOSE-specific A128CBC+HS256 algorithm looks like a valiant = attempt to hide some of the binary processing involved with crypto = =E2=80=93 which has always been defined on bytes, not text. But the = result is a poor chimera.

 

For instance, JWE includes the IV as part of the additional = authenticated data (AAD). No other AEAD system is defined like this. = Everywhere else the IV/nonce and AAD are separate. I hope that = doesn=E2=80=99t adversely affect the crypto properties, but it does = raise questions about whether it is important for some crypto = reason.

 

[= JLS] For this algorithm it is absolutely vital that the IV be = protected.=C2=A0 Since the authentication is computed on the post = encrypted text not the pre-encyrpted text, a decryption could never be = able to correctly determine that the IV passed in was correct if it is = not validated!!!!!!

 

Every AEAD algorithm treats the AAD and ciphertext as bytes arrays = with no restrictions on their content (only restrictions on their = length). Hence they use some binary packing when processing both to = calculate an integrity check. EXCEPT the JOSE-specific AEAD algorithms = (A128CBC+HS256 and A256CBC+HS512). They force base64url-encoding = *inside* the AEAD algorithm so they can use a text dot = =E2=80=9C.=E2=80=9D as a separator.

 

While A128CBC+HS256 is implemented by hand in JOSE-specific code = using AES and HMAC primitives the problems with this chimera are mainly = hidden. However, I don=E2=80=99t believe any generic AEAD interface can = ever handle this JOSE-specific algorithm = efficiently.

 

The =E2=80=9Cextra work=E2=80=9D of adopting the AEAD encoding/decoding conventions is: concatenating byte arrays; and = taking a known-length prefix and suffix from a byte array. You cannot = get much simpler. It can only be an annoyance for a language that is not = byte-array-friendly, but even such a language will have to handle byte = arrays at some point to interface with crypto.

 

Even using the McGrew draft then separating the output into = IV/ciphertext/MAC to re-package as a JOSE message would be better than = the JOSE-specific A128CBC+HS256 and = A256CBC+HS512.

 

P.S. I think ECMAScript edition 6 is introducing support for byte = arrays so even hassle handling bytes in JavaScript should = fade.

 

--

James Manger

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Mike Jones
Sent: Wednesday, 13 March 2013 = 8:06 AM
To: Peck, Michael A; John Bradley
Cc: = Richard Barnes; jose@ietf.org
Subject: Re: = [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from = CMK

 

Possibly using the McGrew draft had been discussed before, but there = was strong push-back on it.  It would change more than the CBC/HMAC = representation =E2=80=93 it would change all the JWE representations, as = it would remove the Initialization Vector and Integrity Value fields, = and instead require all implementations to implement and apply the AEAD = binary encoding and decoding conventions.  Note that this would = change AES-GCM too =E2=80=93 not just = AES-CBC/HMAC.

 

If commonly available crypto libraries implemented algorithms using = the AEAD encoding conventions I would have no problem with this.  = But in fact, they don=E2=80=99t.  I don=E2=80=99t know of a single = library in the attached set of surveyed implementations that do.  = Thus, adopting the AEAD encoding/decoding conventions would create extra = work for all implementations in practice =E2=80=93 not make things = simpler.  It would only be simpler if the existing crypto libraries = implemented this standard interface.

 

We should therefore steer clear of this.

 

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

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

 

P.S.  Jim Schaad also points out that CMS doesn=E2=80=99t use = the RFC 5116 interface either.

 

From:= = Peck, Michael A [mailto:mpeck@mitre.org] =
Sent: Tuesday, March 12, 2013 2:02 PM
To: John = Bradley; Mike Jones
Cc: Richard Barnes; jose@ietf.org
Subject: RE: = [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from = CMK

 

I think that #2 actually reduces complexity for = implementers.

They can implement the RFC 5116 interface once (or eventually just = invoke a crypto library that implements it for them) =E2=80=93 then use = that implementation for all protocols that use the RFC 5116 interface, = not just JOSE, and know that the details of authenticated encryption = have been taken care of.

 

Mike

 

 

From:= = John Bradley [mailto:ve7jtb@ve7jtb.com] =
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike = Jones
Cc: Richard Barnes; Peck, Michael A; jose@ietf.org
Subject: Re: = [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from = CMK

 

Yes I have = the recommendation to change from using a KDF to generate the CEK and = CIK from the CMK to concatenating the CEK and CIK together as in the = McGrew draft.

 

I = don't yet have a slide on the new/old issue of concatenating the tag to = the message body vs sending it in a separate field. =   

 

If people want me to I can add it as well. =  Though I thought that was a closed issue. =  

 

John B.

 

On = 2013-03-12, at 4:19 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

 

From:=  jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Tuesday, March 12, 2013 1:00 = PM
To: Peck, = Michael A
Cc: jose@ietf.org
Subject: Re: [jose] Concat KDF issues = with ECDH-ES and for deriving CEK/CIK from = CMK

 

Actually, for everything but key agreement, we can = just use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys. =  We should not be specifying key expansion here when we can avoid = it.

 

--Richard

 

 

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A = <mpeck@mitre.org> = wrote:

draft-ietf-jose-json-web-algorithms-08 section 4.7.1 = describes the use of Concat KDF on the shared secret Z established by = ECDH-ES.

 

The draft allows for an empty PartyUInfo and = PartyVInfo but that may not be allowed by NIST SP 800-56A (where the = Concat KDF is defined).

The current (March 2007) version of NIST SP 800-56A = requires =E2=80=9CAt a minimum, PartyUInfo shall include IDU, = the identifier of party U.=E2=80=9D and an = equivalent requirement for PartyVInfo. (Page 46 ofhttp://csrc.nist.gov/publications/nistpubs/800-56A= /SP800-56A_Revision1_Mar08-2007.pdf )

<= div>

The August 2012 draft update to NIST SP 800-56A = requires =E2=80=9CAt a minimum, PartyUInfo shall include IDu, an = identifier for party U, as a distinct item of information.=E2=80=9D and = an equivalent requirement for PartyVInfo. (Page 59 of http://csrc.nist.gov/publications/drafts/800-56a/d= raft-sp-800-56a.pdf )  My interpretation of = this text (others may interpret it differently) is that PartyUInfo and = PartyVInfo can=E2=80=99t be empty.

 

Instead of using the Concat KDF, a more appropriate = choice may be the KDF described in NIST SP 800-56C and RFC = 5869.

Its requirements are not as strict.  = (SP 800-56C Page 13: =E2=80=9CIf the = information is available, Context should include the identifiers = of the parties who are deriving and/or using the derived keying = material=E2=80=9D)

 

It would look something like = this:

 

Step 1 - Randomness = Extraction:

Key Derivation = Key :=3D HMAC(salt, Z)         = (HMAC-SHA256 should suffice for all of the current = algorithms)

 

Step 2 - Expansion Step:

Use the Counter Mode KDF defined in SP 800-108 or = section 2.3 of RFC 5869 with the same HMAC algorithm used in step 1 to = produce needed keys from the Key Derivation Key produced in step = 1.

The needed keys would = depend on the values of alg and enc.

If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single = 128 bit or 256 bit key is needed (used to decrypt the CMK, which may = then need to be split into CEK/CIK).

If alg is ECDH-ES, then the needed keys depend on = =E2=80=9Cenc=E2=80=9D:

If = enc is AES-GCM, a 128 bit key or 256 bit key is = needed.

If enc is one of = the AEAD AES-CBC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a = key of ENC_KEY_LEN + MAC_KEY_LEN is needed as it=E2=80=99s then split = into two by the AEAD algorithm.

If enc is one of the current CBC+HMAC options in = draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK = and a CIK.  Counter Mode KDF could be invoked twice, with different = labels each time, or Counter Mode KDF could be invoked once to generate = a big key which would then be split into the CEK and = CIK.

 

Richard has already pointed out the issues with using = the Concat KDF to derive the CEK/CIK from the CMK.  Instead, one = option would be to use the Expansion Step above:  use the Counter = Mode KDF with an HMAC to derive necessary keys from the = CMK. 

Even if we use = encryption algorithms that combine the encryption and integrity key such = as the CBC+HMAC algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01, = there will still be a need to take a smaller master key and create the = combined encryption + integrity key from it.

 

 

Mike

 


______________________________________= _________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose<= /a>

_________= ______________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/= mailman/listinfo/jose

 

------=_NextPart_000_07B8_01CE2186.B9A8BA20-- From rlb@ipv.sx Fri Mar 15 11:11:33 2013 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 B3F2221F887F for ; Fri, 15 Mar 2013 11:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RDNS_NONE=0.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 7CAZ5FcXSA43 for ; Fri, 15 Mar 2013 11:11:32 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A256121F8549 for ; Fri, 15 Mar 2013 11:11:32 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id v19so3515976obq.35 for ; Fri, 15 Mar 2013 11:11:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=byGPUp/99ErEBi72bjH+/rqD4t16XI7vbK8UZuxQxGM=; b=NOi+4nU0e7vp0gImwVZll9II5gyqNggEkMD4Hk2kLiejIgECIRKk+3AjnV0pg5bpsM ZGDn4eVlEGV5Ww8Ycum5Ux/F/TS5O8+4jsOa9V2ZqK3hjJFwPqv/JJs0kmURCZysytRa QDSZ9zoRfhviQYa03oxyg32btD2+mGPaTUpUQRWVm71Vw8T0sY6Jxe+hzF3N9Qw0In0Z aTXHyF7cd2eupFaj+tNoSCN+TEc/u60qD/c+35sVnCvCPykSqXZxvTLT1txzjnc7Erag Mv+DDgLenvTMjrWVnIUskvdFGMfGehHkDIhuYyP9xdNL+LfClnsIM/d2OLfqgWTnS3ML 4iGQ== MIME-Version: 1.0 X-Received: by 10.182.39.69 with SMTP id n5mr3447219obk.72.1363371091746; Fri, 15 Mar 2013 11:11:31 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 15 Mar 2013 11:11:31 -0700 (PDT) X-Originating-IP: [130.129.20.77] In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> Date: Fri, 15 Mar 2013 14:11:31 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d044797559ef4da04d7fa9183 X-Gm-Message-State: ALoCoQkrewaehafUybtaA6qKcVdajTx20bA0VMaocagTpPQNibNW5ASStmay26yap2JZFHWqFQm7 Cc: "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 18:11:33 -0000 --f46d044797559ef4da04d7fa9183 Content-Type: text/plain; charset=ISO-8859-1 Another clarification: I'm fine with either "x5c" as a JWK, or "PKIX" as a "kty" value. In the former case, I would prefer that the "x5c" be attached to individual keys and not key sets. On Friday, March 15, 2013, Richard Barnes wrote: > Just to clarify, what I'm suggesting is to have "x5c" as an attribute for > JWK, with the same syntax as in JWS. As Brian suggested in his slides. > > IF we want to go down the path of having "chained" JWKs, the syntax would > be something like the following: > "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] > Where jws(kx, ky) indicates a JWS with ky as the body and kx as the > signing key. IF we build something like this, it would be used in the same > manner as "x5c", as an attribute of a JWK. However, I think designing such > a thing would be a significant deviation from our charter, so we would need > to recharter or even form a new WG (PKIJ?) > > --Richard > > > > On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes > > wrote: > >> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < >> James.H.Manger@team.telstra.com > 'James.H.Manger@team.telstra.com');>> wrote: >> >>> I agree, a certificate as an optional field of any JWK sounds like a >>> decent approach. >>> >> >> +1, although it's not mutually exclusive with having a "PKIX" key type. >> >> >>> Putting a whole cert chain in one JWK is not ideal. >>> Each cert is about 1 key so really should be in its own JWK. >>> Otherwise you will duplicate the chain of intermediate CA certs in each >>> JWK in a set. >>> >>> It might be useful to define a issuer key-id field ("isskid"). A JWK >>> could include a cert for its own key and (with "isskid") a link to the next >>> cert along the chain. That makes it quick-n-easy to build a chain from the >>> JWKs in a set. >>> >>> It would also help if JWKs in a set where held in a >>> object/dictionary/associative-array with the kid as the name. That would be >>> better than using an array of JWKs with no defined meaning for the order. >>> >> >> This proposal seems much, much worse than having a cert chain in one JWK. >> If you're going to have all the public keys as JWKs, you might as well >> just re-invent X.509 in JWK, in which case you would probably use JWS over >> JWK, which solves the "isskid" problem using the "kid" in the JWS. The >> benefit of having the cert chain is that you don't have to re-invent X.509, >> you just pass the cert chain to your existing X.509 library. >> >> In other words, let's have the trust chain be fully X.509 or fully JOSE, >> even if it starts from a JWK. >> >> --Richard >> >> >> >> >>> >>> -- >>> James Manger >>> >>> > -----Original Message----- >>> > From: jose-bounces@ietf.org >> 'jose-bounces@ietf.org');> [mailto:jose-bounces@ietf.org] >>> On Behalf Of >>> > Matt Miller (mamille2) >>> > Sent: Friday, 15 March 2013 12:48 AM >>> > To: > >>> > Subject: [jose] Rolling PKIX into JWK >>> > >>> > [hoping this topic is the least controversial...] >>> > >>> > In some IRL discussions on moving forward on PKIX in JWK, I've been >>> > convinced the concerns are mostly the same regardless of how the PKIX >>> > is packaged. Given that, I would suggest we make "x5c" an optional >>> > field of JWK, rather than defining a new JWK type. I can propose >>> > various text additions after this meeting. >>> > >>> > >>> > Thoughts? >>> > >>> > - m&m >>> > >>> > Matt Miller < mamille2@cisco.com >> 'mamille2@cisco.com');> > >>> > Cisco Systems, Inc. >>> >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> >> >> > --f46d044797559ef4da04d7fa9183 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Another clarification: =A0I'm fine with either "x5c" as a JWK= , or "PKIX" as a "kty" value. In the former case, I wou= ld prefer that the "x5c" be attached to individual keys and not k= ey sets. =A0



On Friday, March 15, 2013, Richard Barn= es wrote:
Just to clarify, what I'm = suggesting is to have "x5c" as an attribute for JWK, with the sam= e syntax as in JWS. =A0As Brian suggested in his slides.

IF we want to go down the path of having "chained"= JWKs, the syntax would be something like the following:
"jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ]
= Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing= key. =A0IF we build something like this, it would be used in the same mann= er as "x5c", as an attribute of a JWK. =A0However, I think design= ing such a thing would be a significant deviation from our charter, so we w= ould need to recharter or even form a new WG (PKIJ?)

--Richard



On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <rlb@ipv.sx> wrote:
On Fri, Mar 15, 2013 at 2:43 AM, Manger= , James H <James.H.Ma= nger@team.telstra.com> wrote:
I agree, a certificate as an optional field of any JWK sounds like a decent= approach.

+1, although it's = not mutually exclusive with having a "PKIX" key type.
=A0
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK= in a set.

It might be useful to define a issuer key-id field ("isskid"). A = JWK could include a cert for its own key and (with "isskid") a li= nk to the next cert along the chain. That makes it quick-n-easy to build a = chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/assoc= iative-array with the kid as the name. That would be better than using an a= rray of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cer= t chain in one JWK. =A0If you're going to have all the public keys as J= WKs, you might as well just re-invent X.509 in JWK, in which case you would= probably use JWS over JWK, which solves the "isskid" problem usi= ng the "kid" in the JWS. =A0The benefit of having the cert chain = is that you don't have to re-invent X.509, you just pass the cert chain= to your existing X.509 library. =A0

In other words, let's have the trust chain be fully= X.509 or fully JOSE, even if it starts from a JWK. =A0

--Richard


=A0

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.org>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've bee= n
> convinced the concerns are mostly the same regardless of how the PKIX<= br> > is packaged. =A0Given that, I would suggest we make "x5c" an= optional
> field of JWK, rather than defining a new JWK type. =A0I can propose > various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d044797559ef4da04d7fa9183-- From yaronf.ietf@gmail.com Fri Mar 15 10:42:32 2013 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 7E19F21F8945 for ; Fri, 15 Mar 2013 10:42:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[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 zp4jSu--XkSz for ; Fri, 15 Mar 2013 10:42:31 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB8F21F893D for ; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id c50so1688719eek.30 for ; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=v9YhPNtjWvRHBRKnuXjOOU63Alj156K+GGVTlyj7jVY=; b=MFUD9mflYqOjNwzTk2xM9rcrjayXtwgrXsFMezgBtABj4OF7SwsfH2J29y6VMfEXti bm+bXtlDqAiaYS4F7gm8KkiSpsDmiPqdfnSfap3klEZTNO0Zq0sz1lYI3Mp0/yw5jM1h zu3jMbiDH2n4JzjLsO2dXPKeANe7LUxNH7q+QEH3POQb6Fc8ARJ5sDA3da2wBGRSzWQ8 dtHQBbw351R8YptsLOmlR8JwlZDZHJaIJgjy74fkwYVUrJ4Ucya9Xi9YBZH/ATqt3vY+ 8EQtSUtp5ZO+S3mwZtt8EPfHV+GctOeceH12kCjTz8oVpMHK8nzXDvSu4kSBa1K8gesS FzGQ== X-Received: by 10.14.216.198 with SMTP id g46mr20208470eep.30.1363369342068; Fri, 15 Mar 2013 10:42:22 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-148-173.red.bezeqint.net. [109.64.148.173]) by mx.google.com with ESMTPS id ca4sm11363943eeb.15.2013.03.15.10.42.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 10:42:21 -0700 (PDT) Message-ID: <51435D7A.7050800@gmail.com> Date: Fri, 15 Mar 2013 19:42:18 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Peck, Michael A" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:46 -0700 Cc: Richard Barnes , Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 17:42:32 -0000 Hi Mike and Mike, The NIST SP is about using PBKDF2 for storage encryption (which I'm not thrilled with, either). Not for sending the encrypted blob over the wire, for an attacker to intercept and decrypt off-line. And if we read the NIST document, let's adopt the whole thing - quoting from sec. A.1: "Passwords shorter than 10 characters are usually considered to be weak." Are we going to make this recommendation too? Well I guess not. *Please* do not mix passwords with cryptographic keys. If the WG goes through the risk vs. benefit analysis and decides to have a password-based mechanism, fine. But please leave the shared-key mechanism as-is. It's important that readers of JOSE specs are very clear about the difference between randomly generated keys and user-memorable (or even -generated) passwords. Let's be clear: even a single use of a user-generated password for on-the-wire encryption is risky. So-called key rotation of actual cryptographic keys is a whole different matter. Thanks, Yaron On 03/15/2013 06:58 PM, Peck, Michael A wrote: > +1 > > NIST Special Publication 800-132 provides recommendations for the > parameters that the group may find useful. > > http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf > > It may also be worth thinking about using PBKDF2 instead of the “dir” > (Direct Encryption with a Shared Symmetric Key) mechanism described in > draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared > symmetric key would be used as the PBKDF2 “password”, and this would > force a new key to be used for each encryption, rather than the current > “dir” approach of using the same encryption key repeatedly. > > Mike > > *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 15, 2013 12:53 PM > *To:* Mike Jones > *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org > *Subject:* Re: [jose] Draft describing encrypting JWK key > representations, with JWE > > Do I count as an expert? :) > > As I understand it, PBDKF2 is completely fine for key protection. > PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., > having a high number of iterations. We might want to make some > recommendations as to how you set those parameters. And the actual key > wrapping is done with something like AES-KW, so that step is fine. > > So I would be completely fine with adding this to JWE / JWA. We should > do this. > > --Richard > > On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > > wrote: > > That’s up to the working group. I’m actually hoping that experts on the > lists will respond to Yaron’s comments before we make a decision on > whether PBKDF2 as specified is an appropriate key wrapping algorithm or not. > > Assuming that the content in Matt’s draft eventually becomes an RFC or > part of one, the PBKDF2 definition would end up in the algorithms > registry either way, even if it’s not part of the JWA spec itself. > > Cheers, > > -- Mike > > *From:*jose-bounces@ietf.org > [mailto:jose-bounces@ietf.org ] *On Behalf > Of *Richard Barnes > *Sent:* Friday, March 15, 2013 9:43 AM > *To:* Mike Jones > *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org > > *Subject:* Re: [jose] Draft describing encrypting JWK key > representations, with JWE > > So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key > wrapping algorithm? > > --Richard > > On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > > wrote: > > [Adding JOSE mailing list to the thread] > > For clarification, PBKDF2 is not the only algorithm that could be used > to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of > algorithms already specified for use with encryption in the JSON Web > Algorithms (JWA) specification > (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In > particular, other algorithms such as AES Key Wrap and AES GCM are also > present there. > > I'll let others who are experts in PBKDF2 and password-based encryption > respond to Yaron's specific comment. > > -- Mike > > -----Original Message----- > From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com > ] > Sent: Friday, March 15, 2013 8:16 AM > To: cfrg@irtf.org ; Mike Jones > Subject: Re: Draft describing encrypting JWK key representations, with JWE > > Hi Mike, > > I'm probably missing something, but I'm worried about the security of > this scheme (though I do appreciate the usability/convenience of passwords). > > PBKDF2 is meant to make dictionary attacks on stored passwords harder, > as a second line defense, once the server has been breached. Using it to > encrypt data and then sending the data on the wire, makes the data > vulnerable to this same dictionary attack (in this case the effort comes > to the space of all possible passwords - say 1 million - times 1000). > Moreover, this also puts the password itself in danger. > > Thanks, > Yaron > > > > > ------------------------------ > > > > Message: 5 > > Date: Fri, 15 Mar 2013 14:10:32 +0000 > > From: Mike Jones > > > To: "cfrg@irtf.org " > > > Subject: [Cfrg] Draft describing encrypting JWK key representations > > with JWE > > Message-ID: > > > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > > > microsoft.com > > > > > Content-Type: text/plain; charset="us-ascii" > > > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > > > This also adds password-based encryption to the algorithm registry. > > > > -- Mike > > > > -------------- next part -------------- An HTML attachment was > > scrubbed... > > URL: > > > 24/attachment.htm> > > > > ------------------------------ > > > > _______________________________________________ > > Cfrg mailing list > > Cfrg@irtf.org > > http://www.irtf.org/mailman/listinfo/cfrg > > > > > > End of Cfrg Digest, Vol 95, Issue 3 > > *********************************** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From juraj.somorovsky@rub.de Thu Mar 14 09:41:43 2013 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 B2EAF11E80E9 for ; Thu, 14 Mar 2013 09:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 hqnebZPGKuv7 for ; Thu, 14 Mar 2013 09:41:42 -0700 (PDT) Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id 2C9FA11E80BF for ; Thu, 14 Mar 2013 09:41:41 -0700 (PDT) X-Queued: (qmail 5043 invoked by alias); 14 Mar 2013 16:41:40 -0000 X-Queued: (qmail 5028 invoked from network); 14 Mar 2013 16:41:40 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx4.rz.ruhr-uni-bochum.de with SMTP; 14 Mar 2013 16:41:40 -0000 X-Queued: (qmail 25653 invoked by uid 281); 14 Mar 2013 16:41:40 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUy/C1ZspERUPA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(134.147.40.78):. Processed in 0.075495 secs); 14 Mar 2013 16:41:40 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUy/C1ZspERUPA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 14 Mar 2013 16:41:40 -0000 Date: 14 Mar 2013 17:41:37 +0100 Message-ID: <5141FDC1.5000102@rub.de> From: "Juraj Somorovsky" To: "Mike Jones" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:47 -0700 Cc: Tibor Jager , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 16:41:43 -0000 Hi Jeff, hi Mike, I am sorry, it seems that I have totally missed your previous email. I try to answer some of your questions... On 03/14/2013 04:48 PM, Mike Jones wrote: > I believe that these attacks are only possible on encryption without integrity, which in turn was only possible, because Nimbus-JWT continued to implement encryption algorithms without integrity protection. Someone should please correct me if I'm misunderstanding the situation. These attacks were basically possible because: 1) Nimbus-JWT allowed us to use AES-CBC. As we explicitly state in our paper, this is not problem of the jose specification as it forbids AES-CBC in the newer versions 2) We were able to force the Nimbus-JWT framework to decrypt RSA-OAEP ciphertexts with RSA1_5. You are right, in our scenarios, the Headers were not signed and thus we were able to switch from RSA-OAEP to RSA1_5. However, if I take a look at the JSON Web Encryption standard, there is not explicitly written that the messages must be signed. And even if the messages would be signed, there could still exist scenarios where it is possible to apply these attacks. See below. > > As most of you know, JWE now only allows authenticated encryption algorithms to be used, for reasons exactly such as these. It is great that you removed AES-CBC. RSA1_5 encryption is still however in the standard. > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of =JeffH > Sent: Thursday, March 14, 2013 8:17 AM > To: IETF JOSE WG > Cc: Juraj Somorovsky > Subject: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) > > back on Fri, 6 Jul 2012 Mike Jones said: > > > > Looking at this again, it seems to me that because JWE provides integrity > protection for the algorithm, it should be impossible for you to replace > "RSA-OAEP" with "RSA1_5" in the header because then the integrity check will > fail. Thus, the attack that you describe below is prevented by the integrity > protection of the header. > > > > Hence, correct JWE implementations do no provide the OAEP decryption oracle > that you describe. However if I'm missing something, please point it out to > me, since if there's an issue, I'd like to understand it and how to mitigate > it. Yes, this is true, if the attacker is not able to create valid signatures AND he is not able to force the server to process unsigned elements. However, there are few scenarios, where the attacks could still be applied. I am not that familiar with all the JSON scenarios but I assume that they are very close to the scenarios where XML Security is applied. Thus, I would say it is possible to assume the following scenarios: a) If the server is not correctly configured, it could accept unsigned requests JSON elements. Thus, the attacker could simply extract the signature or create an additional encryption element. b) in some Public-Key scenarios, the attacker will have a valid key to sign his JSON requests. In that case, he is able to: 1) take an RSA_OAEP request from his victim 2) extract the signature from this request 3) replace the algorithm (RSA_OAEP -> RSA1_5) and 4) resign the request with his own key. Afterwards, he could send the request to the server and force it to process RSA1_5 Please see our paper for more details (Section 4): http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption-countermeasures/ It describes some techniques how to apply such attacks on signed symmetrically encrypted XML documents. > > just fyi/fwiw...apologies if this has already been followed up on, but I didn't find further discussion of this after the above-quoted msg... > > Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" paper [1] is now out, and it may help answer the above questions. There's also Kenny Patterson's talk [2] from the recent Workshop on Real-World Cryptography. > > It seems, from an admittedly cursory glance at both draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, that perhaps there should be more implementation advice and security considerations in (at least) the -json-web-algorithms spec. Agreed. Some of these attacks are e.g. explicitly handled in the XML Encryption specification: http://www.w3.org/TR/xmlenc-core1/#sec-chosen-ciphertext-attacks You could include similar sections in your spec. If you would need some help, just let us know. Thanks Juraj From juraj.somorovsky@rub.de Thu Mar 14 10:02:38 2013 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 BE20111E8138 for ; Thu, 14 Mar 2013 10:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, 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 QbSxwt+2G2g1 for ; Thu, 14 Mar 2013 10:02:34 -0700 (PDT) Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id E5A4F11E8110 for ; Thu, 14 Mar 2013 10:02:24 -0700 (PDT) X-Queued: (qmail 7355 invoked by alias); 14 Mar 2013 17:02:23 -0000 X-Queued: (qmail 7325 invoked from network); 14 Mar 2013 17:02:23 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx6.rz.ruhr-uni-bochum.de with SMTP; 14 Mar 2013 17:02:23 -0000 X-Queued: (qmail 30622 invoked by uid 281); 14 Mar 2013 17:02:23 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUz3vk0eT+Su4Q==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(134.147.40.78):. Processed in 0.077996 secs); 14 Mar 2013 17:02:23 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUz3vk0eT+Su4Q==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 14 Mar 2013 17:02:23 -0000 Date: 14 Mar 2013 18:02:21 +0100 Message-ID: <5142029D.7090302@rub.de> From: "Juraj Somorovsky" To: "Brian Campbell" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:48 -0700 Cc: Mike Jones , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 17:02:38 -0000 I assume this also depends on the scenario. If you use public key signatures, you can sign whatever you want with your key, even the the RSA1_5 / RSA_OAEP ciphertexts and their algorithms (again, I am not familiar with the json scenarios, but in XML Encryption applications, the RSA ciphertexts are typically *not* signed) If you use HMACs, you need to transport somehow your HMAC key. You would do this probably with RSA-OAEP. In this case, the scenario described by Brian applies. Juraj On 03/14/2013 05:38 PM, Brian Campbell wrote: > But the integrity protected encryption happens using the key that's been > wrapped/encrypted using "RSA-OAEP" or "RSA1_5". That key needs to be > unwrapped/decrypted before any of the integrity checks even come into play, > which is where the attack takes place. So I don't see how the AEAD (or > composite AEAD like) algorithms help for preventing Bleichenbacher attacks > on RSA1_5 or BC attacks on RSA-OAEP to RSA1_5? > > (the general disclaimer correcting me, if I'm wrong, applies) > > > On Thu, Mar 14, 2013 at 11:48 AM, Mike Jones wrote: > >> I believe that these attacks are only possible on encryption without >> integrity, which in turn was only possible, because Nimbus-JWT continued to >> implement encryption algorithms without integrity protection. Someone >> should please correct me if I'm misunderstanding the situation. >> >> As most of you know, JWE now only allows authenticated encryption >> algorithms to be used, for reasons exactly such as these. >> >> -- Mike >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> =JeffH >> Sent: Thursday, March 14, 2013 8:17 AM >> To: IETF JOSE WG >> Cc: Juraj Somorovsky >> Subject: [jose] backwards compatibility attack on JWT impls (was: I-D >> Action: draft-ietf-jose-json-web-algorithms-02.txt) >> >> back on Fri, 6 Jul 2012 Mike Jones said: >> > >> > Looking at this again, it seems to me that because JWE provides >> integrity > protection for the algorithm, it should be impossible for you >> to replace > "RSA-OAEP" with "RSA1_5" in the header because then the >> integrity check will > fail. Thus, the attack that you describe below is >> prevented by the integrity > protection of the header. >> > >> > Hence, correct JWE implementations do no provide the OAEP decryption >> oracle > that you describe. However if I'm missing something, please >> point it out to > me, since if there's an issue, I'd like to understand it >> and how to mitigate > it. >> >> just fyi/fwiw...apologies if this has already been followed up on, but I >> didn't find further discussion of this after the above-quoted msg... >> >> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" >> paper [1] is now out, and it may help answer the above questions. There's >> also Kenny Patterson's talk [2] from the recent Workshop on Real-World >> Cryptography. >> >> It seems, from an admittedly cursory glance at both >> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, that >> perhaps there should be more implementation advice and security >> considerations in (at least) the -json-web-algorithms spec. >> >> Here's some excerpts from the paper for context... >> ... >> In the public-key setting, we show how the well-known attack of >> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] attack >> that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 encryption in >> both XML Encryption [27] and JSON Web Encryption [42], and to forge >> signatures for arbitrary messages in XML Signature [30] and JSON Web >> Signature [41]. The attack principle is described in Section 4. We >> furthermore report on our experimental results, executed against the Java >> implementation of JSON Web Encryption and JSON Web Signature Nimbus-JWT >> [53], in Section 5.3. >> ... >> >> Platform for Experimental Analysis: We investigate the practicality and >> performance of our attacks on JWE and JWS by applying them to the >> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON Web >> Encryption (JWE) and JSON Web Signature (JWS), developed by NimbusDS to >> support their Cloud Identity management portfolio. >> >> Even though Nimbus-JWT claims to implement version 02 of the JWE standard >> draft, it still supports usage of AESCBC (without MAC), which was available >> in version 01, but not in version 02 or any subsequent versions. >> ... >> >> 5.2.3 Evaluation >> >> We evaluated performance of our attacks against both WSS4J and Nimbus-JWT. >> We ï¬rst used the libraries to generate valid messages containing AES-GCM >> ciphertexts. Then we modiï¬ed the algorithm parameters in the messages, >> forcing the receiver to process the ciphertexts using AES-CBC, and executed >> the attack described in Algorithm 1. The required ciphertext validity >> oracles were based on error messages generated by the libraries. >> ... >> >> Experimental Results. In order to assess the practicability and >> performance of the attack, we implemented Bleichenbacher’s attack on XML >> Encryption [13, 38] and applied it to the Nimbus-JWT library. The PKCS#1 >> v1.5 validity oracle was provided by exceptions thrown by this library.11 >> ... >> >> 11 In practice one would instead use the more elaborate attack techniques >> of [38] to determine whether a given ciphertext is PKCS#1 v1.5 valid. >> ... >> >> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols based >> on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, Advances in >> Cryptology – CRYPTO’98, volume 1462 of Lecture Notes in Computer Science, >> pages 1–12. >> Springer, Aug. 1998. >> >> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher’s attack >> strikes >> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. Yung, >> editors, Computer Security - ESORICS 2012 - 17th European Symposium on >> Research in Computer Security, Pisa, Italy, September 10-14, 2012. >> Proceedings, LNCS. >> Springer, 2012. >> >> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. >> https://bitbucket.org/nimbusds/nimbus-jwt. >> >> ### >> >> [1] One Bad Apple: Backwards Compatibility Attacks on >> State-of-the-Art Cryptography >> >> http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCompatibilityAttacks.pdf >> >> [2] Key Reuse: Theory and Practice >> http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf >> >> >> HTH, >> >> =JeffH >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > From juraj.somorovsky@rub.de Thu Mar 14 16:52:46 2013 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 7E33C11E80D9 for ; Thu, 14 Mar 2013 16:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 9FeZZ2MFlpPX for ; Thu, 14 Mar 2013 16:52:45 -0700 (PDT) Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id B545911E8104 for ; Thu, 14 Mar 2013 16:52:44 -0700 (PDT) X-Queued: (qmail 23564 invoked by alias); 14 Mar 2013 23:52:38 -0000 X-Queued: (qmail 23547 invoked from network); 14 Mar 2013 23:52:38 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx4.rz.ruhr-uni-bochum.de with SMTP; 14 Mar 2013 23:52:38 -0000 X-Queued: (qmail 28016 invoked by uid 281); 14 Mar 2013 23:52:38 -0000 X-Qmailscanner: from 88.153.216.226 (7Cil8M2CiUwpD/pNu7e4Ew==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(88.153.216.226):. Processed in 0.074783 secs); 14 Mar 2013 23:52:38 -0000 Received: from ip-88-153-216-226.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUwpD/pNu7e4Ew==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 14 Mar 2013 23:52:37 -0000 Date: 15 Mar 2013 00:52:35 +0100 Message-ID: <514262C3.8010408@rub.de> From: "Juraj Somorovsky" To: "Mike Jones" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5141FDC1.5000102@rub.de> <4E1F6AAD24975D4BA5B1680429673943675110FD@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675110FD@TK5EX14MBXC283.redmond.corp.microsoft.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:49 -0700 Cc: Tibor Jager , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 14 Mar 2013 23:52:46 -0000 Hi Mike, you are right, your symmetric encryption algorithms are ok and Section 4.1.2 is clear enough. My concern was rather about the asymmetric encryption. I also agree with the description of Brian's scenario: 1) the server first decrypts RSA ciphertext using RSA1_5 / RSA_OAEP and obtains CMK 2) the server uses CMK to validate signature and decrypt json data Of course, if the attacker would modify the RSA ciphertext, the server would decrypt a different CMK value and the signature would thus be incorrect. In our paper we *assumed* that the RSA decryption is vulnerable to Bleichenbacher's attack (this is a valid assumption since most of the XML Encryption implementations were vulnerable to this attack, Nimbusds is still vulnerable to it). In that case, if the adversary modifies RSA1_5 ciphertext and sends it to the server, he is able to distinguish if the ciphertext was valid or not. This can be e.g. done using error messages sent from the server: a) in case of an invalid RSA1_5 ciphertext, the server stops its processing in step 1) and directly responds with "RSA1_5 invalid" b) in case of a valid RSA1_5 ciphertext, the server decrypts CMK and tries to validate signature. The signature is of course invalid, which leads to a different response. (See more details in: http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption-pkcs15/ ) This gave us also the possibility to execute backwards compatibility attacks on RSA OAEP. Please note that our point was not to state that jose is in general insecure. Our point was that allowing insecure algorithms (e.g. RSA1_5) and their bad implementation could spoil the security of secure ones (e.g. RSA-OAEP). Generally, such an attack could be of course *mitigated* by generating random CMKs, when the RSA1_5 is invalid. Thus, I would propose to reference Eric's https://tools.ietf.org/rfc/rfc3218.txt in your security considerations. Maybe, it would be even better to explicitly sketch these countermeasures as done in TLS1.2 (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.) Regards Juraj On 03/14/2013 06:56 PM, Mike Jones wrote: > Hi Juraj, > > Thanks for looking at the security characteristics of JWE. > > I don't think that either of your scenarios (a) or (b) apply to JWE. > > For (a), a server implementing JWE will not accept unsigned (really, non-integrity-protected) requests because encryption algorithms not providing integrity protection may not be used. > > For (b), it doesn't matter if the attacker has a valid public key that the server would accept for signatures, because the integrity protection applied to JWE is not simply a separate signature applied after the fact. The JWE's contents are protected using a randomly generated key that is encrypted by the key wrapping step. Unless the attacker already possess the key to decrypt the encrypted key (the objective of the attack in the first place!), he can't learn what key was used to apply the integrity protection, and without that key, the attacker can't apply a different signature. > > The description of the "enc" parameter in http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-08#section-4.1.2 begins with: > The "enc" (encryption method) header parameter identifies the block > encryption algorithm used to encrypt the Plaintext to produce the > Ciphertext. This algorithm MUST be an Authenticated Encryption > algorithm with a specified key length. > > If you think that's not clear enough, we could certainly say more - particularly in the Security Considerations section. Suggested text would be more than welcomed. > > Also, responding to Brian's scenario, I believe that the attack on RSA PKCS #1 1.5 requires the ability for the attacker to submit valid modified messages to the server. Because the JWE messages are integrity-protected using a wrapped key, the reasoning of (b) above applies in this case too. Specifically, without knowing the RSA key in the first place, it's not possible to learn the key used to provide the integrity check, and so not possible to create modified messages that pass the integrity check. > > But by all means, if any of my reasoning is wrong or incomplete, please do point it out! > > Thanks again, Juraj, > -- Mike > > -----Original Message----- > From: Juraj Somorovsky [mailto:juraj.somorovsky@rub.de] > Sent: Thursday, March 14, 2013 9:42 AM > To: Mike Jones > Cc: =JeffH; IETF JOSE WG; Tibor Jager > Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) > > Hi Jeff, hi Mike, > > I am sorry, it seems that I have totally missed your previous email. I try to answer some of your questions... > > On 03/14/2013 04:48 PM, Mike Jones wrote: >> I believe that these attacks are only possible on encryption without integrity, which in turn was only possible, because Nimbus-JWT continued to implement encryption algorithms without integrity protection. Someone should please correct me if I'm misunderstanding the situation. > These attacks were basically possible because: > 1) Nimbus-JWT allowed us to use AES-CBC. As we explicitly state in our paper, this is not problem of the jose specification as it forbids AES-CBC in the newer versions > > 2) We were able to force the Nimbus-JWT framework to decrypt RSA-OAEP ciphertexts with RSA1_5. You are right, in our scenarios, the Headers were not signed and thus we were able to switch from RSA-OAEP to RSA1_5. > However, if I take a look at the JSON Web Encryption standard, there is not explicitly written that the messages must be signed. And even if the messages would be signed, there could still exist scenarios where it is possible to apply these attacks. See below. >> >> As most of you know, JWE now only allows authenticated encryption algorithms to be used, for reasons exactly such as these. > It is great that you removed AES-CBC. RSA1_5 encryption is still however in the standard. >> >> -- Mike >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of =JeffH >> Sent: Thursday, March 14, 2013 8:17 AM >> To: IETF JOSE WG >> Cc: Juraj Somorovsky >> Subject: [jose] backwards compatibility attack on JWT impls (was: I-D >> Action: draft-ietf-jose-json-web-algorithms-02.txt) >> >> back on Fri, 6 Jul 2012 Mike Jones said: >> > >> > Looking at this again, it seems to me that because JWE provides integrity > protection for the algorithm, it should be impossible for you to replace > "RSA-OAEP" with "RSA1_5" in the header because then the integrity check will > fail. Thus, the attack that you describe below is prevented by the integrity > protection of the header. >> > >> > Hence, correct JWE implementations do no provide the OAEP decryption oracle > that you describe. However if I'm missing something, please point it out to > me, since if there's an issue, I'd like to understand it and how to mitigate > it. > Yes, this is true, if the attacker is not able to create valid signatures AND he is not able to force the server to process unsigned elements. However, there are few scenarios, where the attacks could still be applied. > > I am not that familiar with all the JSON scenarios but I assume that they are very close to the scenarios where XML Security is applied. > Thus, I would say it is possible to assume the following scenarios: > > a) If the server is not correctly configured, it could accept unsigned requests JSON elements. Thus, the attacker could simply extract the signature or create an additional encryption element. > > b) in some Public-Key scenarios, the attacker will have a valid key to sign his JSON requests. In that case, he is able to: > 1) take an RSA_OAEP request from his victim > 2) extract the signature from this request > 3) replace the algorithm (RSA_OAEP -> RSA1_5) and > 4) resign the request with his own key. > Afterwards, he could send the request to the server and force it to process RSA1_5 > > Please see our paper for more details (Section 4): > http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption-countermeasures/ > > > It describes some techniques how to apply such attacks on signed symmetrically encrypted XML documents. >> >> just fyi/fwiw...apologies if this has already been followed up on, but I didn't find further discussion of this after the above-quoted msg... >> >> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) attacks" paper [1] is now out, and it may help answer the above questions. There's also Kenny Patterson's talk [2] from the recent Workshop on Real-World Cryptography. >> >> It seems, from an admittedly cursory glance at both draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, that perhaps there should be more implementation advice and security considerations in (at least) the -json-web-algorithms spec. > Agreed. Some of these attacks are e.g. explicitly handled in the XML Encryption specification: > http://www.w3.org/TR/xmlenc-core1/#sec-chosen-ciphertext-attacks > > You could include similar sections in your spec. If you would need some help, just let us know. > > Thanks > Juraj > From juraj.somorovsky@rub.de Thu Mar 14 17:00:52 2013 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 3FF0B21F8B18 for ; Thu, 14 Mar 2013 17:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, 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 inflQcip0hQr for ; Thu, 14 Mar 2013 17:00:51 -0700 (PDT) Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id C214821F8AC8 for ; Thu, 14 Mar 2013 17:00:50 -0700 (PDT) X-Queued: (qmail 2649 invoked by alias); 15 Mar 2013 00:00:50 -0000 X-Queued: (qmail 2633 invoked from network); 15 Mar 2013 00:00:50 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx6.rz.ruhr-uni-bochum.de with SMTP; 15 Mar 2013 00:00:50 -0000 X-Queued: (qmail 794 invoked by uid 281); 15 Mar 2013 00:00:49 -0000 X-Qmailscanner: from 88.153.216.226 (7Cil8M2CiUy1q81idsrBaQ==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(88.153.216.226):. Processed in 0.078084 secs); 15 Mar 2013 00:00:49 -0000 Received: from ip-88-153-216-226.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUy1q81idsrBaQ==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 15 Mar 2013 00:00:49 -0000 Date: 15 Mar 2013 01:00:48 +0100 Message-ID: <514264B0.5090306@rub.de> From: "Juraj Somorovsky" To: "Justin Richer" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5142109D.7010507@mitre.org> In-Reply-To: <5142109D.7010507@mitre.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:50 -0700 Cc: Mike Jones , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 15 Mar 2013 00:00:52 -0000 Ok, thank you for mentioning. The attacks were implemented in August 2012. I mean I used the old library. The newest library seems not to use AES-CBC. However, by taking a look at https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/69de24720368c480ee93479ca84f3801a3f8909d/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java?at=master#cl-153 I assume it is still vulnerable to Bleichenbacher's attack (as it responds with different Exceptions according to the PKCS1 validity). I reported this almost 1 year ago: http://www.ietf.org/mail-archive/web/jose/current/msg00419.html Regards Juraj On 03/14/2013 07:02 PM, Justin Richer wrote: > Also, the Nimbus-JWT library has been deprecated in favor of > Nimbus-JOSE-JWT: > > https://bitbucket.org/nimbusds/nimbus-jose-jwt/ > > The new library is tracking the JOSE specs even more closely, and I'd be > very interested to hear if the attack is still possible against the new > library. > > -- Justin > > On 03/14/2013 11:48 AM, Mike Jones wrote: >> I believe that these attacks are only possible on encryption without >> integrity, which in turn was only possible, because Nimbus-JWT >> continued to implement encryption algorithms without integrity >> protection. Someone should please correct me if I'm misunderstanding >> the situation. >> >> As most of you know, JWE now only allows authenticated encryption >> algorithms to be used, for reasons exactly such as these. >> >> -- Mike >> >> -----Original Message----- >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> Of =JeffH >> Sent: Thursday, March 14, 2013 8:17 AM >> To: IETF JOSE WG >> Cc: Juraj Somorovsky >> Subject: [jose] backwards compatibility attack on JWT impls (was: I-D >> Action: draft-ietf-jose-json-web-algorithms-02.txt) >> >> back on Fri, 6 Jul 2012 Mike Jones said: >> > >> > Looking at this again, it seems to me that because JWE provides >> integrity > protection for the algorithm, it should be impossible for >> you to replace > "RSA-OAEP" with "RSA1_5" in the header because then >> the integrity check will > fail. Thus, the attack that you describe >> below is prevented by the integrity > protection of the header. >> > >> > Hence, correct JWE implementations do no provide the OAEP >> decryption oracle > that you describe. However if I'm missing >> something, please point it out to > me, since if there's an issue, >> I'd like to understand it and how to mitigate > it. >> >> just fyi/fwiw...apologies if this has already been followed up on, but >> I didn't find further discussion of this after the above-quoted msg... >> >> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) >> attacks" paper [1] is now out, and it may help answer the above >> questions. There's also Kenny Patterson's talk [2] from the recent >> Workshop on Real-World Cryptography. >> >> It seems, from an admittedly cursory glance at both >> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, >> that perhaps there should be more implementation advice and security >> considerations in (at least) the -json-web-algorithms spec. >> >> Here's some excerpts from the paper for context... >> ... >> In the public-key setting, we show how the well-known attack of >> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] >> attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 >> encryption in both XML Encryption [27] and JSON Web Encryption [42], >> and to forge signatures for arbitrary messages in XML Signature [30] >> and JSON Web Signature [41]. The attack principle is described in >> Section 4. We furthermore report on our experimental results, executed >> against the Java implementation of JSON Web Encryption and JSON Web >> Signature Nimbus-JWT [53], in Section 5.3. >> ... >> >> Platform for Experimental Analysis: We investigate the practicality >> and performance of our attacks on JWE and JWS by applying them to the >> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON >> Web Encryption (JWE) and JSON Web Signature (JWS), developed by >> NimbusDS to support their Cloud Identity management portfolio. >> >> Even though Nimbus-JWT claims to implement version 02 of the JWE >> standard draft, it still supports usage of AESCBC (without MAC), which >> was available in version 01, but not in version 02 or any subsequent >> versions. >> ... >> >> 5.2.3 Evaluation >> >> We evaluated performance of our attacks against both WSS4J and >> Nimbus-JWT. We ï¬rst used the libraries to generate valid messages >> containing AES-GCM ciphertexts. Then we modiï¬ed the algorithm >> parameters in the messages, forcing the receiver to process the >> ciphertexts using AES-CBC, and executed the attack described in >> Algorithm 1. The required ciphertext validity oracles were based on >> error messages generated by the libraries. >> ... >> >> Experimental Results. In order to assess the practicability and >> performance of the attack, we implemented Bleichenbacher’s attack on >> XML Encryption [13, 38] and applied it to the Nimbus-JWT library. The >> PKCS#1 v1.5 validity oracle was provided by exceptions thrown by this >> library.11 >> ... >> >> 11 In practice one would instead use the more elaborate attack >> techniques of [38] to determine whether a given ciphertext is PKCS#1 >> v1.5 valid. >> ... >> >> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols >> based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, >> Advances in Cryptology – CRYPTO’98, volume 1462 of Lecture Notes in >> Computer Science, pages 1–12. >> Springer, Aug. 1998. >> >> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher’s attack >> strikes >> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. >> Yung, editors, Computer Security - ESORICS 2012 - 17th European >> Symposium on Research in Computer Security, Pisa, Italy, September >> 10-14, 2012. Proceedings, LNCS. >> Springer, 2012. >> >> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. >> https://bitbucket.org/nimbusds/nimbus-jwt. >> >> ### >> >> [1] One Bad Apple: Backwards Compatibility Attacks on >> State-of-the-Art Cryptography >> http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCompatibilityAttacks.pdf >> >> >> [2] Key Reuse: Theory and Practice >> http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf >> >> >> HTH, >> >> =JeffH >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From yaronf.ietf@gmail.com Fri Mar 15 11:20:37 2013 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 824AE21F856D for ; Fri, 15 Mar 2013 11:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 8ThEOl55krfk for ; Fri, 15 Mar 2013 11:20:36 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id CE37621F8494 for ; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id c50so1776824eek.16 for ; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=WTkO75xO7uTe3BzUnqHpJZPjLYfxcvaQ6VQrsy2BjGQ=; b=JlazpskRgq9VpETqiEZSXTPPxOavHe0cJgkpFuBaQZPUOuGbVpjwrnCa0aq7HxIO+6 LnGHq+3xDuwjP/OQH4BNC8Cb4Ec2Nf6d/GJfcgZ9/P1TljO3jW3e/LkDLw5HgK9cxzKf E5RH6l84wutVSqM3jBbaqYQlK8OaEKtlhpZlYFClnhUhunGwgQX97W2TUNys5j9AeI7d LCirIc7bJdcrr7TGZhIWI0dpcjIs46spnqG/cU9WOe1qBosWxhPX3613kBgrj1dcNF9i 81h5M0xqPB0FqVoloxMJnfZ6pOM7odZ9CeQEi0iIK86fUSABDdDFMI7bdq9f4GX2EbbJ Z7zA== X-Received: by 10.15.45.201 with SMTP id b49mr20880776eew.9.1363371635001; Fri, 15 Mar 2013 11:20:35 -0700 (PDT) Received: from [10.0.0.5] (bzq-109-64-148-173.red.bezeqint.net. [109.64.148.173]) by mx.google.com with ESMTPS id q5sm11568556eeo.17.2013.03.15.11.20.33 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 11:20:34 -0700 (PDT) Message-ID: <5143666F.7080701@gmail.com> Date: Fri, 15 Mar 2013 20:20:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Peck, Michael A" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 15 Mar 2013 11:25:46 -0700 Cc: Richard Barnes , Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 18:20:37 -0000 Hi Mike, I understand your point, I believe. At the technical level, using PBKDF2 for crypto keys simply does not buy you any security, but has a high cost in performance (the performance cost is after all the whole point of PBKDF2). But the more important level is educational: I suggest that the document should make a very clear distinction between passwords and keys, so that implementors know what they're dealing with and the risks involved. Using password processing for keys would go against this goal. Thanks, Yaron On 03/15/2013 07:55 PM, Peck, Michael A wrote: > I'll try to clarify (and hopefully not dig a deeper hole). > > JWE currently provides a "dir" mechanism allowing a symmetric key previously agreed to out of band to be used for content encryption. > All of the other JWE mechanisms use a fresh symmetric key for each encryption. > > My suggestion was that instead of directly using the pre-shared symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism available the symmetric key could be used as the PBKDF2 "password", resulting in a fresh key generated for each content encryption. In this particular case the password input to PBKDF2 would hopefully be very random - I would think there would be no more risk than using the pre-shared key directly, rather less risk. > > General password considerations are a different matter. Passwords have lots of issues but if we're stuck with them we should at least advise how to do the best we can. > > Mike > >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, March 15, 2013 1:42 PM >> To: Peck, Michael A >> Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >> Subject: Re: [jose] Draft describing encrypting JWK key representations, with >> JWE >> >> Hi Mike and Mike, >> >> The NIST SP is about using PBKDF2 for storage encryption (which I'm not >> thrilled with, either). Not for sending the encrypted blob over the >> wire, for an attacker to intercept and decrypt off-line. And if we read >> the NIST document, let's adopt the whole thing - quoting from sec. A.1: >> "Passwords shorter than 10 characters are usually considered to be >> weak." Are we going to make this recommendation too? Well I guess not. >> >> *Please* do not mix passwords with cryptographic keys. If the WG goes >> through the risk vs. benefit analysis and decides to have a >> password-based mechanism, fine. But please leave the shared-key >> mechanism as-is. It's important that readers of JOSE specs are very >> clear about the difference between randomly generated keys and >> user-memorable (or even -generated) passwords. >> >> Let's be clear: even a single use of a user-generated password for >> on-the-wire encryption is risky. So-called key rotation of actual >> cryptographic keys is a whole different matter. >> >> Thanks, >> Yaron >> >> >> On 03/15/2013 06:58 PM, Peck, Michael A wrote: >>> +1 >>> >>> NIST Special Publication 800-132 provides recommendations for the >>> parameters that the group may find useful. >>> >>> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >>> >>> It may also be worth thinking about using PBKDF2 instead of the "dir" >>> (Direct Encryption with a Shared Symmetric Key) mechanism described in >>> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >>> symmetric key would be used as the PBKDF2 "password", and this would >>> force a new key to be used for each encryption, rather than the current >>> "dir" approach of using the same encryption key repeatedly. >>> >>> Mike >>> >>> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 12:53 PM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>> >>> Do I count as an expert? :) >>> >>> As I understand it, PBDKF2 is completely fine for key protection. >>> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >>> having a high number of iterations. We might want to make some >>> recommendations as to how you set those parameters. And the actual key >>> wrapping is done with something like AES-KW, so that step is fine. >>> >>> So I would be completely fine with adding this to JWE / JWA. We should >>> do this. >>> >>> --Richard >>> >>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >>> > >> wrote: >>> >>> That's up to the working group. I'm actually hoping that experts on the >>> lists will respond to Yaron's comments before we make a decision on >>> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >> not. >>> >>> Assuming that the content in Matt's draft eventually becomes an RFC or >>> part of one, the PBKDF2 definition would end up in the algorithms >>> registry either way, even if it's not part of the JWA spec itself. >>> >>> Cheers, >>> >>> -- Mike >>> >>> *From:*jose-bounces@ietf.org >>> [mailto:jose-bounces@ietf.org ] *On >> Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 9:43 AM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >>> >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>> >>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >>> wrapping algorithm? >>> >>> --Richard >>> >>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >>> > >> wrote: >>> >>> [Adding JOSE mailing list to the thread] >>> >>> For clarification, PBKDF2 is not the only algorithm that could be used >>> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >>> algorithms already specified for use with encryption in the JSON Web >>> Algorithms (JWA) specification >>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >>> particular, other algorithms such as AES Key Wrap and AES GCM are also >>> present there. >>> >>> I'll let others who are experts in PBKDF2 and password-based encryption >>> respond to Yaron's specific comment. >>> >>> -- Mike >>> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >>> ] >>> Sent: Friday, March 15, 2013 8:16 AM >>> To: cfrg@irtf.org ; Mike Jones >>> Subject: Re: Draft describing encrypting JWK key representations, with JWE >>> >>> Hi Mike, >>> >>> I'm probably missing something, but I'm worried about the security of >>> this scheme (though I do appreciate the usability/convenience of >> passwords). >>> >>> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >>> as a second line defense, once the server has been breached. Using it to >>> encrypt data and then sending the data on the wire, makes the data >>> vulnerable to this same dictionary attack (in this case the effort comes >>> to the space of all possible passwords - say 1 million - times 1000). >>> Moreover, this also puts the password itself in danger. >>> >>> Thanks, >>> Yaron >>> >>> > >>> > ------------------------------ >>> > >>> > Message: 5 >>> > Date: Fri, 15 Mar 2013 14:10:32 +0000 >>> > From: Mike Jones >> > >>> > To: "cfrg@irtf.org " >> > >>> > Subject: [Cfrg] Draft describing encrypting JWK key representations >>> > with JWE >>> > Message-ID: >>> > >>> > >> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >> d.corp. >>> >> > edmond.corp.%0b>> >>> microsoft.com > >>> > >>> > Content-Type: text/plain; charset="us-ascii" >>> > >>> > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >>> > >>> > This also adds password-based encryption to the algorithm registry. >>> > >>> > -- Mike >>> > >>> > -------------- next part -------------- An HTML attachment was >>> > scrubbed... >>> > URL: >>> > > archive/web/cfrg/attachments/20130315/02e36b >>> > 24/attachment.htm> >>> > >>> > ------------------------------ >>> > >>> > _______________________________________________ >>> > Cfrg mailing list >>> > Cfrg@irtf.org >>> > http://www.irtf.org/mailman/listinfo/cfrg >>> > >>> > >>> > End of Cfrg Digest, Vol 95, Issue 3 >>> > *********************************** >>> > >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>> From ietf@augustcellars.com Fri Mar 15 11:36:46 2013 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 367F221F89FC for ; Fri, 15 Mar 2013 11:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, 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 0h-ob0LbHK5B for ; Fri, 15 Mar 2013 11:36:42 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id B471721F89AF for ; Fri, 15 Mar 2013 11:36:42 -0700 (PDT) Received: from Philemon (dhcp-1431.meeting.ietf.org [130.129.20.49]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3CD662CA0B; Fri, 15 Mar 2013 11:36:41 -0700 (PDT) From: "Jim Schaad" To: "'Peck, Michael A'" , "'Richard Barnes'" , "'Mike Jones'" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> Date: Fri, 15 Mar 2013 14:36:07 -0400 Message-ID: <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_07C9_01CE218A.6F30DDC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHWSvveXif1uBJMdQIlAIR3tfOciwIBGSONAb2I7vQB2Zw5NAJhN+hpAaclu5ICD9JAc5g5Pjfw Content-Language: en-us Cc: 'Yaron Sheffer' , cfrg@irtf.org, jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 18:36:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_07C9_01CE218A.6F30DDC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Use PBKDF2 as a general key wrap mechanism seems to be a bad idea. Take the key and use it as a key wrap key for randomly generated content encryption key. Thus alg should be "AES128KW" rather than direct. Jim From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A Sent: Friday, March 15, 2013 12:59 PM To: Richard Barnes; Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE +1 NIST Special Publication 800-132 provides recommendations for the parameters that the group may find useful. http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf It may also be worth thinking about using PBKDF2 instead of the "dir" (Direct Encryption with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared symmetric key would be used as the PBKDF2 "password", and this would force a new key to be used for each encryption, rather than the current "dir" approach of using the same encryption key repeatedly. Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 12:53 PM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE Do I count as an expert? :) As I understand it, PBDKF2 is completely fine for key protection. PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., having a high number of iterations. We might want to make some recommendations as to how you set those parameters. And the actual key wrapping is done with something like AES-KW, so that step is fine. So I would be completely fine with adding this to JWE / JWA. We should do this. --Richard On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones wrote: That's up to the working group. I'm actually hoping that experts on the lists will respond to Yaron's comments before we make a decision on whether PBKDF2 as specified is an appropriate key wrapping algorithm or not. Assuming that the content in Matt's draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it's not part of the JWA spec itself. Cheers, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Friday, March 15, 2013 9:43 AM To: Mike Jones Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrapping algorithm? --Richard On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones wrote: [Adding JOSE mailing list to the thread] For clarification, PBKDF2 is not the only algorithm that could be used to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of algorithms already specified for use with encryption in the JSON Web Algorithms (JWA) specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In particular, other algorithms such as AES Key Wrap and AES GCM are also present there. I'll let others who are experts in PBKDF2 and password-based encryption respond to Yaron's specific comment. -- Mike -----Original Message----- From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] Sent: Friday, March 15, 2013 8:16 AM To: cfrg@irtf.org; Mike Jones Subject: Re: Draft describing encrypting JWK key representations, with JWE Hi Mike, I'm probably missing something, but I'm worried about the security of this scheme (though I do appreciate the usability/convenience of passwords). PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a second line defense, once the server has been breached. Using it to encrypt data and then sending the data on the wire, makes the data vulnerable to this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 million - times 1000). Moreover, this also puts the password itself in danger. Thanks, Yaron > > ------------------------------ > > Message: 5 > Date: Fri, 15 Mar 2013 14:10:32 +0000 > From: Mike Jones > To: "cfrg@irtf.org" > Subject: [Cfrg] Draft describing encrypting JWK key representations > with JWE > Message-ID: > > <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. > microsoft.com> > > Content-Type: text/plain; charset="us-ascii" > > http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 > > This also adds password-based encryption to the algorithm registry. > > -- Mike > > -------------- next part -------------- An HTML attachment was > scrubbed... > URL: > 24/attachment.htm> > > ------------------------------ > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg > > > End of Cfrg Digest, Vol 95, Issue 3 > *********************************** > _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_07C9_01CE218A.6F30DDC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Use PBKDF2 as a general key wrap mechanism seems to be a bad = idea.  Take the key and use it as a key wrap key for randomly = generated content encryption key.  Thus alg should be = “AES128KW” rather than direct.

 

Jim

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Peck, Michael A
Sent: Friday, March 15, 2013 12:59 = PM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; = cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft = describing encrypting JWK key representations, with = JWE

 

+1

 

NIST Special Publication 800-132 provides recommendations for the = parameters that the group may find useful.

http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.p= df

 

It may also be worth thinking about using PBKDF2 instead of the = “dir” (Direct Encryption with a Shared Symmetric Key) = mechanism described in draft-ietf-jose-json-web-algorithms-08 section = 4.6.  The shared symmetric key would be used as the PBKDF2 = “password”, and this would force a new key to be used for = each encryption, rather than the current “dir” approach of = using the same encryption key repeatedly.

 

Mike

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Friday, March 15, = 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: = [jose] Draft describing encrypting JWK key representations, with = JWE

 

Do I count = as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for key = protection.  PBKDF2 has mechanisms to mitigate the dictionary = attack risks, e.g., having a high number of iterations. We might want to = make some recommendations as to how you set those parameters. And the = actual key wrapping is done with something like AES-KW, so that step is = fine.

 

So I would be completely fine with adding this to JWE = / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

That’s up to the working group.  I’m actually hoping = that experts on the lists will respond to Yaron’s comments before = we make a decision on whether PBKDF2 as specified is an appropriate key = wrapping algorithm or not.

 

Assuming that the content in Matt’s draft eventually becomes an = RFC or part of one, the PBKDF2 definition would end up in the algorithms = registry either way, even if it’s not part of the JWA spec = itself.

 

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

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

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike = Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft = describing encrypting JWK key representations, with = JWE

 <= /o:p>

So, Mike, = would you be OK with adding PBE to JWE / JWA, as a new key wrapping = algorithm?

 <= /o:p>

--Richard

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Fri, Mar = 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com> = wrote:

[Adding = JOSE mailing list to the thread]

For clarification, PBKDF2 is not = the only algorithm that could be used to wrap keys in this scheme. =  This draft *adds* PBKDF2 to the set of algorithms already = specified for use with encryption in the JSON Web Algorithms (JWA) = specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-alg= orithms-08).  In particular, other algorithms such as AES Key = Wrap and AES GCM are also present there.

I'll let others who are = experts in PBKDF2 and password-based encryption respond to Yaron's = specific comment.

            =                     -- = Mike

-----Original Message-----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, = 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft = describing encrypting JWK key representations, with JWE

Hi = Mike,

I'm probably missing something, but I'm worried about the = security of this scheme (though I do appreciate the = usability/convenience of passwords).

PBKDF2 is meant to make = dictionary attacks on stored passwords harder, as a second line defense, = once the server has been breached. Using it to encrypt data and then = sending the data on the wire, makes the data vulnerable to this same = dictionary attack (in this case the effort comes to the space of all = possible passwords - say 1 million - times 1000).
Moreover, this also = puts the password itself in danger.

Thanks,
    =     Yaron

>
> = ------------------------------
>
> Message: 5
> Date: = Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: = "cfrg@irtf.org" <cfrg@irtf.org>
> Subject: [Cfrg] Draft = describing encrypting JWK key representations
>     =   with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284= .redmond.corp.
> microsoft.com>
>
> Content-Type: = text/plain; charset=3D"us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protec= ted-jwk-01
>
> This also adds password-based encryption = to the algorithm registry.
>
>         =                     =                     =              -- Mike
>
> = -------------- next part -------------- An HTML attachment was
> = scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg/attachments/2= 0130315/02e36b
> 24/attachment.htm>
>
> = ------------------------------
>
> = _______________________________________________
> Cfrg mailing = list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>>
> End of Cfrg Digest, Vol 95, Issue 3
> = ***********************************
>
__________________________= _____________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 <= /o:p>

 

------=_NextPart_000_07C9_01CE218A.6F30DDC0-- From housley@vigilsec.com Fri Mar 15 11:42:39 2013 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 4709511E80D1; Fri, 15 Mar 2013 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.31 X-Spam-Level: X-Spam-Status: No, score=-102.31 tagged_above=-999 required=5 tests=[AWL=0.289, 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 j485-DC6dAs9; Fri, 15 Mar 2013 11:42:38 -0700 (PDT) Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by ietfa.amsl.com (Postfix) with ESMTP id EAF1811E80A3; Fri, 15 Mar 2013 11:42:37 -0700 (PDT) Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 9EADC9A4095; Fri, 15 Mar 2013 14:42:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id 2k4oZdOcieb9; Fri, 15 Mar 2013 14:41:52 -0400 (EDT) Received: from dhcp-5419.meeting.ietf.org (dhcp-5419.meeting.ietf.org [130.129.84.25]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 110439A4094; Fri, 15 Mar 2013 14:42:08 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=windows-1252 From: Russ Housley In-Reply-To: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Date: Fri, 15 Mar 2013 14:42:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> To: Brian Weis X-Mailer: Apple Mail (2.1085) Cc: cfrg@ietf.org, jose@ietf.org Subject: Re: [jose] Use of authenticated encryption for key wrapping 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, 15 Mar 2013 18:42:39 -0000 There are some system design issues to be considered. The use of = different modes for encryption of user data and keying material makes it = easier to prevent the decryption of keying material outside of the = crypto module. Russ =20 On Mar 15, 2013, at 11:42 AM, Brian Weis wrote: > Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 >=20 > Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: >=20 > "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." >=20 > So if one considers that to be good enough advice, AES-GCM would = indeed be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. >=20 > Brian From bcampbell@pingidentity.com Fri Mar 15 12:16:47 2013 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 AB10921F8A27 for ; Fri, 15 Mar 2013 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.576 X-Spam-Level: X-Spam-Status: No, score=-5.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 b9jCltl8ARcP for ; Fri, 15 Mar 2013 12:16:46 -0700 (PDT) Received: from na3sys009aog135.obsmtp.com (na3sys009aog135.obsmtp.com [74.125.149.84]) by ietfa.amsl.com (Postfix) with ESMTP id 85F5921F8801 for ; Fri, 15 Mar 2013 12:16:46 -0700 (PDT) Received: from mail-ob0-f200.google.com ([209.85.214.200]) (using TLSv1) by na3sys009aob135.postini.com ([74.125.148.12]) with SMTP ID DSNKUUNznlrKZQ7BvWICeA8+Y3KCMBEGh4bT@postini.com; Fri, 15 Mar 2013 12:16:46 PDT Received: by mail-ob0-f200.google.com with SMTP id un3so18708034obb.7 for ; Fri, 15 Mar 2013 12:16:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=GNXTBiE8nzl9HYniXTx5ncDA0lCfwSzQZ09Pgu6Pmrw=; b=NSnhmNMsE3a6aIR4ginWKWwKmmoRsXKsrhEkWY+h61umTkrjgJxmaqxFU4y4Rmg+HE OEaOZAzzvgRlA1IcFreYsVhyecsPXHoqKguCYOkHeCclqi44OIZw5pi7j7kGkbukWVF1 t7Rd0RChKVSSSQq6sPig54P062GDEiQrOqHdcReG840iIwtinr3fl0EdPA7vhqP2AV62 P7m0AH4/qhk0JCZdpKb5T+rlreEsbEJgRd/LSnJF0+Xe5u+kxUj0cyBqBqyZth/Ifu2a p1I4US8bFB1i6f/p+Uk7Bm20qrLF1Gem2Pzd4LhQeOOpbU8CkVzlL/Y4I55oI3s3wV1N cCJA== X-Received: by 10.50.37.236 with SMTP id b12mr2105607igk.42.1363375005655; Fri, 15 Mar 2013 12:16:45 -0700 (PDT) X-Received: by 10.50.37.236 with SMTP id b12mr2105603igk.42.1363375005542; Fri, 15 Mar 2013 12:16:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Fri, 15 Mar 2013 12:16:15 -0700 (PDT) In-Reply-To: References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> From: Brian Campbell Date: Fri, 15 Mar 2013 13:16:15 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=f46d044788d9e6b9fa04d7fb7aa8 X-Gm-Message-State: ALoCoQkWNMgtiSzv4SVe7lAskyKjQMU7TmE9UmEX6ywlP1NTENs3w7lcaMMYFu8NC8rV6iHFDE6mf2IqOTtYBwU6OxeEEdKkO0VRjkIJTqAMX+yPs6UmRb/aRNZ6s/YHpEJLEPuQSQXp Cc: "Manger, James H" , "" , "Matt Miller \(mamille2\)" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 19:16:47 -0000 --f46d044788d9e6b9fa04d7fb7aa8 Content-Type: text/plain; charset=ISO-8859-1 Agreed, if "x5c" goes directly as an attribute of JWK (or an attribute common to EC and RSA key types), it attaches to an individual JWK and definitely not to a whole JWK Set. On Fri, Mar 15, 2013 at 12:11 PM, Richard Barnes wrote: > Another clarification: I'm fine with either "x5c" as a JWK, or "PKIX" as > a "kty" value. In the former case, I would prefer that the "x5c" be > attached to individual keys and not key sets. > > > > On Friday, March 15, 2013, Richard Barnes wrote: > >> Just to clarify, what I'm suggesting is to have "x5c" as an attribute for >> JWK, with the same syntax as in JWS. As Brian suggested in his slides. >> >> IF we want to go down the path of having "chained" JWKs, the syntax would >> be something like the following: >> "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] >> Where jws(kx, ky) indicates a JWS with ky as the body and kx as the >> signing key. IF we build something like this, it would be used in the same >> manner as "x5c", as an attribute of a JWK. However, I think designing such >> a thing would be a significant deviation from our charter, so we would need >> to recharter or even form a new WG (PKIJ?) >> >> --Richard >> >> >> >> On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes wrote: >> >>> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < >>> James.H.Manger@team.telstra.com> wrote: >>> >>>> I agree, a certificate as an optional field of any JWK sounds like a >>>> decent approach. >>>> >>> >>> +1, although it's not mutually exclusive with having a "PKIX" key type. >>> >>> >>>> Putting a whole cert chain in one JWK is not ideal. >>>> Each cert is about 1 key so really should be in its own JWK. >>>> Otherwise you will duplicate the chain of intermediate CA certs in each >>>> JWK in a set. >>>> >>>> It might be useful to define a issuer key-id field ("isskid"). A JWK >>>> could include a cert for its own key and (with "isskid") a link to the next >>>> cert along the chain. That makes it quick-n-easy to build a chain from the >>>> JWKs in a set. >>>> >>>> It would also help if JWKs in a set where held in a >>>> object/dictionary/associative-array with the kid as the name. That would be >>>> better than using an array of JWKs with no defined meaning for the order. >>>> >>> >>> This proposal seems much, much worse than having a cert chain in one >>> JWK. If you're going to have all the public keys as JWKs, you might as >>> well just re-invent X.509 in JWK, in which case you would probably use JWS >>> over JWK, which solves the "isskid" problem using the "kid" in the JWS. >>> The benefit of having the cert chain is that you don't have to re-invent >>> X.509, you just pass the cert chain to your existing X.509 library. >>> >>> In other words, let's have the trust chain be fully X.509 or fully JOSE, >>> even if it starts from a JWK. >>> >>> --Richard >>> >>> >>> >>> >>>> >>>> -- >>>> James Manger >>>> >>>> > -----Original Message----- >>>> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>>> Of >>>> > Matt Miller (mamille2) >>>> > Sent: Friday, 15 March 2013 12:48 AM >>>> > To: >>>> > Subject: [jose] Rolling PKIX into JWK >>>> > >>>> > [hoping this topic is the least controversial...] >>>> > >>>> > In some IRL discussions on moving forward on PKIX in JWK, I've been >>>> > convinced the concerns are mostly the same regardless of how the PKIX >>>> > is packaged. Given that, I would suggest we make "x5c" an optional >>>> > field of JWK, rather than defining a new JWK type. I can propose >>>> > various text additions after this meeting. >>>> > >>>> > >>>> > Thoughts? >>>> > >>>> > - m&m >>>> > >>>> > Matt Miller < mamille2@cisco.com > >>>> > Cisco Systems, Inc. >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >>> >>> >> > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d044788d9e6b9fa04d7fb7aa8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Agreed, if "x5c" goes directly as an attribute o= f JWK (or an attribute common to EC and RSA key types), it attaches to an i= ndividual JWK and definitely not to a whole JWK Set.=A0


On Fri, Mar 15, 2013 at 12:11 PM, Richar= d Barnes <rlb@ipv.sx> wrote:
Another clarification: =A0I'm fine with either "x5c" as a JWK= , or "PKIX" as a "kty" value. In the former case, I wou= ld prefer that the "x5c" be attached to individual keys and not k= ey sets. =A0



On Friday, March 15, 2013, Richard Barn= es wrote:
Just to clarify, what I'm = suggesting is to have "x5c" as an attribute for JWK, with the sam= e syntax as in JWS. =A0As Brian suggested in his slides.

IF we want to go down the path of having "chained"= JWKs, the syntax would be something like the following:
"jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ]
= Where jws(kx, ky) indicates a JWS with ky as the body and kx as the signing= key. =A0IF we build something like this, it would be used in the same mann= er as "x5c", as an attribute of a JWK. =A0However, I think design= ing such a thing would be a significant deviation from our charter, so we w= ould need to recharter or even form a new WG (PKIJ?)

--Richard



On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes <rlb@ipv.sx> wrote:
On Fri, Mar 15, 2013 at 2:43 AM, Manger= , James H <James.H.Manger@team.telstra.com><= /span> wrote:
I agree, a certificate as an optional field of any JWK sounds like a decent= approach.

+1, although it's = not mutually exclusive with having a "PKIX" key type.
=A0
Putting a whole cert chain in one JWK is not ideal.
Each cert is about 1 key so really should be in its own JWK.
Otherwise you will duplicate the chain of intermediate CA certs in each JWK= in a set.

It might be useful to define a issuer key-id field ("isskid"). A = JWK could include a cert for its own key and (with "isskid") a li= nk to the next cert along the chain. That makes it quick-n-easy to build a = chain from the JWKs in a set.

It would also help if JWKs in a set where held in a object/dictionary/assoc= iative-array with the kid as the name. That would be better than using an a= rray of JWKs with no defined meaning for the order.

This proposal seems much, much worse than having a cer= t chain in one JWK. =A0If you're going to have all the public keys as J= WKs, you might as well just re-invent X.509 in JWK, in which case you would= probably use JWS over JWK, which solves the "isskid" problem usi= ng the "kid" in the JWS. =A0The benefit of having the cert chain = is that you don't have to re-invent X.509, you just pass the cert chain= to your existing X.509 library. =A0

In other words, let's have the trust chain be fully= X.509 or fully JOSE, even if it starts from a JWK. =A0

--Richard


=A0

--
James Manger

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Matt Miller (mamille2)
> Sent: Friday, 15 March 2013 12:48 AM
> To: <jose@ietf.org>
> Subject: [jose] Rolling PKIX into JWK
>
> [hoping this topic is the least controversial...]
>
> In some IRL discussions on moving forward on PKIX in JWK, I've bee= n
> convinced the concerns are mostly the same regardless of how the PKIX<= br> > is packaged. =A0Given that, I would suggest we make "x5c" an= optional
> field of JWK, rather than defining a new JWK type. =A0I can propose > various text additions after this meeting.
>
>
> Thoughts?
>
> - m&m
>
> Matt Miller < mamille2@cisco.com >
> Cisco Systems, Inc.

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d044788d9e6b9fa04d7fb7aa8-- From mamille2@cisco.com Fri Mar 15 12:47:46 2013 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 0FF5C21F898A for ; Fri, 15 Mar 2013 12:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, 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 xPHFTTVqN8FC for ; Fri, 15 Mar 2013 12:47:44 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 77FA421F88E1 for ; Fri, 15 Mar 2013 12:47:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13468; q=dns/txt; s=iport; t=1363376864; x=1364586464; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9XvP6I2rxLEYQHxbxFQdV6nzr6O/y+PM4j7/L89sGuY=; b=jWuXYnCLIiglDHFRUvdx7kW7o2YQ/2mI9Bg1h3i8rlSi+E2dDgjIMzM5 stbrl4GgcfepYk7hh0s+WYAcxHino90AlHRf+rWxAOVRhqQRUGXe+3K5N pcswXoxlsw0rcaavMNf1zLCkQK87IAj9QNqAra+pOOg++IKRZ7ACnyKoY 8=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACN5Q1GtJV2a/2dsb2JhbABDhVm/TYFnFnSCKgEBAQIBAQEBAWgDCwUHBAIBCBEDAQEBAQoODwcCHwYLFAkIAgQOBQgBBYd0AwkGBwW5Sg2JW4xCCoEZBnkGEAoGCwcEAgMPgkdhA484gSiBfIIfgn+KSQOFF4MKgWsIFx4 X-IronPort-AV: E=Sophos;i="4.84,853,1355097600"; d="p7s'?scan'208";a="188024867" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 15 Mar 2013 19:47:43 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2FJlhbJ022881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 19:47:43 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 14:47:43 -0500 From: "Matt Miller (mamille2)" To: "Peck, Michael A" Thread-Topic: [jose] Draft describing encrypting JWK key representations, with JWE Thread-Index: AQHOIaVNkbPUau2CRd2Y+GZP3Ym7fZinB6HAgAB0zwA= Date: Fri, 15 Mar 2013 19:47:43 +0000 Message-ID: References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.204] Content-Type: multipart/signed; boundary="Apple-Mail=_C73EF65F-3503-46ED-8590-7C5D9F7099BE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Richard Barnes , Yaron Sheffer , Mike Jones , "cfrg@irtf.org" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 19:47:46 -0000 --Apple-Mail=_C73EF65F-3503-46ED-8590-7C5D9F7099BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii My intent for introducing PBES2 key wrapping algorithms was for those = times when the key exchange is at the human-level. I think there are = probably better mechanisms when the input in appropriately random to = start with, although I personally don't see a tremendous amount of harm = using a PBES2-based algorithm with stronger "passwords". I tried to address some concerns around the use of passwords, but did = rely on what RFC2898 already says about specific values for iteration = counts and salts. I'd be happy to incorporate more direction there, if = someone could help provide some text. I'd also be happy to help = incorporate this into whatever other document we'd rather have it in. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Mar 15, 2013, at 1:55 PM, "Peck, Michael A" wrote: > I'll try to clarify (and hopefully not dig a deeper hole). >=20 > JWE currently provides a "dir" mechanism allowing a symmetric key = previously agreed to out of band to be used for content encryption. > All of the other JWE mechanisms use a fresh symmetric key for each = encryption. >=20 > My suggestion was that instead of directly using the pre-shared = symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism = available the symmetric key could be used as the PBKDF2 "password", = resulting in a fresh key generated for each content encryption. In this = particular case the password input to PBKDF2 would hopefully be very = random - I would think there would be no more risk than using the = pre-shared key directly, rather less risk. >=20 > General password considerations are a different matter. Passwords = have lots of issues but if we're stuck with them we should at least = advise how to do the best we can. >=20 > Mike >=20 >> -----Original Message----- >> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >> Sent: Friday, March 15, 2013 1:42 PM >> To: Peck, Michael A >> Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >> Subject: Re: [jose] Draft describing encrypting JWK key = representations, with >> JWE >>=20 >> Hi Mike and Mike, >>=20 >> The NIST SP is about using PBKDF2 for storage encryption (which I'm = not >> thrilled with, either). Not for sending the encrypted blob over the >> wire, for an attacker to intercept and decrypt off-line. And if we = read >> the NIST document, let's adopt the whole thing - quoting from sec. = A.1: >> "Passwords shorter than 10 characters are usually considered to be >> weak." Are we going to make this recommendation too? Well I guess = not. >>=20 >> *Please* do not mix passwords with cryptographic keys. If the WG goes >> through the risk vs. benefit analysis and decides to have a >> password-based mechanism, fine. But please leave the shared-key >> mechanism as-is. It's important that readers of JOSE specs are very >> clear about the difference between randomly generated keys and >> user-memorable (or even -generated) passwords. >>=20 >> Let's be clear: even a single use of a user-generated password for >> on-the-wire encryption is risky. So-called key rotation of actual >> cryptographic keys is a whole different matter. >>=20 >> Thanks, >> Yaron >>=20 >>=20 >> On 03/15/2013 06:58 PM, Peck, Michael A wrote: >>> +1 >>>=20 >>> NIST Special Publication 800-132 provides recommendations for the >>> parameters that the group may find useful. >>>=20 >>> = http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >>>=20 >>> It may also be worth thinking about using PBKDF2 instead of the = "dir" >>> (Direct Encryption with a Shared Symmetric Key) mechanism described = in >>> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >>> symmetric key would be used as the PBKDF2 "password", and this would >>> force a new key to be used for each encryption, rather than the = current >>> "dir" approach of using the same encryption key repeatedly. >>>=20 >>> Mike >>>=20 >>> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On = Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 12:53 PM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>>=20 >>> Do I count as an expert? :) >>>=20 >>> As I understand it, PBDKF2 is completely fine for key protection. >>> PBKDF2 has mechanisms to mitigate the dictionary attack risks, = e.g., >>> having a high number of iterations. We might want to make some >>> recommendations as to how you set those parameters. And the actual = key >>> wrapping is done with something like AES-KW, so that step is fine. >>>=20 >>> So I would be completely fine with adding this to JWE / JWA. We = should >>> do this. >>>=20 >>> --Richard >>>=20 >>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >>> > >> wrote: >>>=20 >>> That's up to the working group. I'm actually hoping that experts on = the >>> lists will respond to Yaron's comments before we make a decision on >>> whether PBKDF2 as specified is an appropriate key wrapping algorithm = or >> not. >>>=20 >>> Assuming that the content in Matt's draft eventually becomes an RFC = or >>> part of one, the PBKDF2 definition would end up in the algorithms >>> registry either way, even if it's not part of the JWA spec itself. >>>=20 >>> Cheers, >>>=20 >>> -- Mike >>>=20 >>> *From:*jose-bounces@ietf.org >>> [mailto:jose-bounces@ietf.org ] *On >> Behalf >>> Of *Richard Barnes >>> *Sent:* Friday, March 15, 2013 9:43 AM >>> *To:* Mike Jones >>> *Cc:* Yaron Sheffer; cfrg@irtf.org ; = jose@ietf.org >>> >>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>> representations, with JWE >>>=20 >>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >>> wrapping algorithm? >>>=20 >>> --Richard >>>=20 >>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >>> > >> wrote: >>>=20 >>> [Adding JOSE mailing list to the thread] >>>=20 >>> For clarification, PBKDF2 is not the only algorithm that could be = used >>> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >>> algorithms already specified for use with encryption in the JSON Web >>> Algorithms (JWA) specification >>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). = In >>> particular, other algorithms such as AES Key Wrap and AES GCM are = also >>> present there. >>>=20 >>> I'll let others who are experts in PBKDF2 and password-based = encryption >>> respond to Yaron's specific comment. >>>=20 >>> -- Mike >>>=20 >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >>> ] >>> Sent: Friday, March 15, 2013 8:16 AM >>> To: cfrg@irtf.org ; Mike Jones >>> Subject: Re: Draft describing encrypting JWK key representations, = with JWE >>>=20 >>> Hi Mike, >>>=20 >>> I'm probably missing something, but I'm worried about the security = of >>> this scheme (though I do appreciate the usability/convenience of >> passwords). >>>=20 >>> PBKDF2 is meant to make dictionary attacks on stored passwords = harder, >>> as a second line defense, once the server has been breached. Using = it to >>> encrypt data and then sending the data on the wire, makes the data >>> vulnerable to this same dictionary attack (in this case the effort = comes >>> to the space of all possible passwords - say 1 million - times = 1000). >>> Moreover, this also puts the password itself in danger. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>>>=20 >>>> ------------------------------ >>>>=20 >>>> Message: 5 >>>> Date: Fri, 15 Mar 2013 14:10:32 +0000 >>>> From: Mike Jones >> > >>>> To: "cfrg@irtf.org " >> > >>>> Subject: [Cfrg] Draft describing encrypting JWK key representations >>>> with JWE >>>> Message-ID: >>>>=20 >>>>=20 >> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >> d.corp. >>>=20 >> > edmond.corp.%0b>> >>> microsoft.com > >>>>=20 >>>> Content-Type: text/plain; charset=3D"us-ascii" >>>>=20 >>>> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >>>>=20 >>>> This also adds password-based encryption to the algorithm registry. >>>>=20 >>>> -- Mike >>>>=20 >>>> -------------- next part -------------- An HTML attachment was >>>> scrubbed... >>>> URL: >>>> > archive/web/cfrg/attachments/20130315/02e36b >>>> 24/attachment.htm> >>>>=20 >>>> ------------------------------ >>>>=20 >>>> _______________________________________________ >>>> Cfrg mailing list >>>> Cfrg@irtf.org >>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>=20 >>>>=20 >>>> End of Cfrg Digest, Vol 95, Issue 3 >>>> *********************************** >>>>=20 >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>>=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_C73EF65F-3503-46ED-8590-7C5D9F7099BE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxNTE5NDc0M1owIwYJKoZIhvcNAQkEMRYEFD3BW4Jv9Kie9tp0Ix90yteE8wYJMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCmmlp3UdOWZOId22MT7SlpKmq8Bk3W/bZak23n0n8h 3/fW3Bl88Az8gGA7cX1gVjAXfcpU0Xw3c/Bz6Q7NEdIGXKc4iWMl+9+12/rFBzVoc2BdeJs/v/7m 2sL4//o4Nd1noNyD/oOxQZiSOtc5L4Dmcnnf+YK0bt8GaR9wIfwF89IJ9PMFPnVgpdd+kgmM28T+ 5O0OFlXuxETEYcOpdB8jTQVROF9NV6LFPVTUS9+lIWzxdFppz4TD+hun0b+/4OUoGDK8VGAr8fre x6OWM4yMgG8qYsgqupWWNTYcrCFd1mubGG/Ey/Fdz/EE6JZNveGOtJPE4D0mO1tF4UYlcaobAAAA AAAA --Apple-Mail=_C73EF65F-3503-46ED-8590-7C5D9F7099BE-- From mamille2@cisco.com Fri Mar 15 12:49:33 2013 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 916CE21F8903 for ; Fri, 15 Mar 2013 12:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 NcYQgPgjuwfo for ; Fri, 15 Mar 2013 12:49:32 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEA021F88F1 for ; Fri, 15 Mar 2013 12:49:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8016; q=dns/txt; s=iport; t=1363376972; x=1364586572; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5EQJcKvMMHvM5aIFGp0qM+DCH658RISueze9StCjBKc=; b=YTxjZHaOyrwDEy/f8IhDwsFUXezBwsbb7UNT2VCNvP/wDhvBo5wUxFJJ mM6Fxb6g7iFLQZDvm54QO1HVLWiBTK1r2fFC4ImqnUiDFq2amoZfJrYog zbuxe2UZRn6eXlPApXQ+ZehYaj57Rp3O7ZyvASvQkQYt1VjqrpA/jBtQV Y=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANp6Q1GtJXG+/2dsb2JhbABDxSaBZxZ0gioBAQEDAQEBAWsLBQcEAgEIDgMEAQEBCh0HAiULFAkIAgQOBQgGh3QDCQYMuU8diUcEjmQmCwcGgllhA484gSiCNpRHgwqCKA X-IronPort-AV: E=Sophos;i="4.84,853,1355097600"; d="p7s'?scan'208";a="185033460" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 15 Mar 2013 19:49:32 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2FJnWxB021210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 15 Mar 2013 19:49:32 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Fri, 15 Mar 2013 14:49:32 -0500 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [jose] Rolling PKIX into JWK Thread-Index: AQHOILqMA29glkFWZUOgI7llc9nICpimRb5ggAEG0wCAAAYDgIAAENKAgAAbYoA= Date: Fri, 15 Mar 2013 19:49:31 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.21.112.204] Content-Type: multipart/signed; boundary="Apple-Mail=_1F7D6BCF-7E5E-480E-8466-67C355CB0AF8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Manger, James H" , "" Subject: Re: [jose] Rolling PKIX into JWK 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, 15 Mar 2013 19:49:33 -0000 --Apple-Mail=_1F7D6BCF-7E5E-480E-8466-67C355CB0AF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 15, 2013, at 2:11 PM, Richard Barnes wrote: > Another clarification: I'm fine with either "x5c" as a JWK, or "PKIX" = as a > "kty" value. In the former case, I would prefer that the "x5c" be = attached > to individual keys and not key sets. >=20 +1; only in a JWK object, not the set. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. >=20 > On Friday, March 15, 2013, Richard Barnes wrote: >=20 >> Just to clarify, what I'm suggesting is to have "x5c" as an attribute = for >> JWK, with the same syntax as in JWS. As Brian suggested in his = slides. >>=20 >> IF we want to go down the path of having "chained" JWKs, the syntax = would >> be something like the following: >> "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] >> Where jws(kx, ky) indicates a JWS with ky as the body and kx as the >> signing key. IF we build something like this, it would be used in = the same >> manner as "x5c", as an attribute of a JWK. However, I think = designing such >> a thing would be a significant deviation from our charter, so we = would need >> to recharter or even form a new WG (PKIJ?) >>=20 >> --Richard >>=20 >>=20 >>=20 >> On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes = >>> wrote: >>=20 >>> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < >>> James.H.Manger@team.telstra.com >> 'James.H.Manger@team.telstra.com');>> wrote: >>>=20 >>>> I agree, a certificate as an optional field of any JWK sounds like = a >>>> decent approach. >>>>=20 >>>=20 >>> +1, although it's not mutually exclusive with having a "PKIX" key = type. >>>=20 >>>=20 >>>> Putting a whole cert chain in one JWK is not ideal. >>>> Each cert is about 1 key so really should be in its own JWK. >>>> Otherwise you will duplicate the chain of intermediate CA certs in = each >>>> JWK in a set. >>>>=20 >>>> It might be useful to define a issuer key-id field ("isskid"). A = JWK >>>> could include a cert for its own key and (with "isskid") a link to = the next >>>> cert along the chain. That makes it quick-n-easy to build a chain = from the >>>> JWKs in a set. >>>>=20 >>>> It would also help if JWKs in a set where held in a >>>> object/dictionary/associative-array with the kid as the name. That = would be >>>> better than using an array of JWKs with no defined meaning for the = order. >>>>=20 >>>=20 >>> This proposal seems much, much worse than having a cert chain in one = JWK. >>> If you're going to have all the public keys as JWKs, you might as = well >>> just re-invent X.509 in JWK, in which case you would probably use = JWS over >>> JWK, which solves the "isskid" problem using the "kid" in the JWS. = The >>> benefit of having the cert chain is that you don't have to re-invent = X.509, >>> you just pass the cert chain to your existing X.509 library. >>>=20 >>> In other words, let's have the trust chain be fully X.509 or fully = JOSE, >>> even if it starts from a JWK. >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> -- >>>> James Manger >>>>=20 >>>>> -----Original Message----- >>>>> From: jose-bounces@ietf.org >>> 'jose-bounces@ietf.org');> = [mailto:jose-bounces@ietf.org] >>>> On Behalf Of >>>>> Matt Miller (mamille2) >>>>> Sent: Friday, 15 March 2013 12:48 AM >>>>> To: > >>>>> Subject: [jose] Rolling PKIX into JWK >>>>>=20 >>>>> [hoping this topic is the least controversial...] >>>>>=20 >>>>> In some IRL discussions on moving forward on PKIX in JWK, I've = been >>>>> convinced the concerns are mostly the same regardless of how the = PKIX >>>>> is packaged. Given that, I would suggest we make "x5c" an = optional >>>>> field of JWK, rather than defining a new JWK type. I can propose >>>>> various text additions after this meeting. >>>>>=20 >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> - m&m >>>>>=20 >>>>> Matt Miller < mamille2@cisco.com >>> 'mamille2@cisco.com');> > >>>>> Cisco Systems, Inc. >>>>=20 >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>>=20 >>=20 --Apple-Mail=_1F7D6BCF-7E5E-480E-8466-67C355CB0AF8 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxNTE5NDkzMVowIwYJKoZIhvcNAQkEMRYEFKloKitPFLi/8/ruzd5K63yD7xjgMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAxolFhSDOUpOK8+j7+lK9aj6eqFmqU2twIjS/PsDgu hO5WQ5s+G9rjkNEG7jG7YfLon1RnydQt9apRxb4D9c37ndJrIIqf88XDGX0rRiIMI2mle6OwjHyj VwnqGAUj6ZsGYh6iEkSBuchTHJ1/UcxiYqF/3HAcvG22cVE/AmAw6hWtTVer0jb+MhEAYcwZsJMt ptJs/xYRxp/xtS38j8S9i/BLX9ULowBM9ktYCZe0IWVllU7bn5CGTW3mWMMQDaxTEe9YEuwZv2NG lgX9XxHZsxKd8xko0wSuONzQOGTRTe6TqsWp38cS24legawW1xDnCpXD9bw3oa/lzIMhlokZAAAA AAAA --Apple-Mail=_1F7D6BCF-7E5E-480E-8466-67C355CB0AF8-- From bcampbell@pingidentity.com Fri Mar 15 13:04:01 2013 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 3E59B21F86B2 for ; Fri, 15 Mar 2013 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Tl5ahPlvRiL9 for ; Fri, 15 Mar 2013 13:04:00 -0700 (PDT) Received: from na3sys009aog119.obsmtp.com (na3sys009aog119.obsmtp.com [74.125.149.246]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3BB21F8615 for ; Fri, 15 Mar 2013 13:04:00 -0700 (PDT) Received: from mail-ia0-f200.google.com ([209.85.210.200]) (using TLSv1) by na3sys009aob119.postini.com ([74.125.148.12]) with SMTP ID DSNKUUN+sGHW5OtXXLpaypNYJNcZx3eYcLt/@postini.com; Fri, 15 Mar 2013 13:04:00 PDT Received: by mail-ia0-f200.google.com with SMTP id k38so12579010iah.11 for ; Fri, 15 Mar 2013 13:03:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=xG7sWDZ18Rpd95QtzKkMReZHCBI4tI4PKWAKUn5wuQU=; b=XbIMRY6cQkpcgMz80Om9u3LtJPPaMKmPT/j8aIN3kCkCjJRtvo924wqAVcq4+WjiWx gv0wVdT0eUCTww/2qghOWPkAwWHOZjGkz8uMK5xtFoh4Q1oToT/OikC0fEUkOgJstySc gedOP8CkGbnJd/bSITG/rSikc5LnZjETP4qSKxKYhJVhgC/SgtftDbqCAjT32rnpril0 dHZ1fAl8z/kZl62Mmb7JppWWLU9+ca+dw35qJOwLIOP7orJJBIS01Anf2ptoMKIzrYOg r0rkHYXAxeo0wdZoLPFOZXKfthVc2nHqh4nTEEgQh4e5KDAj6rSslbVZfCV9pfO2HnfO n8bw== X-Received: by 10.50.37.236 with SMTP id b12mr2217483igk.42.1363377839643; Fri, 15 Mar 2013 13:03:59 -0700 (PDT) X-Received: by 10.50.37.236 with SMTP id b12mr2217479igk.42.1363377839574; Fri, 15 Mar 2013 13:03:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Fri, 15 Mar 2013 13:03:29 -0700 (PDT) In-Reply-To: <514262C3.8010408@rub.de> References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5141FDC1.5000102@rub.de> <4E1F6AAD24975D4BA5B1680429673943675110FD@TK5EX14MBXC283.redmond.corp.microsoft.com> <514262C3.8010408@rub.de> From: Brian Campbell Date: Fri, 15 Mar 2013 14:03:29 -0600 Message-ID: To: Juraj Somorovsky Content-Type: multipart/alternative; boundary=f46d044788d9d2b07604d7fc23b6 X-Gm-Message-State: ALoCoQnq0IW9c53UtVY+49Bnt4eqwEZ/zgqZiWhKz3H43bSWqjI1Q116gvXRBcHG4BUW1fh7zF5mSawLMrYk2rvlwn/m8+bNsEbDYIUPQel4EZ+reyDZgCdq6tZT9vhC7p9Jh34gAxug Cc: Tibor Jager , Mike Jones , =JeffH , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 15 Mar 2013 20:04:01 -0000 --f46d044788d9d2b07604d7fc23b6 Content-Type: text/plain; charset=ISO-8859-1 +1 Thanks Juraj. On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky wrote: > > Generally, such an attack could be of course *mitigated* by generating > random CMKs, when the RSA1_5 is invalid. Thus, I would propose to > reference Eric's > https://tools.ietf.org/rfc/rfc3218.txt > in your security considerations. Maybe, it would be even better to > explicitly sketch these countermeasures as done in TLS1.2 > (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.) > > Regards > Juraj > --f46d044788d9d2b07604d7fc23b6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Thanks Juraj.

On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky <juraj.somorovsky@rub.de> wrote:

Generally, such an attack could be of course *mitigated* by generating
random CMKs, when the RSA1_5 is invalid. Thus, I would propose to
reference Eric's
https:= //tools.ietf.org/rfc/rfc3218.txt
in your security considerations. Maybe, it would be even better to
explicitly sketch these countermeasures as done in TLS1.2
(http://w= ww.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.)

Regards
Juraj
--f46d044788d9d2b07604d7fc23b6-- From yaronf.ietf@gmail.com Fri Mar 15 12:45:43 2013 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 2E4E221F8873 for ; Fri, 15 Mar 2013 12:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.148 X-Spam-Level: X-Spam-Status: No, score=-97.148 tagged_above=-999 required=5 tests=[AWL=-3.245, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_BEFORE=1.272, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.334, J_CHICKENPOX_53=0.6, RCVD_IN_PBL=0.905, RCVD_IN_XBL=3.033, RDNS_NONE=0.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 BS7q3rAI-qlu for ; Fri, 15 Mar 2013 12:45:40 -0700 (PDT) Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 366A021F8904 for ; Fri, 15 Mar 2013 12:45:39 -0700 (PDT) Received: by mail-ea0-f169.google.com with SMTP id z7so1751428eaf.28 for ; Fri, 15 Mar 2013 12:45:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:user-agent:in-reply-to:references:mime-version :content-type:subject:from:date:to:cc:message-id; bh=P1Bd9our7zTj/hOvsHafWdzKPRuc3DF4S+nopcVBMz8=; b=V7KEVt4gIgAhSS8h5AiFPSfPdHQEFE3o3hGXUpw9VlxtbUU+1Mn3BNwJqlpCVA9rGF ldF6PC5MuXyq3R8qsF9XtXftYM8N5EVhp4aanldp3o9w/i1FZsTpp47SCwLY8oYcADa/ W7vHrXWsFqgtKpdKN3qd2kTEwIorFCRJH/LswRjnHRm1Xq+LcFCvRm4uYTeBZ2jI5gzW 4POvChkzh2bVip6Us2QcQ5AxkQ9+X0OaC5pqoTyucxnb4seitza25Jf91sZoxGmT38Uj TN5oXha0poPL5BkoJvbxFzc7AyIqCtpOfXUdr5Xnc/Oxt6K7YSjftQ28vfYusMgoBP3T 7SWA== X-Received: by 10.14.209.131 with SMTP id s3mr21318713eeo.26.1363376737965; Fri, 15 Mar 2013 12:45:37 -0700 (PDT) Received: from [10.209.190.56] ([95.35.60.56]) by mx.google.com with ESMTPS id a1sm12019630eep.2.2013.03.15.12.45.35 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 12:45:37 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----YXTMSIONN0BDIJ4N2082HKWH1H2BKB" From: Yaron Sheffer Date: Fri, 15 Mar 2013 21:45:30 +0200 To: Jim Schaad , "'Peck, Michael A'" , 'Richard Barnes' , 'Mike Jones' Message-ID: <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> X-Mailman-Approved-At: Fri, 15 Mar 2013 16:33:13 -0700 Cc: cfrg@irtf.org, jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 15 Mar 2013 19:45:43 -0000 ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit no way to generate a strong key in JavaScript. So you also need a way to use a key directly. But I'm by no means a JOSE expert, they may have different assumptions. Thanks, Yaron Jim Schaad wrote: >Use PBKDF2 as a general key wrap mechanism seems to be a bad idea. >Take the >key and use it as a key wrap key for randomly generated content >encryption >key. Thus alg should be "AES128KW" rather than direct. > > > >Jim > > > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Peck, Michael A >Sent: Friday, March 15, 2013 12:59 PM >To: Richard Barnes; Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >+1 > > > >NIST Special Publication 800-132 provides recommendations for the >parameters >that the group may find useful. > >http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf > > > >It may also be worth thinking about using PBKDF2 instead of the "dir" >(Direct Encryption with a Shared Symmetric Key) mechanism described in >draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >symmetric >key would be used as the PBKDF2 "password", and this would force a new >key >to be used for each encryption, rather than the current "dir" approach >of >using the same encryption key repeatedly. > > > >Mike > > > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Richard Barnes >Sent: Friday, March 15, 2013 12:53 PM >To: Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >Do I count as an expert? :) > > > >As I understand it, PBDKF2 is completely fine for key protection. >PBKDF2 >has mechanisms to mitigate the dictionary attack risks, e.g., having a >high >number of iterations. We might want to make some recommendations as to >how >you set those parameters. And the actual key wrapping is done with >something >like AES-KW, so that step is fine. > > > >So I would be completely fine with adding this to JWE / JWA. We should >do >this. > > > >--Richard > > > > > >On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones > >wrote: > >That's up to the working group. I'm actually hoping that experts on >the >lists will respond to Yaron's comments before we make a decision on >whether >PBKDF2 as specified is an appropriate key wrapping algorithm or not. > > > >Assuming that the content in Matt's draft eventually becomes an RFC or >part >of one, the PBKDF2 definition would end up in the algorithms registry >either >way, even if it's not part of the JWA spec itself. > > > > Cheers, > > -- Mike > > > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Richard Barnes >Sent: Friday, March 15, 2013 9:43 AM >To: Mike Jones >Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >Subject: Re: [jose] Draft describing encrypting JWK key >representations, >with JWE > > > >So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >wrapping algorithm? > > > >--Richard > > > > > > > >On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones > >wrote: > >[Adding JOSE mailing list to the thread] > >For clarification, PBKDF2 is not the only algorithm that could be used >to >wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >algorithms >already specified for use with encryption in the JSON Web Algorithms >(JWA) >specification >(http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). >In >particular, other algorithms such as AES Key Wrap and AES GCM are also >present there. > >I'll let others who are experts in PBKDF2 and password-based encryption >respond to Yaron's specific comment. > > -- Mike > >-----Original Message----- >From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >Sent: Friday, March 15, 2013 8:16 AM >To: cfrg@irtf.org; Mike Jones >Subject: Re: Draft describing encrypting JWK key representations, with >JWE > >Hi Mike, > >I'm probably missing something, but I'm worried about the security of >this >scheme (though I do appreciate the usability/convenience of passwords). > >PBKDF2 is meant to make dictionary attacks on stored passwords harder, >as a >second line defense, once the server has been breached. Using it to >encrypt >data and then sending the data on the wire, makes the data vulnerable >to >this same dictionary attack (in this case the effort comes to the space >of >all possible passwords - say 1 million - times 1000). >Moreover, this also puts the password itself in danger. > >Thanks, > Yaron > >> >> ------------------------------ >> >> Message: 5 >> Date: Fri, 15 Mar 2013 14:10:32 +0000 >> From: Mike Jones >> To: "cfrg@irtf.org" >> Subject: [Cfrg] Draft describing encrypting JWK key representations >> with JWE >> Message-ID: >> >> ><4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp. >.%0b> >> microsoft.com> >> >> Content-Type: text/plain; charset="us-ascii" >> >> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >> >> This also adds password-based encryption to the algorithm registry. >> >> -- Mike >> >> -------------- next part -------------- An HTML attachment was >> scrubbed... >> URL: >> >> 24/attachment.htm> >> >> ------------------------------ >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg >> >> >> End of Cfrg Digest, Vol 95, Issue 3 >> *********************************** >> >_______________________________________________ >jose mailing list >jose@ietf.org >https://www.ietf.org/mailman/listinfo/jose > > > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Jim, prior to the new Webcrypto API there'sno way to generate a strong key in JavaScript. So you also need a way to use a key directly. But I'm by no means a JOSE expert, they may have different assumptions.

Thanks, Yaron

Jim Schaad <ietf@augus



tcellars.com> wrote:

Use PBKDF2 as a general key wrap mechanism seems to be a bad idea.  Take the key and use it as a key wrap key for randomly generated content encryption key.  Thus alg should be “AES128KW” rather than direct.

 

Jim

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Peck, Michael A
Sent: Friday, March 15, 2013 12:59 PM
To: Richard Barnes; Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

+1

 

NIST Special Publication 800-132 provides recommendations for the parameters that the group may find useful.

http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf

 

It may also be worth thinking about using PBKDF2 instead of the “dir” (Direct Encryption with a Shared Symmetric Key) mechanism described in draft-ietf-jose-json-web-algorithms-08 section 4.6.  The shared symmetric key would be used as the PBKDF2 “password”, and this would force a new key to be used for each encryption, rather than the current “dir” approach of using the same encryption key repeatedly.

 

Mike

 

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 12:53 PM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

Do I count as an expert?  :)

 

As I understand it, PBDKF2 is completely fine for key protection.  PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., having a high number of iterations. We might want to make some recommendations as to how you set those para meters. And the actual key wrapping is done with something like AES-KW, so that step is fine.

 

So I would be completely fine with adding this to JWE / JWA.  We should do this.

 

--Richard

 

 

On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

That’s up to the working group.  I’m actually hoping that experts on the lists will respond to Yaron’s comments b efore we make a decision on whether PBKDF2 as specified is an appropriate key wrapping algorithm or not.

 

Assuming that the content in Matt’s draft eventually becomes an RFC or part of one, the PBKDF2 definition would end up in the algorithms registry either way, even if it’s not part of the JWA spec itself.

 

                                                            Cheers,

                                                            -- Mike

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Friday, March 15, 2013 9:43 AM
To: Mike Jones
Cc: Yaron Sheffer; cfrg@irtf.org; jose@ietf.org
Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE

 

So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key wrapping algorithm?

 

--Richard

 

 

 

On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

[Adding JOSE mailing list to the thread]

For clarification, PBKDF2 is not the only algorithm that could be used to wrap keys in this scheme.  This draft *adds* PBKDF2 to the set of algorithms already specified for use with encryption in the JSON Web Algorithms (JWA) specification (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08).  In particular, other algorithms such as AES Key Wrap and AES GCM are also present there.

I'll let others who are experts in PBKDF2 and password-based encryption respond to Yaron's specific comment.

                                -- Mike

-----Original Message- ----
From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com]
Sent: Friday, March 15, 2013 8:16 AM
To: cfrg@irtf.org; Mike Jones
Subject: Re: Draft describing encrypting JWK key representations, with JWE

Hi Mike,

I'm probably missing something, but I'm worried about the security of this scheme (though I do appreciate the usability/convenience of passwords).

PBKDF2 is meant to make dictionary attacks on stored passwords harder, as a second line defense, once the server has been breached. Using it to encrypt data and then sending the data on the wire, makes the data vulnerable to this same dictionary attack (in this case the effort comes to the space of all possible passwords - say 1 million - times 1000).
Moreover, this also puts the password itself in danger.

Thanks,
        Yaron

>
> ------------------------------
>
> Message: 5
> Date: Fri, 15 Mar 2013 14:10:32 +0000
> From: Mike Jones <Michael.Jones@microsoft.com>
> To: "cfrg@irtf.org" <cfrg@irtf.org>
> Subject: [Cfrg] Draft describing encrypting JWK key representations
>       with JWE
> Message-ID:
>
> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmond.corp.
> microsoft.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01
>
> This also adds password-based encryption to the algorithm registry.
>
>                                                              -- Mike
>
> -------------- next part -------------- An HTML attachment was
> scrubbed...
> URL:
> <http://www.irtf.org/mail-archive/web/cfrg/attachments/20130315/02e36b
> 24/attachment.htm>
>
> ------------------------------
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>
>
> End of Cfrg Digest, Vol 95, Issue 3
> ***********************************
>
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

 


--
Sent from my Android phone with K-9 Mail. Please excuse my brevity. ------YXTMSIONN0BDIJ4N2082HKWH1H2BKB-- From ve7jtb@ve7jtb.com Fri Mar 15 17:56:06 2013 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 E289811E80F7 for ; Fri, 15 Mar 2013 17:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, 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 npkhJ6hw4UNv for ; Fri, 15 Mar 2013 17:56:06 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED8B21F8801 for ; Fri, 15 Mar 2013 17:56:05 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id q19so2310610qeb.34 for ; Fri, 15 Mar 2013 17:56:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=OwlfmD3ytkpatd1L8noeFwCNmcNUxKhZSHHNw9nzcQA=; b=MfjpyjA0d70ReLyDqRFTXNmVhYaxYl8Pwzwzpvkfq7O+qDUEXG2as4gWS5Afqg2HHI brW8DYuDx7e1ze2Ydvl+PhN96RLI8yBWFwk0yQNg2nQGxGTav5pUH4rX0crViQGIoikx /sAXoH9VgvRs1BuhwPrRQWhvLXyjYWLhy5nK9IujgRHwNCtzxMJ5w1odjiRWs6XlLRav R7KojwOFQTXmBE2fOEmcuDTbEx/UI8xSq13Mb8+fibSMixnb/LLf/tQjUhgbF7QRn/CQ 2gfJMQq2UFg3oaefhuOrbONHkqBqI1tBr8Rs8fXl8alt+LR08w372tpWA6AG4B2Q3KHu 3+Pg== X-Received: by 10.224.97.132 with SMTP id l4mr8811044qan.65.1363395365389; Fri, 15 Mar 2013 17:56:05 -0700 (PDT) Received: from [192.168.10.139] (ip-64-134-184-208.public.wayport.net. [64.134.184.208]) by mx.google.com with ESMTPS id hn9sm7709955qab.8.2013.03.15.17.56.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Mar 2013 17:56:03 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_1A581CD7-9430-47C3-9E5D-422929C4AEF4"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Fri, 15 Mar 2013 20:56:01 -0400 Message-Id: References: <255B9BB34FB7D647A506DC292726F6E1150B9AE08C@WSMSG3153V.srv.dir.telstra.com> To: Matt Miller (mamille2) X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQkhPofms/0wS8Ggahl+y/RM/UtvJD6WCq1YPJBNOCdl5EDrpGQyAsoW9FDbwlomwuWZocqo Cc: Richard Barnes , "Manger, James H" , "" Subject: Re: [jose] Rolling PKIX into JWK 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, 16 Mar 2013 00:56:07 -0000 --Apple-Mail=_1A581CD7-9430-47C3-9E5D-422929C4AEF4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 +1 yes attached to a key not a key set. On 2013-03-15, at 3:49 PM, Matt Miller (mamille2) = wrote: >=20 > On Mar 15, 2013, at 2:11 PM, Richard Barnes > wrote: >=20 >> Another clarification: I'm fine with either "x5c" as a JWK, or = "PKIX" as a >> "kty" value. In the former case, I would prefer that the "x5c" be = attached >> to individual keys and not key sets. >>=20 >=20 > +1; only in a JWK object, not the set. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 >>=20 >> On Friday, March 15, 2013, Richard Barnes wrote: >>=20 >>> Just to clarify, what I'm suggesting is to have "x5c" as an = attribute for >>> JWK, with the same syntax as in JWS. As Brian suggested in his = slides. >>>=20 >>> IF we want to go down the path of having "chained" JWKs, the syntax = would >>> be something like the following: >>> "jwkc": [ jws(jwk1, jwk0), jws(jwk2, jwk1), ... ] >>> Where jws(kx, ky) indicates a JWS with ky as the body and kx as the >>> signing key. IF we build something like this, it would be used in = the same >>> manner as "x5c", as an attribute of a JWK. However, I think = designing such >>> a thing would be a significant deviation from our charter, so we = would need >>> to recharter or even form a new WG (PKIJ?) >>>=20 >>> --Richard >>>=20 >>>=20 >>>=20 >>> On Fri, Mar 15, 2013 at 12:49 PM, Richard Barnes = >>>> wrote: >>>=20 >>>> On Fri, Mar 15, 2013 at 2:43 AM, Manger, James H < >>>> James.H.Manger@team.telstra.com >>> 'James.H.Manger@team.telstra.com');>> wrote: >>>>=20 >>>>> I agree, a certificate as an optional field of any JWK sounds like = a >>>>> decent approach. >>>>>=20 >>>>=20 >>>> +1, although it's not mutually exclusive with having a "PKIX" key = type. >>>>=20 >>>>=20 >>>>> Putting a whole cert chain in one JWK is not ideal. >>>>> Each cert is about 1 key so really should be in its own JWK. >>>>> Otherwise you will duplicate the chain of intermediate CA certs in = each >>>>> JWK in a set. >>>>>=20 >>>>> It might be useful to define a issuer key-id field ("isskid"). A = JWK >>>>> could include a cert for its own key and (with "isskid") a link to = the next >>>>> cert along the chain. That makes it quick-n-easy to build a chain = from the >>>>> JWKs in a set. >>>>>=20 >>>>> It would also help if JWKs in a set where held in a >>>>> object/dictionary/associative-array with the kid as the name. That = would be >>>>> better than using an array of JWKs with no defined meaning for the = order. >>>>>=20 >>>>=20 >>>> This proposal seems much, much worse than having a cert chain in = one JWK. >>>> If you're going to have all the public keys as JWKs, you might as = well >>>> just re-invent X.509 in JWK, in which case you would probably use = JWS over >>>> JWK, which solves the "isskid" problem using the "kid" in the JWS. = The >>>> benefit of having the cert chain is that you don't have to = re-invent X.509, >>>> you just pass the cert chain to your existing X.509 library. >>>>=20 >>>> In other words, let's have the trust chain be fully X.509 or fully = JOSE, >>>> even if it starts from a JWK. >>>>=20 >>>> --Richard >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>>=20 >>>>> -- >>>>> James Manger >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: jose-bounces@ietf.org >>>> 'jose-bounces@ietf.org');> = [mailto:jose-bounces@ietf.org] >>>>> On Behalf Of >>>>>> Matt Miller (mamille2) >>>>>> Sent: Friday, 15 March 2013 12:48 AM >>>>>> To: > >>>>>> Subject: [jose] Rolling PKIX into JWK >>>>>>=20 >>>>>> [hoping this topic is the least controversial...] >>>>>>=20 >>>>>> In some IRL discussions on moving forward on PKIX in JWK, I've = been >>>>>> convinced the concerns are mostly the same regardless of how the = PKIX >>>>>> is packaged. Given that, I would suggest we make "x5c" an = optional >>>>>> field of JWK, rather than defining a new JWK type. I can propose >>>>>> various text additions after this meeting. >>>>>>=20 >>>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> - m&m >>>>>>=20 >>>>>> Matt Miller < mamille2@cisco.com >>>> 'mamille2@cisco.com');> > >>>>>> Cisco Systems, Inc. >>>>>=20 >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>>=20 >>>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_1A581CD7-9430-47C3-9E5D-422929C4AEF4 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE2MDA1NjAyWjAjBgkqhkiG9w0BCQQxFgQU85gOQ0mX Fg74TFcoYDjp2oDeT18wgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAKYnvDc7++dH4dseRRdStaih/IGIyYg16YJl0feZx 4ewhCpdNEOpL0rRcOVcFp3R+k0/YBvxQIVqipK/Cb8Z+DqKw7DiMG1TRIakSIPP8syd5xwk6a946 NUDxJ23o5r065rS4RqhZYwNMK0FrOKJOYv4rlGWBBlQH/DvPZkgXTcWtjjaLvp+BQhfYTMCJmyYq prkxOm0qrLA9zTSZcydfPs3EPGulB+mGKY8YIV29NIsPimEKwtpMh4ziJ8ouUOGNLCus94GMnAaV hAOtetAOdSWCIR4XOA+sVV20g25Dx1P8OGDZEglykrAHIwo/tnDiaQiM+F+XdUj5Opux7w+2AQAA AAAAAA== --Apple-Mail=_1A581CD7-9430-47C3-9E5D-422929C4AEF4-- From yaronf.ietf@gmail.com Sat Mar 16 05:25:12 2013 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 EB07721F8B4A for ; Sat, 16 Mar 2013 05:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.229 X-Spam-Level: X-Spam-Status: No, score=-100.229 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_14=0.6, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 W9Xj7IqRbnta for ; Sat, 16 Mar 2013 05:25:12 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8726321F8B35 for ; Sat, 16 Mar 2013 05:25:11 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id o10so1867245eaj.6 for ; Sat, 16 Mar 2013 05:25:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=5qngBkUYommavs4HYAFjDOre0oN3Gs4uuoEmygRYB5w=; b=hMDdoy7PSdhD7nVp7cze3VrKQbezfnHT7qKDEN2tK/EhYBt/+GoeO9dDvPUDMJw+Cv sJNeyGaO4hGfYfEBgLh+lyZ5EqKHXsEaTFtJLrGkY3dL3O05tB1+DD8DQme0InFW3PJ8 Pu7rM1wXrbsO+jGvCT5G07bU70drwNecaN2c9U6razWQTLSOn+scwfdmEnQ/Cd8/sIRg KcYtq4D+njmbNJUu/po+ZyttPISsj0SU+v89TWZ6atlVsAFMg53wV+thPqrnYGvx8fJF tggs0OvYcwCXFMVSA0fID+S4SrecPJ1U1oqPxJyf7jUNHAea+LbJpvta6oIDBKZyOjOH XtEA== X-Received: by 10.14.183.198 with SMTP id q46mr28693752eem.1.1363436704555; Sat, 16 Mar 2013 05:25:04 -0700 (PDT) Received: from [10.0.0.2] (bzq-109-66-120-100.red.bezeqint.net. [109.66.120.100]) by mx.google.com with ESMTPS id a1sm15742380eep.2.2013.03.16.05.24.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 05:25:03 -0700 (PDT) Message-ID: <51446495.8020708@gmail.com> Date: Sat, 16 Mar 2013 14:24:53 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "Matt Miller (mamille2)" References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <51435D7A.7050800@gmail.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5FBC@IMCMBX04.MITRE.ORG> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 16 Mar 2013 19:11:10 -0700 Cc: Richard Barnes , "cfrg@irtf.org" , Mike Jones , "Peck, Michael A" , "jose@ietf.org" Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 16 Mar 2013 12:25:13 -0000 Well I guess that's for me. So here goes: Despite the protections afforded by PBKDF2 and PBES2, password-protected data is still subject to off-line dictionary attacks, when using human-generated passwords. The same applies to machine generated passwords, if they need to be memorable to humans. Such dictionary attacks reveal both the data and the password to an eavesdropper. Therefore: - Password-based encryption should not be used for high value data. - Password-based encryption should not be used with high-value passwords, e.g. with a user's long-term password. Thanks, Yaron On 03/15/2013 09:47 PM, Matt Miller (mamille2) wrote: > My intent for introducing PBES2 key wrapping algorithms was for those times when the key exchange is at the human-level. I think there are probably better mechanisms when the input in appropriately random to start with, although I personally don't see a tremendous amount of harm using a PBES2-based algorithm with stronger "passwords". > > I tried to address some concerns around the use of passwords, but did rely on what RFC2898 already says about specific values for iteration counts and salts. I'd be happy to incorporate more direction there, if someone could help provide some text. I'd also be happy to help incorporate this into whatever other document we'd rather have it in. > > > - m&m > > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. > > On Mar 15, 2013, at 1:55 PM, "Peck, Michael A" > wrote: > >> I'll try to clarify (and hopefully not dig a deeper hole). >> >> JWE currently provides a "dir" mechanism allowing a symmetric key previously agreed to out of band to be used for content encryption. >> All of the other JWE mechanisms use a fresh symmetric key for each encryption. >> >> My suggestion was that instead of directly using the pre-shared symmetric key to encrypt content, if JWE makes the PBKDF2 mechanism available the symmetric key could be used as the PBKDF2 "password", resulting in a fresh key generated for each content encryption. In this particular case the password input to PBKDF2 would hopefully be very random - I would think there would be no more risk than using the pre-shared key directly, rather less risk. >> >> General password considerations are a different matter. Passwords have lots of issues but if we're stuck with them we should at least advise how to do the best we can. >> >> Mike >> >>> -----Original Message----- >>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com] >>> Sent: Friday, March 15, 2013 1:42 PM >>> To: Peck, Michael A >>> Cc: Richard Barnes; Mike Jones; cfrg@irtf.org; jose@ietf.org >>> Subject: Re: [jose] Draft describing encrypting JWK key representations, with >>> JWE >>> >>> Hi Mike and Mike, >>> >>> The NIST SP is about using PBKDF2 for storage encryption (which I'm not >>> thrilled with, either). Not for sending the encrypted blob over the >>> wire, for an attacker to intercept and decrypt off-line. And if we read >>> the NIST document, let's adopt the whole thing - quoting from sec. A.1: >>> "Passwords shorter than 10 characters are usually considered to be >>> weak." Are we going to make this recommendation too? Well I guess not. >>> >>> *Please* do not mix passwords with cryptographic keys. If the WG goes >>> through the risk vs. benefit analysis and decides to have a >>> password-based mechanism, fine. But please leave the shared-key >>> mechanism as-is. It's important that readers of JOSE specs are very >>> clear about the difference between randomly generated keys and >>> user-memorable (or even -generated) passwords. >>> >>> Let's be clear: even a single use of a user-generated password for >>> on-the-wire encryption is risky. So-called key rotation of actual >>> cryptographic keys is a whole different matter. >>> >>> Thanks, >>> Yaron >>> >>> >>> On 03/15/2013 06:58 PM, Peck, Michael A wrote: >>>> +1 >>>> >>>> NIST Special Publication 800-132 provides recommendations for the >>>> parameters that the group may find useful. >>>> >>>> http://csrc.nist.gov/publications/nistpubs/800-132/nist-sp800-132.pdf >>>> >>>> It may also be worth thinking about using PBKDF2 instead of the "dir" >>>> (Direct Encryption with a Shared Symmetric Key) mechanism described in >>>> draft-ietf-jose-json-web-algorithms-08 section 4.6. The shared >>>> symmetric key would be used as the PBKDF2 "password", and this would >>>> force a new key to be used for each encryption, rather than the current >>>> "dir" approach of using the same encryption key repeatedly. >>>> >>>> Mike >>>> >>>> *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >>>> Of *Richard Barnes >>>> *Sent:* Friday, March 15, 2013 12:53 PM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer; cfrg@irtf.org; jose@ietf.org >>>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>>> representations, with JWE >>>> >>>> Do I count as an expert? :) >>>> >>>> As I understand it, PBDKF2 is completely fine for key protection. >>>> PBKDF2 has mechanisms to mitigate the dictionary attack risks, e.g., >>>> having a high number of iterations. We might want to make some >>>> recommendations as to how you set those parameters. And the actual key >>>> wrapping is done with something like AES-KW, so that step is fine. >>>> >>>> So I would be completely fine with adding this to JWE / JWA. We should >>>> do this. >>>> >>>> --Richard >>>> >>>> On Fri, Mar 15, 2013 at 12:48 PM, Mike Jones >>>> > >>> wrote: >>>> >>>> That's up to the working group. I'm actually hoping that experts on the >>>> lists will respond to Yaron's comments before we make a decision on >>>> whether PBKDF2 as specified is an appropriate key wrapping algorithm or >>> not. >>>> >>>> Assuming that the content in Matt's draft eventually becomes an RFC or >>>> part of one, the PBKDF2 definition would end up in the algorithms >>>> registry either way, even if it's not part of the JWA spec itself. >>>> >>>> Cheers, >>>> >>>> -- Mike >>>> >>>> *From:*jose-bounces@ietf.org >>>> [mailto:jose-bounces@ietf.org ] *On >>> Behalf >>>> Of *Richard Barnes >>>> *Sent:* Friday, March 15, 2013 9:43 AM >>>> *To:* Mike Jones >>>> *Cc:* Yaron Sheffer; cfrg@irtf.org ; jose@ietf.org >>>> >>>> *Subject:* Re: [jose] Draft describing encrypting JWK key >>>> representations, with JWE >>>> >>>> So, Mike, would you be OK with adding PBE to JWE / JWA, as a new key >>>> wrapping algorithm? >>>> >>>> --Richard >>>> >>>> On Fri, Mar 15, 2013 at 12:14 PM, Mike Jones >>>> > >>> wrote: >>>> >>>> [Adding JOSE mailing list to the thread] >>>> >>>> For clarification, PBKDF2 is not the only algorithm that could be used >>>> to wrap keys in this scheme. This draft *adds* PBKDF2 to the set of >>>> algorithms already specified for use with encryption in the JSON Web >>>> Algorithms (JWA) specification >>>> (http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08). In >>>> particular, other algorithms such as AES Key Wrap and AES GCM are also >>>> present there. >>>> >>>> I'll let others who are experts in PBKDF2 and password-based encryption >>>> respond to Yaron's specific comment. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: Yaron Sheffer [mailto:yaronf.ietf@gmail.com >>>> ] >>>> Sent: Friday, March 15, 2013 8:16 AM >>>> To: cfrg@irtf.org ; Mike Jones >>>> Subject: Re: Draft describing encrypting JWK key representations, with JWE >>>> >>>> Hi Mike, >>>> >>>> I'm probably missing something, but I'm worried about the security of >>>> this scheme (though I do appreciate the usability/convenience of >>> passwords). >>>> >>>> PBKDF2 is meant to make dictionary attacks on stored passwords harder, >>>> as a second line defense, once the server has been breached. Using it to >>>> encrypt data and then sending the data on the wire, makes the data >>>> vulnerable to this same dictionary attack (in this case the effort comes >>>> to the space of all possible passwords - say 1 million - times 1000). >>>> Moreover, this also puts the password itself in danger. >>>> >>>> Thanks, >>>> Yaron >>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> Message: 5 >>>>> Date: Fri, 15 Mar 2013 14:10:32 +0000 >>>>> From: Mike Jones >>> > >>>>> To: "cfrg@irtf.org " >>> > >>>>> Subject: [Cfrg] Draft describing encrypting JWK key representations >>>>> with JWE >>>>> Message-ID: >>>>> >>>>> >>> <4E1F6AAD24975D4BA5B168042967394367522C60@TK5EX14MBXC284.redmon >>> d.corp. >>>> >>> >> edmond.corp.%0b>> >>>> microsoft.com > >>>>> >>>>> Content-Type: text/plain; charset="us-ascii" >>>>> >>>>> http://tools.ietf.org/html/draft-miller-jose-jwe-protected-jwk-01 >>>>> >>>>> This also adds password-based encryption to the algorithm registry. >>>>> >>>>> -- Mike >>>>> >>>>> -------------- next part -------------- An HTML attachment was >>>>> scrubbed... >>>>> URL: >>>>> >> archive/web/cfrg/attachments/20130315/02e36b >>>>> 24/attachment.htm> >>>>> >>>>> ------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Cfrg mailing list >>>>> Cfrg@irtf.org >>>>> http://www.irtf.org/mailman/listinfo/cfrg >>>>> >>>>> >>>>> End of Cfrg Digest, Vol 95, Issue 3 >>>>> *********************************** >>>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose > From ryan-ietf@sleevi.com Sat Mar 16 13:14:17 2013 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 6421B21F874A for ; Sat, 16 Mar 2013 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 S2FYXGsYmXVd for ; Sat, 16 Mar 2013 13:14:16 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id C20C621F8718 for ; Sat, 16 Mar 2013 13:14:16 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 6C601264058; Sat, 16 Mar 2013 13:14:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=aOGZdWlZA2SGq3u57DkrB2X0if4=; b=Ai50mV2oqJQwVM9U1 863O7J80RDusagN0NWbeSPVT3ynFxQeAdbi+vQBaDZe/Q7OVRw2d4fKLJKAiHBaX EXHJDdoQImL1dO8yfqlhpYzXnYqc3iNY+BgeP0VAD8ytiy/HwEtPSELkDAttrZv/ 9WYr5elh5hNp9RGR+nM1rq35lQ= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id 2186D264057; Sat, 16 Mar 2013 13:14:16 -0700 (PDT) Received: from 216.3.101.62 (proxying for 216.3.101.62) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Sat, 16 Mar 2013 13:14:16 -0700 Message-ID: In-Reply-To: <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> Date: Sat, 16 Mar 2013 13:14:16 -0700 From: "Ryan Sleevi" To: "Yaron Sheffer" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sat, 16 Mar 2013 19:11:10 -0700 Cc: "'Peck, Michael A'" , 'Richard Barnes' , Jim Schaad , cfrg@irtf.org, 'Mike Jones' , jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ryan-ietf@sleevi.com List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Mar 2013 20:14:17 -0000 On Fri, March 15, 2013 12:45 pm, Yaron Sheffer wrote: > no way to generate a strong key in JavaScript. So you also need a way = to > use a key directly. But I'm by no means a JOSE expert, they may have > different assumptions. > > Thanks, Yaron window.crypto.getRandomValues() ? Already implemented today by WebKit and Firefox, as part of the W3C Web Cryptography API - https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html From yaronf.ietf@gmail.com Sat Mar 16 13:56:56 2013 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 5F29921F87D0 for ; Sat, 16 Mar 2013 13:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.829 X-Spam-Level: X-Spam-Status: No, score=-100.829 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 G3UfzyghmsGD for ; Sat, 16 Mar 2013 13:56:56 -0700 (PDT) Received: from mail-ea0-x22a.google.com (mail-ea0-x22a.google.com [IPv6:2a00:1450:4013:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A11B421F8463 for ; Sat, 16 Mar 2013 13:56:55 -0700 (PDT) Received: by mail-ea0-f170.google.com with SMTP id a15so2064649eae.29 for ; Sat, 16 Mar 2013 13:56:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=CMtQu0tENXF9xpabmz19N/4fxqz/DT4VC4w3xD5W3eo=; b=oHGIGWZU2zk7RHkjqAfho8Z6QXQo/kXAq/vko2f1CnAWEazC8s832S0bI1Q94R3Qcm j534895QgMsocTm+4GqFdikR23ak9m0qvcJJkFKxM0fiYSCsEn4Zm77w5Y7t8XumbH+n Nm29YYyo7q0XG9VNocSqN2E5KtbQqFUdRVO8xeJflWEqerzQlAEZw+Kyn68WLFjf889u zpohcyy1jU/AFAxcUvWmkoVLi1ZmLL2BBvoZRbShJVz4LH7BLZN6K6lSHc0pvtPXhHxd CrgGJXl77bHLTScMbRWxTZR12RkwudPvdNqeyd8iiQLDcsqSbxWbXy1rp2P4weQw2OpK OVXw== X-Received: by 10.14.173.196 with SMTP id v44mr31898602eel.29.1363467414763; Sat, 16 Mar 2013 13:56:54 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-181-130-250.red.bezeqint.net. [79.181.130.250]) by mx.google.com with ESMTPS id 3sm17955019eej.6.2013.03.16.13.56.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 13:56:53 -0700 (PDT) Message-ID: <5144DC8B.9020403@gmail.com> Date: Sat, 16 Mar 2013 22:56:43 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: ryan-ietf@sleevi.com References: <51433B12.1020703@gmail.com> <4E1F6AAD24975D4BA5B168042967394367526568@TK5EX14MBXC284.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367526789@TK5EX14MBXC284.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFD5DFC@IMCMBX04.MITRE.ORG> <07c801ce21ab$f63d74b0$e2b85e10$@augustcellars.com> <6769e08f-8bae-41de-a723-409f7bfae4f2@email.android.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 16 Mar 2013 19:11:10 -0700 Cc: "'Peck, Michael A'" , 'Richard Barnes' , Jim Schaad , cfrg@irtf.org, 'Mike Jones' , jose@ietf.org Subject: Re: [jose] Draft describing encrypting JWK key representations, with JWE 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, 16 Mar 2013 20:56:56 -0000 Hi Ryan, Yes, the complete first sentence in my mail (which the listserv gobbled) was: "prior to the new Webcrypto API there's no way to generate a strong key in JavaScript." Do the JOSE specs assume this API is always available? Thanks, Yaron On 16.3.2013 22:14, Ryan Sleevi wrote: > On Fri, March 15, 2013 12:45 pm, Yaron Sheffer wrote: >> no way to generate a strong key in JavaScript. So you also need a way to >> use a key directly. But I'm by no means a JOSE expert, they may have >> different assumptions. >> >> Thanks, Yaron > window.crypto.getRandomValues() ? > > Already implemented today by WebKit and Firefox, as part of the W3C Web > Cryptography API - > https://dvcs.w3.org/hg/webcrypto-api/raw-file/tip/spec/Overview.html > From ve7jtb@ve7jtb.com Sun Mar 17 15:40:33 2013 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 B301721F8AB2 for ; Sun, 17 Mar 2013 15:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[AWL=1.530, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 UMEp99le7-rs for ; Sun, 17 Mar 2013 15:40:33 -0700 (PDT) Received: from mail-qe0-f46.google.com (mail-qe0-f46.google.com [209.85.128.46]) by ietfa.amsl.com (Postfix) with ESMTP id DFF7621F8A00 for ; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) Received: by mail-qe0-f46.google.com with SMTP id a11so2958150qen.19 for ; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=f6go32YwU6Q9PQ+LmP7MNc4K/CgNXhtns4lvRozu9U0=; b=IIZmg3A1fjQwrOFUY4L/+wIupgBUAP5cXhgcthM2QFjRN6vUoifcBjeer6WDitdEvq bWeIGTa4v7OF+nQyayA1LjjEQ2k1UkIvLXVu1s1/7kEZmvoTDtctao5OcVOQ/MnArIou sMi5buA/MYx6NTAvQDNzVaPqVwxFDYDLZjKZ2U/jQvBzNytRZ1JehEJ/vy5i2NpaH7HB KoRNtzHP5HIKbj1aNYIT5nMgYtzyPrBXU965cjMXdpguEooLH2O8BgNoqi38pWO9cQs5 YmcuBb1sS3IB8uYJILc9BaCUQYsNQ/ZnumyQMF6RqkIYy+0EcNmC46cn95Be0otHDsR1 ft3A== X-Received: by 10.229.106.162 with SMTP id x34mr3893112qco.90.1363560032210; Sun, 17 Mar 2013 15:40:32 -0700 (PDT) Received: from [192.168.1.37] (190-20-39-218.baf.movistar.cl. [190.20.39.218]) by mx.google.com with ESMTPS id u4sm22763678qao.13.2013.03.17.15.40.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Mar 2013 15:40:30 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: John Bradley In-Reply-To: Date: Sun, 17 Mar 2013 18:40:21 -0400 Message-Id: <0A3D2079-279F-4D6C-AEE9-2B4BBF97B609@ve7jtb.com> References: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> To: Russ Housley X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQnkzEqewfHtqXbZ17rNdt8U3Ax/iFnUbbGtmZ1P32gi1U3WbpEWyiD9hCy2btr7Ak622fHd Cc: Brian Weis , cfrg@ietf.org, jose@ietf.org Subject: Re: [jose] [Cfrg] Use of authenticated encryption for key wrapping 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, 17 Mar 2013 22:40:33 -0000 --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 That is true. However the main reason AES-GWC would be used is to allow transport of = keys (RSA, EC and Symmetric) that are intended for use outside the = crypto module. Where I agree, is that it is probably not such a good idea to start = using AESKW on the message body just because that body contains a JWK = with a private key. I think that is where this particular question started. Some people = thought that only AES-KW was appropriate for encrypting keys. My preference is to keep AES-KW for wrapping session keys,and not change = to the newer version that would allow us to encrypt arbitrary length = messages. That at least still provides some additional protection for session keys = in that the KW alg remains internal, so can not be used to expose = session keys accidentally if that is what you are getting at. Regards, John B. On 2013-03-15, at 2:42 PM, Russ Housley wrote: > There are some system design issues to be considered. The use of = different modes for encryption of user data and keying material makes it = easier to prevent the decryption of keying material outside of the = crypto module. >=20 > Russ >=20 >=20 > On Mar 15, 2013, at 11:42 AM, Brian Weis wrote: >=20 >> Jim Schaad gave a presentation on JOSE to CFRG today = (). The = question came up as to whether AES key wrap was necessarily the only = method that was safe for key wrapping in JOSE. The other algorithm under = consideration is AES-GCM.=20 >>=20 >> Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: >>=20 >> "Previously approved authenticated-encryption modes=97as well as = combinations of an approved encryption mode with an approved = authentication method=97are approved for the protection of cryptographic = keys, in addition to general data." >>=20 >> So if one considers that to be good enough advice, AES-GCM would = indeed be an acceptable method of key wrapping. The chairs asked me to = cross-post this for discussion. >>=20 >> Brian >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzE3MjI0MDIyWjAjBgkqhkiG9w0BCQQxFgQUwTFCo4UV mud2IP5vt9hIEUOFvgQwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAl0u7KxAeN2BS/zVyz4TwiHzxTYwL7mIHX+Lz59i1 6gND/uEQaFTdyk1LFuwcJl+TDgExpk8z99sjokc8sS6oyJ3n8ZxnVw19ltDtXElGtbNEInfA4Gr1 Cvv/tvW3BikUNLZ/LGzsP6lfIlkN7/0JQaeZ/649mBM8r4+ej08xBYog5v/x+qh9t8WJy2Fa+wtK 1oe6JaHA7Z0fEXWWxNdMBVg1NMirn1FyH5JHuCC7UXbs0lbHN4fO9NhOwlaFuhUCDffJvsKz6MLc v6tW65pLzrIUuc4sp9rSwei1FknYyf3dhYEPbtQUnAo3OlpHtwjhcxmZiHgMmMZi1woXn5IP3wAA AAAAAA== --Apple-Mail=_3B564EEC-78E5-4225-96DB-21DD142282BB-- From James.H.Manger@team.telstra.com Sun Mar 17 17:02:37 2013 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 CD50C21F8A67 for ; Sun, 17 Mar 2013 17:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 lMYcE4sCB60n for ; Sun, 17 Mar 2013 17:02:37 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2CA21F8A66 for ; Sun, 17 Mar 2013 17:02:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,861,1355058000"; d="scan'208,217";a="123635073" Received: from unknown (HELO ipcdvi.tcif.telstra.com.au) ([10.97.217.212]) by ipoavi.tcif.telstra.com.au with ESMTP; 18 Mar 2013 11:02:33 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7017"; a="118930027" Received: from wsmsg3701.srv.dir.telstra.com ([172.49.40.169]) by ipcdvi.tcif.telstra.com.au with ESMTP; 18 Mar 2013 11:02:33 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3701.srv.dir.telstra.com ([172.49.40.169]) with mapi; Mon, 18 Mar 2013 11:02:27 +1100 From: "Manger, James H" To: Jim Schaad Date: Mon, 18 Mar 2013 11:02:25 +1100 Thread-Topic: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK Thread-Index: AQIfUvokC2KN1bP9hZD3WzbTW1wpuwJJuz3QAMb1EvwBDVdg+AMdMmNBAgT8d5gCo7yYCJelipLggANwViA= Message-ID: <255B9BB34FB7D647A506DC292726F6E1150B9AE692@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> <07b701ce21a8$40b502f0$c21f08d0$@augustcellars.com> In-Reply-To: <07b701ce21a8$40b502f0$c21f08d0$@augustcellars.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150B9AE692WSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 18 Mar 2013 00:02:37 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150B9AE692WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gRm9yIGluc3RhbmNlLCBKV0UgaW5jbHVkZXMgdGhlIElWIGFzIHBhcnQgb2YgdGhlIGFkZGl0 aW9uYWwgYXV0aGVudGljYXRlZCBkYXRhIChBQUQpLiBObyBvdGhlciBBRUFEIHN5c3RlbSBpcyBk ZWZpbmVkIGxpa2UgdGhpcy4gRXZlcnl3aGVyZSBlbHNlIHRoZSBJVi9ub25jZSBhbmQgQUFEIGFy ZSBzZXBhcmF0ZS4gSSBob3BlIHRoYXQgZG9lc27igJl0IGFkdmVyc2VseSBhZmZlY3QgdGhlIGNy eXB0byBwcm9wZXJ0aWVzLCBidXQgaXQgZG9lcyByYWlzZSBxdWVzdGlvbnMgYWJvdXQgd2hldGhl ciBpdCBpcyBpbXBvcnRhbnQgZm9yIHNvbWUgY3J5cHRvIHJlYXNvbi4NCg0KW0pMU10gRm9yIHRo aXMgYWxnb3JpdGhtIGl0IGlzIGFic29sdXRlbHkgdml0YWwgdGhhdCB0aGUgSVYgYmUgcHJvdGVj dGVkLiAgU2luY2UgdGhlIGF1dGhlbnRpY2F0aW9uIGlzIGNvbXB1dGVkIG9uIHRoZSBwb3N0IGVu Y3J5cHRlZCB0ZXh0IG5vdCB0aGUgcHJlLWVuY3lycHRlZCB0ZXh0LCBhIGRlY3J5cHRpb24gY291 bGQgbmV2ZXIgYmUgYWJsZSB0byBjb3JyZWN0bHkgZGV0ZXJtaW5lIHRoYXQgdGhlIElWIHBhc3Nl ZCBpbiB3YXMgY29ycmVjdCBpZiBpdCBpcyBub3QgdmFsaWRhdGVkISEhISEhDQoNCg0KSmltLA0K DQpBMjU2Q0JDK0hTNTEyIG5lZWRzIHRvIGludGVncml0eS1wcm90ZWN0IHRoZSBJVi4gSSBhbSBu b3QgZGlzYWdyZWVpbmcgd2l0aCB0aGF0Lg0KDQpFdmVyeSBvdGhlciBBRUFEIGFsZ29yaXRobSBh Y2NlcHRzIGFuIElWIGFuZCBBQUQgYXMgc2VwYXJhdGUgaW5wdXRzIGFuZCAqaW50ZXJuYWxseSB0 byB0aGUgQUVBRCBhbGdvcml0aG0qIGVuc3VyZXMgdGhlIGFwcHJvcHJpYXRlIGludGVncml0eSBw cm90ZWN0aW9uIGlzIGFwcGxpZWQuIFRoaXMgaXMgd2hhdCBHQ00sIENDTSwgYW5kIFNJViBkby4g SXQgaXMgdGhlIHdoYXQgUkZDNTExNiAoQUVBRCBpbnRlcmZhY2UpIGFzc3VtZXMuIEl0IGlzIHdo YXQgYW55IGNyeXB0byBsaWJyYXJ5IHdpdGggYW4gZXhwbGljaXQgQUVBRCBpbnRlcmZhY2Ugd2ls bCBzdXBwb3J0IChzZXBhcmF0ZSBjYWxscyBvciBzZXBhcmF0ZSBwYXJhbWV0ZXJzIGZvciB0aGUg SVYgYW5kIEFBRCkuDQoNCkpXRSBkZWZpbmVzIHRoZSBBQUQgdG8gYmUgdGhlIEhlYWRlcitXcmFw cGVkS2V5K0lWLiBUaGF0IGlzLCB0aGUgSVYgaXMgaW5jbHVkZWQgaW4gdGhlIEFBRC4NCg0KQ29u c2VxdWVudGx5IGV2ZXJ5IG90aGVyIEFFQUQgYWxnb3JpdGhtIChzdWNoIGFzIEExMjhHQ00pIHdp bGwgcHJvY2VzcyB0aGUgSldFIElWIHR3aWNlLiBJbiBBMTI4R0NNLCBmb3IgZXhhbXBsZSwgdGhl IElWIHdpbGwgYmUgcGFzc2VkIGZyb20gSk9TRSBjb2RlIHRvIGFuIHVuZGVybHlpbmcgY3J5cHRv IEFQSSBvbmNlIGFzIGEgMTItYnl0ZSAoOTYtYml0KSBiaW5hcnkgdmFsdWUsIGFuZCBhbHNvIGFz IDE2IGJhc2U2NHVybCBjaGFyYWN0ZXJzIGF0IHRoZSBlbmQgb2YgdGhlIEFBRC4gRm9yIGFsbCB0 aGVzZSBBRUFEIGFsZ29yaXRobXMgdGhpcyBkdXBsaWNhdGlvbiBpcyBtZXJlbHkgc2xpZ2h0bHkg d2FzdGVmdWwsIGJ1dCBJIGd1ZXNzIChob3BlKSBpdCBoYXMgbm8gaW1wYWN0IG9uIHNlY3VyaXR5 Lg0KDQpUaGUgSk9TRS1zcGVjaWZpYyBBMjU2Q0JDK0hTNTEyIGFsZ29yaXRobSwgaW4gY29udHJh c3QsIGlzIGRpZmZlcmVudC4gVGhpcyBhbGdvcml0aG0gd291bGQgYmUgaW5zZWN1cmUgaWYgdGhl IEFBRCBkaWQgbm90IGluY2x1ZGUgdGhlIElWLiBXaGF0IHdvdWxkIGhhcHBlbiBpZiBBMjU2Q0JD K0hTNTEyIHdhcyBpbXBsZW1lbnRlZCBpbiBhIGNyeXB0byBsaWJyYXJ5IGFjY2Vzc2VkIHZpYSBh IGdlbmVyaWMgQUVBRCBpbnRlcmZhY2U/IFBlcmhhcHMgaXQgd291bGQgaGF2ZSB0byBiYXNlNjR1 cmwtZW5jb2RlIHRoZSBJViBpdCB3YXMgcGFzc2VkIGFuZCBjaGVjayB0aGF0IGl0IG1hdGNoZXMg dGhlIGVuZCBvZiB0aGUgQUFEIGl0IHdhcyBwYXNzZWQgKG1ha2luZyBpdCB1bnN1aXRhYmxlIGFz IGEgZ2VuZXJpYyBBRUFEIGFsZyBpbiBhbnkgb3RoZXIgY29udGV4dCk/DQoNCi0tDQpKYW1lcyBN YW5nZXINCg== --_000_255B9BB34FB7D647A506DC292726F6E1150B9AE692WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PGJhc2UgaHJlZj0ieC1tc2c6 Ly80NjQyLyI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJ cGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRp di5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g VGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uYXBwbGUt Y29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9 DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFp bFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjoj MUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3 OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tQVUg bGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7Jmd0OyBGb3IgaW5zdGFuY2UsIEpX RSBpbmNsdWRlcyB0aGUgSVYgYXMgcGFydCBvZiB0aGUgYWRkaXRpb25hbCBhdXRoZW50aWNhdGVk IGRhdGEgKEFBRCkuIE5vIG90aGVyIEFFQUQgc3lzdGVtIGlzIGRlZmluZWQgbGlrZSB0aGlzLiBF dmVyeXdoZXJlIGVsc2UgdGhlIElWL25vbmNlIGFuZCBBQUQgYXJlIHNlcGFyYXRlLiBJIGhvcGUg dGhhdCBkb2VzbuKAmXQgYWR2ZXJzZWx5IGFmZmVjdCB0aGUgY3J5cHRvIHByb3BlcnRpZXMsIGJ1 dCBpdCBkb2VzIHJhaXNlIHF1ZXN0aW9ucyBhYm91dCB3aGV0aGVyIGl0IGlzIGltcG9ydGFudCBm b3Igc29tZSBjcnlwdG8gcmVhc29uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6cmVkJz5bSkxTXSBGb3IgdGhpcyBhbGdv cml0aG0gaXQgaXMgYWJzb2x1dGVseSB2aXRhbCB0aGF0IHRoZSBJViBiZSBwcm90ZWN0ZWQuJm5i c3A7IFNpbmNlIHRoZSBhdXRoZW50aWNhdGlvbiBpcyBjb21wdXRlZCBvbiB0aGUgcG9zdCBlbmNy eXB0ZWQgdGV4dCBub3QgdGhlIHByZS1lbmN5cnB0ZWQgdGV4dCwgYSBkZWNyeXB0aW9uIGNvdWxk IG5ldmVyIGJlIGFibGUgdG8gY29ycmVjdGx5IGRldGVybWluZSB0aGF0IHRoZSBJViBwYXNzZWQg aW4gd2FzIGNvcnJlY3QgaWYgaXQgaXMgbm90IHZhbGlkYXRlZCEhISEhITxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkppbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkEyNTZDQkMrSFM1MTIg bmVlZHMgdG8gaW50ZWdyaXR5LXByb3RlY3QgdGhlIElWLiBJIGFtIG5vdCBkaXNhZ3JlZWluZyB3 aXRoIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi O2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5FdmVyeSBvdGhlciBBRUFEIGFsZ29yaXRobSBh Y2NlcHRzIGFuIElWIGFuZCBBQUQgYXMgc2VwYXJhdGUgaW5wdXRzIGFuZCAqPGI+aW50ZXJuYWxs eSB0byB0aGUgQUVBRCBhbGdvcml0aG08L2I+KiBlbnN1cmVzIHRoZSBhcHByb3ByaWF0ZSBpbnRl Z3JpdHkgcHJvdGVjdGlvbiBpcyBhcHBsaWVkLiBUaGlzIGlzIHdoYXQgR0NNLCBDQ00sIGFuZCBT SVYgZG8uIEl0IGlzIHRoZSB3aGF0IFJGQzUxMTYgKEFFQUQgaW50ZXJmYWNlKSBhc3N1bWVzLiBJ dCBpcyB3aGF0IGFueSBjcnlwdG8gbGlicmFyeSB3aXRoIGFuIGV4cGxpY2l0IEFFQUQgaW50ZXJm YWNlIHdpbGwgc3VwcG9ydCAoc2VwYXJhdGUgY2FsbHMgb3Igc2VwYXJhdGUgcGFyYW1ldGVycyBm b3IgdGhlIElWIGFuZCBBQUQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SldFIGRlZmluZXMgdGhlIEFB RCB0byBiZSB0aGUgSGVhZGVyK1dyYXBwZWRLZXkrSVYuIFRoYXQgaXMsIHRoZSBJViBpcyBpbmNs dWRlZCBpbiB0aGUgQUFELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Q29uc2VxdWVudGx5IGV2ZXJ5IG90 aGVyIEFFQUQgYWxnb3JpdGhtIChzdWNoIGFzIEExMjhHQ00pIHdpbGwgcHJvY2VzcyB0aGUgSldF IElWIHR3aWNlLiBJbiBBMTI4R0NNLCBmb3IgZXhhbXBsZSwgdGhlIElWIHdpbGwgYmUgcGFzc2Vk IGZyb20gSk9TRSBjb2RlIHRvIGFuIHVuZGVybHlpbmcgY3J5cHRvIEFQSSBvbmNlIGFzIGEgMTIt Ynl0ZSAoOTYtYml0KSBiaW5hcnkgdmFsdWUsIGFuZCBhbHNvIGFzIDE2IGJhc2U2NHVybCBjaGFy YWN0ZXJzIGF0IHRoZSBlbmQgb2YgdGhlIEFBRC4gRm9yIGFsbCB0aGVzZSBBRUFEIGFsZ29yaXRo bXMgdGhpcyBkdXBsaWNhdGlvbiBpcyBtZXJlbHkgc2xpZ2h0bHkgd2FzdGVmdWwsIGJ1dCBJIGd1 ZXNzIChob3BlKSBpdCBoYXMgbm8gaW1wYWN0IG9uIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3 RCc+VGhlIEpPU0Utc3BlY2lmaWMgQTI1NkNCQytIUzUxMiBhbGdvcml0aG0sIGluIGNvbnRyYXN0 LCBpcyBkaWZmZXJlbnQuIFRoaXMgYWxnb3JpdGhtIHdvdWxkIGJlIGluc2VjdXJlIGlmIHRoZSBB QUQgZGlkIG5vdCBpbmNsdWRlIHRoZSBJVi4gV2hhdCB3b3VsZCBoYXBwZW4gaWYgQTI1NkNCQytI UzUxMiB3YXMgaW1wbGVtZW50ZWQgaW4gYSBjcnlwdG8gbGlicmFyeSBhY2Nlc3NlZCB2aWEgYSBn ZW5lcmljIEFFQUQgaW50ZXJmYWNlPyBQZXJoYXBzIGl0IHdvdWxkIGhhdmUgdG8gYmFzZTY0dXJs LWVuY29kZSB0aGUgSVYgaXQgd2FzIHBhc3NlZCBhbmQgY2hlY2sgdGhhdCBpdCBtYXRjaGVzIHRo ZSBlbmQgb2YgdGhlIEFBRCBpdCB3YXMgcGFzc2VkIChtYWtpbmcgaXQgdW5zdWl0YWJsZSBhcyBh IGdlbmVyaWMgQUVBRCBhbGcgaW4gYW55IG90aGVyIGNvbnRleHQpPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj MUY0OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150B9AE692WSMSG3153Vsrv_-- From vladimir@nimbusds.com Mon Mar 18 02:40:05 2013 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 B840A21F862B for ; Mon, 18 Mar 2013 02:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_ENC_UTF8=0.152] 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 to+IFg1woJQk for ; Mon, 18 Mar 2013 02:40:04 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 20D7E21F8525 for ; Mon, 18 Mar 2013 02:40:03 -0700 (PDT) Received: (qmail 12821 invoked from network); 18 Mar 2013 09:40:02 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 18 Mar 2013 09:40:02 -0000 Received: (qmail 11574 invoked by uid 99); 18 Mar 2013 09:40:02 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 95.42.165.196 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: jose@ietf.org Date: Mon, 18 Mar 2013 02:40:01 -0700 Mime-Version: 1.0 Subject: [jose] =?utf-8?q?JPSK=3A_JWKs_with_private_RSA/EC_params_only=3F?= 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, 18 Mar 2013 09:40:05 -0000 Hi guys,=0A=0AJustin and I began an implementation of=0Adraft-jones-jose-js= on-private-and-symmetric-key-00 for the Nimbus=0Alibrary. We're now able to= represent the regular public RSA/EC JWKs as=0Awell as JWKs that contain bo= th public+private RSA/EC params. Does the=0Adraft also envision JWK objects= which include only private key=0Aparameters? I.e. a JWK object for the pub= lic params and then another for=0Athe private params? My reading of the spe= c couldn't answer this=0Aquestion. Please advise.=0A=0AThanks,=0A=0AVladimi= r=0A--=0AVladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com From mcgrew@cisco.com Mon Mar 18 06:24:16 2013 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 02F3121F8DD0; Mon, 18 Mar 2013 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1uFoCyJJGNJA; Mon, 18 Mar 2013 06:24:14 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id C44D621F8CE8; Mon, 18 Mar 2013 06:24:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1873; q=dns/txt; s=iport; t=1363613055; x=1364822655; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=KGe8stE/M5PRG8Wkdq/B09mY6soyai8GFNw5PByWE1o=; b=E6ECOW4EBl0NfJv9YN01yeAdloRAw18GN2pSX8ZfuTVdMRBwxY0mNmS0 kbJ4gYnVnjncxbCRGIUdp6Q7i0bvEp8mspxeL1zUpoG6o2KzHfTp88yA9 AJPx5kGfbNAQmhGDkpLWAS1WNV8S1zgMPh85Ty0U3+Z+o/ryfzjV/9HPV g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC4VR1GtJXG+/2dsb2JhbABDxSCBVBZ0giYBAgIBAQFrHQEIIksLJQIEARIIAYgLDMFfjEKCIjiCX2EDp2CDCoFsJBg X-IronPort-AV: E=Sophos;i="4.84,865,1355097600"; d="scan'208";a="188405890" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-1.cisco.com with ESMTP; 18 Mar 2013 13:24:14 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2IDOEBX011993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Mar 2013 13:24:14 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 18 Mar 2013 08:24:14 -0500 From: "David McGrew (mcgrew)" To: "Brian Weis (bew)" , "jose@ietf.org" , "cfrg@ietf.org" Thread-Topic: [Cfrg] Use of authenticated encryption for key wrapping Thread-Index: AQHOIZaIOO+Qa/7kdEmBaYbXVhCe2pirhVeA Date: Mon, 18 Mar 2013 13:24:13 +0000 Message-ID: <747787E65E3FBD4E93F0EB2F14DB556B183EB276@xmb-rcd-x04.cisco.com> In-Reply-To: <31556AB6-899F-4D81-9FBC-40708864EA55@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4127D9F8DE8BF543BAF395AA9E9B13BF@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 18 Mar 2013 06:26:55 -0700 Subject: Re: [jose] [Cfrg] Use of authenticated encryption for key wrapping 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, 18 Mar 2013 13:24:16 -0000 Hi Brian, On 3/15/13 11:42 AM, "Brian Weis (bew)" wrote: >Jim Schaad gave a presentation on JOSE to CFRG today >(). The >question came up as to whether AES key wrap was necessarily the only >method that was safe for key wrapping in JOSE. The other algorithm under >consideration is AES-GCM. > >Section 3.1 of NIST 800-38F (Methods for Key Wrapping) says: > >"Previously approved authenticated-encryption modes=8Bas well as >combinations of an approved encryption mode with an approved >authentication method=8Bare approved for the protection of cryptographic >keys, in addition to general data." > >So if one considers that to be good enough advice, AES-GCM would indeed >be an acceptable method of key wrapping. The chairs asked me to >cross-post this for discussion. Thanks for sending out the pointer. I think the biggest negative with using AES-GCM for key wrapping is that GCM is not designed to be misuse-resistant. In contrast, the AES-KW algorithm does provide some misuse resistance: the AES-KW encryption algorithm does not require that the caller provide a distinct nonce for each invocation. =20 The biggest negative with requiring the use of AES-KW for key wrapping is that, it requires the implementation of the AES decryption operation (unlike GCM), it is yet another algorithm to implement/test/validate, and it takes up space that is precious in a constrained environment. NIST is right to allow other authenticated encryption methods than AES-KW to be used for key wrapping. But if AES-KW is available for JOSE, then it makes sense to use it for key wrapping. My $0.02. David > >Brian=20 >_______________________________________________ >Cfrg mailing list >Cfrg@irtf.org >http://www.irtf.org/mailman/listinfo/cfrg From rlb@ipv.sx Mon Mar 18 08:42:12 2013 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 30E6521F8A18 for ; Mon, 18 Mar 2013 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.575 X-Spam-Level: X-Spam-Status: No, score=-1.575 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 c6m1OChnRybh for ; Mon, 18 Mar 2013 08:42:11 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 47B9B21F8A0C for ; Mon, 18 Mar 2013 08:42:11 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb18so5473983obb.17 for ; Mon, 18 Mar 2013 08:42:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qpD0AyaQQZl/XdWRBIILYM+wuvQ3iMbvJKDYEspZ80Q=; b=gr+8zWGtdfySwWiQmW1MWQY7fC2quS7SpBIw+07cVGaUk12iDYEbxSkQHTUVbJ+ZeM kN8RoMVr+lVCX9qfUYlOts4T2HTOgx4MrITunHeKdC0RhW7mDs4z3nJUjBlCcvyVWjrF LWg9NrteRkU3ftC5OlS0/FW3FijD/ognZHIzxTmFvobyA4XJYDVwzYke23Pz0zaKnKaC j98VEd4zO7O8+IZSyOPciYJCn88/Tu4UOrw2VZoX9QwAaZANkS7OSL/rGKbCmpcuRe4m SzD7oGed4stCeNVCh1t9iCW70TvoAgmVYG6OGDQfwP9ubrd0xkdN3etpFlA2bB2G60iJ VEQA== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr6877146oec.126.1363621330543; Mon, 18 Mar 2013 08:42:10 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 08:42:10 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150B9AE692@WSMSG3153V.srv.dir.telstra.com> References: <8B4C063947CD794BB6FF90C78BAE9B321EFC09EC@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B1680429673943675001A6@TK5EX14MBXC283.redmond.corp.microsoft.com> <8B4C063947CD794BB6FF90C78BAE9B321EFC0B77@IMCMBX04.MITRE.ORG> <4E1F6AAD24975D4BA5B16804296739436750053A@TK5EX14MBXC283.redmond.corp.microsoft.com> <255B9BB34FB7D647A506DC292726F6E1150B8467A5@WSMSG3153V.srv.dir.telstra.com> <07b701ce21a8$40b502f0$c21f08d0$@augustcellars.com> <255B9BB34FB7D647A506DC292726F6E1150B9AE692@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 18 Mar 2013 11:42:10 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=bcaec54fae480436b004d834d5a4 X-Gm-Message-State: ALoCoQnGvT+njML/2d88uD0LqRAV9QhfMktWQ08DzDaKiEVBR1FpByaLgiM4R6QosGGAlrTXZZdH Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK 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, 18 Mar 2013 15:42:12 -0000 --bcaec54fae480436b004d834d5a4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This sounds to me like yet another argument for (1) removing the integrity protection from the JOSE header, and (2) creating a separate binary component in JWE to hold the AAD. --Richard On Sun, Mar 17, 2013 at 8:02 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > >> For instance, JWE includes the IV as part of the additional > authenticated data (AAD). No other AEAD system is defined like this. > Everywhere else the IV/nonce and AAD are separate. I hope that doesn=92t > adversely affect the crypto properties, but it does raise questions about > whether it is important for some crypto reason.**** > > ** ** > > [JLS] For this algorithm it is absolutely vital that the IV be protected. > Since the authentication is computed on the post encrypted text not the > pre-encyrpted text, a decryption could never be able to correctly determi= ne > that the IV passed in was correct if it is not validated!!!!!!**** > > ** ** > > ** ** > > Jim,**** > > ** ** > > A256CBC+HS512 needs to integrity-protect the IV. I am not disagreeing wit= h > that.**** > > ** ** > > Every other AEAD algorithm accepts an IV and AAD as separate inputs and *= *internally > to the AEAD algorithm** ensures the appropriate integrity protection is > applied. This is what GCM, CCM, and SIV do. It is the what RFC5116 (AEAD > interface) assumes. It is what any crypto library with an explicit AEAD > interface will support (separate calls or separate parameters for the IV > and AAD).**** > > ** ** > > JWE defines the AAD to be the Header+WrappedKey+IV. That is, the IV is > included in the AAD.**** > > ** ** > > Consequently every other AEAD algorithm (such as A128GCM) will process th= e > JWE IV twice. In A128GCM, for example, the IV will be passed from JOSE co= de > to an underlying crypto API once as a 12-byte (96-bit) binary value, and > also as 16 base64url characters at the end of the AAD. For all these AEAD > algorithms this duplication is merely slightly wasteful, but I guess (hop= e) > it has no impact on security.**** > > ** ** > > The JOSE-specific A256CBC+HS512 algorithm, in contrast, is different. Thi= s > algorithm would be insecure if the AAD did not include the IV. What would > happen if A256CBC+HS512 was implemented in a crypto library accessed via = a > generic AEAD interface? Perhaps it would have to base64url-encode the IV = it > was passed and check that it matches the end of the AAD it was passed > (making it unsuitable as a generic AEAD alg in any other context)?**** > > ** ** > > --**** > > James Manger**** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54fae480436b004d834d5a4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This sounds to me like yet another argument for (1) removing the integrity = protection from the JOSE header, and (2) creating a separate binary compone= nt in JWE to hold the AAD.

--Richard



On Sun, Mar 17, 2013 at 8:02 PM, Ma= nger, James H <James.H.Manger@team.telstra.com> wrote:

>> For instance, JWE includes the IV as part of the additional a= uthenticated data (AAD). No other AEAD system is defined like this. Everywh= ere else the IV/nonce and AAD are separate. I hope that doesn=92t adversely= affect the crypto properties, but it does raise questions about whether it= is important for some crypto reason.

=A0<= /p>

[JLS] For this algorithm i= t is absolutely vital that the IV be protected.=A0 Since the authentication= is computed on the post encrypted text not the pre-encyrpted text, a decry= ption could never be able to correctly determine that the IV passed in was = correct if it is not validated!!!!!!

=A0<= /p>

=A0

Jim,<= /span>

=A0

A256CBC+HS512 needs to in= tegrity-protect the IV. I am not disagreeing with that.

=A0<= /p>

Every other AEAD algor= ithm accepts an IV and AAD as separate inputs and *internally to the AEA= D algorithm* ensures the appropriate integrity protection is applied. T= his is what GCM, CCM, and SIV do. It is the what RFC5116 (AEAD interface) a= ssumes. It is what any crypto library with an explicit AEAD interface will = support (separate calls or separate parameters for the IV and AAD).<= u>

=A0<= /p>

JWE defines the AAD to= be the Header+WrappedKey+IV. That is, the IV is included in the AAD.

=A0<= /p>

Consequently every oth= er AEAD algorithm (such as A128GCM) will process the JWE IV twice. In A128G= CM, for example, the IV will be passed from JOSE code to an underlying cryp= to API once as a 12-byte (96-bit) binary value, and also as 16 base64url ch= aracters at the end of the AAD. For all these AEAD algorithms this duplicat= ion is merely slightly wasteful, but I guess (hope) it has no impact on sec= urity.

=A0<= /p>

The JOSE-specific A256= CBC+HS512 algorithm, in contrast, is different. This algorithm would be ins= ecure if the AAD did not include the IV. What would happen if A256CBC+HS512= was implemented in a crypto library accessed via a generic AEAD interface?= Perhaps it would have to base64url-encode the IV it was passed and check t= hat it matches the end of the AAD it was passed (making it unsuitable as a = generic AEAD alg in any other context)?

=A0<= /p>

--<= /span>

James Manger


_________________________________________= ______
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec54fae480436b004d834d5a4-- From rlb@ipv.sx Mon Mar 18 10:41:35 2013 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 B7BF321F8F1E for ; Mon, 18 Mar 2013 10:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.988 X-Spam-Level: X-Spam-Status: No, score=-0.988 tagged_above=-999 required=5 tests=[AWL=-1.163, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, RDNS_NONE=0.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 tCDz7NhwTO4l for ; Mon, 18 Mar 2013 10:41:21 -0700 (PDT) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id E2E7221F8D61 for ; Mon, 18 Mar 2013 10:41:20 -0700 (PDT) Received: by mail-ob0-f169.google.com with SMTP id ta14so5677104obb.0 for ; Mon, 18 Mar 2013 10:41:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=yUzZ1gWbC1IZdURNZBJdl4/yCWsuaouKb7pLXNBIxQA=; b=Ln6yMdj+z7MCWtuESmT9tT/aMhhM8eBqB98M3da2i4yoLdbs+CKEKErqsDSc4EQ+o+ 8GtwidC39wNds3KTpuypNdg3wxSJdkWv2L0uTollW2p49zMd31JEKfX1h/tEPd2P5Fbq ZsqS1K8w0j7khMXgMC7V2aOr87FvcA/pVHYeUz9GVbYCN84sEfkrCVrgJO0DJzeFkAWU dP8Ljro5vo9qyJX5sZlXGQ9+Q9yHavruOYf8/MH/7iQrg3sz+wARovWMGLvcN/8QNv0V A3KsSt52+gX5XfXE8K3b4PWvxHluQZvUv8pnCtBXeZy4ARE8zEPn+ULTC6DNRbnGU1IK OuKQ== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr7053984oec.126.1363628480495; Mon, 18 Mar 2013 10:41:20 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 10:41:20 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <514264B0.5090306@rub.de> References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5142109D.7010507@mitre.org> <514264B0.5090306@rub.de> Date: Mon, 18 Mar 2013 13:41:20 -0400 Message-ID: From: Richard Barnes To: Juraj Somorovsky Content-Type: multipart/alternative; boundary=bcaec54fae482f982604d8367fb2 X-Gm-Message-State: ALoCoQlCfHhBaytrAfGORqdAviwhe1t/4cxvbhlXNI/p/aLKl1NCtXziOePrggGFvJ7hVS+Z7FtL Cc: Mike Jones , =JeffH , Justin Richer , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 18 Mar 2013 17:41:35 -0000 --bcaec54fae482f982604d8367fb2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Juraj, Thanks for engaging in this discussion. I'm sorry it didn't happen earlier! I would like to confirm that I've understood your paper correctly, and discuss what it implies for JOSE. As I read the paper, the backward-compatibility attack arises when a recipient R is willing to use the same key (symmetric or private) to process both a new algorithm (GCM / OAEP) and an old algorithm (CBC / PKCS#1). The willingness to process the old algorithm allows the necessary oracles to be constructed, which can then be used to attack the new algorithm, as long as the new algorithm uses the same key as the old algorithm. I would also note that cross-protocol attacks exacerbate this problem: A BC vulnerability arises if a key is re-used with a different algorithm ANYWHERE -- not just for another JWE, but for any other protocol. For the purposes of discussion, I would like to note that two putative security mechanisms in the current JOSE spec do NOT mitigate BC attacks. -- Use of only authenticated encryption. The an implementation can safely support CBC and GCM (for example), as long as the same key is not used for both. -- Integrity protection of the algorithm value (as part of the JWS/JWE header). The attacker doesn't need to change the algorithm used for any given object, only for two types of (independent, valid) objects to be processed. On the other hand, the following changes to the spec WOULD mitigate BC attacks. -- Recommending the use of a random CMK wherever possible -- Recommending that implementations follow the guidelines in RFC 3218 [1] -- Recommending that implementations track which keys are used with which algorithms, and prevent key reuse -- Deprecating / removing the "direct" mode of encryption [2], which encourages key reuse by making it harder to use random, ephemeral CMK values. Thanks a lot, --Richard [1] [2] < http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4= .6 > On Thu, Mar 14, 2013 at 8:00 PM, Juraj Somorovsky wrote: > Ok, thank you for mentioning. The attacks were implemented in August > 2012. I mean I used the old library. > > The newest library seems not to use AES-CBC. However, by taking a look at > > https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/69de24720368c480ee9347= 9ca84f3801a3f8909d/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java= ?at=3Dmaster#cl-153 > I assume it is still vulnerable to Bleichenbacher's attack (as it > responds with different Exceptions according to the PKCS1 validity). > > I reported this almost 1 year ago: > http://www.ietf.org/mail-archive/web/jose/current/msg00419.html > > Regards > Juraj > > On 03/14/2013 07:02 PM, Justin Richer wrote: > > Also, the Nimbus-JWT library has been deprecated in favor of > > Nimbus-JOSE-JWT: > > > > https://bitbucket.org/nimbusds/nimbus-jose-jwt/ > > > > The new library is tracking the JOSE specs even more closely, and I'd b= e > > very interested to hear if the attack is still possible against the new > > library. > > > > -- Justin > > > > On 03/14/2013 11:48 AM, Mike Jones wrote: > >> I believe that these attacks are only possible on encryption without > >> integrity, which in turn was only possible, because Nimbus-JWT > >> continued to implement encryption algorithms without integrity > >> protection. Someone should please correct me if I'm misunderstanding > >> the situation. > >> > >> As most of you know, JWE now only allows authenticated encryption > >> algorithms to be used, for reasons exactly such as these. > >> > >> -- Mike > >> > >> -----Original Message----- > >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >> Of =3DJeffH > >> Sent: Thursday, March 14, 2013 8:17 AM > >> To: IETF JOSE WG > >> Cc: Juraj Somorovsky > >> Subject: [jose] backwards compatibility attack on JWT impls (was: I-D > >> Action: draft-ietf-jose-json-web-algorithms-02.txt) > >> > >> back on Fri, 6 Jul 2012 Mike Jones said: > >> > > >> > Looking at this again, it seems to me that because JWE provides > >> integrity > protection for the algorithm, it should be impossible for > >> you to replace > "RSA-OAEP" with "RSA1_5" in the header because then > >> the integrity check will > fail. Thus, the attack that you describe > >> below is prevented by the integrity > protection of the header. > >> > > >> > Hence, correct JWE implementations do no provide the OAEP > >> decryption oracle > that you describe. However if I'm missing > >> something, please point it out to > me, since if there's an issue, > >> I'd like to understand it and how to mitigate > it. > >> > >> just fyi/fwiw...apologies if this has already been followed up on, but > >> I didn't find further discussion of this after the above-quoted msg... > >> > >> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) > >> attacks" paper [1] is now out, and it may help answer the above > >> questions. There's also Kenny Patterson's talk [2] from the recent > >> Workshop on Real-World Cryptography. > >> > >> It seems, from an admittedly cursory glance at both > >> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, > >> that perhaps there should be more implementation advice and security > >> considerations in (at least) the -json-web-algorithms spec. > >> > >> Here's some excerpts from the paper for context... > >> ... > >> In the public-key setting, we show how the well-known attack of > >> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] > >> attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 > >> encryption in both XML Encryption [27] and JSON Web Encryption [42], > >> and to forge signatures for arbitrary messages in XML Signature [30] > >> and JSON Web Signature [41]. The attack principle is described in > >> Section 4. We furthermore report on our experimental results, executed > >> against the Java implementation of JSON Web Encryption and JSON Web > >> Signature Nimbus-JWT [53], in Section 5.3. > >> ... > >> > >> Platform for Experimental Analysis: We investigate the practicality > >> and performance of our attacks on JWE and JWS by applying them to the > >> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON > >> Web Encryption (JWE) and JSON Web Signature (JWS), developed by > >> NimbusDS to support their Cloud Identity management portfolio. > >> > >> Even though Nimbus-JWT claims to implement version 02 of the JWE > >> standard draft, it still supports usage of AESCBC (without MAC), which > >> was available in version 01, but not in version 02 or any subsequent > >> versions. > >> ... > >> > >> 5.2.3 Evaluation > >> > >> We evaluated performance of our attacks against both WSS4J and > >> Nimbus-JWT. We =EF=AC=81rst used the libraries to generate valid messa= ges > >> containing AES-GCM ciphertexts. Then we modi=EF=AC=81ed the algorithm > >> parameters in the messages, forcing the receiver to process the > >> ciphertexts using AES-CBC, and executed the attack described in > >> Algorithm 1. The required ciphertext validity oracles were based on > >> error messages generated by the libraries. > >> ... > >> > >> Experimental Results. In order to assess the practicability and > >> performance of the attack, we implemented Bleichenbacher=E2=80=99s att= ack on > >> XML Encryption [13, 38] and applied it to the Nimbus-JWT library. The > >> PKCS#1 v1.5 validity oracle was provided by exceptions thrown by this > >> library.11 > >> ... > >> > >> 11 In practice one would instead use the more elaborate attack > >> techniques of [38] to determine whether a given ciphertext is PKCS#1 > >> v1.5 valid. > >> ... > >> > >> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols > >> based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, > >> Advances in Cryptology =E2=80=93 CRYPTO=E2=80=9998, volume 1462 of Lec= ture Notes in > >> Computer Science, pages 1=E2=80=9312. > >> Springer, Aug. 1998. > >> > >> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2=80=99= s attack > >> strikes > >> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. > >> Yung, editors, Computer Security - ESORICS 2012 - 17th European > >> Symposium on Research in Computer Security, Pisa, Italy, September > >> 10-14, 2012. Proceedings, LNCS. > >> Springer, 2012. > >> > >> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. > >> https://bitbucket.org/nimbusds/nimbus-jwt. > >> > >> ### > >> > >> [1] One Bad Apple: Backwards Compatibility Attacks on > >> State-of-the-Art Cryptography > >> > http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/0= 8/BackwardsCompatibilityAttacks.pdf > >> > >> > >> [2] Key Reuse: Theory and Practice > >> http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf > >> > >> > >> HTH, > >> > >> =3DJeffH > >> > >> > >> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --bcaec54fae482f982604d8367fb2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Juraj,

Thanks for engaging in this discussion. =C2=A0= I'm sorry it didn't happen earlier! =C2=A0I would like to confirm t= hat I've understood your paper correctly, and discuss what it implies f= or JOSE.

As I read the paper, the backward-compatibility attack = arises when a recipient R is willing to use the same key (symmetric or priv= ate) to process both a new algorithm (GCM / OAEP) and an old algorithm (CBC= / PKCS#1). =C2=A0The willingness to process the old algorithm allows the n= ecessary oracles to be constructed, which can then be used to attack the ne= w algorithm, as long as the new algorithm uses the same key as the old algo= rithm. =C2=A0I would also note that cross-protocol attacks exacerbate this = problem: A BC vulnerability arises if a key is re-used with a different alg= orithm ANYWHERE -- not just for another JWE, but for any other protocol.

For the purposes of discussion, I would like to note th= at two putative security mechanisms in the current JOSE spec do NOT mitigat= e BC attacks.
-- Use of only authenticated encryption. =C2=A0The = an implementation can safely support CBC and GCM (for example), as long as = the same key is not used for both.
-- Integrity protection of the algorithm value (as part of the JWS/JWE= header). =C2=A0The attacker doesn't need to change the algorithm used = for any given object, only for two types of (independent, valid) objects to= be processed.

On the other hand, the following changes to the spec WO= ULD mitigate BC attacks.
-- Recommending the use of a random CMK = wherever possible=C2=A0
-- Recommending that implementations foll= ow the guidelines in RFC 3218 [1]
-- Recommending that implementations track which keys are used with wh= ich algorithms, and prevent key reuse
-- Deprecating / removing t= he "direct" mode of encryption [2], which encourages key reuse by= making it harder to use random, ephemeral CMK values.

Thanks a lot,
--Richard

<= div>[1] <http://tools.iet= f.org/html/rfc3218>
[2] <http://tools.ie= tf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.6>



On Thu, Mar 14, 2013= at 8:00 PM, Juraj Somorovsky <juraj.somorovsky@rub.de> wrote:
Ok, thank you for mentioning. The attacks we= re implemented in August
2012. I mean I used the old library.

The newest library seems not to use AES-CBC. However, by taking a look at https://bitbucket.org/nimbu= sds/nimbus-jose-jwt/src/69de24720368c480ee93479ca84f3801a3f8909d/src/main/j= ava/com/nimbusds/jose/crypto/RSADecrypter.java?at=3Dmaster#cl-153
I assume it is still vulnerable to Bleichenbacher's attack (as it
responds with different Exceptions according to the PKCS1 validity).

I reported this almost 1 year ago:
http://www.ietf.org/mail-archive/web/jose/current/msg004= 19.html

Regards
Juraj

On 03/14/2013 07:02 PM, Justin Richer wrote:
> Also, the Nimbus-JWT library has been deprecated in favor of
> Nimbus-JOSE-JWT:
>
> =C2=A0 https://bitbucket.org/nimbusds/nimbus-jose-jwt/
>
> The new library is tracking the JOSE specs even more closely, and I= 9;d be
> very interested to hear if the attack is still possible against the ne= w
> library.
>
> =C2=A0-- Justin
>
> On 03/14/2013 11:48 AM, Mike Jones wrote:
>> I believe that these attacks are only possible on encryption witho= ut
>> integrity, which in turn was only possible, because Nimbus-JWT
>> continued to implement encryption algorithms without integrity
>> protection. =C2=A0Someone should please correct me if I'm misu= nderstanding
>> the situation.
>>
>> As most of you know, JWE now only allows authenticated encryption<= br> >> algorithms to be used, for reasons exactly such as these.
>>
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mike >>
>> -----Original Message-----
>> From: jose-bounces@ietf.o= rg [mailto:jose-bounces@ietf.o= rg] On Behalf
>> Of =3DJeffH
>> Sent: Thursday, March 14, 2013 8:17 AM
>> To: IETF JOSE WG
>> Cc: Juraj Somorovsky
>> Subject: [jose] backwards compatibility attack on JWT impls (was: = I-D
>> Action: draft-ietf-jose-json-web-algorithms-02.txt)
>>
>> back on Fri, 6 Jul 2012 =C2=A0Mike Jones said:
>> =C2=A0 >
>> =C2=A0 > Looking at this again, it seems to me that because JWE= provides
>> integrity =C2=A0> protection for the algorithm, it should be im= possible for
>> you to replace =C2=A0> "RSA-OAEP" with "RSA1_5&q= uot; in the header because then
>> the integrity check will =C2=A0> fail. =C2=A0Thus, the attack t= hat you describe
>> below is prevented by the integrity =C2=A0> protection of the h= eader.
>> =C2=A0 >
>> =C2=A0 > Hence, correct JWE implementations do no provide the O= AEP
>> decryption oracle =C2=A0> that you describe. =C2=A0However if I= 'm missing
>> something, please point it out to =C2=A0> me, since if there= 9;s an issue,
>> I'd like to understand it and how to mitigate =C2=A0> it. >>
>> just fyi/fwiw...apologies if this has already been followed up on,= but
>> I didn't find further discussion of this after the above-quote= d msg...
>>
>> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibili= ty (BC)
>> attacks" paper [1] is now out, and it may help answer the abo= ve
>> questions. There's also Kenny Patterson's talk [2] from th= e recent
>> Workshop on Real-World Cryptography.
>>
>> It seems, from an admittedly cursory glance at both
>> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slid= es,
>> that perhaps there should be more implementation advice and securi= ty
>> considerations in (at least) the -json-web-algorithms spec.
>>
>> Here's some excerpts from the paper for context...
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >> In the public-key setting, we show how the well-known attack of >> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] >> attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2= .0
>> encryption in both XML Encryption [27] and JSON Web Encryption [42= ],
>> and to forge signatures for arbitrary messages in XML Signature [3= 0]
>> and JSON Web Signature [41]. The attack principle is described in<= br> >> Section 4. We furthermore report on our experimental results, exec= uted
>> against the Java implementation of JSON Web Encryption and JSON We= b
>> Signature Nimbus-JWT [53], in Section 5.3.
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >>
>> Platform for Experimental Analysis: We investigate the practicalit= y
>> and performance of our attacks on JWE and JWS by applying them to = the
>> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JS= ON
>> Web Encryption (JWE) and JSON Web Signature (JWS), developed by >> NimbusDS to support their Cloud Identity management portfolio.
>>
>> Even though Nimbus-JWT claims to implement version 02 of the JWE >> standard draft, it still supports usage of AESCBC (without MAC), w= hich
>> was available in version 01, but not in version 02 or any subseque= nt
>> versions.
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >>
>> 5.2.3 Evaluation
>>
>> We evaluated performance of our attacks against both WSS4J and
>> Nimbus-JWT. We =EF=AC=81rst used the libraries to generate valid m= essages
>> containing AES-GCM ciphertexts. Then we modi=EF=AC=81ed the algori= thm
>> parameters in the messages, forcing the receiver to process the >> ciphertexts using AES-CBC, and executed the attack described in >> Algorithm 1. The required ciphertext validity oracles were based o= n
>> error messages generated by the libraries.
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >>
>> Experimental Results. In order to assess the practicability and >> performance of the attack, we implemented Bleichenbacher=E2=80=99s= attack on
>> XML Encryption [13, 38] and applied it to the Nimbus-JWT library. = The
>> PKCS#1 v1.5 validity oracle was provided by exceptions thrown by t= his
>> library.11
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >>
>> 11 In practice one would instead use the more elaborate attack
>> techniques of [38] to determine whether a given ciphertext is PKCS= #1
>> v1.5 valid.
>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...<= br> >>
>> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocol= s
>> based on the RSA encryption standard PKCS#1. In H. Krawczyk, edito= r,
>> Advances in Cryptology =E2=80=93 CRYPTO=E2=80=9998, volume 1462 of= Lecture Notes in
>> Computer Science, pages 1=E2=80=9312.
>> Springer, Aug. 1998.
>>
>> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2= =80=99s attack
>> strikes
>> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M= .
>> Yung, editors, Computer Security - ESORICS 2012 - 17th European >> Symposium on Research in Computer Security, Pisa, Italy, September=
>> 10-14, 2012. Proceedings, LNCS.
>> Springer, 2012.
>>
>> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. >> https://bitbucket.org/nimbusds/nimbus-jwt.
>>
>> ###
>>
>> [1] One Bad Apple: Backwards Compatibility Attacks on
>> =C2=A0 =C2=A0State-of-the-Art Cryptography
>> ht= tp://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/Ba= ckwardsCompatibilityAttacks.pdf
>>
>>
>> [2] Key Reuse: Theory and Practice
>> http://crypto.stanford.edu/RealWorldCrypto/slides/k= enny.pdf
>>
>>
>> HTH,
>>
>> =3DJeffH
>>
>>
>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--bcaec54fae482f982604d8367fb2-- From Michael.Jones@microsoft.com Mon Mar 18 11:32:04 2013 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 2EC7C21F8F53 for ; Mon, 18 Mar 2013 11:32:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599] 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 E1jn6xWtT9Xd for ; Mon, 18 Mar 2013 11:31:56 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id D820B21F8D12 for ; Mon, 18 Mar 2013 11:31:52 -0700 (PDT) Received: from BL2FFO11FD028.protection.gbl (10.173.161.202) by BL2FFO11HUB034.protection.gbl (10.173.161.114) with Microsoft SMTP Server (TLS) id 15.0.641.9; Mon, 18 Mar 2013 18:31:50 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Mon, 18 Mar 2013 18:31:49 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 18 Mar 2013 18:31:27 +0000 From: Mike Jones To: Vladimir Dzhuvinov / NimbusDS , "jose@ietf.org" Thread-Topic: [jose] JPSK: JWKs with private RSA/EC params only? Thread-Index: AQHOI7yvBre+nR11SkuYMKwRwb18i5irxVCA Date: Mon, 18 Mar 2013 18:31:27 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367556729@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> In-Reply-To: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(199002)(189002)(51164002)(377454001)(13464002)(5343655001)(54356001)(5343635001)(76482001)(51856001)(74502001)(74662001)(54316002)(56816002)(44976002)(33656001)(47446002)(31966008)(46406002)(47976001)(50466001)(47736001)(55846006)(79102001)(16406001)(66066001)(69226001)(56776001)(53806001)(50986001)(80022001)(77982001)(59766001)(65816001)(15974865001)(49866001)(20776003)(46102001)(4396001)(23726001)(47776003)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB034; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07891BF289 Subject: Re: [jose] JPSK: JWKs with private RSA/EC params only? 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, 18 Mar 2013 18:32:04 -0000 I don't think so, but that's a question we should answer clearly one way or= the other. What's done in this regard in other specs, such as the XML key= representation for XML DSIG and RFC 3447? -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Vla= dimir Dzhuvinov / NimbusDS Sent: Monday, March 18, 2013 2:40 AM To: jose@ietf.org Subject: [jose] JPSK: JWKs with private RSA/EC params only? Hi guys, Justin and I began an implementation of draft-jones-jose-json-private-and-symmetric-key-00 for the Nimbus library. = We're now able to represent the regular public RSA/EC JWKs as well as JWKs = that contain both public+private RSA/EC params. Does the draft also envisio= n JWK objects which include only private key parameters? I.e. a JWK object = for the public params and then another for the private params? My reading o= f the spec couldn't answer this question. Please advise. Thanks, Vladimir -- Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com _____________= __________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From jricher@mitre.org Mon Mar 18 11:47:57 2013 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 3B6F421F9077 for ; Mon, 18 Mar 2013 11:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.732 X-Spam-Level: X-Spam-Status: No, score=-4.732 tagged_above=-999 required=5 tests=[AWL=1.867, BAYES_00=-2.599, 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 ByvkclnzewGp for ; Mon, 18 Mar 2013 11:47:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 05F8521F8FFA for ; Mon, 18 Mar 2013 11:47:47 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 980AA1F0659; Mon, 18 Mar 2013 14:47:46 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 68D661F062A; Mon, 18 Mar 2013 14:47:46 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS02.MITRE.ORG (129.83.29.79) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 18 Mar 2013 14:47:46 -0400 Message-ID: <514760FF.7070101@mitre.org> Date: Mon, 18 Mar 2013 14:46:23 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: Vladimir Dzhuvinov / NimbusDS References: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> In-Reply-To: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [129.83.31.58] Cc: jose@ietf.org Subject: Re: [jose] JPSK: JWKs with private RSA/EC params only? 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, 18 Mar 2013 18:47:57 -0000 For what it's worth, my reading of the spec was that a JWK would be a keypair or a public key, but never just the private key on its own. (Symmetric keys are their own thing, of course.) -- Justin On 03/18/2013 05:40 AM, Vladimir Dzhuvinov / NimbusDS wrote: > Hi guys, > > Justin and I began an implementation of > draft-jones-jose-json-private-and-symmetric-key-00 for the Nimbus > library. We're now able to represent the regular public RSA/EC JWKs as > well as JWKs that contain both public+private RSA/EC params. Does the > draft also envision JWK objects which include only private key > parameters? I.e. a JWK object for the public params and then another for > the private params? My reading of the spec couldn't answer this > question. Please advise. > > Thanks, > > Vladimir > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rlb@ipv.sx Mon Mar 18 15:41:42 2013 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 84BB721F8A64 for ; Mon, 18 Mar 2013 15:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 rJZUB70qTE0k for ; Mon, 18 Mar 2013 15:41:41 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id DFADB21F8B8A for ; Mon, 18 Mar 2013 15:41:40 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id j1so6108893oag.7 for ; Mon, 18 Mar 2013 15:41:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=qQyzcQzac/m/Y3zfNnXsleH5iwG2cSPo0oWuICgkn60=; b=H0MpL0wLOPMpGDHdh9Maw6OEGGXep7K1deQ6VnO9AliqZKHggzJCzPdTb/bn/GCAl+ Bl6vOJZ0x5LXjMQcmd599GnUBpw44DzhXritcav7PN6OWScXZNIo5ouR/DsLXK9sdgzW RihuqDRpJNR/zmJY2ZpqwYRxVKyBJwbjVoNviCcatiWBf3WRjahrm1jt9XIqbmexFrzb fJ2Q5Blvc4XkNtrtWgGFs1nawL9ZIXFOmY1xbi2vvhKFZytfEnuYOLMgNV6fGZySKGr9 Het6VHTuINAFH0NYz962EMYDzlEmvndzp18OKrlDl4jQJU2q1/um5yIJl/pqtLs15zTp pHUQ== MIME-Version: 1.0 X-Received: by 10.182.8.70 with SMTP id p6mr7366296oba.90.1363646491871; Mon, 18 Mar 2013 15:41:31 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 15:41:31 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <514760FF.7070101@mitre.org> References: <20130318024001.cc40c4f3d92d2001859047cd8cabb9ab.36405e633c.wbe@email07.europe.secureserver.net> <514760FF.7070101@mitre.org> Date: Mon, 18 Mar 2013 18:41:31 -0400 Message-ID: From: Richard Barnes To: Justin Richer Content-Type: multipart/alternative; boundary=f46d0444ea41bf640d04d83ab0c5 X-Gm-Message-State: ALoCoQl97WahfSrO8eZvXmCq4o6CGxAgBKJtzTm+lCV2Blodikc2MZxEZYK94DbRxD80U+qEMiy7 Cc: jose@ietf.org, Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] JPSK: JWKs with private RSA/EC params only? 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, 18 Mar 2013 22:41:42 -0000 --f46d0444ea41bf640d04d83ab0c5 Content-Type: text/plain; charset=ISO-8859-1 It's not clear to me that there's a clear answer here, or that there needs to be. On the one hand, there's not really a reason *omit* public key information, since it's public. (Unless you're being very bit-thrifty.) On the other hand, public key fields aren't technically necessary for a private key, so I hesitate to mandate their inclusion. So overall, I lean toward making them optional. --Richard On Mon, Mar 18, 2013 at 2:46 PM, Justin Richer wrote: > For what it's worth, my reading of the spec was that a JWK would be a > keypair or a public key, but never just the private key on its own. > (Symmetric keys are their own thing, of course.) > > -- Justin > > > On 03/18/2013 05:40 AM, Vladimir Dzhuvinov / NimbusDS wrote: > >> Hi guys, >> >> Justin and I began an implementation of >> draft-jones-jose-json-private-**and-symmetric-key-00 for the Nimbus >> library. We're now able to represent the regular public RSA/EC JWKs as >> well as JWKs that contain both public+private RSA/EC params. Does the >> draft also envision JWK objects which include only private key >> parameters? I.e. a JWK object for the public params and then another for >> the private params? My reading of the spec couldn't answer this >> question. Please advise. >> >> Thanks, >> >> Vladimir >> -- >> Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com >> ______________________________**_________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/**listinfo/jose >> > > ______________________________**_________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/**listinfo/jose > --f46d0444ea41bf640d04d83ab0c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It's not clear to me that there's a clear answer here, or that ther= e needs to be. =A0On the one hand, there's not really a reason *omit* p= ublic key information, since it's public. =A0(Unless you're being v= ery bit-thrifty.) =A0On the other hand, public key fields aren't techni= cally necessary for a private key, so I hesitate to mandate their inclusion= . =A0So overall, I lean toward making them optional.

--Richard


On Mo= n, Mar 18, 2013 at 2:46 PM, Justin Richer <jricher@mitre.org> wrote:
For what it's worth, my reading of the s= pec was that a JWK would be a keypair or a public key, but never just the p= rivate key on its own. (Symmetric keys are their own thing, of course.)

=A0-- Justin


On 03/18/2013 05:40 AM, Vladimir Dzhuvinov / NimbusDS wrote:
Hi guys,

Justin and I began an implementation of
draft-jones-jose-json-private-and-symmetric-key-00 for the Nimbus library. We're now able to represent the regular public RSA/EC JWKs as<= br> well as JWKs that contain both public+private RSA/EC params. Does the
draft also envision JWK objects which include only private key
parameters? I.e. a JWK object for the public params and then another for the private params? My reading of the spec couldn't answer this
question. Please advise.

Thanks,

Vladimir
--
Vladimir Dzhuvinov : = www.NimbusDS.com : vladimir@nimbusds.com
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d0444ea41bf640d04d83ab0c5-- From trac+jose@trac.tools.ietf.org Mon Mar 18 16:23:26 2013 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 BF5DD21F8AD5 for ; Mon, 18 Mar 2013 16:23:26 -0700 (PDT) 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 XVT5L3DzT80M for ; Mon, 18 Mar 2013 16:23:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 10CDB21F8AD1 for ; Mon, 18 Mar 2013 16:23:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:43666 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UHjOm-0000k5-Tb; Tue, 19 Mar 2013 00:23:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-barnes-jose-use-cases@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Mon, 18 Mar 2013 23:23:24 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/13 Message-ID: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-barnes-jose-use-cases@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: rlb@ipv.sx Resent-Message-Id: <20130318232326.10CDB21F8AD1@ietfa.amsl.com> Resent-Date: Mon, 18 Mar 2013 16:23:25 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:23:26 -0000 #13: Enable AEAD key wrapping Wrapped keys in JWE and JWS (pending Issue #2) need to be able to use AEAD algorithms for key wrapping. Thus, these objects need to be able to specify AEAD algorithm parameters (e.g., IVs) for both the key wrapping operation and the encryption operation. -- -------------------------------------+------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-barnes-jose-use- Type: defect | cases@tools.ietf.org Priority: major | Status: new Component: draft-barnes-jose-use- | Milestone: cases | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Mon Mar 18 16:23:28 2013 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 C42C421F8B7C for ; Mon, 18 Mar 2013 16:23:28 -0700 (PDT) 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 Ex8E8tCotA8W for ; Mon, 18 Mar 2013 16:23:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1434221F8AD8 for ; Mon, 18 Mar 2013 16:23:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:43676 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UHjOp-0001Yv-DY; Tue, 19 Mar 2013 00:23:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-barnes-jose-use-cases@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Mon, 18 Mar 2013 23:23:27 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/14 Message-ID: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-barnes-jose-use-cases@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: rlb@ipv.sx Resent-Message-Id: <20130318232328.1434221F8AD8@ietfa.amsl.com> Resent-Date: Mon, 18 Mar 2013 16:23:28 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #14: Support longer wrapped keys than OAEP allows X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:23:28 -0000 #14: Support longer wrapped keys than OAEP allows The use of RSA-OAEP for key wrapping imposes a limit on the length of the key package being wrapped. With SHA1, this length is N-320, where N is the length of the RSA modulus. Especially with larger hash functions, and especially for wrapping private keys, the size of key packages will be larger than this bound. We should incorporate a mechanism to accommodate these situations. -- -------------------------------------+------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-barnes-jose-use- Type: defect | cases@tools.ietf.org Priority: major | Status: new Component: draft-barnes-jose-use- | Milestone: cases | Version: Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Mon Mar 18 16:23:47 2013 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 5C15C21F84C1 for ; Mon, 18 Mar 2013 16:23:47 -0700 (PDT) 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 rs-L9KWl9bok for ; Mon, 18 Mar 2013 16:23:46 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1BD21F84B9 for ; Mon, 18 Mar 2013 16:23:45 -0700 (PDT) Received: from localhost ([127.0.0.1]:43718 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UHjP2-0005We-LC; Tue, 19 Mar 2013 00:23:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Mon, 18 Mar 2013 23:23:40 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/jose/trac/ticket/13#comment:1 Message-ID: <064.3916b4f2b28d0b7bcd6ec5eb448918d8@trac.tools.ietf.org> References: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130318232345.5A1BD21F84B9@ietfa.amsl.com> Resent-Date: Mon, 18 Mar 2013 16:23:45 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:23:47 -0000 #13: Enable AEAD key wrapping Changes (by rlb@ipv.sx): * owner: draft-barnes-jose-use-cases@tools.ietf.org => draft-ietf-jose- json-web-encryption@tools.ietf.org * component: draft-barnes-jose-use-cases => json-web-encryption -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Mon Mar 18 16:24:03 2013 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 B582221F84C5 for ; Mon, 18 Mar 2013 16:24:01 -0700 (PDT) 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=[AWL=0.000, 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 vdZF7jWXQYRJ for ; Mon, 18 Mar 2013 16:24:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5496621F84C9 for ; Mon, 18 Mar 2013 16:23:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:43758 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UHjPH-0002M8-HQ; Tue, 19 Mar 2013 00:23:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Mon, 18 Mar 2013 23:23:55 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/14#comment:1 Message-ID: <064.48360dd8d5e5fcbd7663d70833bafe5c@trac.tools.ietf.org> References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130318232359.5496621F84C9@ietfa.amsl.com> Resent-Date: Mon, 18 Mar 2013 16:23:59 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:24:03 -0000 #14: Support longer wrapped keys than OAEP allows Changes (by rlb@ipv.sx): * owner: draft-barnes-jose-use-cases@tools.ietf.org => draft-ietf-jose- json-web-encryption@tools.ietf.org * component: draft-barnes-jose-use-cases => json-web-encryption -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Mon Mar 18 16:25:20 2013 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 EA0D721F84C1 for ; Mon, 18 Mar 2013 16:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.024 X-Spam-Level: X-Spam-Status: No, score=-1.024 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 dUa88ehiaAb7 for ; Mon, 18 Mar 2013 16:25:20 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3851021F84B9 for ; Mon, 18 Mar 2013 16:25:20 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id un3so5926763obb.38 for ; Mon, 18 Mar 2013 16:25:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:date:message-id:subject :from:to:content-type:x-gm-message-state; bh=2lrGS2moO9MxH55buVklKRCQchokSpgKlhYInnTDDhA=; b=lVjYdBvYP9vjfGSP/ijmEhhA+HbCTMFEUzutAoWxMMATe17k8Y3fqm8USGTRPgdWKi OjBCkzbP24vKuINeXg8a8YBtGTbGxs7oP9Rg09x9oEYaGSdCYzlUEwJT0ddN0Ohk5uSd w52gg9gxIKM+Ghoq4tapgAcIp4nk6AtejjfBoj/C/Mf69H+AlejJn5bEn9yuC5r3T0vJ sSb4BZzrE96LynhGvnlP0eXUmNjm6Yanf4gcbftXvHk7djmkm9b9qaa1NoKNln1AYdcR 46/5+qYQS8yN/IzXqiDYJ/AI0vC4xtSkc0S4WmH6UG82uxaVDM3a0gZRV7FJBEv4FwqG nx1Q== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr7723205oec.116.1363649119746; Mon, 18 Mar 2013 16:25:19 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 16:25:19 -0700 (PDT) X-Originating-IP: [192.1.51.16] Date: Mon, 18 Mar 2013 19:25:19 -0400 Message-ID: From: Richard Barnes To: jose@ietf.org Content-Type: multipart/alternative; boundary=bcaec5523bb661db3404d83b4d4e X-Gm-Message-State: ALoCoQm3DcB88vueV+4aWOUFimeQa8lamGzn8t0rya2tuLpHRerj395Ph+PhTFG8yWedmelpZja9 Subject: [jose] WebCrypto feedback on key wrapping 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, 18 Mar 2013 23:25:21 -0000 --bcaec5523bb661db3404d83b4d4e Content-Type: text/plain; charset=ISO-8859-1 On today's call with the W3C WebCrypto working group, I reported on the discussion of JOSE key wrapping at the last IETF. I was asked to relay a few bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of favor with some parts of the cryptographic community. People prefer to be able to use AEAD algorithms for key wrapping, since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEEE 802.1 uses AES CCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped key objects, then we would need something other than OAEP in order to carry arbitrary-length payloads. I agreed, and suggested that something like RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack of support by native crypto libraries. It seems to me that these comments have impacts on JWE and JWS (pending ISSUE-2), as well as the wrapping discussion. The former has more impact than the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as well as for wrapped keys. It seems to me that the simplest approach to this would be to make the "alg" field contain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly the same form that algorithm identifiers have in the WebCrypto API. Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, which is too long to be encrypted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. The best idea I've got is to allow wrapped keys to nest, so that you can wrap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping draft, and I've filed two issues against JWE to track them. --Richard --bcaec5523bb661db3404d83b4d4e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On today's call with the W3C WebCrypto working =A0group, I reported on = the discussion of JOSE key wrapping at the last IETF. =A0I was asked to rel= ay a few bits of feedback:

1. Vijay Bharadwaj (Microsoft= ) observed that AES key wrap has fallen out of favor with some parts of the= cryptographic community. =A0People prefer to be able to use AEAD algorithm= s for key wrapping, since they are perceived to be faster and offer a highe= r level of security than AES-KW. He gave the example that IEEE 802.1 uses A= ES CCM.

2. Mark Watson (Netflix) noted that if we use RSA direc= tly to encrypt wrapped key objects, then we would need something other than= OAEP in order to carry arbitrary-length payloads. =A0I agreed, and suggest= ed that something like RSA-KEM would be necessary. =A0Ryan Sleevi (Google) = and Vijay observed that KEM is troublesome due to the lack of support by na= tive crypto libraries.

It seems to me that these comments have impacts on JWE = and JWS (pending ISSUE-2), as well as the wrapping discussion. =A0The forme= r has more impact than the latter.=A0

Point number= 1 implies that we should offer AEAD for key wrapping in JWE as well as for= wrapped keys. =A0It seems to me that the simplest approach to this would b= e to make the "alg" field contain an object that is semantically = equivalent to an AlgorithmIdentifier in CMS/PKCS8. =A0For example, { name: = "A128GCM", iv: "PCIGJe0DjunuM7s0" }. =A0This syntax, in= cidentally, is roughly the same form that algorithm identifiers have in the= WebCrypto API. =A0Note that this type of key wrapping is supported in CMS = by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo structure= . =A0

Point number 2 likely applies for some scenarios of JWE= , especially if we adopt the McGrew approach. =A0For example, if using HMAC= -SHA1 and AES with a 256-bit key, the total key length is 788 bits, which i= s too long to be encrypted with OAEP under a 1,024-bit RSA key. =A0I'm = not sure how to resolve it. =A0The best idea I've got is to allow wrapp= ed keys to nest, so that you can wrap a key inside of another wrapped key.<= /div>

I will try to take these points into account in my fort= hcoming key wrapping draft, and I've filed two issues against JWE to tr= ack them.

--Richard
--bcaec5523bb661db3404d83b4d4e-- From Michael.Jones@microsoft.com Mon Mar 18 17:14:28 2013 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 ED8BF21F85E0 for ; Mon, 18 Mar 2013 17:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.269 X-Spam-Level: X-Spam-Status: No, score=-2.269 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LkfpZv1amKsT for ; Mon, 18 Mar 2013 17:14:26 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9916021F85DC for ; Mon, 18 Mar 2013 17:14:25 -0700 (PDT) Received: from BL2FFO11FD027.protection.gbl (10.173.161.204) by BL2FFO11HUB013.protection.gbl (10.173.160.105) with Microsoft SMTP Server (TLS) id 15.0.641.9; Tue, 19 Mar 2013 00:02:31 +0000 Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD027.mail.protection.outlook.com (10.173.161.106) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Tue, 19 Mar 2013 00:02:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC106.redmond.corp.microsoft.com ([157.54.80.61]) with mapi id 14.02.0318.003; Tue, 19 Mar 2013 00:02:18 +0000 From: Mike Jones To: Richard Barnes , "jose@ietf.org" Thread-Topic: [jose] WebCrypto feedback on key wrapping Thread-Index: AQHOJC/fb0UrhnxpB0CL7KQe/F+ugpisIMPA Date: Tue, 19 Mar 2013 00:02:18 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436755A50CTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(377454001)(56776001)(65816001)(77982001)(512954001)(44976002)(16236675001)(76482001)(80022001)(56816002)(69226001)(63696002)(47976001)(33656001)(15202345001)(16406001)(79102001)(53806001)(74662001)(54356001)(59766001)(5343655001)(51856001)(74502001)(50986001)(20776003)(49866001)(55846006)(5343635001)(47446002)(4396001)(66066001)(46102001)(47736001)(31966008)(54316002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB013; H:TK5EX14HUBC106.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0790FB1F33 Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 00:14:28 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436755A50CTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Given that we require RSA keys to be a minimum of 2048 bits in length, ther= e's no problem wrapping 768 bit keys with OAEP in practice. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, March 18, 2013 4:25 PM To: jose@ietf.org Subject: [jose] WebCrypto feedback on key wrapping On today's call with the W3C WebCrypto working group, I reported on the di= scussion of JOSE key wrapping at the last IETF. I was asked to relay a few= bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of= favor with some parts of the cryptographic community. People prefer to be= able to use AEAD algorithms for key wrapping, since they are perceived to = be faster and offer a higher level of security than AES-KW. He gave the exa= mple that IEEE 802.1 uses AES CCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapp= ed key objects, then we would need something other than OAEP in order to ca= rry arbitrary-length payloads. I agreed, and suggested that something like= RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that = KEM is troublesome due to the lack of support by native crypto libraries. It seems to me that these comments have impacts on JWE and JWS (pending ISS= UE-2), as well as the wrapping discussion. The former has more impact than= the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as= well as for wrapped keys. It seems to me that the simplest approach to th= is would be to make the "alg" field contain an object that is semantically = equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly t= he same form that algorithm identifiers have in the WebCrypto API. Note th= at this type of key wrapping is supported in CMS by the use of an AEAD Algo= rithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we a= dopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 2= 56-bit key, the total key length is 788 bits, which is too long to be encry= pted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. = The best idea I've got is to allow wrapped keys to nest, so that you can w= rap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping= draft, and I've filed two issues against JWE to track them. --Richard --_000_4E1F6AAD24975D4BA5B16804296739436755A50CTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Given that we require RSA= keys to be a minimum of 2048 bits in length, there’s no problem wrap= ping 768 bit keys with OAEP in practice.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 18, 2013 4:25 PM
To: jose@ietf.org
Subject: [jose] WebCrypto feedback on key wrapping=

 

On today's call with the W3C WebCrypto working  = ;group, I reported on the discussion of JOSE key wrapping at the last IETF.=  I was asked to relay a few bits of feedback:

 

1. Vijay Bharadwaj (Microsoft) observed that AES key= wrap has fallen out of favor with some parts of the cryptographic communit= y.  People prefer to be able to use AEAD algorithms for key wrapping, = since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEE= E 802.1 uses AES CCM.

 

2. Mark Watson (Netflix) noted that if we use RSA di= rectly to encrypt wrapped key objects, then we would need something other t= han OAEP in order to carry arbitrary-length payloads.  I agreed, and s= uggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is tr= oublesome due to the lack of support by native crypto libraries.=

 

It seems to me that these comments have impacts on J= WE and JWS (pending ISSUE-2), as well as the wrapping discussion.  The= former has more impact than the latter. 

 

Point number 1 implies that we should offer AEAD for= key wrapping in JWE as well as for wrapped keys.  It seems to me that= the simplest approach to this would be to make the "alg" field c= ontain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax, incide= ntally, is roughly the same form that algorithm identifiers have in the Web= Crypto API.  Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo s= tructure.  

 

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach.  For example, if usin= g HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, w= hich is too long to be encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The= best idea I've got is to allow wrapped keys to nest, so that you can wrap = a key inside of another wrapped key.

 

I will try to take these points into account in my f= orthcoming key wrapping draft, and I've filed two issues against JWE to tra= ck them.

 

--Richard

--_000_4E1F6AAD24975D4BA5B16804296739436755A50CTK5EX14MBXC283r_-- From James.H.Manger@team.telstra.com Mon Mar 18 17:16:59 2013 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 09C7921F85EE for ; Mon, 18 Mar 2013 17:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 FT2B1RInD-F3 for ; Mon, 18 Mar 2013 17:16:58 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2877621F85EB for ; Mon, 18 Mar 2013 17:16:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,868,1355058000"; d="scan'208";a="123974600" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 19 Mar 2013 11:16:44 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7018"; a="119708181" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipccvi.tcif.telstra.com.au with ESMTP; 19 Mar 2013 11:16:44 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 19 Mar 2013 11:16:43 +1100 From: "Manger, James H" To: "rlb@ipv.sx" , "jose@ietf.org" Date: Tue, 19 Mar 2013 11:16:42 +1100 Thread-Topic: [jose] #14: Support longer wrapped keys than OAEP allows Thread-Index: Ac4kL5uMQGd5kYeuRj6XiWhLNdMq4gABCvjA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BAAC4D8@WSMSG3153V.srv.dir.telstra.com> References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> In-Reply-To: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 00:16:59 -0000 UmljaGFyZCwNCg0KSG93IGRvIHlvdSBnZXQgYSA3ODgtYml0IGtleSBsZW5ndGg/DQoNCmRyYWZ0 LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGRlZmluZXMgNSBjb21iaW5hdGlvbnMgb2Yg QUVTLTEyOC8xOTIvMjU2IGFuZCBTSEEtMS8yNTYvMzg0LzUxMi4gVGhlIHRvdGFsIGtleSBsZW5n dGhzIHJhbmdlIGZyb20gMjU2IGJpdHMgdG8gNTEyIGJpdHMuDQoNCktleXMgZm9yIHR3byBvZiB0 aGUgYWxnb3JpdGhtcyAoQUVBRF9BRVNfMTI4X0NCQ19ITUFDX1NIQV8yNTYgYW5kIEFFQURfQUVT XzEyOF9DQkNfSE1BQ19TSEExKSBmaXQgd2l0aGluIE9BRVAgd2l0aCBhIDEwMjQtYml0IFJTQSBr ZXkuDQoNCktleXMgZm9yIGFsbCBvZiB0aGUgYWxnb3JpdGhtcyBmaXQgd2l0aGluIE9BRVAgd2l0 aCBhIDIwNDgtYml0IFJTQSBrZXkuIEpXQSBhbHJlYWR5IHNheXMgUlNBIGtleSBzaXplcyBNVVNU IGJlIGF0IGxlYXN0IDIwNDggYml0cy4NCg0KVGhpcyBhbHJlYWR5IGxvb2tzIHN1ZmZpY2llbnQu DQogDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg0KPiBGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJhcm5l cw0KPiBTZW50OiBUdWVzZGF5LCAxOSBNYXJjaCAyMDEzIDEwOjI1IEFNDQo+IFN1YmplY3Q6IFtq b3NlXSBXZWJDcnlwdG8gZmVlZGJhY2sgb24ga2V5IHdyYXBwaW5nDQo+DQo+IDIuIE1hcmsgV2F0 c29uIChOZXRmbGl4KSBub3RlZCB0aGF0IGlmIHdlIHVzZSBSU0EgZGlyZWN0bHkgdG8gZW5jcnlw dCB3cmFwcGVkIGtleSBvYmplY3RzLCB0aGVuIHdlIHdvdWxkIG5lZWQgc29tZXRoaW5nIG90aGVy IHRoYW4gT0FFUCBpbiBvcmRlciB0byBjYXJyeSBhcmJpdHJhcnktbGVuZ3RoIHBheWxvYWRzLiAg SSBhZ3JlZWQsIGFuZCBzdWdnZXN0ZWQgdGhhdCBzb21ldGhpbmcgbGlrZSBSU0EtS0VNIHdvdWxk IGJlIG5lY2Vzc2FyeS4gIFJ5YW4gU2xlZXZpIChHb29nbGUpIGFuZCBWaWpheSBvYnNlcnZlZCB0 aGF0IEtFTSBpcyB0cm91Ymxlc29tZSBkdWUgdG8gdGhlIGxhY2sgb2Ygc3VwcG9ydCBieSBuYXRp dmUgY3J5cHRvIGxpYnJhcmllcy4NCj4NCj4gUG9pbnQgbnVtYmVyIDIgbGlrZWx5IGFwcGxpZXMg Zm9yIHNvbWUgc2NlbmFyaW9zIG9mIEpXRSwgZXNwZWNpYWxseSBpZiB3ZSBhZG9wdCB0aGUgTWNH cmV3IGFwcHJvYWNoLiAgRm9yIGV4YW1wbGUsIGlmIHVzaW5nIEhNQUMtU0hBMSBhbmQgQUVTIHdp dGggYSAyNTYtYml0IGtleSwgdGhlIHRvdGFsIGtleSBsZW5ndGggaXMgNzg4IGJpdHMsIHdoaWNo IGlzIHRvbyBsb25nIHRvIGJlIGVuY3J5cHRlZCB3aXRoIE9BRVAgdW5kZXIgYSAxLDAyNC1iaXQg UlNBIGtleS4gIEknbSBub3Qgc3VyZSBob3cgdG8gcmVzb2x2ZSBpdC4gIFRoZSBiZXN0IGlkZWEg SSd2ZSBnb3QgaXMgdG8gYWxsb3cgd3JhcHBlZCBrZXlzIHRvIG5lc3QsIHNvIHRoYXQgeW91IGNh biB3cmFwIGEga2V5IGluc2lkZSBvZiBhbm90aGVyIHdyYXBwZWQga2V5Lg0KPg0KPiAtLVJpY2hh cmQNCg0KDQo+PiAtLS0tLS0tLS0tDQo+PiBTZW50OiBUdWVzZGF5LCAxOSBNYXJjaCAyMDEzIDEw OjIzIEFNDQo+PiBTdWJqZWN0OiBbam9zZV0gIzE0OiBTdXBwb3J0IGxvbmdlciB3cmFwcGVkIGtl eXMgdGhhbiBPQUVQIGFsbG93cw0KPj4gDQo+PiAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQg a2V5cyB0aGFuIE9BRVAgYWxsb3dzDQo+PiANCj4+ICBUaGUgdXNlIG9mIFJTQS1PQUVQIGZvciBr ZXkgd3JhcHBpbmcgaW1wb3NlcyBhIGxpbWl0IG9uIHRoZSBsZW5ndGggb2YNCj4+ICB0aGUga2V5 IHBhY2thZ2UgYmVpbmcgd3JhcHBlZC4gV2l0aCBTSEExLCB0aGlzIGxlbmd0aCBpcyBOLTMyMCwg d2hlcmUNCj4+ICBOIGlzIHRoZSBsZW5ndGggb2YgdGhlIFJTQSBtb2R1bHVzLiAgRXNwZWNpYWxs eSB3aXRoIGxhcmdlciBoYXNoDQo+PiAgZnVuY3Rpb25zLCBhbmQgZXNwZWNpYWxseSBmb3Igd3Jh cHBpbmcgcHJpdmF0ZSBrZXlzLCB0aGUgc2l6ZSBvZiBrZXkNCj4+ICBwYWNrYWdlcyB3aWxsIGJl IGxhcmdlciB0aGFuIHRoaXMgYm91bmQuICBXZSBzaG91bGQgaW5jb3Jwb3JhdGUgYQ0KPj4gIG1l Y2hhbmlzbSB0byBhY2NvbW1vZGF0ZSB0aGVzZSBzaXR1YXRpb25zLg0KPj4gDQo+PiANCj4+IFRp Y2tldCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0 LzE0Pg0K From ietf@augustcellars.com Mon Mar 18 17:40:19 2013 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 6339021F89AA for ; Mon, 18 Mar 2013 17:40:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.059, 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 eh4mH7STDDwg for ; Mon, 18 Mar 2013 17:40:18 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6F521F899E for ; Mon, 18 Mar 2013 17:40:18 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 522102CA2B; Mon, 18 Mar 2013 17:40:18 -0700 (PDT) From: "Jim Schaad" To: "'Richard Barnes'" , References: In-Reply-To: Date: Mon, 18 Mar 2013 17:39:30 -0700 Message-ID: <096701ce243a$40a54880$c1efd980$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0968_01CE23FF.94475AE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJp5Fw5bjj7VLaKZ95E+Mj7F7IDmJd0qc/g Content-Language: en-us Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 00:40:19 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0968_01CE23FF.94475AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, March 18, 2013 4:25 PM To: jose@ietf.org Subject: [jose] WebCrypto feedback on key wrapping On today's call with the W3C WebCrypto working group, I reported on the discussion of JOSE key wrapping at the last IETF. I was asked to relay a few bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of favor with some parts of the cryptographic community. People prefer to be able to use AEAD algorithms for key wrapping, since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEEE 802.1 uses AES CCM. [JLS] AES Key Wrap is an AD algorithm and a variant of it exists that is an AEAD algorithm. So this is a case of not correctly using terminology. I would also question the issue of perceived security as with AES-KW every bit of the plain text affects every other bit of plain text in the encryption process and this is not true for AES-GW or AES-CCM. I would agree that there is both a speed advantage and perhaps more importantly the fact that only one side of the AES engine is needed (i.e. you only need to encrypt but not decrypt) for AES CCM and AES-GCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped key objects, then we would need something other than OAEP in order to carry arbitrary-length payloads. I agreed, and suggested that something like RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack of support by native crypto libraries. Note that using RSA-KEM is not using RSA directly. RSA-KEM should be thought of as a single party key agreement algorithm and not a key transport algorithm. You encrypt a large integer and then run a KDF on that large integer to get a key. I perceive no advantage to using RSA-KEM except for the fact that the security on it is more provable. It seems to me that these comments have impacts on JWE and JWS (pending ISSUE-2), as well as the wrapping discussion. The former has more impact than the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as well as for wrapped keys. It seems to me that the simplest approach to this would be to make the "alg" field contain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly the same form that algorithm identifiers have in the WebCrypto API. Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, which is too long to be encrypted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. The best idea I've got is to allow wrapped keys to nest, so that you can wrap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping draft, and I've filed two issues against JWE to track them. --Richard ------=_NextPart_000_0968_01CE23FF.94475AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of = Richard Barnes
Sent: Monday, March 18, 2013 4:25 = PM
To: jose@ietf.org
Subject: [jose] WebCrypto = feedback on key wrapping

 

On today's = call with the W3C WebCrypto working  group, I reported on the = discussion of JOSE key wrapping at the last IETF.  I was asked to = relay a few bits of feedback:

 

1. Vijay Bharadwaj (Microsoft) observed that AES key = wrap has fallen out of favor with some parts of the cryptographic = community.  People prefer to be able to use AEAD algorithms for key = wrapping, since they are perceived to be faster and offer a higher level = of security than AES-KW. He gave the example that IEEE 802.1 uses AES = CCM.

 

[JLS] AES Key Wrap is an AD algorithm and a variant of it exists that = is an AEAD algorithm.  So this is a case of not correctly using = terminology.  I would also question the issue of perceived security = as with AES-KW every bit of the plain text affects every other bit of = plain text in the encryption process and this is not true for AES-GW or = AES-CCM.  I would agree that there is both a speed advantage and = perhaps more importantly the fact that only one side of the AES engine = is needed (i.e. you only need to encrypt but not decrypt) for AES CCM = and AES-GCM.

 

2. Mark Watson (Netflix) noted that if we use RSA = directly to encrypt wrapped key objects, then we would need something = other than OAEP in order to carry arbitrary-length payloads.  I = agreed, and suggested that something like RSA-KEM would be necessary. =  Ryan Sleevi (Google) and Vijay observed that KEM is troublesome = due to the lack of support by native crypto libraries.

 

Note that using RSA-KEM is not using RSA directly.  RSA-KEM = should be thought of as a single party key agreement algorithm and not a = key transport algorithm.  You encrypt a large integer and then run = a KDF on that large integer to get a key.  I perceive no advantage = to using RSA-KEM except for the fact that the security on it is more = provable.

 

It seems to me that these comments have impacts on JWE = and JWS (pending ISSUE-2), as well as the wrapping discussion.  The = former has more impact than the = latter. 

 

Point number 1 implies that we should offer AEAD for = key wrapping in JWE as well as for wrapped keys.  It seems to me = that the simplest approach to this would be to make the "alg" = field contain an object that is semantically equivalent to an = AlgorithmIdentifier in CMS/PKCS8.  For example, { name: = "A128GCM", iv: "PCIGJe0DjunuM7s0" }.  This = syntax, incidentally, is roughly the same form that algorithm = identifiers have in the WebCrypto API.  Note that this type of key = wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier = in the KEKRecipientInfo structure.  

 

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach.  For example, if = using HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 = bits, which is too long to be encrypted with OAEP under a 1,024-bit RSA = key.  I'm not sure how to resolve it.  The best idea I've got = is to allow wrapped keys to nest, so that you can wrap a key inside of = another wrapped key.

 

I = will try to take these points into account in my forthcoming key = wrapping draft, and I've filed two issues against JWE to track = them.

 

--Richard

------=_NextPart_000_0968_01CE23FF.94475AE0-- From ietf@augustcellars.com Mon Mar 18 17:40:37 2013 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 BC40321F8A08 for ; Mon, 18 Mar 2013 17:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.549 X-Spam-Level: X-Spam-Status: No, score=-3.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 Dqfmrnm2yZzO for ; Mon, 18 Mar 2013 17:40:36 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id F12AB21F899E for ; Mon, 18 Mar 2013 17:40:35 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id C55D02CA19; Mon, 18 Mar 2013 17:40:35 -0700 (PDT) From: "Jim Schaad" To: "'Manger, James H'" , , References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BAAC4D8@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BAAC4D8@WSMSG3153V.srv.dir.telstra.com> Date: Mon, 18 Mar 2013 17:40:01 -0700 Message-ID: <096c01ce243a$4b22fb90$e168f2b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJWVlO7IyJW1JDUvtvGkNj7Tdt/eAH0uFjvl4whmnA= Content-Language: en-us Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 00:40:37 -0000 Think in terms of encrypting a JWK directly not an intermediate key. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > Manger, James H > Sent: Monday, March 18, 2013 5:17 PM > To: rlb@ipv.sx; jose@ietf.org > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows > > Richard, > > How do you get a 788-bit key length? > > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 > bits to 512 bits. > > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. > > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. JWA > already says RSA key sizes MUST be at least 2048 bits. > > This already looks sufficient. > > -- > James Manger > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Richard Barnes > > Sent: Tuesday, 19 March 2013 10:25 AM > > Subject: [jose] WebCrypto feedback on key wrapping > > > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapped > key objects, then we would need something other than OAEP in order to carry > arbitrary-length payloads. I agreed, and suggested that something like RSA- > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that KEM is > troublesome due to the lack of support by native crypto libraries. > > > > Point number 2 likely applies for some scenarios of JWE, especially if we > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with > a 256-bit key, the total key length is 788 bits, which is too long to be encrypted > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. The best > idea I've got is to allow wrapped keys to nest, so that you can wrap a key inside > of another wrapped key. > > > > --Richard > > > >> ---------- > >> Sent: Tuesday, 19 March 2013 10:23 AM > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows > >> > >> #14: Support longer wrapped keys than OAEP allows > >> > >> The use of RSA-OAEP for key wrapping imposes a limit on the length > >> of the key package being wrapped. With SHA1, this length is N-320, > >> where N is the length of the RSA modulus. Especially with larger > >> hash functions, and especially for wrapping private keys, the size > >> of key packages will be larger than this bound. We should > >> incorporate a mechanism to accommodate these situations. > >> > >> > >> Ticket URL: > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From rlb@ipv.sx Mon Mar 18 19:31:03 2013 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 D01C321F8F2F for ; Mon, 18 Mar 2013 19:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 JGXNwVCF0LQo for ; Mon, 18 Mar 2013 19:31:03 -0700 (PDT) Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id EF88421F8EFC for ; Mon, 18 Mar 2013 19:31:02 -0700 (PDT) Received: by mail-oa0-f47.google.com with SMTP id o17so6323715oag.6 for ; Mon, 18 Mar 2013 19:31:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=lBIk5stfWeVgUkhH0nDpMRwZeWZHcZy17UFtlUxvw8U=; b=UN+nODSuIedF9eL7q9FuCGkFq56PhKNBEYumukpA89JgXdeyOqVZvpNRzIUPyQKDx/ AThKTbUeUctSuyjwisKb+X+oDONpKhJ69KCbUXt+1dCnW+eLegvz+svnfT7dOuo1XENf wYGHxkWeU2ywffHh8STBUd5SIfFu0GxiIQyPDgX0DTQ6cVVyyST7EHEYVk+QsirlE29h 4eEJ88P9dbFaNb0fD3LFqEgOpHZabTLfHU8QAFIUdzOqB74Jc0+TTKKMHEiP1LRkHbW1 Wz5LEPa2LY+SDNpjYBVyphzk+ECaB2/8zZKl6lQv/dJSpyXGLbAeDhrk2lpwwwi7GaJ+ I6UQ== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr171011oec.126.1363660262457; Mon, 18 Mar 2013 19:31:02 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 19:31:02 -0700 (PDT) X-Originating-IP: [128.89.254.222] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 18 Mar 2013 22:31:02 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec54fae4889d99704d83de5cb X-Gm-Message-State: ALoCoQlISsitxjp1XOW2Tf6xEHoS/wbZbMnO75ORiyfCCWDP8wLzHQrU/iwHrRa0nNGNV4quBMVA Cc: "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 02:31:03 -0000 --bcaec54fae4889d99704d83de5cb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable ISSUE-(n+1): Remove silly restriction on key sizes. We're a formatting working group, not a crypto parameters working group. --Richard On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones wr= ote: > Given that we require RSA keys to be a minimum of 2048 bits in length, > there=92s no problem wrapping 768 bit keys with OAEP in practice.**** > > ** ** > > -- Mike**= * > * > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, March 18, 2013 4:25 PM > *To:* jose@ietf.org > *Subject:* [jose] WebCrypto feedback on key wrapping**** > > ** ** > > On today's call with the W3C WebCrypto working group, I reported on the > discussion of JOSE key wrapping at the last IETF. I was asked to relay a > few bits of feedback:**** > > ** ** > > 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out > of favor with some parts of the cryptographic community. People prefer t= o > be able to use AEAD algorithms for key wrapping, since they are perceived > to be faster and offer a higher level of security than AES-KW. He gave th= e > example that IEEE 802.1 uses AES CCM.**** > > ** ** > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt > wrapped key objects, then we would need something other than OAEP in orde= r > to carry arbitrary-length payloads. I agreed, and suggested that somethi= ng > like RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed > that KEM is troublesome due to the lack of support by native crypto > libraries.**** > > ** ** > > It seems to me that these comments have impacts on JWE and JWS (pending > ISSUE-2), as well as the wrapping discussion. The former has more impact > than the latter. **** > > ** ** > > Point number 1 implies that we should offer AEAD for key wrapping in JWE > as well as for wrapped keys. It seems to me that the simplest approach t= o > this would be to make the "alg" field contain an object that is > semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. For > example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, > incidentally, is roughly the same form that algorithm identifiers have in > the WebCrypto API. Note that this type of key wrapping is supported in C= MS > by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo > structure. **** > > ** ** > > Point number 2 likely applies for some scenarios of JWE, especially if we > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with = a > 256-bit key, the total key length is 788 bits, which is too long to be > encrypted with OAEP under a 1,024-bit RSA key. I'm not sure how to resol= ve > it. The best idea I've got is to allow wrapped keys to nest, so that you > can wrap a key inside of another wrapped key.**** > > ** ** > > I will try to take these points into account in my forthcoming key > wrapping draft, and I've filed two issues against JWE to track them.**** > > ** ** > > --Richard**** > --bcaec54fae4889d99704d83de5cb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable ISSUE-(n+1): Remove silly restriction on key sizes. =A0We're a formatti= ng working group, not a crypto parameters working group.

--Richard


On Mon, Mar 18, 201= 3 at 8:02 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

Given that we require RSA= keys to be a minimum of 2048 bits in length, there=92s no problem wrapping= 768 bit keys with OAEP in practice.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 18, 2013 4:25 PM
To: jose@ietf.org=
Subject: [jose] WebCrypto feedback on key wrapping

=A0

On today's call with the W3C WebCrypto working = =A0group, I reported on the discussion of JOSE key wrapping at the last IET= F. =A0I was asked to relay a few bits of feedback:

=A0

1. Vijay Bharadwaj (Microsoft) observed that AES key= wrap has fallen out of favor with some parts of the cryptographic communit= y. =A0People prefer to be able to use AEAD algorithms for key wrapping, sin= ce they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEE= E 802.1 uses AES CCM.

=A0

2. Mark Watson (Netflix) noted that if we use RSA di= rectly to encrypt wrapped key objects, then we would need something other t= han OAEP in order to carry arbitrary-length payloads. =A0I agreed, and sugg= ested that something like RSA-KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed that KEM is troub= lesome due to the lack of support by native crypto libraries.=

=A0

It seems to me that these comments have impacts on J= WE and JWS (pending ISSUE-2), as well as the wrapping discussion. =A0The fo= rmer has more impact than the latter.=A0

=A0

Point number 1 implies that we should offer AEAD for= key wrapping in JWE as well as for wrapped keys. =A0It seems to me that th= e simplest approach to this would be to make the "alg" field cont= ain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. =A0For example, { name: "A128= GCM", iv: "PCIGJe0DjunuM7s0" }. =A0This syntax, incidentally= , is roughly the same form that algorithm identifiers have in the WebCrypto= API. =A0Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo s= tructure. =A0

=A0

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach. =A0For example, if using H= MAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, whic= h is too long to be encrypted with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolve it. =A0The b= est idea I've got is to allow wrapped keys to nest, so that you can wra= p a key inside of another wrapped key.

=A0

I will try to take these points into account in my f= orthcoming key wrapping draft, and I've filed two issues against JWE to= track them.

=A0

--Richard


--bcaec54fae4889d99704d83de5cb-- From rlb@ipv.sx Mon Mar 18 19:35:49 2013 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 E5D8B21F856D for ; Mon, 18 Mar 2013 19:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 QYJNPis4Cy+s for ; Mon, 18 Mar 2013 19:35:49 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE5221F8521 for ; Mon, 18 Mar 2013 19:35:39 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so6445282oag.12 for ; Mon, 18 Mar 2013 19:35:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=OMY6J7wtOkVFVoZxr+SVwjvRkP11HRrm8QX63da9Cwc=; b=KOL1qwKZa8VPdmlzVLwV6KAgBFpfX6AG39/TT5L4BSfaUPcLzsVclxdMO39O1vOdPP bIZluj34N2mYcp6CA0lussKcTNQ1eIUEmW9JeArX1wk6n4QV8mtl9PO8feGgZ6utQQtO TChuxnZNSdQgC+IAGGNTzOnB26Y4ChdMN83cEjQMde+im/VBodokhv5r2SbDnvm0ANIa ZUQBK7j65ze0XA1wgMPMtMkY+PcTwDaFxRBfh6pYoED2aozmP/U8F3F4d7VCC53o/j+6 eGQfWIoVfTJj3UQNQkvy3KXoddh0Sdsg6DRdXA/yosH8nvSGjCu0gYxxdFAGADYpH+7P VnlA== MIME-Version: 1.0 X-Received: by 10.182.8.70 with SMTP id p6mr177076oba.90.1363660539070; Mon, 18 Mar 2013 19:35:39 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Mon, 18 Mar 2013 19:35:38 -0700 (PDT) X-Originating-IP: [128.89.254.222] In-Reply-To: <096c01ce243a$4b22fb90$e168f2b0$@augustcellars.com> References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BAAC4D8@WSMSG3153V.srv.dir.telstra.com> <096c01ce243a$4b22fb90$e168f2b0$@augustcellars.com> Date: Mon, 18 Mar 2013 22:35:38 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d0444ea4106edd004d83df627 X-Gm-Message-State: ALoCoQm3dWQcomtCqKhPgzc4BUOUZ/RQRsQd6lu9x7R8ZdEsjZHtANjs+Tdy0t+gDkqIaUz97QSo Cc: "Manger, James H" , jose@ietf.org Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 02:35:50 -0000 --f46d0444ea4106edd004d83df627 Content-Type: text/plain; charset=ISO-8859-1 Well, I got to 788 by doing math incorrectly*. Mike was correct on the other thread that 768 is the right number. However, that's still too big for a 1024-bit RSA key and SHA1, since 768 + 320 = 1088 > 1024. Regardless, there is clearly an issue here when wrapping a JWK, which is much larger, possibly containing an RSA key itself. So if we accept the goal that there should be one way of encrypting keys, then we'll need to deal with getting around the OAEP size limitations. --Richard * This is why my degree is in mathematics, and not accounting. On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad wrote: > Think in terms of encrypting a JWK directly not an intermediate key. > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > Manger, James H > > Sent: Monday, March 18, 2013 5:17 PM > > To: rlb@ipv.sx; jose@ietf.org > > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows > > > > Richard, > > > > How do you get a 788-bit key length? > > > > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- > > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 > > bits to 512 bits. > > > > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and > > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. > > > > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. > JWA > > already says RSA key sizes MUST be at least 2048 bits. > > > > This already looks sufficient. > > > > -- > > James Manger > > > > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > > Of Richard Barnes > > > Sent: Tuesday, 19 March 2013 10:25 AM > > > Subject: [jose] WebCrypto feedback on key wrapping > > > > > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt > wrapped > > key objects, then we would need something other than OAEP in order to > carry > > arbitrary-length payloads. I agreed, and suggested that something like > RSA- > > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that KEM > is > > troublesome due to the lack of support by native crypto libraries. > > > > > > Point number 2 likely applies for some scenarios of JWE, especially if > we > > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with > > a 256-bit key, the total key length is 788 bits, which is too long to be > encrypted > > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. > The > best > > idea I've got is to allow wrapped keys to nest, so that you can wrap a > key > inside > > of another wrapped key. > > > > > > --Richard > > > > > > >> ---------- > > >> Sent: Tuesday, 19 March 2013 10:23 AM > > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows > > >> > > >> #14: Support longer wrapped keys than OAEP allows > > >> > > >> The use of RSA-OAEP for key wrapping imposes a limit on the length > > >> of the key package being wrapped. With SHA1, this length is N-320, > > >> where N is the length of the RSA modulus. Especially with larger > > >> hash functions, and especially for wrapping private keys, the size > > >> of key packages will be larger than this bound. We should > > >> incorporate a mechanism to accommodate these situations. > > >> > > >> > > >> Ticket URL: > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --f46d0444ea4106edd004d83df627 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Well, I got to 788 by doing math incorrectly*.=A0

Mike w= as correct on the other thread that 768 is the right number. =A0However, th= at's still too big for a 1024-bit RSA key and SHA1, since 768 + 320 =3D= 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a J= WK, which is much larger, possibly containing an RSA key itself. =A0So if w= e accept the goal that there should be one way of encrypting keys, then we&= #39;ll need to deal with getting around the OAEP size limitations.

--Richard

* This is why my degree is in mathemat= ics, and not accounting.


On Mon, Mar = 18, 2013 at 8:40 PM, Jim Schaad <ietf@augustcellars.com> wrote:
Think in terms of encrypting a JWK directly = not an intermediate key.

> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: rlb@ipv.sx; jose@ietf.org
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows<= br> >
> Richard,
>
> How do you get a 788-bit key length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 25= 6
> bits to 512 bits.
>
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key= .
JWA
> already says RSA key sizes MUST be at least 2048 bits.
>
> This already looks sufficient.
>
> --
> James Manger
>
>
> > From: jose-bounces@ietf.= org [mailto:jose-bounces@ietf.= org] On Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on key wrapping
> >
> > 2. Mark Watson (Netflix) noted that if we use RSA directly to enc= rypt
wrapped
> key objects, then we would need something other than OAEP in order to<= br> carry
> arbitrary-length payloads. =A0I agreed, and suggested that something l= ike
RSA-
> KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed tha= t KEM
is
> troublesome due to the lack of support by native crypto libraries.
> >
> > Point number 2 likely applies for some scenarios of JWE, especial= ly if
we
> adopt the McGrew approach. =A0For example, if using HMAC-SHA1 and AES = with
> a 256-bit key, the total key length is 788 bits, which is too long to = be
encrypted
> with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolv= e it. =A0The
best
> idea I've got is to allow wrapped keys to nest, so that you can wr= ap a key
inside
> of another wrapped key.
> >
> > --Richard
>
>
> >> ----------
> >> Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] #14: Support longer wrapped keys than OAEP al= lows
> >>
> >> #14: Support longer wrapped keys than OAEP allows
> >>
> >> =A0The use of RSA-OAEP for key wrapping imposes a limit on th= e length
> >> of =A0the key package being wrapped. With SHA1, this length i= s N-320,
> >> where =A0N is the length of the RSA modulus. =A0Especially wi= th larger
> >> hash =A0functions, and especially for wrapping private keys, = the size
> >> of key =A0packages will be larger than this bound. =A0We shou= ld
> >> incorporate a =A0mechanism to accommodate these situations. > >>
> >>
> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/= ticket/14>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


--f46d0444ea4106edd004d83df627-- From James.H.Manger@team.telstra.com Mon Mar 18 20:23:58 2013 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 54B6221F8613 for ; Mon, 18 Mar 2013 20:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 9nGWOA7pu2Xj for ; Mon, 18 Mar 2013 20:23:57 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 8B24121F860B for ; Mon, 18 Mar 2013 20:23:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,868,1355058000"; d="scan'208,217";a="124018819" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipoavi.tcif.telstra.com.au with ESMTP; 19 Mar 2013 14:23:49 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7018"; a="119748609" Received: from wsmsg3705.srv.dir.telstra.com ([172.49.40.203]) by ipccvi.tcif.telstra.com.au with ESMTP; 19 Mar 2013 14:23:49 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3705.srv.dir.telstra.com ([172.49.40.203]) with mapi; Tue, 19 Mar 2013 14:23:48 +1100 From: "Manger, James H" To: Richard Barnes , Jim Schaad Date: Tue, 19 Mar 2013 14:23:47 +1100 Thread-Topic: [jose] #14: Support longer wrapped keys than OAEP allows Thread-Index: Ac4kSnNicfSOfT3iSRSNjR/kV+qFtAAABMag Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BB430EE@WSMSG3153V.srv.dir.telstra.com> References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BAAC4D8@WSMSG3153V.srv.dir.telstra.com> <096c01ce243a$4b22fb90$e168f2b0$@augustcellars.com> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150BB430EEWSMSG3153Vsrv_" MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 03:23:58 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150BB430EEWSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 NzY4IGlzIGFsc28gdGhlIHdyb25nIG51bWJlciwgd2hpY2ggaXMgYW5vdGhlciByZWFzb24gdG8g dXNlIGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGluc3RlYWQgb2YgdGhlIEpP U0Utc3BlY2lmaWMgQUVBRCBjb25zdHJ1Y3Rpb24gKGJldHRlciBrZXkgc2l6ZSBjaG9pY2VzKS4g QnV0IHRoYXQgaXNu4oCZdCB0aGUgbWFpbiBpc3N1ZS4NCg0KPiBTbyBpZiB3ZSBhY2NlcHQgdGhl IGdvYWwgdGhhdCB0aGVyZSBzaG91bGQgYmUgb25lIHdheSBvZiBlbmNyeXB0aW5nIGtleXMNCg0K SGF2aW5nIG9uZSB3YXkgb2YgZW5jcnlwdGluZyBlcGhlbWVyYWwgcmF3IHN5bW1ldHJpYyBzZXNz aW9uIGtleXMgc291bmRzIGxpa2UgYSBkZWNlbnQgZ29hbC4NCknigJltIGZhciBmcm9tIGNlcnRh aW4gdGhhdCBleHRlbmRpbmcgdGhhdCB0byBhc3ltbWV0cmljIGtleXMgYW5kIHRoZWlyIG1ldGFk YXRhIChzdWNoIGFzIGNlcnRzKSBpcyBhIHNlbnNpYmxlIGdvYWwuDQoNCi0tDQpKYW1lcyBNYW5n ZXINCg0KRnJvbTogUmljaGFyZCBCYXJuZXMgW21haWx0bzpybGJAaXB2LnN4XQ0KU2VudDogVHVl c2RheSwgMTkgTWFyY2ggMjAxMyAxOjM2IFBNDQpUbzogSmltIFNjaGFhZA0KQ2M6IE1hbmdlciwg SmFtZXMgSDsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtqb3NlXSAjMTQ6IFN1cHBvcnQg bG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzDQoNCldlbGwsIEkgZ290IHRvIDc4 OCBieSBkb2luZyBtYXRoIGluY29ycmVjdGx5Ki4NCg0KTWlrZSB3YXMgY29ycmVjdCBvbiB0aGUg b3RoZXIgdGhyZWFkIHRoYXQgNzY4IGlzIHRoZSByaWdodCBudW1iZXIuICBIb3dldmVyLCB0aGF0 J3Mgc3RpbGwgdG9vIGJpZyBmb3IgYSAxMDI0LWJpdCBSU0Ega2V5IGFuZCBTSEExLCBzaW5jZSA3 NjggKyAzMjAgPSAxMDg4ID4gMTAyNC4NCg0KUmVnYXJkbGVzcywgdGhlcmUgaXMgY2xlYXJseSBh biBpc3N1ZSBoZXJlIHdoZW4gd3JhcHBpbmcgYSBKV0ssIHdoaWNoIGlzIG11Y2ggbGFyZ2VyLCBw b3NzaWJseSBjb250YWluaW5nIGFuIFJTQSBrZXkgaXRzZWxmLiAgU28gaWYgd2UgYWNjZXB0IHRo ZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSB3YXkgb2YgZW5jcnlwdGluZyBrZXlzLCB0 aGVuIHdlJ2xsIG5lZWQgdG8gZGVhbCB3aXRoIGdldHRpbmcgYXJvdW5kIHRoZSBPQUVQIHNpemUg bGltaXRhdGlvbnMuDQoNCi0tUmljaGFyZA0KDQoqIFRoaXMgaXMgd2h5IG15IGRlZ3JlZSBpcyBp biBtYXRoZW1hdGljcywgYW5kIG5vdCBhY2NvdW50aW5nLg0KDQpPbiBNb24sIE1hciAxOCwgMjAx MyBhdCA4OjQwIFBNLCBKaW0gU2NoYWFkIDxpZXRmQGF1Z3VzdGNlbGxhcnMuY29tPG1haWx0bzpp ZXRmQGF1Z3VzdGNlbGxhcnMuY29tPj4gd3JvdGU6DQpUaGluayBpbiB0ZXJtcyBvZiBlbmNyeXB0 aW5nIGEgSldLIGRpcmVjdGx5IG5vdCBhbiBpbnRlcm1lZGlhdGUga2V5Lg0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWls dG86am9zZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+IE1hbmdlciwgSmFtZXMg SA0KPiBTZW50OiBNb25kYXksIE1hcmNoIDE4LCAyMDEzIDU6MTcgUE0NCj4gVG86IHJsYkBpcHYu c3g8bWFpbHRvOnJsYkBpcHYuc3g+OyBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3Jn Pg0KPiBTdWJqZWN0OiBSZTogW2pvc2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlz IHRoYW4gT0FFUCBhbGxvd3MNCj4NCj4gUmljaGFyZCwNCj4NCj4gSG93IGRvIHlvdSBnZXQgYSA3 ODgtYml0IGtleSBsZW5ndGg/DQo+DQo+IGRyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1z aGEyIGRlZmluZXMgNSBjb21iaW5hdGlvbnMgb2YgQUVTLQ0KPiAxMjgvMTkyLzI1NiBhbmQgU0hB LTEvMjU2LzM4NC81MTIuIFRoZSB0b3RhbCBrZXkgbGVuZ3RocyByYW5nZSBmcm9tIDI1Ng0KPiBi aXRzIHRvIDUxMiBiaXRzLg0KPg0KPiBLZXlzIGZvciB0d28gb2YgdGhlIGFsZ29yaXRobXMgKEFF QURfQUVTXzEyOF9DQkNfSE1BQ19TSEFfMjU2IGFuZA0KPiBBRUFEX0FFU18xMjhfQ0JDX0hNQUNf U0hBMSkgZml0IHdpdGhpbiBPQUVQIHdpdGggYSAxMDI0LWJpdCBSU0Ega2V5Lg0KPg0KPiBLZXlz IGZvciBhbGwgb2YgdGhlIGFsZ29yaXRobXMgZml0IHdpdGhpbiBPQUVQIHdpdGggYSAyMDQ4LWJp dCBSU0Ega2V5Lg0KSldBDQo+IGFscmVhZHkgc2F5cyBSU0Ega2V5IHNpemVzIE1VU1QgYmUgYXQg bGVhc3QgMjA0OCBiaXRzLg0KPg0KPiBUaGlzIGFscmVhZHkgbG9va3Mgc3VmZmljaWVudC4NCj4N Cj4gLS0NCj4gSmFtZXMgTWFuZ2VyDQo+DQo+DQo+ID4gRnJvbTogam9zZS1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9zZS1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYNCj4gPiBPZiBS aWNoYXJkIEJhcm5lcw0KPiA+IFNlbnQ6IFR1ZXNkYXksIDE5IE1hcmNoIDIwMTMgMTA6MjUgQU0N Cj4gPiBTdWJqZWN0OiBbam9zZV0gV2ViQ3J5cHRvIGZlZWRiYWNrIG9uIGtleSB3cmFwcGluZw0K PiA+DQo+ID4gMi4gTWFyayBXYXRzb24gKE5ldGZsaXgpIG5vdGVkIHRoYXQgaWYgd2UgdXNlIFJT QSBkaXJlY3RseSB0byBlbmNyeXB0DQp3cmFwcGVkDQo+IGtleSBvYmplY3RzLCB0aGVuIHdlIHdv dWxkIG5lZWQgc29tZXRoaW5nIG90aGVyIHRoYW4gT0FFUCBpbiBvcmRlciB0bw0KY2FycnkNCj4g YXJiaXRyYXJ5LWxlbmd0aCBwYXlsb2Fkcy4gIEkgYWdyZWVkLCBhbmQgc3VnZ2VzdGVkIHRoYXQg c29tZXRoaW5nIGxpa2UNClJTQS0NCj4gS0VNIHdvdWxkIGJlIG5lY2Vzc2FyeS4gIFJ5YW4gU2xl ZXZpIChHb29nbGUpIGFuZCBWaWpheSBvYnNlcnZlZCB0aGF0IEtFTQ0KaXMNCj4gdHJvdWJsZXNv bWUgZHVlIHRvIHRoZSBsYWNrIG9mIHN1cHBvcnQgYnkgbmF0aXZlIGNyeXB0byBsaWJyYXJpZXMu DQo+ID4NCj4gPiBQb2ludCBudW1iZXIgMiBsaWtlbHkgYXBwbGllcyBmb3Igc29tZSBzY2VuYXJp b3Mgb2YgSldFLCBlc3BlY2lhbGx5IGlmDQp3ZQ0KPiBhZG9wdCB0aGUgTWNHcmV3IGFwcHJvYWNo LiAgRm9yIGV4YW1wbGUsIGlmIHVzaW5nIEhNQUMtU0hBMSBhbmQgQUVTIHdpdGgNCj4gYSAyNTYt Yml0IGtleSwgdGhlIHRvdGFsIGtleSBsZW5ndGggaXMgNzg4IGJpdHMsIHdoaWNoIGlzIHRvbyBs b25nIHRvIGJlDQplbmNyeXB0ZWQNCj4gd2l0aCBPQUVQIHVuZGVyIGEgMSwwMjQtYml0IFJTQSBr ZXkuICBJJ20gbm90IHN1cmUgaG93IHRvIHJlc29sdmUgaXQuICBUaGUNCmJlc3QNCj4gaWRlYSBJ J3ZlIGdvdCBpcyB0byBhbGxvdyB3cmFwcGVkIGtleXMgdG8gbmVzdCwgc28gdGhhdCB5b3UgY2Fu IHdyYXAgYSBrZXkNCmluc2lkZQ0KPiBvZiBhbm90aGVyIHdyYXBwZWQga2V5Lg0KPiA+DQo+ID4g LS1SaWNoYXJkDQo+DQo+DQo+ID4+IC0tLS0tLS0tLS0NCj4gPj4gU2VudDogVHVlc2RheSwgMTkg TWFyY2ggMjAxMyAxMDoyMyBBTQ0KPiA+PiBTdWJqZWN0OiBbam9zZV0gIzE0OiBTdXBwb3J0IGxv bmdlciB3cmFwcGVkIGtleXMgdGhhbiBPQUVQIGFsbG93cw0KPiA+Pg0KPiA+PiAjMTQ6IFN1cHBv cnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzDQo+ID4+DQo+ID4+ICBUaGUg dXNlIG9mIFJTQS1PQUVQIGZvciBrZXkgd3JhcHBpbmcgaW1wb3NlcyBhIGxpbWl0IG9uIHRoZSBs ZW5ndGgNCj4gPj4gb2YgIHRoZSBrZXkgcGFja2FnZSBiZWluZyB3cmFwcGVkLiBXaXRoIFNIQTEs IHRoaXMgbGVuZ3RoIGlzIE4tMzIwLA0KPiA+PiB3aGVyZSAgTiBpcyB0aGUgbGVuZ3RoIG9mIHRo ZSBSU0EgbW9kdWx1cy4gIEVzcGVjaWFsbHkgd2l0aCBsYXJnZXINCj4gPj4gaGFzaCAgZnVuY3Rp b25zLCBhbmQgZXNwZWNpYWxseSBmb3Igd3JhcHBpbmcgcHJpdmF0ZSBrZXlzLCB0aGUgc2l6ZQ0K PiA+PiBvZiBrZXkgIHBhY2thZ2VzIHdpbGwgYmUgbGFyZ2VyIHRoYW4gdGhpcyBib3VuZC4gIFdl IHNob3VsZA0KPiA+PiBpbmNvcnBvcmF0ZSBhICBtZWNoYW5pc20gdG8gYWNjb21tb2RhdGUgdGhl c2Ugc2l0dWF0aW9ucy4NCj4gPj4NCj4gPj4NCj4gPj4gVGlja2V0IFVSTDogPGh0dHA6Ly90cmFj LnRvb2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMTQ+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGpvc2UgbWFpbGluZyBsaXN0DQo+ IGpvc2VAaWV0Zi5vcmc8bWFpbHRvOmpvc2VAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150BB430EEWSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjc2OCBpcyBhbHNvIHRoZSB3cm9u ZyBudW1iZXIsIHdoaWNoIGlzIGFub3RoZXIgcmVhc29uIHRvIHVzZSBkcmFmdC1tY2dyZXctYWVh ZC1hZXMtY2JjLWhtYWMtc2hhMiBpbnN0ZWFkIG9mIHRoZSBKT1NFLXNwZWNpZmljIEFFQUQgY29u c3RydWN0aW9uIChiZXR0ZXIga2V5IHNpemUgY2hvaWNlcykuIEJ1dCB0aGF0IGlzbuKAmXQgdGhl IG1haW4gaXNzdWUuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4mZ3Q7IDwvc3Bhbj5TbyBpZiB3ZSBhY2Nl cHQgdGhlIGdvYWwgdGhhdCB0aGVyZSBzaG91bGQgYmUgb25lIHdheSBvZiBlbmNyeXB0aW5nIGtl eXM8c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGF2aW5nIG9uZSB3 YXkgb2YgZW5jcnlwdGluZyBlcGhlbWVyYWwgcmF3IHN5bW1ldHJpYyBzZXNzaW9uIGtleXMgc291 bmRzIGxpa2UgYSBkZWNlbnQgZ29hbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SeKAmW0gZmFyIGZyb20gY2VydGFpbiB0aGF0 IGV4dGVuZGluZyB0aGF0IHRvIGFzeW1tZXRyaWMga2V5cyBhbmQgdGhlaXIgbWV0YWRhdGEgKHN1 Y2ggYXMgY2VydHMpIGlzIGEgc2Vuc2libGUgZ29hbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86 cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5 N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1N c29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmxiQGlwdi5zeF0gPGJyPjxiPlNlbnQ6 PC9iPiBUdWVzZGF5LCAxOSBNYXJjaCAyMDEzIDE6MzYgUE08YnI+PGI+VG86PC9iPiBKaW0gU2No YWFkPGJyPjxiPkNjOjwvYj4gTWFuZ2VyLCBKYW1lcyBIOyBqb3NlQGlldGYub3JnPGJyPjxiPlN1 YmplY3Q6PC9iPiBSZTogW2pvc2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRo YW4gT0FFUCBhbGxvd3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD5XZWxsLCBJ IGdvdCB0byA3ODggYnkgZG9pbmcgbWF0aCBpbmNvcnJlY3RseSouJm5ic3A7PG86cD48L286cD48 L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRp dj48cCBjbGFzcz1Nc29Ob3JtYWw+TWlrZSB3YXMgY29ycmVjdCBvbiB0aGUgb3RoZXIgdGhyZWFk IHRoYXQgNzY4IGlzIHRoZSByaWdodCBudW1iZXIuICZuYnNwO0hvd2V2ZXIsIHRoYXQncyBzdGls bCB0b28gYmlnIGZvciBhIDEwMjQtYml0IFJTQSBrZXkgYW5kIFNIQTEsIHNpbmNlIDc2OCArIDMy MCA9IDEwODggJmd0OyAxMDI0LjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlJlZ2Fy ZGxlc3MsIHRoZXJlIGlzIGNsZWFybHkgYW4gaXNzdWUgaGVyZSB3aGVuIHdyYXBwaW5nIGEgSldL LCB3aGljaCBpcyBtdWNoIGxhcmdlciwgcG9zc2libHkgY29udGFpbmluZyBhbiBSU0Ega2V5IGl0 c2VsZi4gJm5ic3A7U28gaWYgd2UgYWNjZXB0IHRoZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJl IG9uZSB3YXkgb2YgZW5jcnlwdGluZyBrZXlzLCB0aGVuIHdlJ2xsIG5lZWQgdG8gZGVhbCB3aXRo IGdldHRpbmcgYXJvdW5kIHRoZSBPQUVQIHNpemUgbGltaXRhdGlvbnMuPG86cD48L286cD48L3A+ PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz4tLVJp Y2hhcmQ8YnI+PGJyPiogVGhpcyBpcyB3aHkgbXkgZGVncmVlIGlzIGluIG1hdGhlbWF0aWNzLCBh bmQgbm90IGFjY291bnRpbmcuPGJyPjxicj48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1z b05vcm1hbD5PbiBNb24sIE1hciAxOCwgMjAxMyBhdCA4OjQwIFBNLCBKaW0gU2NoYWFkICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmll dGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+VGhpbmsgaW4gdGVybXMgb2YgZW5jcnlwdGluZyBhIEpXSyBkaXJlY3RseSBu b3QgYW4gaW50ZXJtZWRpYXRlIGtleS48bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48YnI+Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4mZ3Q7IEZyb206IDxh IGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9y ZzwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3Nl LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8bzpwPjwvbzpwPjwvcD48L2Rpdj48 ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPiZndDsgTWFuZ2VyLCBKYW1lcyBIPGJyPiZndDsg U2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA1OjE3IFBNPGJyPiZndDsgVG86IDxhIGhyZWY9 Im1haWx0bzpybGJAaXB2LnN4Ij5ybGJAaXB2LnN4PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmpvc2VA aWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPiZndDsgU3ViamVjdDogUmU6IFtqb3NlXSAj MTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzPGJyPiZndDs8 YnI+Jmd0OyBSaWNoYXJkLDxicj4mZ3Q7PGJyPiZndDsgSG93IGRvIHlvdSBnZXQgYSA3ODgtYml0 IGtleSBsZW5ndGg/PGJyPiZndDs8YnI+Jmd0OyBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWht YWMtc2hhMiBkZWZpbmVzIDUgY29tYmluYXRpb25zIG9mIEFFUy08YnI+Jmd0OyAxMjgvMTkyLzI1 NiBhbmQgU0hBLTEvMjU2LzM4NC81MTIuIFRoZSB0b3RhbCBrZXkgbGVuZ3RocyByYW5nZSBmcm9t IDI1Njxicj4mZ3Q7IGJpdHMgdG8gNTEyIGJpdHMuPGJyPiZndDs8YnI+Jmd0OyBLZXlzIGZvciB0 d28gb2YgdGhlIGFsZ29yaXRobXMgKEFFQURfQUVTXzEyOF9DQkNfSE1BQ19TSEFfMjU2IGFuZDxi cj4mZ3Q7IEFFQURfQUVTXzEyOF9DQkNfSE1BQ19TSEExKSBmaXQgd2l0aGluIE9BRVAgd2l0aCBh IDEwMjQtYml0IFJTQSBrZXkuPGJyPiZndDs8YnI+Jmd0OyBLZXlzIGZvciBhbGwgb2YgdGhlIGFs Z29yaXRobXMgZml0IHdpdGhpbiBPQUVQIHdpdGggYSAyMDQ4LWJpdCBSU0Ega2V5Ljxicj5KV0E8 YnI+Jmd0OyBhbHJlYWR5IHNheXMgUlNBIGtleSBzaXplcyBNVVNUIGJlIGF0IGxlYXN0IDIwNDgg Yml0cy48YnI+Jmd0Ozxicj4mZ3Q7IFRoaXMgYWxyZWFkeSBsb29rcyBzdWZmaWNpZW50Ljxicj4m Z3Q7PGJyPiZndDsgLS08YnI+Jmd0OyBKYW1lcyBNYW5nZXI8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZn dDsgJmd0OyBGcm9tOiA8YSBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3Nl LWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNl c0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmPGJyPiZndDsg Jmd0OyBPZiBSaWNoYXJkIEJhcm5lczxicj4mZ3Q7ICZndDsgU2VudDogVHVlc2RheSwgMTkgTWFy Y2ggMjAxMyAxMDoyNSBBTTxicj4mZ3Q7ICZndDsgU3ViamVjdDogW2pvc2VdIFdlYkNyeXB0byBm ZWVkYmFjayBvbiBrZXkgd3JhcHBpbmc8YnI+Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAyLiBNYXJr IFdhdHNvbiAoTmV0ZmxpeCkgbm90ZWQgdGhhdCBpZiB3ZSB1c2UgUlNBIGRpcmVjdGx5IHRvIGVu Y3J5cHQ8YnI+d3JhcHBlZDxicj4mZ3Q7IGtleSBvYmplY3RzLCB0aGVuIHdlIHdvdWxkIG5lZWQg c29tZXRoaW5nIG90aGVyIHRoYW4gT0FFUCBpbiBvcmRlciB0bzxicj5jYXJyeTxicj4mZ3Q7IGFy Yml0cmFyeS1sZW5ndGggcGF5bG9hZHMuICZuYnNwO0kgYWdyZWVkLCBhbmQgc3VnZ2VzdGVkIHRo YXQgc29tZXRoaW5nIGxpa2U8YnI+UlNBLTxicj4mZ3Q7IEtFTSB3b3VsZCBiZSBuZWNlc3Nhcnku ICZuYnNwO1J5YW4gU2xlZXZpIChHb29nbGUpIGFuZCBWaWpheSBvYnNlcnZlZCB0aGF0IEtFTTxi cj5pczxicj4mZ3Q7IHRyb3VibGVzb21lIGR1ZSB0byB0aGUgbGFjayBvZiBzdXBwb3J0IGJ5IG5h dGl2ZSBjcnlwdG8gbGlicmFyaWVzLjxicj4mZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7IFBvaW50IG51 bWJlciAyIGxpa2VseSBhcHBsaWVzIGZvciBzb21lIHNjZW5hcmlvcyBvZiBKV0UsIGVzcGVjaWFs bHkgaWY8YnI+d2U8YnI+Jmd0OyBhZG9wdCB0aGUgTWNHcmV3IGFwcHJvYWNoLiAmbmJzcDtGb3Ig ZXhhbXBsZSwgaWYgdXNpbmcgSE1BQy1TSEExIGFuZCBBRVMgd2l0aDxicj4mZ3Q7IGEgMjU2LWJp dCBrZXksIHRoZSB0b3RhbCBrZXkgbGVuZ3RoIGlzIDc4OCBiaXRzLCB3aGljaCBpcyB0b28gbG9u ZyB0byBiZTxicj5lbmNyeXB0ZWQ8YnI+Jmd0OyB3aXRoIE9BRVAgdW5kZXIgYSAxLDAyNC1iaXQg UlNBIGtleS4gJm5ic3A7SSdtIG5vdCBzdXJlIGhvdyB0byByZXNvbHZlIGl0LiAmbmJzcDtUaGU8 YnI+YmVzdDxicj4mZ3Q7IGlkZWEgSSd2ZSBnb3QgaXMgdG8gYWxsb3cgd3JhcHBlZCBrZXlzIHRv IG5lc3QsIHNvIHRoYXQgeW91IGNhbiB3cmFwIGEga2V5PGJyPmluc2lkZTxicj4mZ3Q7IG9mIGFu b3RoZXIgd3JhcHBlZCBrZXkuPGJyPiZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgLS1SaWNoYXJkPGJy PiZndDs8YnI+Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7IC0tLS0tLS0tLS08YnI+Jmd0OyAmZ3Q7Jmd0 OyBTZW50OiBUdWVzZGF5LCAxOSBNYXJjaCAyMDEzIDEwOjIzIEFNPGJyPiZndDsgJmd0OyZndDsg U3ViamVjdDogW2pvc2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FF UCBhbGxvd3M8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsmZ3Q7ICMxNDogU3VwcG9ydCBs b25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FFUCBhbGxvd3M8YnI+Jmd0OyAmZ3Q7Jmd0Ozxicj4m Z3Q7ICZndDsmZ3Q7ICZuYnNwO1RoZSB1c2Ugb2YgUlNBLU9BRVAgZm9yIGtleSB3cmFwcGluZyBp bXBvc2VzIGEgbGltaXQgb24gdGhlIGxlbmd0aDxicj4mZ3Q7ICZndDsmZ3Q7IG9mICZuYnNwO3Ro ZSBrZXkgcGFja2FnZSBiZWluZyB3cmFwcGVkLiBXaXRoIFNIQTEsIHRoaXMgbGVuZ3RoIGlzIE4t MzIwLDxicj4mZ3Q7ICZndDsmZ3Q7IHdoZXJlICZuYnNwO04gaXMgdGhlIGxlbmd0aCBvZiB0aGUg UlNBIG1vZHVsdXMuICZuYnNwO0VzcGVjaWFsbHkgd2l0aCBsYXJnZXI8YnI+Jmd0OyAmZ3Q7Jmd0 OyBoYXNoICZuYnNwO2Z1bmN0aW9ucywgYW5kIGVzcGVjaWFsbHkgZm9yIHdyYXBwaW5nIHByaXZh dGUga2V5cywgdGhlIHNpemU8YnI+Jmd0OyAmZ3Q7Jmd0OyBvZiBrZXkgJm5ic3A7cGFja2FnZXMg d2lsbCBiZSBsYXJnZXIgdGhhbiB0aGlzIGJvdW5kLiAmbmJzcDtXZSBzaG91bGQ8YnI+Jmd0OyAm Z3Q7Jmd0OyBpbmNvcnBvcmF0ZSBhICZuYnNwO21lY2hhbmlzbSB0byBhY2NvbW1vZGF0ZSB0aGVz ZSBzaXR1YXRpb25zLjxicj4mZ3Q7ICZndDsmZ3Q7PGJyPiZndDsgJmd0OyZndDs8YnI+Jmd0OyAm Z3Q7Jmd0OyBUaWNrZXQgVVJMOiAmbHQ7PGEgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvd2cvam9zZS90cmFjL3RpY2tldC8xNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly90cmFjLnRv b2xzLmlldGYub3JnL3dnL2pvc2UvdHJhYy90aWNrZXQvMTQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4w cHQnPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+Jmd0OyBqb3NlIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGll dGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48bzpwPjwvbzpwPjwvcD48L2Rpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_255B9BB34FB7D647A506DC292726F6E1150BB430EEWSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Mon Mar 18 20:24:46 2013 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 22A1921F8613 for ; Mon, 18 Mar 2013 20:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 lltWM8LFiTKq for ; Mon, 18 Mar 2013 20:24:45 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0240.outbound.protection.outlook.com [207.46.163.240]) by ietfa.amsl.com (Postfix) with ESMTP id E181021F860B for ; Mon, 18 Mar 2013 20:24:43 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.202) by BL2FFO11HUB012.protection.gbl (10.173.161.118) with Microsoft SMTP Server (TLS) id 15.0.641.9; Tue, 19 Mar 2013 03:24:41 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Tue, 19 Mar 2013 03:24:41 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 19 Mar 2013 03:23:38 +0000 From: Mike Jones To: Jim Schaad , Richard Barnes Thread-Topic: [jose] #14: Support longer wrapped keys than OAEP allows Thread-Index: Ac4kUSSp0CdJ4UeFJ0WR/FqpfMVesA== Date: Tue, 19 Mar 2013 03:23:37 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436755CB51TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(76482001)(49866001)(77982001)(69226001)(55846006)(59766001)(47736001)(51856001)(65816001)(74662001)(63696002)(47976001)(54316002)(54356001)(20776003)(33656001)(53806001)(44976002)(46102001)(50986001)(56816002)(4396001)(16406001)(79102001)(56776001)(31966008)(5343635001)(47446002)(80022001)(74502001)(512874001)(148743001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB012; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0790FB1F33 Cc: James H Manger , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 03:24:46 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436755CB51TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U2luY2UgeW91IG1lc3NhZ2UgYXBwZWFycyB0byB0YWtlIGl0IGFzIGdpdmVuIHRoYXQg4oCcdGhl cmUgc2hvdWxkIGJlIG9ubHkgb25lIHdheSBvZiBlbmNyeXB0aW5nIGtleXPigJ0sIEnigJlsbCBw b2ludCBvdXQgdGhhdCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBpdOKAmXMgcmVhc29uYWJsZSB0byBh c3N1bWUgdGhhdC4gIEpPU0UgaXMgZmlyc3QgYW5kIGZvcmVtb3N0IGFuIGVuZ2luZWVyaW5nIGV4 ZXJjaXNlLCB3aGVyZSB0aGUgY29zdC9iZW5lZml0IGdlbmVyYWxpdHkvY29tcGxleGl0eSB0cmFk ZW9mZnMgbWF0dGVyLCBhbmQgdGhlIGdvYWwgaXMgYSB1YmlxdWl0b3VzbHkgaW1wbGVtZW50ZWQg Y3J5cHRvIGZvcm1hdCBmb3IgdGhlIFdlYiB0aGF0IHNvbHZlcyB0aGUgcHJvYmxlbXMgdGhhdCBw ZW9wbGUgYWN0dWFsbHkgaGF2ZSwgcmF0aGVyIHRoYW4gYSBtYXRoZW1hdGljYWwgZXhlcmNpc2Us IHdoZXJlIHRoZSBnb2FsIGlzIGNvbXBsZXRlbmVzcyBhbmQgZ2VuZXJhbGl0eS4gIENvbXBsZXhp dHkgaXMgdGhlIGVuZW15IG9mIGFkb3B0aW9uLg0KDQpTbyBpdOKAmXMgZmFpciBnYW1lIHRvIGFz ayDigJxXaGF0IGFyZSB0aGUgY29zdHMgYW5kIGJlbmVmaXRzIG9mIGhhdmluZyBvbmx5IG9uZSB3 YXkgdG8gZW5jcnlwdCBrZXlz4oCdLCB2ZXJzdXMgdGFraW5nIHRoYXQgYXMgYSBnaXZlbi4NCg0K SSBoYXBwZW4gdG8gcGVyc29uYWxseSBiZWxpZXZlIHRoYXQgZW5jcnlwdGluZyBhIGJhcmUgc3lt bWV0cmljIGVwaGVtZXJhbCBDb250ZW50IE1hc3RlciBLZXkgaXMgc3VmZmljaWVudGx5IGRpZmZl cmVudCB0aGFuIGVuY3J5cHRpbmcgYSBrZXkgdGhhdCBtYXkgYmUgcHVibGljLCBwcml2YXRlLCBv ciBzeW1tZXRyaWMgYW5kIG1heSBoYXZlIGFkZGl0aW9uYWwgYXR0cmlidXRlcywgdGhhdCBpdOKA mXMgYXQgbGVhc3Qgd29ydGggYXNraW5nIHRoZSBlbmdpbmVlcmluZyBxdWVzdGlvbiB3aGV0aGVy IHNwZWNpYWwtY2FzaW5nIHRoZSBlbmNyeXB0aW9uIG9mIHRoaXMgYmFyZSBzeW1tZXRyaWMgZXBo ZW1lcmFsIGtleSByZXN1bHRzIGluIGVuZ2luZWVyaW5nIGJlbmVmaXRzLg0KDQpFbmNyeXB0aW5n IGEga2V5IHdpdGggYXR0cmlidXRlcyBmb3Igc3RvcmFnZSBvciBkaXNzZW1pbmF0aW9uIGlzIG5v dCB0aGUgc2FtZSBraW5kIG9mIG9wZXJhdGlvbiBhcyB3cmFwcGluZyBhbiBlcGhlbWVyYWwgc3lt bWV0cmljIGtleSB0byBiZSB1c2VkIGZvciBibG9jayBlbmNyeXB0aW9uLiAgSeKAmW0gcGVyc29u YWxseSBmaW5lIHdpdGggdGhpcyBiZWluZyBkb25lIGRpZmZlcmVudGx5LiAgVGhlIGVuZ2luZWVy aW5nIGJlbmVmaXQgaWYgd2UgZG8gaXQgZGlmZmVyZW50bHkgaW4gdGhlIHdheSB0aGF0IE1hdHTi gJlzIGRyYWZ0IHByb3Bvc2VkLCBhdCBsZWFzdCBhcyBJIHNlZSBpdCwgaXMgdGhhdCB3ZSBoYXZl IHRvIGludmVudCBub3RoaW5nIG5ldy4gIFdlIGFscmVhZHkgaGF2ZSBhIGdyZWF0IGZvcm1hdCBm b3IgZW5jcnlwdGluZyBhcmJpdHJhcnkgZGF0YSwgYW5kIGtleXMgd2l0aCBhdHRyaWJ1dGVzIGFy ZSBhIHdob2xlIGxvdCBsaWtlIGFyYml0cmFyeSBkYXRhLg0KDQpJIHJlc3BlY3QgdGhhdCBzb21l IHdpdGggZGlzYWdyZWUgd2l0aCBteSBwZXJzb25hbCB2aWV3LCBidXQgSeKAmWQgYWxzbyBhc2sg eW91IHRvIHJlc3BlY3QgdGhhdCB0aGUgZW5naW5lZXJpbmcgdHJhZGVvZmZzIG1heSBmYXZvciBo YXZpbmcgdHdvIHdheXMgdG8gZG8gdGhpbmdzIHRoYXQgb24gdGhlIHN1cmZhY2UgbWF5IHNlZW0g c2ltaWxhciwgYnV0IGFyZSBhY3R1YWxseSBmYWlybHkgZGlmZmVyZW50IGluIG5hdHVyZS4NCg0K QmVzdCB3aXNoZXMsDQotLSBNaWtlDQoNCkZyb206IFJpY2hhcmQgQmFybmVzDQpTZW50OiDigI5N YXJjaOKAjiDigI4xOOKAjiwg4oCOMjAxMyDigI434oCOOuKAjjM24oCOIOKAjlBNDQpUbzogSmlt IFNjaGFhZA0KQ0M6IE1hbmdlciwgSmFtZXMgSCwgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dz DQoNCldlbGwsIEkgZ290IHRvIDc4OCBieSBkb2luZyBtYXRoIGluY29ycmVjdGx5Ki4NCg0KTWlr ZSB3YXMgY29ycmVjdCBvbiB0aGUgb3RoZXIgdGhyZWFkIHRoYXQgNzY4IGlzIHRoZSByaWdodCBu dW1iZXIuICBIb3dldmVyLCB0aGF0J3Mgc3RpbGwgdG9vIGJpZyBmb3IgYSAxMDI0LWJpdCBSU0Eg a2V5IGFuZCBTSEExLCBzaW5jZSA3NjggKyAzMjAgPSAxMDg4ID4gMTAyNC4NCg0KUmVnYXJkbGVz cywgdGhlcmUgaXMgY2xlYXJseSBhbiBpc3N1ZSBoZXJlIHdoZW4gd3JhcHBpbmcgYSBKV0ssIHdo aWNoIGlzIG11Y2ggbGFyZ2VyLCBwb3NzaWJseSBjb250YWluaW5nIGFuIFJTQSBrZXkgaXRzZWxm LiAgU28gaWYgd2UgYWNjZXB0IHRoZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSB3YXkg b2YgZW5jcnlwdGluZyBrZXlzLCB0aGVuIHdlJ2xsIG5lZWQgdG8gZGVhbCB3aXRoIGdldHRpbmcg YXJvdW5kIHRoZSBPQUVQIHNpemUgbGltaXRhdGlvbnMuDQoNCi0tUmljaGFyZA0KDQoqIFRoaXMg aXMgd2h5IG15IGRlZ3JlZSBpcyBpbiBtYXRoZW1hdGljcywgYW5kIG5vdCBhY2NvdW50aW5nLg0K DQoNCk9uIE1vbiwgTWFyIDE4LCAyMDEzIGF0IDg6NDAgUE0sIEppbSBTY2hhYWQgPGlldGZAYXVn dXN0Y2VsbGFycy5jb208bWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb20+PiB3cm90ZToNClRo aW5rIGluIHRlcm1zIG9mIGVuY3J5cHRpbmcgYSBKV0sgZGlyZWN0bHkgbm90IGFuIGludGVybWVk aWF0ZSBrZXkuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogam9zZS1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86am9z ZS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhh bGYgT2YNCj4gTWFuZ2VyLCBKYW1lcyBIDQo+IFNlbnQ6IE1vbmRheSwgTWFyY2ggMTgsIDIwMTMg NToxNyBQTQ0KPiBUbzogcmxiQGlwdi5zeDsgam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRm Lm9yZz4NCj4gU3ViamVjdDogUmU6IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQg a2V5cyB0aGFuIE9BRVAgYWxsb3dzDQo+DQo+IFJpY2hhcmQsDQo+DQo+IEhvdyBkbyB5b3UgZ2V0 IGEgNzg4LWJpdCBrZXkgbGVuZ3RoPw0KPg0KPiBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWht YWMtc2hhMiBkZWZpbmVzIDUgY29tYmluYXRpb25zIG9mIEFFUy0NCj4gMTI4LzE5Mi8yNTYgYW5k IFNIQS0xLzI1Ni8zODQvNTEyLiBUaGUgdG90YWwga2V5IGxlbmd0aHMgcmFuZ2UgZnJvbSAyNTYN Cj4gYml0cyB0byA1MTIgYml0cy4NCj4NCj4gS2V5cyBmb3IgdHdvIG9mIHRoZSBhbGdvcml0aG1z IChBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1NiBhbmQNCj4gQUVBRF9BRVNfMTI4X0NCQ19I TUFDX1NIQTEpIGZpdCB3aXRoaW4gT0FFUCB3aXRoIGEgMTAyNC1iaXQgUlNBIGtleS4NCj4NCj4g S2V5cyBmb3IgYWxsIG9mIHRoZSBhbGdvcml0aG1zIGZpdCB3aXRoaW4gT0FFUCB3aXRoIGEgMjA0 OC1iaXQgUlNBIGtleS4NCkpXQQ0KPiBhbHJlYWR5IHNheXMgUlNBIGtleSBzaXplcyBNVVNUIGJl IGF0IGxlYXN0IDIwNDggYml0cy4NCj4NCj4gVGhpcyBhbHJlYWR5IGxvb2tzIHN1ZmZpY2llbnQu DQo+DQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPg0KPg0KPiA+IEZyb206IGpvc2UtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmpvc2UtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmDQo+ID4g T2YgUmljaGFyZCBCYXJuZXMNCj4gPiBTZW50OiBUdWVzZGF5LCAxOSBNYXJjaCAyMDEzIDEwOjI1 IEFNDQo+ID4gU3ViamVjdDogW2pvc2VdIFdlYkNyeXB0byBmZWVkYmFjayBvbiBrZXkgd3JhcHBp bmcNCj4gPg0KPiA+IDIuIE1hcmsgV2F0c29uIChOZXRmbGl4KSBub3RlZCB0aGF0IGlmIHdlIHVz ZSBSU0EgZGlyZWN0bHkgdG8gZW5jcnlwdA0Kd3JhcHBlZA0KPiBrZXkgb2JqZWN0cywgdGhlbiB3 ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBvdGhlciB0aGFuIE9BRVAgaW4gb3JkZXIgdG8NCmNhcnJ5 DQo+IGFyYml0cmFyeS1sZW5ndGggcGF5bG9hZHMuICBJIGFncmVlZCwgYW5kIHN1Z2dlc3RlZCB0 aGF0IHNvbWV0aGluZyBsaWtlDQpSU0EtDQo+IEtFTSB3b3VsZCBiZSBuZWNlc3NhcnkuICBSeWFu IFNsZWV2aSAoR29vZ2xlKSBhbmQgVmlqYXkgb2JzZXJ2ZWQgdGhhdCBLRU0NCmlzDQo+IHRyb3Vi bGVzb21lIGR1ZSB0byB0aGUgbGFjayBvZiBzdXBwb3J0IGJ5IG5hdGl2ZSBjcnlwdG8gbGlicmFy aWVzLg0KPiA+DQo+ID4gUG9pbnQgbnVtYmVyIDIgbGlrZWx5IGFwcGxpZXMgZm9yIHNvbWUgc2Nl bmFyaW9zIG9mIEpXRSwgZXNwZWNpYWxseSBpZg0Kd2UNCj4gYWRvcHQgdGhlIE1jR3JldyBhcHBy b2FjaC4gIEZvciBleGFtcGxlLCBpZiB1c2luZyBITUFDLVNIQTEgYW5kIEFFUyB3aXRoDQo+IGEg MjU2LWJpdCBrZXksIHRoZSB0b3RhbCBrZXkgbGVuZ3RoIGlzIDc4OCBiaXRzLCB3aGljaCBpcyB0 b28gbG9uZyB0byBiZQ0KZW5jcnlwdGVkDQo+IHdpdGggT0FFUCB1bmRlciBhIDEsMDI0LWJpdCBS U0Ega2V5LiAgSSdtIG5vdCBzdXJlIGhvdyB0byByZXNvbHZlIGl0LiAgVGhlDQpiZXN0DQo+IGlk ZWEgSSd2ZSBnb3QgaXMgdG8gYWxsb3cgd3JhcHBlZCBrZXlzIHRvIG5lc3QsIHNvIHRoYXQgeW91 IGNhbiB3cmFwIGEga2V5DQppbnNpZGUNCj4gb2YgYW5vdGhlciB3cmFwcGVkIGtleS4NCj4gPg0K PiA+IC0tUmljaGFyZA0KPg0KPg0KPiA+PiAtLS0tLS0tLS0tDQo+ID4+IFNlbnQ6IFR1ZXNkYXks IDE5IE1hcmNoIDIwMTMgMTA6MjMgQU0NCj4gPj4gU3ViamVjdDogW2pvc2VdICMxNDogU3VwcG9y dCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FFUCBhbGxvd3MNCj4gPj4NCj4gPj4gIzE0OiBT dXBwb3J0IGxvbmdlciB3cmFwcGVkIGtleXMgdGhhbiBPQUVQIGFsbG93cw0KPiA+Pg0KPiA+PiAg VGhlIHVzZSBvZiBSU0EtT0FFUCBmb3Iga2V5IHdyYXBwaW5nIGltcG9zZXMgYSBsaW1pdCBvbiB0 aGUgbGVuZ3RoDQo+ID4+IG9mICB0aGUga2V5IHBhY2thZ2UgYmVpbmcgd3JhcHBlZC4gV2l0aCBT SEExLCB0aGlzIGxlbmd0aCBpcyBOLTMyMCwNCj4gPj4gd2hlcmUgIE4gaXMgdGhlIGxlbmd0aCBv ZiB0aGUgUlNBIG1vZHVsdXMuICBFc3BlY2lhbGx5IHdpdGggbGFyZ2VyDQo+ID4+IGhhc2ggIGZ1 bmN0aW9ucywgYW5kIGVzcGVjaWFsbHkgZm9yIHdyYXBwaW5nIHByaXZhdGUga2V5cywgdGhlIHNp emUNCj4gPj4gb2Yga2V5ICBwYWNrYWdlcyB3aWxsIGJlIGxhcmdlciB0aGFuIHRoaXMgYm91bmQu ICBXZSBzaG91bGQNCj4gPj4gaW5jb3Jwb3JhdGUgYSAgbWVjaGFuaXNtIHRvIGFjY29tbW9kYXRl IHRoZXNlIHNpdHVhdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRpY2tldCBVUkw6IDxodHRwOi8v dHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzE0Pg0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBqb3NlIG1haWxpbmcgbGlz dA0KPiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739436755CB51TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHk+DQo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLCdTZWdvZSBVSScsTWVpcnlvLCdNaWNyb3NvZnQgWWFIZWkgVUknLCdNaWNyb3Nv ZnQgSmhlbmdIZWkgVUknLCdNYWxndW4gR290aGljJywnS2htZXIgVUknLCdOaXJtYWxhIFVJJyxU dW5nYSwnTGFvIFVJJyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdj5T aW5jZSB5b3UgbWVzc2FnZSBhcHBlYXJzIHRvIHRha2UgaXQgYXMgZ2l2ZW4gdGhhdCZuYnNwO+KA nHRoZXJlIHNob3VsZCBiZSBvbmx5IG9uZSB3YXkgb2YgZW5jcnlwdGluZyBrZXlz4oCdLCBJ4oCZ bGwgcG9pbnQgb3V0IHRoYXQgSSBkb27igJl0IHRoaW5rIHRoYXQgaXTigJlzIHJlYXNvbmFibGUg dG8gYXNzdW1lIHRoYXQuJm5ic3A7IEpPU0UgaXMgZmlyc3QgYW5kIGZvcmVtb3N0IGFuIGVuZ2lu ZWVyaW5nIGV4ZXJjaXNlLCB3aGVyZSB0aGUgY29zdC9iZW5lZml0IGdlbmVyYWxpdHkvY29tcGxl eGl0eQ0KIHRyYWRlb2ZmcyBtYXR0ZXIsIGFuZCB0aGUgZ29hbCBpcyBhIHViaXF1aXRvdXNseSBp bXBsZW1lbnRlZCBjcnlwdG8mbmJzcDtmb3JtYXQgZm9yIHRoZSBXZWIgdGhhdCBzb2x2ZXMgdGhl IHByb2JsZW1zIHRoYXQgcGVvcGxlIGFjdHVhbGx5IGhhdmUsIHJhdGhlciB0aGFuIGEgbWF0aGVt YXRpY2FsIGV4ZXJjaXNlLCB3aGVyZSB0aGUgZ29hbCBpcyBjb21wbGV0ZW5lc3MgYW5kIGdlbmVy YWxpdHkuJm5ic3A7IENvbXBsZXhpdHkgaXMgdGhlIGVuZW15IG9mIGFkb3B0aW9uLjwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj5TbyBp dOKAmXMgZmFpciBnYW1lIHRvIGFzayZuYnNwO+KAnFdoYXQgYXJlIHRoZSBjb3N0cyBhbmQgYmVu ZWZpdHMgb2YgaGF2aW5nIG9ubHkgb25lIHdheSB0byBlbmNyeXB0IGtleXPigJ0sIHZlcnN1cyB0 YWtpbmcgdGhhdCBhcyBhIGdpdmVuLjwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9 InRydWUiPiZuYnNwOzwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPkkg aGFwcGVuIHRvIHBlcnNvbmFsbHkgYmVsaWV2ZSB0aGF0IGVuY3J5cHRpbmcgYSBiYXJlIHN5bW1l dHJpYyBlcGhlbWVyYWwmbmJzcDtDb250ZW50IE1hc3RlciBLZXkgaXMgc3VmZmljaWVudGx5IGRp ZmZlcmVudCB0aGFuIGVuY3J5cHRpbmcgYSBrZXkgdGhhdCBtYXkgYmUgcHVibGljLCBwcml2YXRl LCBvciBzeW1tZXRyaWMgYW5kIG1heSBoYXZlIGFkZGl0aW9uYWwgYXR0cmlidXRlcywgdGhhdA0K IGl04oCZcyBhdCBsZWFzdCB3b3J0aCBhc2tpbmcgdGhlIGVuZ2luZWVyaW5nIHF1ZXN0aW9uIHdo ZXRoZXIgc3BlY2lhbC1jYXNpbmcgdGhlIGVuY3J5cHRpb24gb2YgdGhpcyBiYXJlIHN5bW1ldHJp YyBlcGhlbWVyYWwga2V5IHJlc3VsdHMgaW4gZW5naW5lZXJpbmcgYmVuZWZpdHMuPC9kaXY+DQo8 ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRhdGEt Zm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSI+RW5jcnlwdGluZyBhIGtleSB3aXRoIGF0dHJpYnV0ZXMg Zm9yIHN0b3JhZ2Ugb3IgZGlzc2VtaW5hdGlvbiBpcyBub3QgdGhlIHNhbWUga2luZCBvZiBvcGVy YXRpb24gYXMgd3JhcHBpbmcgYW4gZXBoZW1lcmFsIHN5bW1ldHJpYyBrZXkgdG8gYmUgdXNlZCBm b3IgYmxvY2sgZW5jcnlwdGlvbi4mbmJzcDsgSeKAmW0gcGVyc29uYWxseSBmaW5lIHdpdGggdGhp cyBiZWluZyBkb25lIGRpZmZlcmVudGx5LiZuYnNwOw0KIFRoZSBlbmdpbmVlcmluZyBiZW5lZml0 IGlmIHdlIGRvIGl0IGRpZmZlcmVudGx5IGluIHRoZSB3YXkgdGhhdCBNYXR04oCZcyBkcmFmdCBw cm9wb3NlZCwgYXQgbGVhc3QgYXMgSSBzZWUgaXQsIGlzIHRoYXQgd2UgaGF2ZSB0byBpbnZlbnQg bm90aGluZyBuZXcuJm5ic3A7IFdlIGFscmVhZHkgaGF2ZSBhIGdyZWF0IGZvcm1hdCBmb3IgZW5j cnlwdGluZyBhcmJpdHJhcnkgZGF0YSwgYW5kIGtleXMgd2l0aCBhdHRyaWJ1dGVzIGFyZSBhIHdo b2xlIGxvdCBsaWtlDQogYXJiaXRyYXJ5IGRhdGEuPC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9t cG9pbnRlcj0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0i dHJ1ZSI+SSByZXNwZWN0IHRoYXQgc29tZSB3aXRoIGRpc2FncmVlIHdpdGggbXkgcGVyc29uYWwg dmlldywgYnV0IEnigJlkIGFsc28gYXNrIHlvdSB0byByZXNwZWN0IHRoYXQgdGhlIGVuZ2luZWVy aW5nIHRyYWRlb2ZmcyBtYXkgZmF2b3IgaGF2aW5nIHR3byB3YXlzIHRvIGRvIHRoaW5ncyB0aGF0 IG9uIHRoZSBzdXJmYWNlIG1heSBzZWVtIHNpbWlsYXIsIGJ1dCBhcmUgYWN0dWFsbHkgZmFpcmx5 IGRpZmZlcmVudA0KIGluIG5hdHVyZS48L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVy PSJ0cnVlIj4mbmJzcDs8L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj5C ZXN0IHdpc2hlcyw8L2Rpdj4NCjxkaXYgZGF0YS1mb2N1c2Zyb21wb2ludGVyPSJ0cnVlIj4tLSBN aWtlPC9kaXY+DQo8ZGl2IGRhdGEtZm9jdXNmcm9tcG9pbnRlcj0idHJ1ZSIgZGF0YS1zaWduYXR1 cmVibG9jaz0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItdG9wLWNvbG9y OiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lkdGg6IDFweDsgYm9yZGVyLXRvcC1z dHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9uZz4mbmJzcDtSaWNoYXJkIEJhcm5l czxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9uZz4mbmJzcDvigI5NYXJjaOKAjiDigI4xOOKAjiwg 4oCOMjAxMyDigI434oCOOuKAjjM24oCOIOKAjlBNPGJyPg0KPHN0cm9uZz5Ubzo8L3N0cm9uZz4m bmJzcDtKaW0gU2NoYWFkPGJyPg0KPHN0cm9uZz5DQzo8L3N0cm9uZz4mbmJzcDtNYW5nZXIsIEph bWVzIEgsIGpvc2VAaWV0Zi5vcmc8YnI+DQo8c3Ryb25nPlN1YmplY3Q6PC9zdHJvbmc+Jm5ic3A7 UmU6IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxs b3dzPGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KV2VsbCwgSSBnb3QgdG8gNzg4IGJ5 IGRvaW5nIG1hdGggaW5jb3JyZWN0bHkqLiZuYnNwOw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ TWlrZSB3YXMgY29ycmVjdCBvbiB0aGUgb3RoZXIgdGhyZWFkIHRoYXQgNzY4IGlzIHRoZSByaWdo dCBudW1iZXIuICZuYnNwO0hvd2V2ZXIsIHRoYXQncyBzdGlsbCB0b28gYmlnIGZvciBhIDEwMjQt Yml0IFJTQSBrZXkgYW5kIFNIQTEsIHNpbmNlIDc2OCAmIzQzOyAzMjAgPSAxMDg4ICZndDsgMTAy NC4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlJlZ2FyZGxlc3MsIHRoZXJlIGlzIGNsZWFybHkg YW4gaXNzdWUgaGVyZSB3aGVuIHdyYXBwaW5nIGEgSldLLCB3aGljaCBpcyBtdWNoIGxhcmdlciwg cG9zc2libHkgY29udGFpbmluZyBhbiBSU0Ega2V5IGl0c2VsZi4gJm5ic3A7U28gaWYgd2UgYWNj ZXB0IHRoZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSB3YXkgb2YgZW5jcnlwdGluZyBr ZXlzLCB0aGVuIHdlJ2xsIG5lZWQgdG8gZGVhbCB3aXRoIGdldHRpbmcgYXJvdW5kIHRoZSBPQUVQ DQogc2l6ZSBsaW1pdGF0aW9ucy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pi0tUmlj aGFyZDxicj4NCjxicj4NCiogVGhpcyBpcyB3aHkgbXkgZGVncmVlIGlzIGluIG1hdGhlbWF0aWNz LCBhbmQgbm90IGFjY291bnRpbmcuPGJyPg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iIGdtYWls X3F1b3RlIj5PbiBNb24sIE1hciAxOCwgMjAxMyBhdCA4OjQwIFBNLCBKaW0gU2NoYWFkIDxzcGFu IGRpcj0ibHRyIj4NCiZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzppZXRmQGF1Z3Vz dGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9hPiZndDs8L3NwYW4+IHdyb3Rl Ojxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSIgZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBw eCAwcHggMHB4IDAuOGV4OyBwYWRkaW5nLWxlZnQ6IDFleDsgYm9yZGVyLWxlZnQtY29sb3I6IHJn YigyMDQsIDIwNCwgMjA0KTsgYm9yZGVyLWxlZnQtd2lkdGg6IDFweDsgYm9yZGVyLWxlZnQtc3R5 bGU6IHNvbGlkOyI+DQpUaGluayBpbiB0ZXJtcyBvZiBlbmNyeXB0aW5nIGEgSldLIGRpcmVjdGx5 IG5vdCBhbiBpbnRlcm1lZGlhdGUga2V5Ljxicj4NCjxkaXYgY2xhc3M9IiBpbSI+PGJyPg0KJmd0 OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogPGEgdGFiaW5kZXg9 Ii0xIiBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+IFttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86am9zZS1ib3Vu Y2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2Y8YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSIgaDUiPiZndDsgTWFuZ2VyLCBKYW1lcyBIPGJy Pg0KJmd0OyBTZW50OiBNb25kYXksIE1hcmNoIDE4LCAyMDEzIDU6MTcgUE08YnI+DQomZ3Q7IFRv OiBybGJAaXB2LnN4OyA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3Jn Ij5qb3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtqb3NlXSAjMTQ6IFN1 cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzPGJyPg0KJmd0Ozxicj4N CiZndDsgUmljaGFyZCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3cgZG8geW91IGdldCBhIDc4OC1i aXQga2V5IGxlbmd0aD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFmdC1tY2dyZXctYWVhZC1hZXMt Y2JjLWhtYWMtc2hhMiBkZWZpbmVzIDUgY29tYmluYXRpb25zIG9mIEFFUy08YnI+DQomZ3Q7IDEy OC8xOTIvMjU2IGFuZCBTSEEtMS8yNTYvMzg0LzUxMi4gVGhlIHRvdGFsIGtleSBsZW5ndGhzIHJh bmdlIGZyb20gMjU2PGJyPg0KJmd0OyBiaXRzIHRvIDUxMiBiaXRzLjxicj4NCiZndDs8YnI+DQom Z3Q7IEtleXMgZm9yIHR3byBvZiB0aGUgYWxnb3JpdGhtcyAoQUVBRF9BRVNfMTI4X0NCQ19ITUFD X1NIQV8yNTYgYW5kPGJyPg0KJmd0OyBBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBMSkgZml0IHdp dGhpbiBPQUVQIHdpdGggYSAxMDI0LWJpdCBSU0Ega2V5Ljxicj4NCiZndDs8YnI+DQomZ3Q7IEtl eXMgZm9yIGFsbCBvZiB0aGUgYWxnb3JpdGhtcyBmaXQgd2l0aGluIE9BRVAgd2l0aCBhIDIwNDgt Yml0IFJTQSBrZXkuPGJyPg0KSldBPGJyPg0KJmd0OyBhbHJlYWR5IHNheXMgUlNBIGtleSBzaXpl cyBNVVNUIGJlIGF0IGxlYXN0IDIwNDggYml0cy48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIGFs cmVhZHkgbG9va3Mgc3VmZmljaWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLTxicj4NCiZndDsg SmFtZXMgTWFuZ2VyPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgRnJvbTogPGEg dGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJv dW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgdGFiaW5kZXg9Ii0xIiBocmVmPSJtYWlsdG86 am9zZS1ib3VuY2VzQGlldGYub3JnIj5qb3NlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhh bGY8YnI+DQomZ3Q7ICZndDsgT2YgUmljaGFyZCBCYXJuZXM8YnI+DQomZ3Q7ICZndDsgU2VudDog VHVlc2RheSwgMTkgTWFyY2ggMjAxMyAxMDoyNSBBTTxicj4NCiZndDsgJmd0OyBTdWJqZWN0OiBb am9zZV0gV2ViQ3J5cHRvIGZlZWRiYWNrIG9uIGtleSB3cmFwcGluZzxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAyLiBNYXJrIFdhdHNvbiAoTmV0ZmxpeCkgbm90ZWQgdGhhdCBpZiB3ZSB1 c2UgUlNBIGRpcmVjdGx5IHRvIGVuY3J5cHQ8YnI+DQp3cmFwcGVkPGJyPg0KJmd0OyBrZXkgb2Jq ZWN0cywgdGhlbiB3ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBvdGhlciB0aGFuIE9BRVAgaW4gb3Jk ZXIgdG88YnI+DQpjYXJyeTxicj4NCiZndDsgYXJiaXRyYXJ5LWxlbmd0aCBwYXlsb2Fkcy4gJm5i c3A7SSBhZ3JlZWQsIGFuZCBzdWdnZXN0ZWQgdGhhdCBzb21ldGhpbmcgbGlrZTxicj4NClJTQS08 YnI+DQomZ3Q7IEtFTSB3b3VsZCBiZSBuZWNlc3NhcnkuICZuYnNwO1J5YW4gU2xlZXZpIChHb29n bGUpIGFuZCBWaWpheSBvYnNlcnZlZCB0aGF0IEtFTTxicj4NCmlzPGJyPg0KJmd0OyB0cm91Ymxl c29tZSBkdWUgdG8gdGhlIGxhY2sgb2Ygc3VwcG9ydCBieSBuYXRpdmUgY3J5cHRvIGxpYnJhcmll cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgUG9pbnQgbnVtYmVyIDIgbGlrZWx5IGFw cGxpZXMgZm9yIHNvbWUgc2NlbmFyaW9zIG9mIEpXRSwgZXNwZWNpYWxseSBpZjxicj4NCndlPGJy Pg0KJmd0OyBhZG9wdCB0aGUgTWNHcmV3IGFwcHJvYWNoLiAmbmJzcDtGb3IgZXhhbXBsZSwgaWYg dXNpbmcgSE1BQy1TSEExIGFuZCBBRVMgd2l0aDxicj4NCiZndDsgYSAyNTYtYml0IGtleSwgdGhl IHRvdGFsIGtleSBsZW5ndGggaXMgNzg4IGJpdHMsIHdoaWNoIGlzIHRvbyBsb25nIHRvIGJlPGJy Pg0KZW5jcnlwdGVkPGJyPg0KJmd0OyB3aXRoIE9BRVAgdW5kZXIgYSAxLDAyNC1iaXQgUlNBIGtl eS4gJm5ic3A7SSdtIG5vdCBzdXJlIGhvdyB0byByZXNvbHZlIGl0LiAmbmJzcDtUaGU8YnI+DQpi ZXN0PGJyPg0KJmd0OyBpZGVhIEkndmUgZ290IGlzIHRvIGFsbG93IHdyYXBwZWQga2V5cyB0byBu ZXN0LCBzbyB0aGF0IHlvdSBjYW4gd3JhcCBhIGtleTxicj4NCmluc2lkZTxicj4NCiZndDsgb2Yg YW5vdGhlciB3cmFwcGVkIGtleS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS1SaWNo YXJkPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IC0tLS0tLS0tLS08YnI+ DQomZ3Q7ICZndDsmZ3Q7IFNlbnQ6IFR1ZXNkYXksIDE5IE1hcmNoIDIwMTMgMTA6MjMgQU08YnI+ DQomZ3Q7ICZndDsmZ3Q7IFN1YmplY3Q6IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBw ZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0 OyZndDsgIzE0OiBTdXBwb3J0IGxvbmdlciB3cmFwcGVkIGtleXMgdGhhbiBPQUVQIGFsbG93czxi cj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwO1RoZSB1c2Ugb2YgUlNB LU9BRVAgZm9yIGtleSB3cmFwcGluZyBpbXBvc2VzIGEgbGltaXQgb24gdGhlIGxlbmd0aDxicj4N CiZndDsgJmd0OyZndDsgb2YgJm5ic3A7dGhlIGtleSBwYWNrYWdlIGJlaW5nIHdyYXBwZWQuIFdp dGggU0hBMSwgdGhpcyBsZW5ndGggaXMgTi0zMjAsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB3aGVyZSAm bmJzcDtOIGlzIHRoZSBsZW5ndGggb2YgdGhlIFJTQSBtb2R1bHVzLiAmbmJzcDtFc3BlY2lhbGx5 IHdpdGggbGFyZ2VyPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBoYXNoICZuYnNwO2Z1bmN0aW9ucywgYW5k IGVzcGVjaWFsbHkgZm9yIHdyYXBwaW5nIHByaXZhdGUga2V5cywgdGhlIHNpemU8YnI+DQomZ3Q7 ICZndDsmZ3Q7IG9mIGtleSAmbmJzcDtwYWNrYWdlcyB3aWxsIGJlIGxhcmdlciB0aGFuIHRoaXMg Ym91bmQuICZuYnNwO1dlIHNob3VsZDxicj4NCiZndDsgJmd0OyZndDsgaW5jb3Jwb3JhdGUgYSAm bmJzcDttZWNoYW5pc20gdG8gYWNjb21tb2RhdGUgdGhlc2Ugc2l0dWF0aW9ucy48YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgVGlja2V0IFVS TDogJmx0OzxhIHRhYmluZGV4PSItMSIgaHJlZj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcv d2cvam9zZS90cmFjL3RpY2tldC8xNCI+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9z ZS90cmFjL3RpY2tldC8xNDwvYT4mZ3Q7PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IGpvc2Ug bWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpqb3Nl QGlldGYub3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgdGFiaW5kZXg9Ii0xIiBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZTwvYT48YnI+DQo8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_4E1F6AAD24975D4BA5B16804296739436755CB51TK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Mon Mar 18 20:38:35 2013 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 2FFA021F85D6 for ; Mon, 18 Mar 2013 20:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 ymcpNoRx2xOu for ; Mon, 18 Mar 2013 20:38:34 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id 1740B21F85AD for ; Mon, 18 Mar 2013 20:38:33 -0700 (PDT) Received: from BN1AFFO11FD018.protection.gbl (10.58.52.202) by BN1BFFO11HUB002.protection.gbl (10.58.53.112) with Microsoft SMTP Server (TLS) id 15.0.641.9; Tue, 19 Mar 2013 03:28:46 +0000 Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.37) by BN1AFFO11FD018.mail.protection.outlook.com (10.58.52.78) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Tue, 19 Mar 2013 03:28:45 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.02.0318.003; Tue, 19 Mar 2013 03:28:43 +0000 From: Mike Jones To: Richard Barnes Thread-Topic: [jose] WebCrypto feedback on key wrapping Thread-Index: Ac4kUdrmb0UrhnxpB0CL7KQe/F+ugg== Date: Tue, 19 Mar 2013 03:28:42 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436755CE48@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739436755CE48TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51856001)(512874001)(77982001)(4396001)(74502001)(33656001)(47446002)(76482001)(55846006)(56816002)(79102001)(46102001)(47736001)(74662001)(53806001)(54356001)(59766001)(50986001)(63696002)(47976001)(20776003)(80022001)(31966008)(65816001)(16406001)(69226001)(5343635001)(54316002)(56776001)(49866001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB002; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0790FB1F33 Cc: "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 03:38:35 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436755CE48TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHRoYXQgdGhlIDIwNDggcmVzdHJpY3Rpb24gd2FzIG1vdGl2YXRlZCBieSBhIE5J U1QgZXZhbHVhdGlvbiBvbiBhY2NlcHRhYmxlIGtleSBsZW5ndGhzIGluIHdoaWNoIHRoZSB1c2Ug b2YgMTAyNCBiaXQgUlNBIGtleXMgaGFzIGFscmVhZHkgYmVlbiBkZXByZWNhdGVkLiAgRXJpYyBS ZXNjb3JsYeKAmXMgcHJlc2VudGF0aW9uIHRvIHRoZSB3b3JraW5nIGdyb3VwIHNldmVyYWwgSUVU RnMgYWdvIHNwZWNpZmljYWxseSByZWNvbW1lbmRlZCB0aGlzLCBhcyB3ZWxsIGFzIHRoZSBvdGhl ciBrZXkgc2l6ZSByZXN0cmljdGlvbnMgaW4gSldBLg0KDQpBdCB0aGUgdGltZSwgdGhlIHdvcmtp bmcgZ3JvdXAgZmVsdCB0aGF0IHJlcXVpcmluZyB0aGF0IHBlb3BsZSB1c2Uga2V5cyBvZiBhY2Nl cHRhYmxlIGxlbmd0aHMgZm9yIHRoZSBjdXJyZW50IGNyeXB0b2dyYXBoaWMgY2xpZW50IGZvciBu ZXcgYXBwbGljYXRpb25zIHdhcyBhIGdvb2QgdGhpbmcgLSBlc3BlY2lhbGx5IHNpbmNlIEpXUyBh bmQgSldFIGhhdmUgbm8gbGVnYWN5IGFwcGxpY2F0aW9ucyB0byBzdXBwb3J0Lg0KDQotLSBNaWtl DQoNCkZyb206IFJpY2hhcmQgQmFybmVzDQpTZW50OiDigI5NYXJjaOKAjiDigI4xOOKAjiwg4oCO MjAxMyDigI434oCOOuKAjjMx4oCOIOKAjlBNDQpUbzogTWlrZSBKb25lcw0KQ0M6IGpvc2VAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbam9zZV0gV2ViQ3J5cHRvIGZlZWRiYWNrIG9uIGtleSB3cmFw cGluZw0KDQpJU1NVRS0obisxKTogUmVtb3ZlIHNpbGx5IHJlc3RyaWN0aW9uIG9uIGtleSBzaXpl cy4gIFdlJ3JlIGEgZm9ybWF0dGluZyB3b3JraW5nIGdyb3VwLCBub3QgYSBjcnlwdG8gcGFyYW1l dGVycyB3b3JraW5nIGdyb3VwLg0KDQotLVJpY2hhcmQNCg0KDQpPbiBNb24sIE1hciAxOCwgMjAx MyBhdCA4OjAyIFBNLCBNaWtlIEpvbmVzIDxNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208bWFp bHRvOk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KR2l2ZW4gdGhhdCB3ZSBy ZXF1aXJlIFJTQSBrZXlzIHRvIGJlIGEgbWluaW11bSBvZiAyMDQ4IGJpdHMgaW4gbGVuZ3RoLCB0 aGVyZeKAmXMgbm8gcHJvYmxlbSB3cmFwcGluZyA3NjggYml0IGtleXMgd2l0aCBPQUVQIGluIHBy YWN0aWNlLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBSaWNoYXJkIEJh cm5lcw0KU2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA0OjI1IFBNDQpUbzogam9zZUBpZXRm Lm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtqb3NlXSBXZWJDcnlwdG8gZmVl ZGJhY2sgb24ga2V5IHdyYXBwaW5nDQoNCk9uIHRvZGF5J3MgY2FsbCB3aXRoIHRoZSBXM0MgV2Vi Q3J5cHRvIHdvcmtpbmcgIGdyb3VwLCBJIHJlcG9ydGVkIG9uIHRoZSBkaXNjdXNzaW9uIG9mIEpP U0Uga2V5IHdyYXBwaW5nIGF0IHRoZSBsYXN0IElFVEYuICBJIHdhcyBhc2tlZCB0byByZWxheSBh IGZldyBiaXRzIG9mIGZlZWRiYWNrOg0KDQoxLiBWaWpheSBCaGFyYWR3YWogKE1pY3Jvc29mdCkg b2JzZXJ2ZWQgdGhhdCBBRVMga2V5IHdyYXAgaGFzIGZhbGxlbiBvdXQgb2YgZmF2b3Igd2l0aCBz b21lIHBhcnRzIG9mIHRoZSBjcnlwdG9ncmFwaGljIGNvbW11bml0eS4gIFBlb3BsZSBwcmVmZXIg dG8gYmUgYWJsZSB0byB1c2UgQUVBRCBhbGdvcml0aG1zIGZvciBrZXkgd3JhcHBpbmcsIHNpbmNl IHRoZXkgYXJlIHBlcmNlaXZlZCB0byBiZSBmYXN0ZXIgYW5kIG9mZmVyIGEgaGlnaGVyIGxldmVs IG9mIHNlY3VyaXR5IHRoYW4gQUVTLUtXLiBIZSBnYXZlIHRoZSBleGFtcGxlIHRoYXQgSUVFRSA4 MDIuMSB1c2VzIEFFUyBDQ00uDQoNCjIuIE1hcmsgV2F0c29uIChOZXRmbGl4KSBub3RlZCB0aGF0 IGlmIHdlIHVzZSBSU0EgZGlyZWN0bHkgdG8gZW5jcnlwdCB3cmFwcGVkIGtleSBvYmplY3RzLCB0 aGVuIHdlIHdvdWxkIG5lZWQgc29tZXRoaW5nIG90aGVyIHRoYW4gT0FFUCBpbiBvcmRlciB0byBj YXJyeSBhcmJpdHJhcnktbGVuZ3RoIHBheWxvYWRzLiAgSSBhZ3JlZWQsIGFuZCBzdWdnZXN0ZWQg dGhhdCBzb21ldGhpbmcgbGlrZSBSU0EtS0VNIHdvdWxkIGJlIG5lY2Vzc2FyeS4gIFJ5YW4gU2xl ZXZpIChHb29nbGUpIGFuZCBWaWpheSBvYnNlcnZlZCB0aGF0IEtFTSBpcyB0cm91Ymxlc29tZSBk dWUgdG8gdGhlIGxhY2sgb2Ygc3VwcG9ydCBieSBuYXRpdmUgY3J5cHRvIGxpYnJhcmllcy4NCg0K SXQgc2VlbXMgdG8gbWUgdGhhdCB0aGVzZSBjb21tZW50cyBoYXZlIGltcGFjdHMgb24gSldFIGFu ZCBKV1MgKHBlbmRpbmcgSVNTVUUtMiksIGFzIHdlbGwgYXMgdGhlIHdyYXBwaW5nIGRpc2N1c3Np b24uICBUaGUgZm9ybWVyIGhhcyBtb3JlIGltcGFjdCB0aGFuIHRoZSBsYXR0ZXIuDQoNClBvaW50 IG51bWJlciAxIGltcGxpZXMgdGhhdCB3ZSBzaG91bGQgb2ZmZXIgQUVBRCBmb3Iga2V5IHdyYXBw aW5nIGluIEpXRSBhcyB3ZWxsIGFzIGZvciB3cmFwcGVkIGtleXMuICBJdCBzZWVtcyB0byBtZSB0 aGF0IHRoZSBzaW1wbGVzdCBhcHByb2FjaCB0byB0aGlzIHdvdWxkIGJlIHRvIG1ha2UgdGhlICJh bGciIGZpZWxkIGNvbnRhaW4gYW4gb2JqZWN0IHRoYXQgaXMgc2VtYW50aWNhbGx5IGVxdWl2YWxl bnQgdG8gYW4gQWxnb3JpdGhtSWRlbnRpZmllciBpbiBDTVMvUEtDUzguICBGb3IgZXhhbXBsZSwg eyBuYW1lOiAiQTEyOEdDTSIsIGl2OiAiUENJR0plMERqdW51TTdzMCIgfS4gIFRoaXMgc3ludGF4 LCBpbmNpZGVudGFsbHksIGlzIHJvdWdobHkgdGhlIHNhbWUgZm9ybSB0aGF0IGFsZ29yaXRobSBp ZGVudGlmaWVycyBoYXZlIGluIHRoZSBXZWJDcnlwdG8gQVBJLiAgTm90ZSB0aGF0IHRoaXMgdHlw ZSBvZiBrZXkgd3JhcHBpbmcgaXMgc3VwcG9ydGVkIGluIENNUyBieSB0aGUgdXNlIG9mIGFuIEFF QUQgQWxnb3JpdGhtSWRlbnRpZmllciBpbiB0aGUgS0VLUmVjaXBpZW50SW5mbyBzdHJ1Y3R1cmUu DQoNClBvaW50IG51bWJlciAyIGxpa2VseSBhcHBsaWVzIGZvciBzb21lIHNjZW5hcmlvcyBvZiBK V0UsIGVzcGVjaWFsbHkgaWYgd2UgYWRvcHQgdGhlIE1jR3JldyBhcHByb2FjaC4gIEZvciBleGFt cGxlLCBpZiB1c2luZyBITUFDLVNIQTEgYW5kIEFFUyB3aXRoIGEgMjU2LWJpdCBrZXksIHRoZSB0 b3RhbCBrZXkgbGVuZ3RoIGlzIDc4OCBiaXRzLCB3aGljaCBpcyB0b28gbG9uZyB0byBiZSBlbmNy eXB0ZWQgd2l0aCBPQUVQIHVuZGVyIGEgMSwwMjQtYml0IFJTQSBrZXkuICBJJ20gbm90IHN1cmUg aG93IHRvIHJlc29sdmUgaXQuICBUaGUgYmVzdCBpZGVhIEkndmUgZ290IGlzIHRvIGFsbG93IHdy YXBwZWQga2V5cyB0byBuZXN0LCBzbyB0aGF0IHlvdSBjYW4gd3JhcCBhIGtleSBpbnNpZGUgb2Yg YW5vdGhlciB3cmFwcGVkIGtleS4NCg0KSSB3aWxsIHRyeSB0byB0YWtlIHRoZXNlIHBvaW50cyBp bnRvIGFjY291bnQgaW4gbXkgZm9ydGhjb21pbmcga2V5IHdyYXBwaW5nIGRyYWZ0LCBhbmQgSSd2 ZSBmaWxlZCB0d28gaXNzdWVzIGFnYWluc3QgSldFIHRvIHRyYWNrIHRoZW0uDQoNCi0tUmljaGFy ZA0KDQo= --_000_4E1F6AAD24975D4BA5B16804296739436755CE48TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSBkYXRhLWV4dGVybmFsc3R5bGU9InRy dWUiPgpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoIHsKbWFyZ2luLXRvcDowaW47Cm1hcmdpbi1yaWdodDowaW47Cm1hcmdpbi1ib3R0 b206MGluOwptYXJnaW4tbGVmdDouNWluOwptYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cn0KCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgbGkuTXNvTGlzdFBhcmFncmFwaEN4U3BGaXJzdCwgZGl2 Lk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUs IGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBkaXYuTXNvTGlzdFBhcmFncmFwaEN4U3BN aWRkbGUsIHAuTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0LCBsaS5Nc29MaXN0UGFyYWdyYXBoQ3hT cExhc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcExhc3QgewptYXJnaW4tdG9wOjBpbjsKbWFy Z2luLXJpZ2h0OjBpbjsKbWFyZ2luLWJvdHRvbTowaW47Cm1hcmdpbi1sZWZ0Oi41aW47Cm1hcmdp bi1ib3R0b206LjAwMDFwdDsKbGluZS1oZWlnaHQ6MTE1JTsKfQo8L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHk+DQo8ZGl2IGRhdGEtZXh0ZXJuYWxzdHlsZT0iZmFsc2UiIHN0eWxlPSJmb250LWZhbWls eTpDYWxpYnJpLCdTZWdvZSBVSScsTWVpcnlvLCdNaWNyb3NvZnQgWWFIZWkgVUknLCdNaWNyb3Nv ZnQgSmhlbmdIZWkgVUknLCdNYWxndW4gR290aGljJywnS2htZXIgVUknLCdOaXJtYWxhIFVJJyxU dW5nYSwnTGFvIFVJJyxFYnJpbWEsc2Fucy1zZXJpZjtmb250LXNpemU6MTZweDsiPg0KPGRpdiBk YXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPkkgYmVsaWV2ZSB0aGF0IHRoZSAyMDQ4IHJlc3Ry aWN0aW9uIHdhcyBtb3RpdmF0ZWQgYnkgYSBOSVNUJm5ic3A7ZXZhbHVhdGlvbiBvbiBhY2NlcHRh YmxlIGtleSBsZW5ndGhzIGluIHdoaWNoIHRoZSB1c2Ugb2YmbmJzcDsxMDI0IGJpdCBSU0Ega2V5 cyBoYXMgYWxyZWFkeSBiZWVuIGRlcHJlY2F0ZWQuJm5ic3A7IEVyaWMgUmVzY29ybGHigJlzIHBy ZXNlbnRhdGlvbiB0byB0aGUgd29ya2luZyBncm91cCBzZXZlcmFsDQogSUVURnMgYWdvIHNwZWNp ZmljYWxseSByZWNvbW1lbmRlZCB0aGlzLCBhcyB3ZWxsIGFzIHRoZSBvdGhlciBrZXkgc2l6ZSBy ZXN0cmljdGlvbnMgaW4gSldBLjwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRy dWUiPiZuYnNwOzwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPkF0IHRo ZSB0aW1lLCB0aGUgd29ya2luZyBncm91cCBmZWx0IHRoYXQmbmJzcDtyZXF1aXJpbmcgdGhhdCBw ZW9wbGUgdXNlIGtleXMgb2YgYWNjZXB0YWJsZSBsZW5ndGhzIGZvciB0aGUgY3VycmVudCBjcnlw dG9ncmFwaGljIGNsaWVudCBmb3IgbmV3IGFwcGxpY2F0aW9ucyB3YXMgYSBnb29kIHRoaW5nIC0g ZXNwZWNpYWxseSBzaW5jZSBKV1MgYW5kIEpXRSBoYXZlIG5vIGxlZ2FjeSBhcHBsaWNhdGlvbnMN CiB0byBzdXBwb3J0LjwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPiZu YnNwOzwvZGl2Pg0KPGRpdiBkYXRhLWZvY3VzZnJvbXBvaW50ZXI9InRydWUiPi0tIE1pa2U8L2Rp dj4NCjxkaXYgZGF0YS1zaWduYXR1cmVibG9jaz0idHJ1ZSI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXItdG9wLWNvbG9yOiByZ2IoMjI1LCAyMjUsIDIyNSk7IGJvcmRlci10b3Atd2lk dGg6IDFweDsgYm9yZGVyLXRvcC1zdHlsZTogc29saWQ7Ij4NCjxzdHJvbmc+RnJvbTo8L3N0cm9u Zz4mbmJzcDtSaWNoYXJkIEJhcm5lczxicj4NCjxzdHJvbmc+U2VudDo8L3N0cm9uZz4mbmJzcDvi gI5NYXJjaOKAjiDigI4xOOKAjiwg4oCOMjAxMyDigI434oCOOuKAjjMx4oCOIOKAjlBNPGJyPg0K PHN0cm9uZz5Ubzo8L3N0cm9uZz4mbmJzcDtNaWtlIEpvbmVzPGJyPg0KPHN0cm9uZz5DQzo8L3N0 cm9uZz4mbmJzcDtqb3NlQGlldGYub3JnPGJyPg0KPHN0cm9uZz5TdWJqZWN0Ojwvc3Ryb25nPiZu YnNwO1JlOiBbam9zZV0gV2ViQ3J5cHRvIGZlZWRiYWNrIG9uIGtleSB3cmFwcGluZzxicj4NCjwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCklTU1VFLShuJiM0MzsxKTogUmVtb3ZlIHNpbGx5IHJl c3RyaWN0aW9uIG9uIGtleSBzaXplcy4gJm5ic3A7V2UncmUgYSBmb3JtYXR0aW5nIHdvcmtpbmcg Z3JvdXAsIG5vdCBhIGNyeXB0byBwYXJhbWV0ZXJzIHdvcmtpbmcgZ3JvdXAuDQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj4tLVJpY2hhcmQ8L2Rpdj4NCjxkaXY+PGJyPg0KPGJyPg0KPGRpdiBjbGFz cz0iIGdtYWlsX3F1b3RlIj5PbiBNb24sIE1hciAxOCwgMjAxMyBhdCA4OjAyIFBNLCBNaWtlIEpv bmVzIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpN aWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20iPk1pY2hhZWwuSm9uZXNAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iIGdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOiAwcHggMHB4IDBweCAwLjhleDsgcGFkZGluZy1sZWZ0OiAxZXg7IGJv cmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7IGJvcmRlci1sZWZ0LXdpZHRoOiAx cHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiPg0KPGRpdiBsYW5nPSJFTi1VUyI+DQo8ZGl2 Pg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgZm9udC1mYW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OzsgZm9udC1zaXplOiAxMXB0OyI+R2l2ZW4gdGhhdCB3ZSByZXF1aXJlIFJTQSBrZXlzIHRv IGJlIGEgbWluaW11bSBvZiAyMDQ4IGJpdHMgaW4gbGVuZ3RoLCB0aGVyZeKAmXMgbm8gcHJvYmxl bSB3cmFwcGluZyA3NjggYml0IGtleXMgd2l0aCBPQUVQIGluIHByYWN0aWNlLjx1PjwvdT48dT48 L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPjx1PjwvdT4mbmJzcDs8dT48L3U+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiAmcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTFwdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAtLSBNaWtlPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 IiBNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6ICZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsgZm9udC1z aXplOiAxMXB0OyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9IiBN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7IGZvbnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7OyBmb250LXNpemU6IDEwcHQ7Ij4NCjxhIHRhYmluZGV4PSItMSIgaHJlZj0i bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPiBb bWFpbHRvOjxhIHRhYmluZGV4PSItMSIgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9y ZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+UmljaGFy ZCBCYXJuZXM8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA0OjI1IFBN PGJyPg0KPGI+VG86PC9iPiA8YSB0YWJpbmRleD0iLTEiIGhyZWY9Im1haWx0bzpqb3NlQGlldGYu b3JnIj5qb3NlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBbam9zZV0gV2ViQ3J5 cHRvIGZlZWRiYWNrIG9uIGtleSB3cmFwcGluZzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxk aXY+DQo8ZGl2IGNsYXNzPSIgaDUiPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9IiBNc29Ob3JtYWwiPk9uIHRvZGF5J3MgY2FsbCB3aXRo IHRoZSBXM0MgV2ViQ3J5cHRvIHdvcmtpbmcgJm5ic3A7Z3JvdXAsIEkgcmVwb3J0ZWQgb24gdGhl IGRpc2N1c3Npb24gb2YgSk9TRSBrZXkgd3JhcHBpbmcgYXQgdGhlIGxhc3QgSUVURi4gJm5ic3A7 SSB3YXMgYXNrZWQgdG8gcmVsYXkgYSBmZXcgYml0cyBvZiBmZWVkYmFjazo8dT48L3U+PHU+PC91 PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+MS4gVmlqYXkgQmhhcmFk d2FqIChNaWNyb3NvZnQpIG9ic2VydmVkIHRoYXQgQUVTIGtleSB3cmFwIGhhcyBmYWxsZW4gb3V0 IG9mIGZhdm9yIHdpdGggc29tZSBwYXJ0cyBvZiB0aGUgY3J5cHRvZ3JhcGhpYyBjb21tdW5pdHku ICZuYnNwO1Blb3BsZSBwcmVmZXIgdG8gYmUgYWJsZSB0byB1c2UgQUVBRCBhbGdvcml0aG1zIGZv ciBrZXkgd3JhcHBpbmcsIHNpbmNlIHRoZXkgYXJlIHBlcmNlaXZlZCB0byBiZSBmYXN0ZXINCiBh bmQgb2ZmZXIgYSBoaWdoZXIgbGV2ZWwgb2Ygc2VjdXJpdHkgdGhhbiBBRVMtS1cuIEhlIGdhdmUg dGhlIGV4YW1wbGUgdGhhdCBJRUVFIDgwMi4xIHVzZXMgQUVTIENDTS48dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj4yLiBNYXJrIFdh dHNvbiAoTmV0ZmxpeCkgbm90ZWQgdGhhdCBpZiB3ZSB1c2UgUlNBIGRpcmVjdGx5IHRvIGVuY3J5 cHQgd3JhcHBlZCBrZXkgb2JqZWN0cywgdGhlbiB3ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBvdGhl ciB0aGFuIE9BRVAgaW4gb3JkZXIgdG8gY2FycnkgYXJiaXRyYXJ5LWxlbmd0aCBwYXlsb2Fkcy4g Jm5ic3A7SSBhZ3JlZWQsIGFuZCBzdWdnZXN0ZWQgdGhhdCBzb21ldGhpbmcgbGlrZSBSU0EtS0VN IHdvdWxkDQogYmUgbmVjZXNzYXJ5LiAmbmJzcDtSeWFuIFNsZWV2aSAoR29vZ2xlKSBhbmQgVmlq YXkgb2JzZXJ2ZWQgdGhhdCBLRU0gaXMgdHJvdWJsZXNvbWUgZHVlIHRvIHRoZSBsYWNrIG9mIHN1 cHBvcnQgYnkgbmF0aXZlIGNyeXB0byBsaWJyYXJpZXMuPHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iIE1zb05vcm1hbCI+SXQgc2VlbXMgdG8gbWUgdGhh dCB0aGVzZSBjb21tZW50cyBoYXZlIGltcGFjdHMgb24gSldFIGFuZCBKV1MgKHBlbmRpbmcgSVNT VUUtMiksIGFzIHdlbGwgYXMgdGhlIHdyYXBwaW5nIGRpc2N1c3Npb24uICZuYnNwO1RoZSBmb3Jt ZXIgaGFzIG1vcmUgaW1wYWN0IHRoYW4gdGhlIGxhdHRlci4mbmJzcDs8dT48L3U+PHU+PC91Pjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+ PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5Qb2ludCBudW1i ZXIgMSBpbXBsaWVzIHRoYXQgd2Ugc2hvdWxkIG9mZmVyIEFFQUQgZm9yIGtleSB3cmFwcGluZyBp biBKV0UgYXMgd2VsbCBhcyBmb3Igd3JhcHBlZCBrZXlzLiAmbmJzcDtJdCBzZWVtcyB0byBtZSB0 aGF0IHRoZSBzaW1wbGVzdCBhcHByb2FjaCB0byB0aGlzIHdvdWxkIGJlIHRvIG1ha2UgdGhlICZx dW90O2FsZyZxdW90OyBmaWVsZCBjb250YWluIGFuIG9iamVjdCB0aGF0IGlzIHNlbWFudGljYWxs eSBlcXVpdmFsZW50DQogdG8gYW4gQWxnb3JpdGhtSWRlbnRpZmllciBpbiBDTVMvUEtDUzguICZu YnNwO0ZvciBleGFtcGxlLCB7IG5hbWU6ICZxdW90O0ExMjhHQ00mcXVvdDssIGl2OiAmcXVvdDtQ Q0lHSmUwRGp1bnVNN3MwJnF1b3Q7IH0uICZuYnNwO1RoaXMgc3ludGF4LCBpbmNpZGVudGFsbHks IGlzIHJvdWdobHkgdGhlIHNhbWUgZm9ybSB0aGF0IGFsZ29yaXRobSBpZGVudGlmaWVycyBoYXZl IGluIHRoZSBXZWJDcnlwdG8gQVBJLiAmbmJzcDtOb3RlIHRoYXQgdGhpcyB0eXBlIG9mIGtleSB3 cmFwcGluZyBpcyBzdXBwb3J0ZWQNCiBpbiBDTVMgYnkgdGhlIHVzZSBvZiBhbiBBRUFEIEFsZ29y aXRobUlkZW50aWZpZXIgaW4gdGhlIEtFS1JlY2lwaWVudEluZm8gc3RydWN0dXJlLiAmbmJzcDs8 dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48 dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9y bWFsIj5Qb2ludCBudW1iZXIgMiBsaWtlbHkgYXBwbGllcyBmb3Igc29tZSBzY2VuYXJpb3Mgb2Yg SldFLCBlc3BlY2lhbGx5IGlmIHdlIGFkb3B0IHRoZSBNY0dyZXcgYXBwcm9hY2guICZuYnNwO0Zv ciBleGFtcGxlLCBpZiB1c2luZyBITUFDLVNIQTEgYW5kIEFFUyB3aXRoIGEgMjU2LWJpdCBrZXks IHRoZSB0b3RhbCBrZXkgbGVuZ3RoIGlzIDc4OCBiaXRzLCB3aGljaCBpcyB0b28gbG9uZyB0byBi ZSBlbmNyeXB0ZWQgd2l0aA0KIE9BRVAgdW5kZXIgYSAxLDAyNC1iaXQgUlNBIGtleS4gJm5ic3A7 SSdtIG5vdCBzdXJlIGhvdyB0byByZXNvbHZlIGl0LiAmbmJzcDtUaGUgYmVzdCBpZGVhIEkndmUg Z290IGlzIHRvIGFsbG93IHdyYXBwZWQga2V5cyB0byBuZXN0LCBzbyB0aGF0IHlvdSBjYW4gd3Jh cCBhIGtleSBpbnNpZGUgb2YgYW5vdGhlciB3cmFwcGVkIGtleS48dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91 PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNvTm9ybWFsIj5JIHdpbGwgdHJ5IHRv IHRha2UgdGhlc2UgcG9pbnRzIGludG8gYWNjb3VudCBpbiBteSBmb3J0aGNvbWluZyBrZXkgd3Jh cHBpbmcgZHJhZnQsIGFuZCBJJ3ZlIGZpbGVkIHR3byBpc3N1ZXMgYWdhaW5zdCBKV0UgdG8gdHJh Y2sgdGhlbS48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSIgTXNv Tm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSIgTXNvTm9ybWFsIj4tLVJpY2hhcmQ8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4E1F6AAD24975D4BA5B16804296739436755CE48TK5EX14MBXC283r_-- From rlb@ipv.sx Tue Mar 19 06:44:47 2013 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 27FAA21F8B75 for ; Tue, 19 Mar 2013 06:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.762, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 hXjvoLkXAZWa for ; Tue, 19 Mar 2013 06:44:46 -0700 (PDT) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) by ietfa.amsl.com (Postfix) with ESMTP id AC12021F860A for ; Tue, 19 Mar 2013 06:44:45 -0700 (PDT) Received: by mail-oa0-f41.google.com with SMTP id i10so456333oag.28 for ; Tue, 19 Mar 2013 06:44:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=DDBggJoaCUMOzzVDXfKSUC/xp0Im+Upd7FeizNlf2o0=; b=h7MYw8NZ3jdd6e3wj6AIU7l3NmNq/c3A1OdI3wLnQ1otmLtAvKITh5yasbUCYeCeu2 GbrJoAzypS8Bg2ClhI+Sm7Oyi9X5wIDcDwnBbm5iVthyWNJH14stjHrSE+5/dQOB3ca8 Wb0+cknsyc9WeTz+xBdkl63uUUdeEj4WfQG0vhSqltw7YJKBnKybRlX4nUq/eraYL/57 rWFfR0X9BsePQgNZRQ1et5koQUrKgZMgRm4nmBHpLS0qR191nA1lfEahcRPclo6tYsjL 5emo4whX638uchKLq1AQLyiZKIkZw7sa8WzdgU3i2rB6MuvBpXqrpCs6R5QrFXE0pk35 b1OQ== MIME-Version: 1.0 X-Received: by 10.60.171.102 with SMTP id at6mr1348547oec.60.1363700685232; Tue, 19 Mar 2013 06:44:45 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 06:44:45 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436755CE48@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755CE48@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 19 Mar 2013 09:44:45 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec54ee094eccad104d8474e31 X-Gm-Message-State: ALoCoQm1PajFPTqRDy1Owj/v/L2i3MU1T5L4qU9mfJ3F6cDrq/aaW8fWjMPSiC4odeItBn74RB5b Cc: "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 13:44:47 -0000 --bcaec54ee094eccad104d8474e31 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't disagree that the minimum size is a good thing for implementors to do. I just don't think that that restriction is necessary in a formatting document like JW*, since it has no impact on interoperability. At most, it should be RECOMMENDED in the security considerations. It should not be a MUST. --Richard On Mon, Mar 18, 2013 at 11:28 PM, Mike Jones w= rote: > I believe that the 2048 restriction was motivated by a NIST evaluation > on acceptable key lengths in which the use of 1024 bit RSA keys has alrea= dy > been deprecated. Eric Rescorla=92s presentation to the working group sev= eral > IETFs ago specifically recommended this, as well as the other key size > restrictions in JWA. > > At the time, the working group felt that requiring that people use keys o= f > acceptable lengths for the current cryptographic client for new > applications was a good thing - especially since JWS and JWE have no lega= cy > applications to support. > > -- Mike > > *From:* Richard Barnes > *Sent:* March 18, 2013 7:31 PM > *To:* Mike Jones > *CC:* jose@ietf.org > *Subject:* Re: [jose] WebCrypto feedback on key wrapping > > ISSUE-(n+1): Remove silly restriction on key sizes. We're a formatting > working group, not a crypto parameters working group. > > --Richard > > > On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones = wrote: > >> Given that we require RSA keys to be a minimum of 2048 bits in length, >> there=92s no problem wrapping 768 bit keys with OAEP in practice.**** >> >> ** ** >> >> -- Mike*= * >> ** >> >> ** ** >> >> *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf >> Of *Richard Barnes >> *Sent:* Monday, March 18, 2013 4:25 PM >> *To:* jose@ietf.org >> *Subject:* [jose] WebCrypto feedback on key wrapping**** >> >> ** ** >> >> On today's call with the W3C WebCrypto working group, I reported on the >> discussion of JOSE key wrapping at the last IETF. I was asked to relay = a >> few bits of feedback:**** >> >> ** ** >> >> 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out >> of favor with some parts of the cryptographic community. People prefer = to >> be able to use AEAD algorithms for key wrapping, since they are perceive= d >> to be faster and offer a higher level of security than AES-KW. He gave t= he >> example that IEEE 802.1 uses AES CCM.**** >> >> ** ** >> >> 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt >> wrapped key objects, then we would need something other than OAEP in ord= er >> to carry arbitrary-length payloads. I agreed, and suggested that someth= ing >> like RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observe= d >> that KEM is troublesome due to the lack of support by native crypto >> libraries.**** >> >> ** ** >> >> It seems to me that these comments have impacts on JWE and JWS (pending >> ISSUE-2), as well as the wrapping discussion. The former has more impac= t >> than the latter. **** >> >> ** ** >> >> Point number 1 implies that we should offer AEAD for key wrapping in JWE >> as well as for wrapped keys. It seems to me that the simplest approach = to >> this would be to make the "alg" field contain an object that is >> semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. For >> example, { name: "A128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, >> incidentally, is roughly the same form that algorithm identifiers have i= n >> the WebCrypto API. Note that this type of key wrapping is supported in = CMS >> by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo >> structure. **** >> >> ** ** >> >> Point number 2 likely applies for some scenarios of JWE, especially if w= e >> adopt the McGrew approach. For example, if using HMAC-SHA1 and AES with= a >> 256-bit key, the total key length is 788 bits, which is too long to be >> encrypted with OAEP under a 1,024-bit RSA key. I'm not sure how to reso= lve >> it. The best idea I've got is to allow wrapped keys to nest, so that yo= u >> can wrap a key inside of another wrapped key.**** >> >> ** ** >> >> I will try to take these points into account in my forthcoming key >> wrapping draft, and I've filed two issues against JWE to track them.**** >> >> ** ** >> >> --Richard**** >> > > --bcaec54ee094eccad104d8474e31 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I don't disagree that the minimum size is a good thing for implementors= to do. =A0I just don't think that that restriction is necessary in a f= ormatting document like JW*, since it has no impact on interoperability. = =A0At most, it should be RECOMMENDED in the security considerations. =A0It = should not be a MUST. =A0

--Richard


On Mon, Mar 18, 2013 a= t 11:28 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:
I believe that the 2048 restriction was motivated by a NIST=A0evaluati= on on acceptable key lengths in which the use of=A01024 bit RSA keys has al= ready been deprecated.=A0 Eric Rescorla=92s presentation to the working gro= up several IETFs ago specifically recommended this, as well as the other key size res= trictions in JWA.
=A0
At the time, the working group felt that=A0requiring that people use k= eys of acceptable lengths for the current cryptographic client for new appl= ications was a good thing - especially since JWS and JWE have no legacy app= lications to support.
=A0
-- Mike
=A0
From:=A0Richard Barnes
Sent:=A0March 18, 2013 7:31 PM
To:=A0Mike Jones
CC:=A0j= ose@ietf.org
Subject:=A0Re: [jose] WebCrypto feedback on key wrapping
=A0
ISSUE-(n+1): Remove silly restriction on key sizes. =A0We're a formatti= ng working group, not a crypto parameters working group.

--Richard


On Mon, Mar 18, 2013 at 8:02 PM, Mike Jones <Michae= l.Jones@microsoft.com> wrote:

Given that we requir= e RSA keys to be a minimum of 2048 bits in length, there=92s no problem wra= pping 768 bit keys with OAEP in practice.

=A0

=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 -- Mike

=A0

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 18, 2013 4:25 PM
To: jose@ietf.org=
Subject: [jose] WebCrypto feedback on key wrapping

=A0

On today's call with the W3C WebCrypto working = =A0group, I reported on the discussion of JOSE key wrapping at the last IET= F. =A0I was asked to relay a few bits of feedback:

=A0

1. Vijay Bharadwaj (Microsoft) observed that AES key= wrap has fallen out of favor with some parts of the cryptographic communit= y. =A0People prefer to be able to use AEAD algorithms for key wrapping, sin= ce they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that= IEEE 802.1 uses AES CCM.

=A0

2. Mark Watson (Netflix) noted that if we use RSA di= rectly to encrypt wrapped key objects, then we would need something other t= han OAEP in order to carry arbitrary-length payloads. =A0I agreed, and sugg= ested that something like RSA-KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed that KEM is troub= lesome due to the lack of support by native crypto libraries.=

=A0

It seems to me that these comments have impacts on J= WE and JWS (pending ISSUE-2), as well as the wrapping discussion. =A0The fo= rmer has more impact than the latter.=A0

=A0

Point number 1 implies that we should offer AEAD for= key wrapping in JWE as well as for wrapped keys. =A0It seems to me that th= e simplest approach to this would be to make the "alg" field cont= ain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8. =A0For example, { name: "A128= GCM", iv: "PCIGJe0DjunuM7s0" }. =A0This syntax, incidentally= , is roughly the same form that algorithm identifiers have in the WebCrypto= API. =A0Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo s= tructure. =A0

=A0

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach. =A0For example, if using H= MAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, whic= h is too long to be encrypted with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolve it. =A0= The best idea I've got is to allow wrapped keys to nest, so that you ca= n wrap a key inside of another wrapped key.

=A0

I will try to take these points into account in my f= orthcoming key wrapping draft, and I've filed two issues against JWE to= track them.

=A0

--Richard



--bcaec54ee094eccad104d8474e31-- From rlb@ipv.sx Tue Mar 19 06:55:33 2013 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 6E7C921F8B51 for ; Tue, 19 Mar 2013 06:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.309 X-Spam-Level: X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 ARlOuIMwv8qx for ; Tue, 19 Mar 2013 06:55:31 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 34EBF21F8BF8 for ; Tue, 19 Mar 2013 06:55:29 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so470638oag.26 for ; Tue, 19 Mar 2013 06:55:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=TWDWMxi3Gh5ERQYeHl1JoNV/BBGE0riPTDO5Kb6sygs=; b=ayiouV3lu+ktYvp50p3VNHhYGvQLM+0Ouo0m6RD1k4/tpBOF2CTbnQkaLVcRrIUJjE Fli6MXxbflSe7cgadVnS1hUekq5ynQuxZge7ixUZrW+ecz9VvwVBPP1bkDhitaiZseKW ZAKKwIb7OZzLs6eZhaRI/B9FVb/epOzDqo+GMID9W71xCYHt0bpoHhyoDLoCIfF5hRJ/ aJsu1Cdafwn4bge8VSpREg7vjbderKRMOF++06kroBtPEehzkU1W8tnpt+Th0iT6BY2W 2CNshRgWHlitOtCxS0UKcpGTmfCPgTRq8h+PPznuPkuIUDO7pe+b5MZEmsRKruG9OGzM tYQQ== MIME-Version: 1.0 X-Received: by 10.182.59.20 with SMTP id v20mr1314025obq.80.1363701327972; Tue, 19 Mar 2013 06:55:27 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 06:55:27 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 19 Mar 2013 09:55:27 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=14dae93a0db13bef4c04d8477513 X-Gm-Message-State: ALoCoQmcoKGXRLncBZGlZSouZXYgj2WAA2SPqha1ZjYUTWKxKxUn3Xr74kZrFd9wXy+BEpIy3uPr Cc: Jim Schaad , James H Manger , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 13:55:33 -0000 --14dae93a0db13bef4c04d8477513 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree that it's a fair question to ask. As I'm writing this key wrapping document (as requested in Orlando), I'm trying to develop a comparison of the costs of various wrapping schemes. It would be interesting to get feedback on the group as to how you would measure cost in this case? For example: -- Which algorithms can/cannot be supported -- How large the encrypted object is -- How many encryption formats a JOSE library has to support On the latter point, the request to use GCM for key wrapping has gotten me thinking that perhaps we should just make JWE self-similar, by using a JWE to wrap the key for a JWE*. That would reduce the number of encryption code paths from two (JWE, key wrapping) to one (JWE). Again, I'll try to make a concrete proposal in the forthcoming document. --Richard On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones w= rote: > Since you message appears to take it as given that =93there should be on= ly > one way of encrypting keys=94, I=92ll point out that I don=92t think that= it=92s > reasonable to assume that. JOSE is first and foremost an engineering > exercise, where the cost/benefit generality/complexity tradeoffs matter, > and the goal is a ubiquitously implemented crypto format for the Web that > solves the problems that people actually have, rather than a mathematical > exercise, where the goal is completeness and generality. Complexity is t= he > enemy of adoption. > > So it=92s fair game to ask =93What are the costs and benefits of having o= nly > one way to encrypt keys=94, versus taking that as a given. > > I happen to personally believe that encrypting a bare symmetric > ephemeral Content Master Key is sufficiently different than encrypting a > key that may be public, private, or symmetric and may have additional > attributes, that it=92s at least worth asking the engineering question > whether special-casing the encryption of this bare symmetric ephemeral ke= y > results in engineering benefits. > > Encrypting a key with attributes for storage or dissemination is not the > same kind of operation as wrapping an ephemeral symmetric key to be used > for block encryption. I=92m personally fine with this being done > differently. The engineering benefit if we do it differently in the way > that Matt=92s draft proposed, at least as I see it, is that we have to in= vent > nothing new. We already have a great format for encrypting arbitrary dat= a, > and keys with attributes are a whole lot like arbitrary data. > > I respect that some with disagree with my personal view, but I=92d also a= sk > you to respect that the engineering tradeoffs may favor having two ways t= o > do things that on the surface may seem similar, but are actually fairly > different in nature. > > Best wishes, > -- Mike > > *From:* Richard Barnes > *Sent:* March 18, 2013 7:36 PM > *To:* Jim Schaad > *CC:* Manger, James H, jose@ietf.org > > *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows > > Well, I got to 788 by doing math incorrectly*. > > Mike was correct on the other thread that 768 is the right number. > However, that's still too big for a 1024-bit RSA key and SHA1, since 768= + > 320 =3D 1088 > 1024. > > Regardless, there is clearly an issue here when wrapping a JWK, which is > much larger, possibly containing an RSA key itself. So if we accept the > goal that there should be one way of encrypting keys, then we'll need to > deal with getting around the OAEP size limitations. > > --Richard > > * This is why my degree is in mathematics, and not accounting. > > > On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad wrote= : > >> Think in terms of encrypting a JWK directly not an intermediate key. >> >> > -----Original Message----- >> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf O= f >> > Manger, James H >> > Sent: Monday, March 18, 2013 5:17 PM >> > To: rlb@ipv.sx; jose@ietf.org >> > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows >> > >> > Richard, >> > >> > How do you get a 788-bit key length? >> > >> > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- >> > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 25= 6 >> > bits to 512 bits. >> > >> > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and >> > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >> > >> > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key= . >> JWA >> > already says RSA key sizes MUST be at least 2048 bits. >> > >> > This already looks sufficient. >> > >> > -- >> > James Manger >> > >> > >> > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >> > > Of Richard Barnes >> > > Sent: Tuesday, 19 March 2013 10:25 AM >> > > Subject: [jose] WebCrypto feedback on key wrapping >> > > >> > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encryp= t >> wrapped >> > key objects, then we would need something other than OAEP in order to >> carry >> > arbitrary-length payloads. I agreed, and suggested that something lik= e >> RSA- >> > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that >> KEM >> is >> > troublesome due to the lack of support by native crypto libraries. >> > > >> > > Point number 2 likely applies for some scenarios of JWE, especially = if >> we >> > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES wi= th >> > a 256-bit key, the total key length is 788 bits, which is too long to = be >> encrypted >> > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. >> The >> best >> > idea I've got is to allow wrapped keys to nest, so that you can wrap a >> key >> inside >> > of another wrapped key. >> > > >> > > --Richard >> > >> > >> > >> ---------- >> > >> Sent: Tuesday, 19 March 2013 10:23 AM >> > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows >> > >> >> > >> #14: Support longer wrapped keys than OAEP allows >> > >> >> > >> The use of RSA-OAEP for key wrapping imposes a limit on the length >> > >> of the key package being wrapped. With SHA1, this length is N-320, >> > >> where N is the length of the RSA modulus. Especially with larger >> > >> hash functions, and especially for wrapping private keys, the size >> > >> of key packages will be larger than this bound. We should >> > >> incorporate a mechanism to accommodate these situations. >> > >> >> > >> >> > >> Ticket URL: >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >> >> > --14dae93a0db13bef4c04d8477513 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree that it's a fair question to ask. =A0As I'm writing this ke= y wrapping document (as requested in Orlando), I'm trying to develop a = comparison of the costs of various wrapping schemes.

It = would be interesting to get feedback on the group as to how you would measu= re cost in this case? =A0For example:
-- Which algorithms can/cannot be supported
-- How large the= encrypted object is
-- How many encryption formats a JOSE librar= y has to support

On the latter point, the request = to use GCM for key wrapping has gotten me thinking that perhaps we should j= ust make JWE self-similar, by using a JWE to wrap the key for a JWE*. =A0Th= at would reduce the number of encryption code paths from two (JWE, key wrap= ping) to one (JWE). =A0Again, I'll try to make a concrete proposal in t= he forthcoming document.

--Richard



<= br>
On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:
Since you message appears to take it as given that=A0=93there should b= e only one way of encrypting keys=94, I=92ll point out that I don=92t think= that it=92s reasonable to assume that.=A0 JOSE is first and foremost an en= gineering exercise, where the cost/benefit generality/complexity tradeoffs matter, and the goal is a ubiquitously implemented crypto=A0form= at for the Web that solves the problems that people actually have, rather t= han a mathematical exercise, where the goal is completeness and generality.= =A0 Complexity is the enemy of adoption.
=A0
So it=92s fair game to ask=A0=93What are the costs and benefits of hav= ing only one way to encrypt keys=94, versus taking that as a given.
=A0
I happen to personally believe that encrypting a bare symmetric epheme= ral=A0Content Master Key is sufficiently different than encrypting a key th= at may be public, private, or symmetric and may have additional attributes,= that it=92s at least worth asking the engineering question whether special-casi= ng the encryption of this bare symmetric ephemeral key results in engineeri= ng benefits.
=A0
Encrypting a key with attributes for storage or dissemination is not t= he same kind of operation as wrapping an ephemeral symmetric key to be used= for block encryption.=A0 I=92m personally fine with this being done differ= ently.=A0 The engineering benefit if we do it differently in the way that Matt=92s d= raft proposed, at least as I see it, is that we have to invent nothing new.= =A0 We already have a great format for encrypting arbitrary data, and keys = with attributes are a whole lot like arbitrary data.
=A0
I respect that some with disagree with my personal view, but I=92d als= o ask you to respect that the engineering tradeoffs may favor having two wa= ys to do things that on the surface may seem similar, but are actually fair= ly different in nature.
=A0
Best wishes,
-- Mike
=A0
From:=A0Richard Barnes
Sent:=A0March 18, 2013 7:36 PM
To:=A0Jim Schaad
CC:=A0Manger, James H, jose@ietf.org

Subject:=A0Re: [jose] #14: Support longer wrapped keys tha= n OAEP allows
=A0
Well, I got to 788 by doing math incorrectly*.=A0

Mike was correct on the other thread that 768 is the right number. =A0= However, that's still too big for a 1024-bit RSA key and SHA1, since 76= 8 + 320 =3D 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a JWK, which = is much larger, possibly containing an RSA key itself. =A0So if we accept t= he goal that there should be one way of encrypting keys, then we'll nee= d to deal with getting around the OAEP size limitations.

--Richard

* This is why my degree is in mathematics, and not accounting.


On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <ietf@august= cellars.com> wrote:
Think in terms of encrypting a JWK directly not an intermediate key.

> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: rlb@ipv.sx; jos= e@ietf.org
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows<= br> >
> Richard,
>
> How do you get a 788-bit key length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 25= 6
> bits to 512 bits.
>
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key= .
JWA
> already says RSA key sizes MUST be at least 2048 bits.
>
> This already looks sufficient.
>
> --
> James Manger
>
>
> > From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on key wrapping
> >
> > 2. Mark Watson (Netflix) noted that if we use RSA directly to enc= rypt
wrapped
> key objects, then we would need something other than OAEP in order to<= br> carry
> arbitrary-length payloads. =A0I agreed, and suggested that something l= ike
RSA-
> KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed tha= t KEM
is
> troublesome due to the lack of support by native crypto libraries.
> >
> > Point number 2 likely applies for some scenarios of JWE, especial= ly if
we
> adopt the McGrew approach. =A0For example, if using HMAC-SHA1 and AES = with
> a 256-bit key, the total key length is 788 bits, which is too long to = be
encrypted
> with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolv= e it. =A0The
best
> idea I've got is to allow wrapped keys to nest, so that you can wr= ap a key
inside
> of another wrapped key.
> >
> > --Richard
>
>
> >> ----------
> >> Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] #14: Support longer wrapped keys than OAEP al= lows
> >>
> >> #14: Support longer wrapped keys than OAEP allows
> >>
> >> =A0The use of RSA-OAEP for key wrapping imposes a limit on th= e length
> >> of =A0the key package being wrapped. With SHA1, this length i= s N-320,
> >> where =A0N is the length of the RSA modulus. =A0Especially wi= th larger
> >> hash =A0functions, and especially for wrapping private keys, = the size
> >> of key =A0packages will be larger than this bound. =A0We shou= ld
> >> incorporate a =A0mechanism to accommodate these situations. > >>
> >>
> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/= ticket/14>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose



--14dae93a0db13bef4c04d8477513-- From mamille2@cisco.com Tue Mar 19 07:02:58 2013 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 666AE21F8C09 for ; Tue, 19 Mar 2013 07:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 gttlG4fbC0Dj for ; Tue, 19 Mar 2013 07:02:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id EF27121F8BDE for ; Tue, 19 Mar 2013 07:02:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11700; q=dns/txt; s=iport; t=1363701777; x=1364911377; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fgoeoOXUbkmt3C7K2iG9HSMT3R63gTw27LDouChh2TM=; b=VlZCpNN3JtNeXidEm0P/Z5swpxtRC5i2hh4LveFltc2yFLi0P9eky/Ti VAziKkKUEBm/4CzkVTWid8Q7mYjrhGBFwL2SX/zo2xmErRAshqsnbal6t MV9LV56qOK1NASLvOCsZehcXJPToE7dgXND5Rp1D8yqRKZPRum9yIDtQp A=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK5vSFGtJXG//2dsb2JhbABDxR6BXBZ0giQBAQEDAQEBAWsLBQcEAgEIDgMEAQELHQcCJQsUCQgBAQQOBQgGiAAGDLItkCKNWQsEdQYQEAsHBAKCWWEDjzyBKII1hGWPY4MKgWs9 X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="p7s'?scan'208";a="189068066" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 19 Mar 2013 14:02:38 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2JE2cVE000883 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 14:02:38 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 09:02:38 -0500 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [jose] #14: Support longer wrapped keys than OAEP allows Thread-Index: Ac4kUSSpzaw33w0xg0eXtJ94+jvSHgAgi0uAAABAE4A= Date: Tue, 19 Mar 2013 14:02:37 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.61] Content-Type: multipart/signed; boundary="Apple-Mail=_9EE7CB25-1404-477C-BF12-92786001B512"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: Mike Jones , James H Manger , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 14:02:58 -0000 --Apple-Mail=_9EE7CB25-1404-477C-BF12-92786001B512 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Personally, I don't think it's worth discussing this much further = without a more complete counter-proposal on the table. As I said in the = meeting, I can see the desire for "on true way" from an architectural = purity standpoint, but pragmatically I mostly agree with Mike. While some might say "keys are keys are keys", I do think the context = that a key is used is an important consideration. Now, does JWE as it = exists right now have an important enough differentiation in context to = warrant special consideration? I'm leaning toward "yes", if one also = assumes that the key associated with a JWE is transient (which I think = is a desirable property here). - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. On Mar 19, 2013, at 7:55 AM, Richard Barnes wrote: > I agree that it's a fair question to ask. As I'm writing this key = wrapping > document (as requested in Orlando), I'm trying to develop a comparison = of > the costs of various wrapping schemes. >=20 > It would be interesting to get feedback on the group as to how you = would > measure cost in this case? For example: > -- Which algorithms can/cannot be supported > -- How large the encrypted object is > -- How many encryption formats a JOSE library has to support >=20 > On the latter point, the request to use GCM for key wrapping has = gotten me > thinking that perhaps we should just make JWE self-similar, by using a = JWE > to wrap the key for a JWE*. That would reduce the number of = encryption > code paths from two (JWE, key wrapping) to one (JWE). Again, I'll try = to > make a concrete proposal in the forthcoming document. >=20 > --Richard >=20 >=20 >=20 >=20 > On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones = wrote: >=20 >> Since you message appears to take it as given that =93there should be = only >> one way of encrypting keys=94, I=92ll point out that I don=92t think = that it=92s >> reasonable to assume that. JOSE is first and foremost an engineering >> exercise, where the cost/benefit generality/complexity tradeoffs = matter, >> and the goal is a ubiquitously implemented crypto format for the Web = that >> solves the problems that people actually have, rather than a = mathematical >> exercise, where the goal is completeness and generality. Complexity = is the >> enemy of adoption. >>=20 >> So it=92s fair game to ask =93What are the costs and benefits of = having only >> one way to encrypt keys=94, versus taking that as a given. >>=20 >> I happen to personally believe that encrypting a bare symmetric >> ephemeral Content Master Key is sufficiently different than = encrypting a >> key that may be public, private, or symmetric and may have additional >> attributes, that it=92s at least worth asking the engineering = question >> whether special-casing the encryption of this bare symmetric = ephemeral key >> results in engineering benefits. >>=20 >> Encrypting a key with attributes for storage or dissemination is not = the >> same kind of operation as wrapping an ephemeral symmetric key to be = used >> for block encryption. I=92m personally fine with this being done >> differently. The engineering benefit if we do it differently in the = way >> that Matt=92s draft proposed, at least as I see it, is that we have = to invent >> nothing new. We already have a great format for encrypting arbitrary = data, >> and keys with attributes are a whole lot like arbitrary data. >>=20 >> I respect that some with disagree with my personal view, but I=92d = also ask >> you to respect that the engineering tradeoffs may favor having two = ways to >> do things that on the surface may seem similar, but are actually = fairly >> different in nature. >>=20 >> Best wishes, >> -- Mike >>=20 >> *From:* Richard Barnes >> *Sent:* March 18, 2013 7:36 PM >> *To:* Jim Schaad >> *CC:* Manger, James H, jose@ietf.org >>=20 >> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP = allows >>=20 >> Well, I got to 788 by doing math incorrectly*. >>=20 >> Mike was correct on the other thread that 768 is the right number. >> However, that's still too big for a 1024-bit RSA key and SHA1, since = 768 + >> 320 =3D 1088 > 1024. >>=20 >> Regardless, there is clearly an issue here when wrapping a JWK, which = is >> much larger, possibly containing an RSA key itself. So if we accept = the >> goal that there should be one way of encrypting keys, then we'll need = to >> deal with getting around the OAEP size limitations. >>=20 >> --Richard >>=20 >> * This is why my degree is in mathematics, and not accounting. >>=20 >>=20 >> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad = wrote: >>=20 >>> Think in terms of encrypting a JWK directly not an intermediate key. >>>=20 >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >>>> Manger, James H >>>> Sent: Monday, March 18, 2013 5:17 PM >>>> To: rlb@ipv.sx; jose@ietf.org >>>> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP = allows >>>>=20 >>>> Richard, >>>>=20 >>>> How do you get a 788-bit key length? >>>>=20 >>>> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- >>>> 128/192/256 and SHA-1/256/384/512. The total key lengths range from = 256 >>>> bits to 512 bits. >>>>=20 >>>> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and >>>> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA = key. >>>>=20 >>>> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA = key. >>> JWA >>>> already says RSA key sizes MUST be at least 2048 bits. >>>>=20 >>>> This already looks sufficient. >>>>=20 >>>> -- >>>> James Manger >>>>=20 >>>>=20 >>>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf >>>>> Of Richard Barnes >>>>> Sent: Tuesday, 19 March 2013 10:25 AM >>>>> Subject: [jose] WebCrypto feedback on key wrapping >>>>>=20 >>>>> 2. Mark Watson (Netflix) noted that if we use RSA directly to = encrypt >>> wrapped >>>> key objects, then we would need something other than OAEP in order = to >>> carry >>>> arbitrary-length payloads. I agreed, and suggested that something = like >>> RSA- >>>> KEM would be necessary. Ryan Sleevi (Google) and Vijay observed = that >>> KEM >>> is >>>> troublesome due to the lack of support by native crypto libraries. >>>>>=20 >>>>> Point number 2 likely applies for some scenarios of JWE, = especially if >>> we >>>> adopt the McGrew approach. For example, if using HMAC-SHA1 and AES = with >>>> a 256-bit key, the total key length is 788 bits, which is too long = to be >>> encrypted >>>> with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve = it. >>> The >>> best >>>> idea I've got is to allow wrapped keys to nest, so that you can = wrap a >>> key >>> inside >>>> of another wrapped key. >>>>>=20 >>>>> --Richard >>>>=20 >>>>=20 >>>>>> ---------- >>>>>> Sent: Tuesday, 19 March 2013 10:23 AM >>>>>> Subject: [jose] #14: Support longer wrapped keys than OAEP allows >>>>>>=20 >>>>>> #14: Support longer wrapped keys than OAEP allows >>>>>>=20 >>>>>> The use of RSA-OAEP for key wrapping imposes a limit on the = length >>>>>> of the key package being wrapped. With SHA1, this length is = N-320, >>>>>> where N is the length of the RSA modulus. Especially with = larger >>>>>> hash functions, and especially for wrapping private keys, the = size >>>>>> of key packages will be larger than this bound. We should >>>>>> incorporate a mechanism to accommodate these situations. >>>>>>=20 >>>>>>=20 >>>>>> Ticket URL: >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>>=20 >>=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_9EE7CB25-1404-477C-BF12-92786001B512 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxOTE0MDIzN1owIwYJKoZIhvcNAQkEMRYEFKBhS6nVa5R/eE5oIYmfm20TO5SWMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCwosCyMtsY9GrdyyVUl5wEX5MP7K32uIxKKuoH1T53 IxDarVEZjPzufUy7XA1OCUefVxnfbQc/GhNx4i7dTjNQEjzdmHN+obc47ryriU6GIqYb/H9eLpp5 +zOec1SmaB4nYhRdlDkPcvzKm+cGWWdbbQ2rfBwtV/f+gGvnz/GylK4mqD+Wy0MuwwBzfNmibDBV LDsZAoULsbcZdO1JpZZlsulwkFMqrkO+PrS228Y8vq0cM+b7bJJaKHoLg7JgdCybJ1Pvk8fPbOKl gI4J9UHu80HyYQ1iYVbUW8LrNvad9oVBImAcigbxFNYdX/HKfzkCjGTxs6XyAywdgveDBB62AAAA AAAA --Apple-Mail=_9EE7CB25-1404-477C-BF12-92786001B512-- From mamille2@cisco.com Tue Mar 19 07:17:31 2013 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 8307321F8C85 for ; Tue, 19 Mar 2013 07:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.374 X-Spam-Level: X-Spam-Status: No, score=-10.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 R476tpsPYYdM for ; Tue, 19 Mar 2013 07:17:30 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4D621F8BF2 for ; Tue, 19 Mar 2013 07:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4391; q=dns/txt; s=iport; t=1363702650; x=1364912250; h=from:to:subject:date:message-id:mime-version; bh=uvCadwsKyu9O6fNLA5HTUyYEsz+PblzarDcUPWam58U=; b=XAtxuHDd9Y9anT+ygXmtMCMwgS83IB0ODnW55CadvtCyDW2Sms+Vr2nt aejUivHNhhCuBGKyjpJytYr3p7/Ve2vX1mNsguduwep8ztlvQne7cmz8h U6l0elyIpC0dGpxWdOO+4PX0hLVXrwEaafSXugkDxIJsRGtDoOUHoEtwl Y=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwFAJJySFGtJV2a/2dsb2JhbABDh1i9PIFWFm0HgiYBBIELASomMCcEEwgGiAahGJEVkCGOXYMXYQOPPIEoln2DCoIo X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="p7s'?scan'208";a="189052333" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 19 Mar 2013 14:17:29 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2JEHSNG018349 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Mar 2013 14:17:29 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 09:17:28 -0500 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: JWK Parameter Registry Considerations Thread-Index: AQHOJKx8FqJE351Np0SzIVUR6z+Zdw== Date: Tue, 19 Mar 2013 14:17:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.61] Content-Type: multipart/signed; boundary="Apple-Mail=_9232BA5C-B8CB-41B9-A7CB-F3F404858AC5"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [jose] JWK Parameter Registry Considerations 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, 19 Mar 2013 14:17:31 -0000 --Apple-Mail=_9232BA5C-B8CB-41B9-A7CB-F3F404858AC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In thinking about the JWK parameter registry, I have a couple of = questions/concerns. 1) Should JWK parameter names be absolutely unique, or are they = potentially tied to a specific JWK type? In looking at the specs to = date, I think there's only one case where a parameter name is re-used = ("d" for both private RSA and ECC keys); currently syntactically and = semantically identical, but I'm not sure that's adequate. 2) Should JWK parameters be marked as private (confidential, secret, = privileged, etc etc)? The current documentation set loosely defines = this only because they are current split between multiple documents. = However, I wonder if there is value in being much more explicit about = it, including in a parameter's registration. Thoughts? - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_9232BA5C-B8CB-41B9-A7CB-F3F404858AC5 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxOTE0MTcyN1owIwYJKoZIhvcNAQkEMRYEFHZw1yw6n2f9YqUCq0iJVv007M/0MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQBxTsDkikiaLIQCrf7eHP1kK0ZlodQPu2vSasg7TyaE ttraPvTU/0xuTcaPwd+k6dB1glchlZB+So1JGSqBef1Z+7kjQcogW4o3/H069IiBKU6DW9+fSN2L zolvTbYl7M3DgnWu3CsDA+Rp4GbweG2Buu/73cSf5sTWHOV5o0Krb1mJZcSauBOreK1YqlTOqIr0 xseYkB+PcDVWr8AuAbGNbYkBYmmVVjt+wUbMEa06kR1eAIbYoh2nvZ6C1JutBBKTryUnAilHcwAv I092/YJQpsjrCnLiCnL6VCLucUfrhz5WEL7bMplDwK83HWkkzv/mTKWd6OENEowTJtAAAMBpAAAA AAAA --Apple-Mail=_9232BA5C-B8CB-41B9-A7CB-F3F404858AC5-- From mamille2@cisco.com Tue Mar 19 07:19:58 2013 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 5EC9B21F8A6F for ; Tue, 19 Mar 2013 07:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.419 X-Spam-Level: X-Spam-Status: No, score=-10.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 mF29cbd2ZN2q for ; Tue, 19 Mar 2013 07:19:57 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9542321F8A6E for ; Tue, 19 Mar 2013 07:19:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4583; q=dns/txt; s=iport; t=1363702797; x=1364912397; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SZr5gZ2BkwlsLbhSnfInkqxW3n72FbTp7DZ6sOQUIwE=; b=fuDowXavr+0la8v3yX5HfoayZHYJsBPpQnJQiogwU4tH28HinOeWchsJ EbbW9erGLTAqYX4jivtlIClQIGdEdMQf60osT4CrHLXj2+k1kocXs6IAK J7TOQXn+noNp5lkPfdC4tmn1l2rUXzpLSnPB4Ebk4KDZ8KrkvyBOmfGCQ 0=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKxzSFGtJV2c/2dsb2JhbABDxRSBVhZtB4IkAQEBAwEdYQsCAQgiJAIwJQIEEwgGiAAGsjGQIo5dOIJfYQOPPIEoln2DCoIo X-IronPort-AV: E=Sophos;i="4.84,872,1355097600"; d="p7s'?scan'208";a="189075212" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 19 Mar 2013 14:19:57 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2JEJuCp008195 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 19 Mar 2013 14:19:56 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 09:19:56 -0500 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: [jose] JWK Parameter Registry Considerations Thread-Index: AQHOJKx8FqJE351Np0SzIVUR6z+Zd5itZCEA Date: Tue, 19 Mar 2013 14:19:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.61] Content-Type: multipart/signed; boundary="Apple-Mail=_865091FE-DD56-4A13-80ED-7CB979526480"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: Re: [jose] JWK Parameter Registry Considerations 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, 19 Mar 2013 14:19:58 -0000 --Apple-Mail=_865091FE-DD56-4A13-80ED-7CB979526480 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 19, 2013, at 8:17 AM, Matt Miller (mamille2) = wrote: > In thinking about the JWK parameter registry, I have a couple of = questions/concerns. >=20 > 1) Should JWK parameter names be absolutely unique, or are they = potentially tied to a specific JWK type? In looking at the specs to = date, I think there's only one case where a parameter name is re-used = ("d" for both private RSA and ECC keys); currently syntactically and = semantically identical, but I'm not sure that's adequate. >=20 > 2) Should JWK parameters be marked as private (confidential, secret, = privileged, etc etc)? The current documentation set loosely defines = this only because they are current split between multiple documents. = However, I wonder if there is value in being much more explicit about = it, including in a parameter's registration. >=20 >=20 And, yes, I do (now) remember there was a general call for merging JPSK = into JWA (-: - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_865091FE-DD56-4A13-80ED-7CB979526480 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxOTE0MTk1NlowIwYJKoZIhvcNAQkEMRYEFAP5Hf/V85ZHIpES64bSC1UFo3mjMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCfwM+57S2udjYgUBwTV2HwRNI61lKMVo0gfZzRehNh 0SIcsRQpdcy4Jf1VV63f7knUXv3f2YGFkfaoBmZFqcU9Am0RRe8kWRuaE9Ql63z8+2pqEV1IT0K8 peHyc25HcaH1ULvWvb3At6tXfYfBP8HgnTiLrnFUZdnQVt70In/wK4CfXb4YDlJmWAxZp2oKulxf NxakUaLw9utiVuGnaKGZOWhg2I94w3svr7TxVocUtvWlH5hABaCm5XFOviXuJ1fku4tBR45H+ilX NYJ/ZpYgZ8mphQ7CtZK+wfCMNlfynaHS0XDfz8CSRNgwt6EC0npPVu55AcnGLUQOtgfkx5V9AAAA AAAA --Apple-Mail=_865091FE-DD56-4A13-80ED-7CB979526480-- From watsonm@netflix.com Tue Mar 19 07:33:08 2013 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 AA36521F8C98 for ; Tue, 19 Mar 2013 07:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 6EUXFwyo3OiJ for ; Tue, 19 Mar 2013 07:33:07 -0700 (PDT) Received: from exout103.netflix.com (exout103.netflix.com [69.53.237.162]) by ietfa.amsl.com (Postfix) with ESMTP id D362721F8C06 for ; Tue, 19 Mar 2013 07:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; bh=dmiF/KAOm3EoPWPlx8GwTfKnNGo=; b=TyrAiVVHAB5/2EMyQMYgQRcvicHllMpWtr3DcLjegvEG0ml/xniDM56mJ2Ngu5n+grBC0Z8W QahGfm3qNEKjfD/nZmPjngJU1+fo8lfWu2YsmrjR7Pk9tWetUHIVdfbYkEBr8hMVXST2LSmw unI9ApYnurlFERcN3GSOzlWmVrvPJCOUUywFCGEyv34wu4yuWEp+zJI/hCaLAGeg0DfZnMWd 9TzRnJy1D6nXJgcVxJL31ubQDEfwxgyxlcV74r6ckvKXGLNygPodZBLCOMCT/GoMMewqSWfS 1cwZ8ayHMISVnEx00Ny4kOFy4rLPxcMP02ReEVZrTggYxv7devhknQ== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; b=oKowgRFqH1wheVd55cLkceUdGhH+mhCIOcFrZw/UocmchUuuVWdWkPTN39baIJ+TMFaLR/vO m5NV7ao8gBsL4zm8hn1wIjRM8BVGT+nxIueAw7YGCafVHh/mLTyzHWwsuqvuSzPr0NLPfVyo zCsbhmo14z4lqC0MLW/m+VKcXehpGj6QzhXbkH9UD6HFquE/Swqox84CSVp7658mBGtdxYJn bcbk0LGuwTuXQ4TtZe8Wod26cjfMWWNkfrVgAJddJZoVOUj5DWuBZ5vJ9X0Or/qrjN4pOsTw hR4OkSF2devyVXfzr1UZP9YI2cu+Kn4++QYUqYItoW7OuZ+WDg2eXA== Received: from EXFE104.corp.netflix.com (10.64.32.104) by exout103.netflix.com (10.64.240.73) with Microsoft SMTP Server (TLS) id 14.2.298.4; Tue, 19 Mar 2013 07:35:40 -0700 Received: from EXMB106.corp.netflix.com ([169.254.6.196]) by exfe104.corp.netflix.com ([10.64.32.104]) with mapi id 14.02.0283.003; Tue, 19 Mar 2013 07:33:06 -0700 From: Mark Watson To: Mike Jones Thread-Topic: [jose] WebCrypto feedback on key wrapping Thread-Index: AQHOJC/gHm/6YfyVNUer4VrZXdmufpislwMAgADztQA= Date: Tue, 19 Mar 2013 14:33:06 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.32.81] Content-Type: multipart/alternative; boundary="_000_D5933EDBB4184F2180E2CB3104421A8Bnetflixcom_" MIME-Version: 1.0 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 14:33:08 -0000 --_000_D5933EDBB4184F2180E2CB3104421A8Bnetflixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable On Mar 18, 2013, at 5:02 PM, Mike Jones wrote: Given that we require RSA keys to be a minimum of 2048 bits in length, ther= e=92s no problem wrapping 768 bit keys with OAEP in practice. Sure, but there would be a problem if what you are wrapping is a JWK object= , which could get much bigger than 768 bits. =85Mark -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, March 18, 2013 4:25 PM To: jose@ietf.org Subject: [jose] WebCrypto feedback on key wrapping On today's call with the W3C WebCrypto working group, I reported on the di= scussion of JOSE key wrapping at the last IETF. I was asked to relay a few= bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of= favor with some parts of the cryptographic community. People prefer to be= able to use AEAD algorithms for key wrapping, since they are perceived to = be faster and offer a higher level of security than AES-KW. He gave the exa= mple that IEEE 802.1 uses AES CCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapp= ed key objects, then we would need something other than OAEP in order to ca= rry arbitrary-length payloads. I agreed, and suggested that something like= RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that = KEM is troublesome due to the lack of support by native crypto libraries. It seems to me that these comments have impacts on JWE and JWS (pending ISS= UE-2), as well as the wrapping discussion. The former has more impact than= the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as= well as for wrapped keys. It seems to me that the simplest approach to th= is would be to make the "alg" field contain an object that is semantically = equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly t= he same form that algorithm identifiers have in the WebCrypto API. Note th= at this type of key wrapping is supported in CMS by the use of an AEAD Algo= rithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we a= dopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 2= 56-bit key, the total key length is 788 bits, which is too long to be encry= pted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. = The best idea I've got is to allow wrapped keys to nest, so that you can w= rap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping= draft, and I've filed two issues against JWE to track them. --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_D5933EDBB4184F2180E2CB3104421A8Bnetflixcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
On Mar 18, 2013, at 5:02 PM, Mike Jones wrote:

Given that we require RSA keys to be a minimum of 2048 bi= ts in length, there=92s no problem wrapping 768 bit keys with OAEP in pract= ice.

Sure, but there would be a problem if what you are wrapping is a JWK o= bject, which could get much bigger than 768 bits.

=85Mark

 
         &nb= sp;            =             &nb= sp;            =             &nb= sp;    -- Mike
 
From:=  jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] = On Behalf Of Richard Barnes
Sent: Monday, Marc= h 18, 2013 4:25 PM
To: jose@ietf.org
Subject: [jose] We= bCrypto feedback on key wrapping
 
On today's call with the W3C WebCrypto working  group, I reported on t= he discussion of JOSE key wrapping at the last IETF.  I was asked to r= elay a few bits of feedback:
 
1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of= favor with some parts of the cryptographic community.  People prefer = to be able to use AEAD algorithms for key wrapping, since they are perceive= d to be faster and offer a higher level of security than AES-KW. He gave the example that IEEE 802.1 uses AES CCM.=
 
2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapp= ed key objects, then we would need something other than OAEP in order to ca= rry arbitrary-length payloads.  I agreed, and suggested that something= like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is troublesome due to the lack= of support by native crypto libraries.
 
It seems to me that these comments have impacts on JWE and JWS (pending ISS= UE-2), as well as the wrapping discussion.  The former has more impact= than the latter. 
 
Point number 1 implies that we should offer AEAD for key wrapping in JWE as= well as for wrapped keys.  It seems to me that the simplest approach = to this would be to make the "alg" field contain an object that i= s semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For example, { name: "A128GCM", iv: "PC= IGJe0DjunuM7s0" }.  This syntax, incidentally, is roughly the sam= e form that algorithm identifiers have in the WebCrypto API.  Note tha= t this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo structure.  
 
Point number 2 likely applies for some scenarios of JWE, especially if we a= dopt the McGrew approach.  For example, if using HMAC-SHA1 and AES wit= h a 256-bit key, the total key length is 788 bits, which is too long to be = encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The best idea I've go= t is to allow wrapped keys to nest, so that you can wrap a key inside of an= other wrapped key.
 
I will try to take these points into account in my forthcoming key wrapping= draft, and I've filed two issues against JWE to track them.
 
--Richard
_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--_000_D5933EDBB4184F2180E2CB3104421A8Bnetflixcom_-- From ietf@augustcellars.com Tue Mar 19 08:17:25 2013 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 20F4221F8D27 for ; Tue, 19 Mar 2013 08:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.556 X-Spam-Level: X-Spam-Status: No, score=-3.556 tagged_above=-999 required=5 tests=[AWL=0.042, 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 1pohXyaBngVx for ; Tue, 19 Mar 2013 08:17:23 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id D88B421F8650 for ; Tue, 19 Mar 2013 08:17:23 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 7A35038F14; Tue, 19 Mar 2013 08:17:22 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , "'Richard Barnes'" References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 19 Mar 2013 08:16:37 -0700 Message-ID: <006301ce24b4$c765e4e0$5631aea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0064_01CE247A.1B105BB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+c2N8y3GiY16DYL992JDhGYqxcJdMgijQ Content-Language: en-us Cc: 'James H Manger' , jose@ietf.org Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 15:17:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0064_01CE247A.1B105BB0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =20 The issue has been raised for discussion. I do not believe that = documenting what the extents of the issue are is out of scope of any and = all follow on discussion. Until that has been done it is not possible = to talk about what the costs and benefits are. If you have a full set = of costs and benefits that would be an interesting message to see. =20 From: Mike Jones [mailto:Michael.Jones@microsoft.com]=20 Sent: Monday, March 18, 2013 8:24 PM To: Jim Schaad; Richard Barnes Cc: James H Manger; jose@ietf.org Subject: RE: [jose] #14: Support longer wrapped keys than OAEP allows =20 Since you message appears to take it as given that =E2=80=9Cthere should = be only one way of encrypting keys=E2=80=9D, I=E2=80=99ll point out that = I don=E2=80=99t think that it=E2=80=99s reasonable to assume that. JOSE = is first and foremost an engineering exercise, where the cost/benefit = generality/complexity tradeoffs matter, and the goal is a ubiquitously = implemented crypto format for the Web that solves the problems that = people actually have, rather than a mathematical exercise, where the = goal is completeness and generality. Complexity is the enemy of = adoption. =20 So it=E2=80=99s fair game to ask =E2=80=9CWhat are the costs and = benefits of having only one way to encrypt keys=E2=80=9D, versus taking = that as a given. =20 I happen to personally believe that encrypting a bare symmetric = ephemeral Content Master Key is sufficiently different than encrypting a = key that may be public, private, or symmetric and may have additional = attributes, that it=E2=80=99s at least worth asking the engineering = question whether special-casing the encryption of this bare symmetric = ephemeral key results in engineering benefits. =20 Encrypting a key with attributes for storage or dissemination is not the = same kind of operation as wrapping an ephemeral symmetric key to be used = for block encryption. I=E2=80=99m personally fine with this being done = differently. The engineering benefit if we do it differently in the way = that Matt=E2=80=99s draft proposed, at least as I see it, is that we = have to invent nothing new. We already have a great format for = encrypting arbitrary data, and keys with attributes are a whole lot like = arbitrary data. =20 I respect that some with disagree with my personal view, but I=E2=80=99d = also ask you to respect that the engineering tradeoffs may favor having = two ways to do things that on the surface may seem similar, but are = actually fairly different in nature. =20 Best wishes, -- Mike =20 From: Richard Barnes Sent: =E2=80=8EMarch=E2=80=8E =E2=80=8E18=E2=80=8E, =E2=80=8E2013 = =E2=80=8E7=E2=80=8E:=E2=80=8E36=E2=80=8E =E2=80=8EPM To: Jim Schaad CC: Manger, James H, jose@ietf.org Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows =20 Well, I got to 788 by doing math incorrectly*. =20 =20 Mike was correct on the other thread that 768 is the right number. = However, that's still too big for a 1024-bit RSA key and SHA1, since 768 = + 320 =3D 1088 > 1024.=20 =20 Regardless, there is clearly an issue here when wrapping a JWK, which is = much larger, possibly containing an RSA key itself. So if we accept the = goal that there should be one way of encrypting keys, then we'll need to = deal with getting around the OAEP size limitations. =20 --Richard * This is why my degree is in mathematics, and not accounting. On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad = wrote: Think in terms of encrypting a JWK directly not an intermediate key. > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > Manger, James H > Sent: Monday, March 18, 2013 5:17 PM > To: rlb@ipv.sx; jose@ietf.org > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows > > Richard, > > How do you get a 788-bit key length? > > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- > 128/192/256 and SHA-1/256/384/512. The total key lengths range from = 256 > bits to 512 bits. > > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. > > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA = key. JWA > already says RSA key sizes MUST be at least 2048 bits. > > This already looks sufficient. > > -- > James Manger > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > Of Richard Barnes > > Sent: Tuesday, 19 March 2013 10:25 AM > > Subject: [jose] WebCrypto feedback on key wrapping > > > > 2. Mark Watson (Netflix) noted that if we use RSA directly to = encrypt wrapped > key objects, then we would need something other than OAEP in order to carry > arbitrary-length payloads. I agreed, and suggested that something = like RSA- > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that = KEM is > troublesome due to the lack of support by native crypto libraries. > > > > Point number 2 likely applies for some scenarios of JWE, especially = if we > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES = with > a 256-bit key, the total key length is 788 bits, which is too long to = be encrypted > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. = The best > idea I've got is to allow wrapped keys to nest, so that you can wrap a = key inside > of another wrapped key. > > > > --Richard > > > >> ---------- > >> Sent: Tuesday, 19 March 2013 10:23 AM > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows > >> > >> #14: Support longer wrapped keys than OAEP allows > >> > >> The use of RSA-OAEP for key wrapping imposes a limit on the length > >> of the key package being wrapped. With SHA1, this length is N-320, > >> where N is the length of the RSA modulus. Especially with larger > >> hash functions, and especially for wrapping private keys, the size > >> of key packages will be larger than this bound. We should > >> incorporate a mechanism to accommodate these situations. > >> > >> > >> Ticket URL: > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose =20 ------=_NextPart_000_0064_01CE247A.1B105BB0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<personal>

 

The issue has been raised for discussion.=C2=A0 I do not believe that = documenting what the extents of the issue are is out of scope of any and = all follow on discussion. =C2=A0Until that has been done it is not = possible to talk about what the costs and benefits are.=C2=A0 If you = have a full set of costs and benefits that would be an interesting = message to see.

 

From:= = Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Monday, = March 18, 2013 8:24 PM
To: Jim Schaad; Richard = Barnes
Cc: James H Manger; jose@ietf.org
Subject: = RE: [jose] #14: Support longer wrapped keys than OAEP = allows

 

Since you message appears = to take it as given that =E2=80=9Cthere should be only one way of = encrypting keys=E2=80=9D, I=E2=80=99ll point out that I don=E2=80=99t = think that it=E2=80=99s reasonable to assume that.  JOSE is first = and foremost an engineering exercise, where the cost/benefit = generality/complexity tradeoffs matter, and the goal is a ubiquitously = implemented crypto format for the Web that solves the problems that = people actually have, rather than a mathematical exercise, where the = goal is completeness and generality.  Complexity is the enemy of = adoption.

 

=

So it=E2=80=99s fair game = to ask =E2=80=9CWhat are the costs and benefits of having only one = way to encrypt keys=E2=80=9D, versus taking that as a = given.

 

=

I happen to personally = believe that encrypting a bare symmetric ephemeral Content Master = Key is sufficiently different than encrypting a key that may be public, = private, or symmetric and may have additional attributes, that = it=E2=80=99s at least worth asking the engineering question whether = special-casing the encryption of this bare symmetric ephemeral key = results in engineering benefits.

 

=

Encrypting a key with = attributes for storage or dissemination is not the same kind of = operation as wrapping an ephemeral symmetric key to be used for block = encryption.  I=E2=80=99m personally fine with this being done = differently.  The engineering benefit if we do it differently in = the way that Matt=E2=80=99s draft proposed, at least as I see it, is = that we have to invent nothing new.  We already have a great format = for encrypting arbitrary data, and keys with attributes are a whole lot = like arbitrary data.

 

=

I respect that some with = disagree with my personal view, but I=E2=80=99d also ask you to respect = that the engineering tradeoffs may favor having two ways to do things = that on the surface may seem similar, but are actually fairly different = in nature.

 

=

Best = wishes,

-- = Mike

 

=

From: Richard = Barnes
Sent: =E2= =80=8EMarch=E2=80=8E =E2=80=8E18=E2=80=8E, =E2=80=8E2013 = =E2=80=8E7=E2=80=8E:=E2=80=8E36=E2=80=8E =E2=80=8EPM
To: Jim= Schaad
CC: Man= ger, James H, jose@ietf.org
Subject:&nbs= p;Re: [jose] #14: Support longer wrapped keys than OAEP = allows

 

=

Well, I got to 788 by doing = math incorrectly*. 

 

=

Mike was correct on the = other thread that 768 is the right number.  However, that's still = too big for a 1024-bit RSA key and SHA1, since 768 + 320 =3D 1088 > = 1024.

 

=

Regardless, there is = clearly an issue here when wrapping a JWK, which is much larger, = possibly containing an RSA key itself.  So if we accept the goal = that there should be one way of encrypting keys, then we'll need to deal = with getting around the OAEP size = limitations.

 

=

--Richard

* This is = why my degree is in mathematics, and not = accounting.

On Mon, Mar 18, 2013 at = 8:40 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

Think in terms of = encrypting a JWK directly not an intermediate = key.


> -----Original = Message-----
> From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf Of

> Manger, James = H
> Sent: Monday, March 18, 2013 5:17 PM
> To: rlb@ipv.sx; jose@ietf.org
> Subject: Re: = [jose] #14: Support longer wrapped keys than OAEP allows
>
> = Richard,
>
> How do you get a 788-bit key = length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 = combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The = total key lengths range from 256
> bits to 512 = bits.
>
> Keys for two of the algorithms = (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) = fit within OAEP with a 1024-bit RSA key.
>
> Keys for all of = the algorithms fit within OAEP with a 2048-bit RSA key.
JWA
> = already says RSA key sizes MUST be at least 2048 bits.
>
> = This already looks sufficient.
>
> --
> James = Manger
>
>
> > From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 = March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on = key wrapping
> >
> > 2. Mark Watson (Netflix) noted = that if we use RSA directly to encrypt
wrapped
> key objects, = then we would need something other than OAEP in order = to
carry
> arbitrary-length payloads.  I agreed, and = suggested that something like
RSA-
> KEM would be necessary. =  Ryan Sleevi (Google) and Vijay observed that KEM
is
> = troublesome due to the lack of support by native crypto = libraries.
> >
> > Point number 2 likely applies for = some scenarios of JWE, especially if
we
> adopt the McGrew = approach.  For example, if using HMAC-SHA1 and AES with
> a = 256-bit key, the total key length is 788 bits, which is too long to = be
encrypted
> with OAEP under a 1,024-bit RSA key.  I'm = not sure how to resolve it.  The
best
> idea I've got is = to allow wrapped keys to nest, so that you can wrap a = key
inside
> of another wrapped key.
> >
> > = --Richard
>
>
> >> ----------
> >> = Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] = #14: Support longer wrapped keys than OAEP allows
> = >>
> >> #14: Support longer wrapped keys than OAEP = allows
> >>
> >>  The use of RSA-OAEP for = key wrapping imposes a limit on the length
> >> of  the = key package being wrapped. With SHA1, this length is N-320,
> = >> where  N is the length of the RSA modulus. =  Especially with larger
> >> hash  functions, and = especially for wrapping private keys, the size
> >> of key =  packages will be larger than this bound.  We should
> = >> incorporate a  mechanism to accommodate these = situations.
> >>
> >>
> >> Ticket = URL: <http://trac.to= ols.ietf.org/wg/jose/trac/ticket/14>

> = _______________________________________________
> jose mailing = list
> jose@ietf.org
> = https://www.ietf.org/= mailman/listinfo/jose

 

=
------=_NextPart_000_0064_01CE247A.1B105BB0-- From Michael.Jones@microsoft.com Tue Mar 19 09:27:55 2013 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 DCB7A11E80AE for ; Tue, 19 Mar 2013 09:27:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DpV1UHs3dMOw for ; Tue, 19 Mar 2013 09:27:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4A40511E80A4 for ; Tue, 19 Mar 2013 09:27:53 -0700 (PDT) Received: from BL2FFO11FD001.protection.gbl (10.173.161.203) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.641.9; Tue, 19 Mar 2013 16:27:50 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD001.mail.protection.outlook.com (10.173.160.101) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Tue, 19 Mar 2013 16:27:50 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.02.0318.003; Tue, 19 Mar 2013 16:27:31 +0000 From: Mike Jones To: Mark Watson Thread-Topic: [jose] WebCrypto feedback on key wrapping Thread-Index: AQHOJC/fb0UrhnxpB0CL7KQe/F+ugpisIMPAgAD0NACAAB+G4A== Date: Tue, 19 Mar 2013 16:27:31 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367561ECB@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367561ECBTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(24454001)(199002)(377454001)(63696002)(59766001)(50986001)(47446002)(5343655001)(51856001)(47736001)(4396001)(54316002)(74502001)(55846006)(47976001)(31966008)(20776003)(5343635001)(49866001)(54356001)(56816002)(46102001)(80022001)(56776001)(77982001)(16236675001)(44976002)(512954001)(66066001)(16406001)(79102001)(76482001)(74662001)(53806001)(65816001)(33656001)(69226001)(15202345001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0790FB1F33 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 19 Mar 2013 16:27:56 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367561ECBTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, but at least as I see it, you wouldn't wrap a JWK with OAEP directly. = You'd encrypt an ephemeral symmetric key with OAEP and then use an authent= icated symmetric key encryption algorithm to encrypt the JWK. This is exac= tly what a JWE does. -- Mike From: Mark Watson [mailto:watsonm@netflix.com] Sent: Tuesday, March 19, 2013 7:33 AM To: Mike Jones Cc: Richard Barnes; jose@ietf.org Subject: Re: [jose] WebCrypto feedback on key wrapping On Mar 18, 2013, at 5:02 PM, Mike Jones wrote: Given that we require RSA keys to be a minimum of 2048 bits in length, ther= e's no problem wrapping 768 bit keys with OAEP in practice. Sure, but there would be a problem if what you are wrapping is a JWK object= , which could get much bigger than 768 bits. ...Mark -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, March 18, 2013 4:25 PM To: jose@ietf.org Subject: [jose] WebCrypto feedback on key wrapping On today's call with the W3C WebCrypto working group, I reported on the di= scussion of JOSE key wrapping at the last IETF. I was asked to relay a few= bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of= favor with some parts of the cryptographic community. People prefer to be= able to use AEAD algorithms for key wrapping, since they are perceived to = be faster and offer a higher level of security than AES-KW. He gave the exa= mple that IEEE 802.1 uses AES CCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapp= ed key objects, then we would need something other than OAEP in order to ca= rry arbitrary-length payloads. I agreed, and suggested that something like= RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that = KEM is troublesome due to the lack of support by native crypto libraries. It seems to me that these comments have impacts on JWE and JWS (pending ISS= UE-2), as well as the wrapping discussion. The former has more impact than= the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as= well as for wrapped keys. It seems to me that the simplest approach to th= is would be to make the "alg" field contain an object that is semantically = equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly t= he same form that algorithm identifiers have in the WebCrypto API. Note th= at this type of key wrapping is supported in CMS by the use of an AEAD Algo= rithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we a= dopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 2= 56-bit key, the total key length is 788 bits, which is too long to be encry= pted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. = The best idea I've got is to allow wrapped keys to nest, so that you can w= rap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping= draft, and I've filed two issues against JWE to track them. --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367561ECBTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes, but at least as I se= e it, you wouldn’t wrap a JWK with OAEP directly.  You’d e= ncrypt an ephemeral symmetric key with OAEP and then use an authenticated symmetric key encryption algorithm to encrypt the JWK.  This is exact= ly what a JWE does.

 <= /p>

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

 <= /p>

From: Mark Wat= son [mailto:watsonm@netflix.com]
Sent: Tuesday, March 19, 2013 7:33 AM
To: Mike Jones
Cc: Richard Barnes; jose@ietf.org
Subject: Re: [jose] WebCrypto feedback on key wrapping

 

 

On Mar 18, 2013, at 5:02 PM, Mike Jones wrote:<= /o:p>



Given that we require RSA= keys to be a minimum of 2048 bits in length, there’s no problem wrap= ping 768 bit keys with OAEP in practice.

 

Sure, but there would be a problem if what you are w= rapping is a JWK object, which could get much bigger than 768 bits.

 

…Mark



 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of Richard Barnes
Sent: Monday, Marc= h 18, 2013 4:25 PM
To: jose@ietf.org
Subject: [jose] We= bCrypto feedback on key wrapping

 

On today's call with the W3C WebCrypto working  = ;group, I reported on the discussion of JOSE key wrapping at the last IETF.=  I was asked to relay a few bits of feedback:

 

1. Vijay Bharadwaj (Microsoft) observed that AES key= wrap has fallen out of favor with some parts of the cryptographic communit= y.  People prefer to be able to use AEAD algorithms for key wrapping, = since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEE= E 802.1 uses AES CCM.

 

2. Mark Watson (Netflix) noted that if we use RSA di= rectly to encrypt wrapped key objects, then we would need something other t= han OAEP in order to carry arbitrary-length payloads.  I agreed, and s= uggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is tr= oublesome due to the lack of support by native crypto libraries.=

 

It seems to me that these comments have impacts on J= WE and JWS (pending ISSUE-2), as well as the wrapping discussion.  The= former has more impact than the latter. 

 

Point number 1 implies that we should offer AEAD for= key wrapping in JWE as well as for wrapped keys.  It seems to me that= the simplest approach to this would be to make the "alg" field c= ontain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax, incide= ntally, is roughly the same form that algorithm identifiers have in the Web= Crypto API.  Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo s= tructure.  

 

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach.  For example, if usin= g HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, w= hich is too long to be encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The= best idea I've got is to allow wrapped keys to nest, so that you can wrap = a key inside of another wrapped key.

 

I will try to take these points into account in my f= orthcoming key wrapping draft, and I've filed two issues against JWE to tra= ck them.

 

--Richard

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367561ECBTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Tue Mar 19 09:33:10 2013 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 B1E6521F8F41 for ; Tue, 19 Mar 2013 09:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.295, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 3bLpzXRtHp7j for ; Tue, 19 Mar 2013 09:33:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id B29D921F8EDE for ; Tue, 19 Mar 2013 09:33:05 -0700 (PDT) Received: from BY2FFO11FD014.protection.gbl (10.1.15.201) by BY2FFO11HUB022.protection.gbl (10.1.14.109) with Microsoft SMTP Server (TLS) id 15.0.641.9; Tue, 19 Mar 2013 16:33:02 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD014.mail.protection.outlook.com (10.1.14.76) with Microsoft SMTP Server (TLS) id 15.0.641.9 via Frontend Transport; Tue, 19 Mar 2013 16:33:02 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Tue, 19 Mar 2013 16:32:34 +0000 From: Mike Jones To: Jim Schaad , 'Richard Barnes' Thread-Topic: [jose] #14: Support longer wrapped keys than OAEP allows Thread-Index: Ac4kUSSp0CdJ4UeFJ0WR/FqpfMVesAAY5sWAAAJ8CmA= Date: Tue, 19 Mar 2013 16:32:34 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367561F27@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> <006301ce24b4$c765e4e0$5631aea0$@augustcellars.com> In-Reply-To: <006301ce24b4$c765e4e0$5631aea0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367561F27TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(189002)(53806001)(69226001)(47976001)(55846006)(63696002)(33656001)(16406001)(46102001)(65816001)(56816002)(512874001)(47446002)(77982001)(66066001)(50986001)(54356001)(54316002)(51856001)(20776003)(76482001)(47736001)(74662001)(49866001)(44976002)(4396001)(59766001)(74502001)(56776001)(80022001)(79102001)(31966008)(148743001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB022; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0790FB1F33 Cc: 'James H Manger' , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 19 Mar 2013 16:33:10 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367561F27TK5EX14MBXC283r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjb21wbGV0ZWx5IGFncmVlIHRoYXQgZG9jdW1lbnRpbmcgdGhlIGVuZ2luZWVyaW5nIHRyYWRl b2ZmcyBpcyBpbiBzY29wZSBhbmQgYSB3b3J0aHdoaWxlIGV4ZXJjaXNlLiAgVGhlIHBvaW50IG9m IG15IG1lc3NhZ2Ugd2FzIHNpbXBseSB0aGF0IHdlIG5lZWRu4oCZdCDigJxhY2NlcHQgdGhlIGdv YWwgdGhhdCB0aGVyZSBzaG91bGQgYmUgb25lIHdheSBvZiBlbmNyeXB0aW5nIGtleXPigJ0gd2l0 aG91dCBkb2luZyB0aGlzIGFuYWx5c2lzLg0KDQpJIHRoaW5rIE1hdHQgTWlsbGVyIGhhZCBpdCBy aWdodCB3aGVuIGhlIHdyb3RlIHRoaXMgbW9ybmluZyDigJxQZXJzb25hbGx5LCBJIGRvbid0IHRo aW5rIGl0J3Mgd29ydGggZGlzY3Vzc2luZyB0aGlzIG11Y2ggZnVydGhlciB3aXRob3V0IGEgbW9y ZSBjb21wbGV0ZSBjb3VudGVyLXByb3Bvc2FsIG9uIHRoZSB0YWJsZeKAnS4gIFNob3VsZCBhIGNv bmNyZXRlIGNvdW50ZXItcHJvcG9zYWwgdG8gTWF0dOKAmXMgZHJhZnQgYmUgd3JpdHRlbiwgYXQg dGhhdCBwb2ludCB3ZSBjb3VsZCBoYXZlIGEgbXVjaCBtb3JlIGNvbmNyZXRlIGRpc2N1c3Npb24u DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBDaGVlcnMsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgLS0gTWlrZQ0KDQpGcm9tOiBKaW0gU2NoYWFkIFtt YWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbV0NClNlbnQ6IFR1ZXNkYXksIE1hcmNoIDE5LCAy MDEzIDg6MTcgQU0NClRvOiBNaWtlIEpvbmVzOyAnUmljaGFyZCBCYXJuZXMnDQpDYzogJ0phbWVz IEggTWFuZ2VyJzsgam9zZUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtqb3NlXSAjMTQ6IFN1cHBv cnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzDQoNCjxwZXJzb25hbD4NCg0K VGhlIGlzc3VlIGhhcyBiZWVuIHJhaXNlZCBmb3IgZGlzY3Vzc2lvbi4gIEkgZG8gbm90IGJlbGll dmUgdGhhdCBkb2N1bWVudGluZyB3aGF0IHRoZSBleHRlbnRzIG9mIHRoZSBpc3N1ZSBhcmUgaXMg b3V0IG9mIHNjb3BlIG9mIGFueSBhbmQgYWxsIGZvbGxvdyBvbiBkaXNjdXNzaW9uLiAgVW50aWwg dGhhdCBoYXMgYmVlbiBkb25lIGl0IGlzIG5vdCBwb3NzaWJsZSB0byB0YWxrIGFib3V0IHdoYXQg dGhlIGNvc3RzIGFuZCBiZW5lZml0cyBhcmUuICBJZiB5b3UgaGF2ZSBhIGZ1bGwgc2V0IG9mIGNv c3RzIGFuZCBiZW5lZml0cyB0aGF0IHdvdWxkIGJlIGFuIGludGVyZXN0aW5nIG1lc3NhZ2UgdG8g c2VlLg0KDQpGcm9tOiBNaWtlIEpvbmVzIFttYWlsdG86TWljaGFlbC5Kb25lc0BtaWNyb3NvZnQu Y29tXQ0KU2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA4OjI0IFBNDQpUbzogSmltIFNjaGFh ZDsgUmljaGFyZCBCYXJuZXMNCkNjOiBKYW1lcyBIIE1hbmdlcjsgam9zZUBpZXRmLm9yZzxtYWls dG86am9zZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbam9zZV0gIzE0OiBTdXBwb3J0IGxvbmdl ciB3cmFwcGVkIGtleXMgdGhhbiBPQUVQIGFsbG93cw0KDQpTaW5jZSB5b3UgbWVzc2FnZSBhcHBl YXJzIHRvIHRha2UgaXQgYXMgZ2l2ZW4gdGhhdCDigJx0aGVyZSBzaG91bGQgYmUgb25seSBvbmUg d2F5IG9mIGVuY3J5cHRpbmcga2V5c+KAnSwgSeKAmWxsIHBvaW50IG91dCB0aGF0IEkgZG9u4oCZ dCB0aGluayB0aGF0IGl04oCZcyByZWFzb25hYmxlIHRvIGFzc3VtZSB0aGF0LiAgSk9TRSBpcyBm aXJzdCBhbmQgZm9yZW1vc3QgYW4gZW5naW5lZXJpbmcgZXhlcmNpc2UsIHdoZXJlIHRoZSBjb3N0 L2JlbmVmaXQgZ2VuZXJhbGl0eS9jb21wbGV4aXR5IHRyYWRlb2ZmcyBtYXR0ZXIsIGFuZCB0aGUg Z29hbCBpcyBhIHViaXF1aXRvdXNseSBpbXBsZW1lbnRlZCBjcnlwdG8gZm9ybWF0IGZvciB0aGUg V2ViIHRoYXQgc29sdmVzIHRoZSBwcm9ibGVtcyB0aGF0IHBlb3BsZSBhY3R1YWxseSBoYXZlLCBy YXRoZXIgdGhhbiBhIG1hdGhlbWF0aWNhbCBleGVyY2lzZSwgd2hlcmUgdGhlIGdvYWwgaXMgY29t cGxldGVuZXNzIGFuZCBnZW5lcmFsaXR5LiAgQ29tcGxleGl0eSBpcyB0aGUgZW5lbXkgb2YgYWRv cHRpb24uDQoNClNvIGl04oCZcyBmYWlyIGdhbWUgdG8gYXNrIOKAnFdoYXQgYXJlIHRoZSBjb3N0 cyBhbmQgYmVuZWZpdHMgb2YgaGF2aW5nIG9ubHkgb25lIHdheSB0byBlbmNyeXB0IGtleXPigJ0s IHZlcnN1cyB0YWtpbmcgdGhhdCBhcyBhIGdpdmVuLg0KDQpJIGhhcHBlbiB0byBwZXJzb25hbGx5 IGJlbGlldmUgdGhhdCBlbmNyeXB0aW5nIGEgYmFyZSBzeW1tZXRyaWMgZXBoZW1lcmFsIENvbnRl bnQgTWFzdGVyIEtleSBpcyBzdWZmaWNpZW50bHkgZGlmZmVyZW50IHRoYW4gZW5jcnlwdGluZyBh IGtleSB0aGF0IG1heSBiZSBwdWJsaWMsIHByaXZhdGUsIG9yIHN5bW1ldHJpYyBhbmQgbWF5IGhh dmUgYWRkaXRpb25hbCBhdHRyaWJ1dGVzLCB0aGF0IGl04oCZcyBhdCBsZWFzdCB3b3J0aCBhc2tp bmcgdGhlIGVuZ2luZWVyaW5nIHF1ZXN0aW9uIHdoZXRoZXIgc3BlY2lhbC1jYXNpbmcgdGhlIGVu Y3J5cHRpb24gb2YgdGhpcyBiYXJlIHN5bW1ldHJpYyBlcGhlbWVyYWwga2V5IHJlc3VsdHMgaW4g ZW5naW5lZXJpbmcgYmVuZWZpdHMuDQoNCkVuY3J5cHRpbmcgYSBrZXkgd2l0aCBhdHRyaWJ1dGVz IGZvciBzdG9yYWdlIG9yIGRpc3NlbWluYXRpb24gaXMgbm90IHRoZSBzYW1lIGtpbmQgb2Ygb3Bl cmF0aW9uIGFzIHdyYXBwaW5nIGFuIGVwaGVtZXJhbCBzeW1tZXRyaWMga2V5IHRvIGJlIHVzZWQg Zm9yIGJsb2NrIGVuY3J5cHRpb24uICBJ4oCZbSBwZXJzb25hbGx5IGZpbmUgd2l0aCB0aGlzIGJl aW5nIGRvbmUgZGlmZmVyZW50bHkuICBUaGUgZW5naW5lZXJpbmcgYmVuZWZpdCBpZiB3ZSBkbyBp dCBkaWZmZXJlbnRseSBpbiB0aGUgd2F5IHRoYXQgTWF0dOKAmXMgZHJhZnQgcHJvcG9zZWQsIGF0 IGxlYXN0IGFzIEkgc2VlIGl0LCBpcyB0aGF0IHdlIGhhdmUgdG8gaW52ZW50IG5vdGhpbmcgbmV3 LiAgV2UgYWxyZWFkeSBoYXZlIGEgZ3JlYXQgZm9ybWF0IGZvciBlbmNyeXB0aW5nIGFyYml0cmFy eSBkYXRhLCBhbmQga2V5cyB3aXRoIGF0dHJpYnV0ZXMgYXJlIGEgd2hvbGUgbG90IGxpa2UgYXJi aXRyYXJ5IGRhdGEuDQoNCkkgcmVzcGVjdCB0aGF0IHNvbWUgd2l0aCBkaXNhZ3JlZSB3aXRoIG15 IHBlcnNvbmFsIHZpZXcsIGJ1dCBJ4oCZZCBhbHNvIGFzayB5b3UgdG8gcmVzcGVjdCB0aGF0IHRo ZSBlbmdpbmVlcmluZyB0cmFkZW9mZnMgbWF5IGZhdm9yIGhhdmluZyB0d28gd2F5cyB0byBkbyB0 aGluZ3MgdGhhdCBvbiB0aGUgc3VyZmFjZSBtYXkgc2VlbSBzaW1pbGFyLCBidXQgYXJlIGFjdHVh bGx5IGZhaXJseSBkaWZmZXJlbnQgaW4gbmF0dXJlLg0KDQpCZXN0IHdpc2hlcywNCi0tIE1pa2UN Cg0KRnJvbTogUmljaGFyZCBCYXJuZXMNClNlbnQ6IOKAjk1hcmNo4oCOIOKAjjE44oCOLCDigI4y MDEzIOKAjjfigI464oCOMzbigI4g4oCOUE0NClRvOiBKaW0gU2NoYWFkDQpDQzogTWFuZ2VyLCBK YW1lcyBILCBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dz DQoNCldlbGwsIEkgZ290IHRvIDc4OCBieSBkb2luZyBtYXRoIGluY29ycmVjdGx5Ki4NCg0KTWlr ZSB3YXMgY29ycmVjdCBvbiB0aGUgb3RoZXIgdGhyZWFkIHRoYXQgNzY4IGlzIHRoZSByaWdodCBu dW1iZXIuICBIb3dldmVyLCB0aGF0J3Mgc3RpbGwgdG9vIGJpZyBmb3IgYSAxMDI0LWJpdCBSU0Eg a2V5IGFuZCBTSEExLCBzaW5jZSA3NjggKyAzMjAgPSAxMDg4ID4gMTAyNC4NCg0KUmVnYXJkbGVz cywgdGhlcmUgaXMgY2xlYXJseSBhbiBpc3N1ZSBoZXJlIHdoZW4gd3JhcHBpbmcgYSBKV0ssIHdo aWNoIGlzIG11Y2ggbGFyZ2VyLCBwb3NzaWJseSBjb250YWluaW5nIGFuIFJTQSBrZXkgaXRzZWxm LiAgU28gaWYgd2UgYWNjZXB0IHRoZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSB3YXkg b2YgZW5jcnlwdGluZyBrZXlzLCB0aGVuIHdlJ2xsIG5lZWQgdG8gZGVhbCB3aXRoIGdldHRpbmcg YXJvdW5kIHRoZSBPQUVQIHNpemUgbGltaXRhdGlvbnMuDQoNCi0tUmljaGFyZA0KDQoqIFRoaXMg aXMgd2h5IG15IGRlZ3JlZSBpcyBpbiBtYXRoZW1hdGljcywgYW5kIG5vdCBhY2NvdW50aW5nLg0K T24gTW9uLCBNYXIgMTgsIDIwMTMgYXQgODo0MCBQTSwgSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3Rj ZWxsYXJzLmNvbTxtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4+IHdyb3RlOg0KVGhpbmsg aW4gdGVybXMgb2YgZW5jcnlwdGluZyBhIEpXSyBkaXJlY3RseSBub3QgYW4gaW50ZXJtZWRpYXRl IGtleS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBqb3NlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBP Zg0KPiBNYW5nZXIsIEphbWVzIEgNCj4gU2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA1OjE3 IFBNDQo+IFRvOiBybGJAaXB2LnN4PG1haWx0bzpybGJAaXB2LnN4Pjsgam9zZUBpZXRmLm9yZzxt YWlsdG86am9zZUBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtqb3NlXSAjMTQ6IFN1cHBvcnQg bG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzDQo+DQo+IFJpY2hhcmQsDQo+DQo+ IEhvdyBkbyB5b3UgZ2V0IGEgNzg4LWJpdCBrZXkgbGVuZ3RoPw0KPg0KPiBkcmFmdC1tY2dyZXct YWVhZC1hZXMtY2JjLWhtYWMtc2hhMiBkZWZpbmVzIDUgY29tYmluYXRpb25zIG9mIEFFUy0NCj4g MTI4LzE5Mi8yNTYgYW5kIFNIQS0xLzI1Ni8zODQvNTEyLiBUaGUgdG90YWwga2V5IGxlbmd0aHMg cmFuZ2UgZnJvbSAyNTYNCj4gYml0cyB0byA1MTIgYml0cy4NCj4NCj4gS2V5cyBmb3IgdHdvIG9m IHRoZSBhbGdvcml0aG1zIChBRUFEX0FFU18xMjhfQ0JDX0hNQUNfU0hBXzI1NiBhbmQNCj4gQUVB RF9BRVNfMTI4X0NCQ19ITUFDX1NIQTEpIGZpdCB3aXRoaW4gT0FFUCB3aXRoIGEgMTAyNC1iaXQg UlNBIGtleS4NCj4NCj4gS2V5cyBmb3IgYWxsIG9mIHRoZSBhbGdvcml0aG1zIGZpdCB3aXRoaW4g T0FFUCB3aXRoIGEgMjA0OC1iaXQgUlNBIGtleS4NCkpXQQ0KPiBhbHJlYWR5IHNheXMgUlNBIGtl eSBzaXplcyBNVVNUIGJlIGF0IGxlYXN0IDIwNDggYml0cy4NCj4NCj4gVGhpcyBhbHJlYWR5IGxv b2tzIHN1ZmZpY2llbnQuDQo+DQo+IC0tDQo+IEphbWVzIE1hbmdlcg0KPg0KPg0KPiA+IEZyb206 IGpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPiBbbWFp bHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86am9zZS1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmDQo+ID4gT2YgUmljaGFyZCBCYXJuZXMNCj4gPiBTZW50OiBUdWVzZGF5LCAxOSBN YXJjaCAyMDEzIDEwOjI1IEFNDQo+ID4gU3ViamVjdDogW2pvc2VdIFdlYkNyeXB0byBmZWVkYmFj ayBvbiBrZXkgd3JhcHBpbmcNCj4gPg0KPiA+IDIuIE1hcmsgV2F0c29uIChOZXRmbGl4KSBub3Rl ZCB0aGF0IGlmIHdlIHVzZSBSU0EgZGlyZWN0bHkgdG8gZW5jcnlwdA0Kd3JhcHBlZA0KPiBrZXkg b2JqZWN0cywgdGhlbiB3ZSB3b3VsZCBuZWVkIHNvbWV0aGluZyBvdGhlciB0aGFuIE9BRVAgaW4g b3JkZXIgdG8NCmNhcnJ5DQo+IGFyYml0cmFyeS1sZW5ndGggcGF5bG9hZHMuICBJIGFncmVlZCwg YW5kIHN1Z2dlc3RlZCB0aGF0IHNvbWV0aGluZyBsaWtlDQpSU0EtDQo+IEtFTSB3b3VsZCBiZSBu ZWNlc3NhcnkuICBSeWFuIFNsZWV2aSAoR29vZ2xlKSBhbmQgVmlqYXkgb2JzZXJ2ZWQgdGhhdCBL RU0NCmlzDQo+IHRyb3VibGVzb21lIGR1ZSB0byB0aGUgbGFjayBvZiBzdXBwb3J0IGJ5IG5hdGl2 ZSBjcnlwdG8gbGlicmFyaWVzLg0KPiA+DQo+ID4gUG9pbnQgbnVtYmVyIDIgbGlrZWx5IGFwcGxp ZXMgZm9yIHNvbWUgc2NlbmFyaW9zIG9mIEpXRSwgZXNwZWNpYWxseSBpZg0Kd2UNCj4gYWRvcHQg dGhlIE1jR3JldyBhcHByb2FjaC4gIEZvciBleGFtcGxlLCBpZiB1c2luZyBITUFDLVNIQTEgYW5k IEFFUyB3aXRoDQo+IGEgMjU2LWJpdCBrZXksIHRoZSB0b3RhbCBrZXkgbGVuZ3RoIGlzIDc4OCBi aXRzLCB3aGljaCBpcyB0b28gbG9uZyB0byBiZQ0KZW5jcnlwdGVkDQo+IHdpdGggT0FFUCB1bmRl ciBhIDEsMDI0LWJpdCBSU0Ega2V5LiAgSSdtIG5vdCBzdXJlIGhvdyB0byByZXNvbHZlIGl0LiAg VGhlDQpiZXN0DQo+IGlkZWEgSSd2ZSBnb3QgaXMgdG8gYWxsb3cgd3JhcHBlZCBrZXlzIHRvIG5l c3QsIHNvIHRoYXQgeW91IGNhbiB3cmFwIGEga2V5DQppbnNpZGUNCj4gb2YgYW5vdGhlciB3cmFw cGVkIGtleS4NCj4gPg0KPiA+IC0tUmljaGFyZA0KPg0KPg0KPiA+PiAtLS0tLS0tLS0tDQo+ID4+ IFNlbnQ6IFR1ZXNkYXksIDE5IE1hcmNoIDIwMTMgMTA6MjMgQU0NCj4gPj4gU3ViamVjdDogW2pv c2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FFUCBhbGxvd3MNCj4g Pj4NCj4gPj4gIzE0OiBTdXBwb3J0IGxvbmdlciB3cmFwcGVkIGtleXMgdGhhbiBPQUVQIGFsbG93 cw0KPiA+Pg0KPiA+PiAgVGhlIHVzZSBvZiBSU0EtT0FFUCBmb3Iga2V5IHdyYXBwaW5nIGltcG9z ZXMgYSBsaW1pdCBvbiB0aGUgbGVuZ3RoDQo+ID4+IG9mICB0aGUga2V5IHBhY2thZ2UgYmVpbmcg d3JhcHBlZC4gV2l0aCBTSEExLCB0aGlzIGxlbmd0aCBpcyBOLTMyMCwNCj4gPj4gd2hlcmUgIE4g aXMgdGhlIGxlbmd0aCBvZiB0aGUgUlNBIG1vZHVsdXMuICBFc3BlY2lhbGx5IHdpdGggbGFyZ2Vy DQo+ID4+IGhhc2ggIGZ1bmN0aW9ucywgYW5kIGVzcGVjaWFsbHkgZm9yIHdyYXBwaW5nIHByaXZh dGUga2V5cywgdGhlIHNpemUNCj4gPj4gb2Yga2V5ICBwYWNrYWdlcyB3aWxsIGJlIGxhcmdlciB0 aGFuIHRoaXMgYm91bmQuICBXZSBzaG91bGQNCj4gPj4gaW5jb3Jwb3JhdGUgYSAgbWVjaGFuaXNt IHRvIGFjY29tbW9kYXRlIHRoZXNlIHNpdHVhdGlvbnMuDQo+ID4+DQo+ID4+DQo+ID4+IFRpY2tl dCBVUkw6IDxodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy93Zy9qb3NlL3RyYWMvdGlja2V0LzE0 Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBq b3NlIG1haWxpbmcgbGlzdA0KPiBqb3NlQGlldGYub3JnPG1haWx0bzpqb3NlQGlldGYub3JnPg0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pvc2UNCg0K --_000_4E1F6AAD24975D4BA5B168042967394367561F27TK5EX14MBXC283r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJU YWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3QsIGxpLm1z b2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3QsIGRpdi5tc29saXN0cGFyYWdyYXBoY3hzcGZpcnN0DQoJ e21zby1zdHlsZS1uYW1lOm1zb2xpc3RwYXJhZ3JhcGhjeHNwZmlyc3Q7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhlaWdodDoxMTUlOw0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9 DQpwLm1zb2xpc3RwYXJhZ3JhcGhjeHNwbWlkZGxlLCBsaS5tc29saXN0cGFyYWdyYXBoY3hzcG1p ZGRsZSwgZGl2Lm1zb2xpc3RwYXJhZ3JhcGhjeHNwbWlkZGxlDQoJe21zby1zdHlsZS1uYW1lOm1z b2xpc3RwYXJhZ3JhcGhjeHNwbWlkZGxlOw0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJbGluZS1oZWlnaHQ6MTE1JTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KcC5tc29saXN0cGFyYWdy YXBoY3hzcGxhc3QsIGxpLm1zb2xpc3RwYXJhZ3JhcGhjeHNwbGFzdCwgZGl2Lm1zb2xpc3RwYXJh Z3JhcGhjeHNwbGFzdA0KCXttc28tc3R5bGUtbmFtZTptc29saXN0cGFyYWdyYXBoY3hzcGxhc3Q7 DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBp bjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglsaW5lLWhl aWdodDoxMTUlOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsInNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBj b21wbGV0ZWx5IGFncmVlIHRoYXQgZG9jdW1lbnRpbmcgdGhlIGVuZ2luZWVyaW5nIHRyYWRlb2Zm cyBpcyBpbiBzY29wZSBhbmQgYSB3b3J0aHdoaWxlIGV4ZXJjaXNlLiZuYnNwOyBUaGUgcG9pbnQg b2YgbXkgbWVzc2FnZSB3YXMgc2ltcGx5IHRoYXQgd2UgbmVlZG7igJl0IOKAnDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5hY2NlcHQNCiB0aGUgZ29hbCB0aGF0IHRoZXJlIHNob3VsZCBiZSBvbmUgd2F5IG9m IGVuY3J5cHRpbmcga2V5czwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+4oCdIHdpdGhvdXQgZG9pbmcgdGhpcyBhbmFseXNpcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhp bmsgTWF0dCBNaWxsZXIgaGFkIGl0IHJpZ2h0IHdoZW4gaGUgd3JvdGUgdGhpcyBtb3JuaW5nIOKA nDwvc3Bhbj5QZXJzb25hbGx5LCBJIGRvbid0IHRoaW5rIGl0J3Mgd29ydGggZGlzY3Vzc2luZyB0 aGlzIG11Y2ggZnVydGhlciB3aXRob3V0IGEgbW9yZSBjb21wbGV0ZQ0KIGNvdW50ZXItcHJvcG9z YWwgb24gdGhlIHRhYmxlPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PuKAnS4mbmJzcDsgU2hvdWxkIGEgY29uY3JldGUgY291bnRlci1wcm9wb3NhbCB0byBNYXR04oCZ cyBkcmFmdCBiZSB3cml0dGVuLCBhdCB0aGF0IHBvaW50IHdlIGNvdWxkIGhhdmUgYSBtdWNoIG1v cmUgY29uY3JldGUgZGlzY3Vzc2lvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBDaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLSBNaWtlPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij4gSmltIFNjaGFhZCBbbWFpbHRvOmlldGZAYXVndXN0Y2VsbGFycy5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMTksIDIwMTMgODoxNyBBTTxicj4NCjxiPlRvOjwvYj4g TWlrZSBKb25lczsgJ1JpY2hhcmQgQmFybmVzJzxicj4NCjxiPkNjOjwvYj4gJ0phbWVzIEggTWFu Z2VyJzsgam9zZUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2pvc2VdICMxNDog U3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FFUCBhbGxvd3M8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmx0O3BlcnNvbmFsJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlIGlzc3Vl IGhhcyBiZWVuIHJhaXNlZCBmb3IgZGlzY3Vzc2lvbi4mbmJzcDsgSSBkbyBub3QgYmVsaWV2ZSB0 aGF0IGRvY3VtZW50aW5nIHdoYXQgdGhlIGV4dGVudHMgb2YgdGhlIGlzc3VlIGFyZSBpcyBvdXQg b2Ygc2NvcGUgb2YgYW55IGFuZCBhbGwgZm9sbG93IG9uIGRpc2N1c3Npb24uDQogJm5ic3A7VW50 aWwgdGhhdCBoYXMgYmVlbiBkb25lIGl0IGlzIG5vdCBwb3NzaWJsZSB0byB0YWxrIGFib3V0IHdo YXQgdGhlIGNvc3RzIGFuZCBiZW5lZml0cyBhcmUuJm5ic3A7IElmIHlvdSBoYXZlIGEgZnVsbCBz ZXQgb2YgY29zdHMgYW5kIGJlbmVmaXRzIHRoYXQgd291bGQgYmUgYW4gaW50ZXJlc3RpbmcgbWVz c2FnZSB0byBzZWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IE1pa2UgSm9uZXMgWzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb20i Pm1haWx0bzpNaWNoYWVsLkpvbmVzQG1pY3Jvc29mdC5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgTWFyY2ggMTgsIDIwMTMgODoyNCBQTTxicj4NCjxiPlRvOjwvYj4gSmltIFNj aGFhZDsgUmljaGFyZCBCYXJuZXM8YnI+DQo8Yj5DYzo8L2I+IEphbWVzIEggTWFuZ2VyOyA8YSBo cmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFu IE9BRVAgYWxsb3dzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TaW5jZSB5b3UgbWVzc2FnZSBhcHBlYXJzIHRv IHRha2UgaXQgYXMgZ2l2ZW4gdGhhdCZuYnNwO+KAnHRoZXJlIHNob3VsZCBiZSBvbmx5IG9uZSB3 YXkgb2YgZW5jcnlwdGluZyBrZXlz4oCdLCBJ4oCZbGwgcG9pbnQgb3V0IHRoYXQgSSBkb27igJl0 IHRoaW5rIHRoYXQgaXTigJlzIHJlYXNvbmFibGUgdG8gYXNzdW1lIHRoYXQuJm5ic3A7IEpPU0Ug aXMgZmlyc3QNCiBhbmQgZm9yZW1vc3QgYW4gZW5naW5lZXJpbmcgZXhlcmNpc2UsIHdoZXJlIHRo ZSBjb3N0L2JlbmVmaXQgZ2VuZXJhbGl0eS9jb21wbGV4aXR5IHRyYWRlb2ZmcyBtYXR0ZXIsIGFu ZCB0aGUgZ29hbCBpcyBhIHViaXF1aXRvdXNseSBpbXBsZW1lbnRlZCBjcnlwdG8mbmJzcDtmb3Jt YXQgZm9yIHRoZSBXZWIgdGhhdCBzb2x2ZXMgdGhlIHByb2JsZW1zIHRoYXQgcGVvcGxlIGFjdHVh bGx5IGhhdmUsIHJhdGhlciB0aGFuIGEgbWF0aGVtYXRpY2FsIGV4ZXJjaXNlLA0KIHdoZXJlIHRo ZSBnb2FsIGlzIGNvbXBsZXRlbmVzcyBhbmQgZ2VuZXJhbGl0eS4mbmJzcDsgQ29tcGxleGl0eSBp cyB0aGUgZW5lbXkgb2YgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+U28gaXTigJlzIGZhaXIgZ2FtZSB0byBhc2smbmJzcDvigJxXaGF0IGFyZSB0aGUgY29zdHMg YW5kIGJlbmVmaXRzIG9mIGhhdmluZyBvbmx5IG9uZSB3YXkgdG8gZW5jcnlwdCBrZXlz4oCdLCB2 ZXJzdXMgdGFraW5nIHRoYXQgYXMgYSBnaXZlbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5JIGhhcHBlbiB0byBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCBlbmNyeXB0aW5nIGEg YmFyZSBzeW1tZXRyaWMgZXBoZW1lcmFsJm5ic3A7Q29udGVudCBNYXN0ZXIgS2V5IGlzIHN1ZmZp Y2llbnRseSBkaWZmZXJlbnQgdGhhbiBlbmNyeXB0aW5nIGEga2V5IHRoYXQgbWF5IGJlIHB1Ymxp YywgcHJpdmF0ZSwgb3Igc3ltbWV0cmljIGFuZA0KIG1heSBoYXZlIGFkZGl0aW9uYWwgYXR0cmli dXRlcywgdGhhdCBpdOKAmXMgYXQgbGVhc3Qgd29ydGggYXNraW5nIHRoZSBlbmdpbmVlcmluZyBx dWVzdGlvbiB3aGV0aGVyIHNwZWNpYWwtY2FzaW5nIHRoZSBlbmNyeXB0aW9uIG9mIHRoaXMgYmFy ZSBzeW1tZXRyaWMgZXBoZW1lcmFsIGtleSByZXN1bHRzIGluIGVuZ2luZWVyaW5nIGJlbmVmaXRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkVuY3J5cHRpbmcgYSBrZXkgd2l0 aCBhdHRyaWJ1dGVzIGZvciBzdG9yYWdlIG9yIGRpc3NlbWluYXRpb24gaXMgbm90IHRoZSBzYW1l IGtpbmQgb2Ygb3BlcmF0aW9uIGFzIHdyYXBwaW5nIGFuIGVwaGVtZXJhbCBzeW1tZXRyaWMga2V5 IHRvIGJlIHVzZWQgZm9yIGJsb2NrIGVuY3J5cHRpb24uJm5ic3A7IEnigJltIHBlcnNvbmFsbHkg ZmluZQ0KIHdpdGggdGhpcyBiZWluZyBkb25lIGRpZmZlcmVudGx5LiZuYnNwOyBUaGUgZW5naW5l ZXJpbmcgYmVuZWZpdCBpZiB3ZSBkbyBpdCBkaWZmZXJlbnRseSBpbiB0aGUgd2F5IHRoYXQgTWF0 dOKAmXMgZHJhZnQgcHJvcG9zZWQsIGF0IGxlYXN0IGFzIEkgc2VlIGl0LCBpcyB0aGF0IHdlIGhh dmUgdG8gaW52ZW50IG5vdGhpbmcgbmV3LiZuYnNwOyBXZSBhbHJlYWR5IGhhdmUgYSBncmVhdCBm b3JtYXQgZm9yIGVuY3J5cHRpbmcgYXJiaXRyYXJ5IGRhdGEsIGFuZCBrZXlzIHdpdGgNCiBhdHRy aWJ1dGVzIGFyZSBhIHdob2xlIGxvdCBsaWtlIGFyYml0cmFyeSBkYXRhLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkkgcmVzcGVjdCB0aGF0IHNvbWUgd2l0aCBkaXNhZ3JlZSB3 aXRoIG15IHBlcnNvbmFsIHZpZXcsIGJ1dCBJ4oCZZCBhbHNvIGFzayB5b3UgdG8gcmVzcGVjdCB0 aGF0IHRoZSBlbmdpbmVlcmluZyB0cmFkZW9mZnMgbWF5IGZhdm9yIGhhdmluZyB0d28gd2F5cyB0 byBkbyB0aGluZ3MgdGhhdCBvbiB0aGUgc3VyZmFjZSBtYXkgc2VlbQ0KIHNpbWlsYXIsIGJ1dCBh cmUgYWN0dWFsbHkgZmFpcmx5IGRpZmZlcmVudCBpbiBuYXR1cmUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+QmVzdCB3aXNoZXMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+LS0gTWlrZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7UmljaGFyZCBCYXJuZXM8YnI+ DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiZuYnNwO+KAjk1hcmNo 4oCOIOKAjjE44oCOLCDigI4yMDEzIOKAjjfigI464oCOMzbigI4g4oCOUE08YnI+DQo8c3Ryb25n PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPlRvOjwvc3Bhbj48L3N0cm9uZz4mbmJzcDtKaW0gU2NoYWFkPGJyPg0KPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5DQzo8L3NwYW4+PC9zdHJvbmc+Jm5ic3A7TWFuZ2VyLCBKYW1lcyBI LA0KPGEgaHJlZj0ibWFpbHRvOmpvc2VAaWV0Zi5vcmciPmpvc2VAaWV0Zi5vcmc8L2E+PGJyPg0K PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4mbmJzcDtSZTogW2pv c2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4gT0FFUCBhbGxvd3M8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlbGwsIEkgZ290IHRvIDc4OCBieSBkb2luZyBtYXRo IGluY29ycmVjdGx5Ki4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5NaWtlIHdh cyBjb3JyZWN0IG9uIHRoZSBvdGhlciB0aHJlYWQgdGhhdCA3NjggaXMgdGhlIHJpZ2h0IG51bWJl ci4gJm5ic3A7SG93ZXZlciwgdGhhdCdzIHN0aWxsIHRvbyBiaWcgZm9yIGEgMTAyNC1iaXQgUlNB IGtleSBhbmQgU0hBMSwgc2luY2UgNzY4ICYjNDM7IDMyMCA9IDEwODggJmd0OyAxMDI0Lg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJlZ2FyZGxlc3MsIHRoZXJlIGlzIGNsZWFybHkgYW4g aXNzdWUgaGVyZSB3aGVuIHdyYXBwaW5nIGEgSldLLCB3aGljaCBpcyBtdWNoIGxhcmdlciwgcG9z c2libHkgY29udGFpbmluZyBhbiBSU0Ega2V5IGl0c2VsZi4gJm5ic3A7U28gaWYgd2UgYWNjZXB0 IHRoZSBnb2FsIHRoYXQgdGhlcmUgc2hvdWxkIGJlIG9uZSB3YXkgb2YgZW5jcnlwdGluZw0KIGtl eXMsIHRoZW4gd2UnbGwgbmVlZCB0byBkZWFsIHdpdGggZ2V0dGluZyBhcm91bmQgdGhlIE9BRVAg c2l6ZSBsaW1pdGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPi0tUmljaGFyZDxicj4NCjxicj4NCiogVGhpcyBpcyB3 aHkgbXkgZGVncmVlIGlzIGluIG1hdGhlbWF0aWNzLCBhbmQgbm90IGFjY291bnRpbmcuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi Pk9uIE1vbiwgTWFyIDE4LCAyMDEzIGF0IDg6NDAgUE0sIEppbSBTY2hhYWQgJmx0OzxhIGhyZWY9 Im1haWx0bzppZXRmQGF1Z3VzdGNlbGxhcnMuY29tIj5pZXRmQGF1Z3VzdGNlbGxhcnMuY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+VGhpbmsgaW4gdGVybXMgb2YgZW5jcnlwdGluZyBhIEpXSyBkaXJlY3RseSBu b3QgYW4gaW50ZXJtZWRpYXRlIGtleS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZyI+am9zZS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpqb3NlLWJvdW5jZXNAaWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mZ3Q7IE1hbmdlciwgSmFtZXMgSDxicj4NCiZn dDsgU2VudDogTW9uZGF5LCBNYXJjaCAxOCwgMjAxMyA1OjE3IFBNPGJyPg0KJmd0OyBUbzogPGEg aHJlZj0ibWFpbHRvOnJsYkBpcHYuc3giPnJsYkBpcHYuc3g8L2E+OyA8YSBocmVmPSJtYWlsdG86 am9zZUBpZXRmLm9yZyI+DQpqb3NlQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6 IFtqb3NlXSAjMTQ6IFN1cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dz PGJyPg0KJmd0Ozxicj4NCiZndDsgUmljaGFyZCw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIb3cgZG8g eW91IGdldCBhIDc4OC1iaXQga2V5IGxlbmd0aD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBkcmFmdC1t Y2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiBkZWZpbmVzIDUgY29tYmluYXRpb25zIG9mIEFF Uy08YnI+DQomZ3Q7IDEyOC8xOTIvMjU2IGFuZCBTSEEtMS8yNTYvMzg0LzUxMi4gVGhlIHRvdGFs IGtleSBsZW5ndGhzIHJhbmdlIGZyb20gMjU2PGJyPg0KJmd0OyBiaXRzIHRvIDUxMiBiaXRzLjxi cj4NCiZndDs8YnI+DQomZ3Q7IEtleXMgZm9yIHR3byBvZiB0aGUgYWxnb3JpdGhtcyAoQUVBRF9B RVNfMTI4X0NCQ19ITUFDX1NIQV8yNTYgYW5kPGJyPg0KJmd0OyBBRUFEX0FFU18xMjhfQ0JDX0hN QUNfU0hBMSkgZml0IHdpdGhpbiBPQUVQIHdpdGggYSAxMDI0LWJpdCBSU0Ega2V5Ljxicj4NCiZn dDs8YnI+DQomZ3Q7IEtleXMgZm9yIGFsbCBvZiB0aGUgYWxnb3JpdGhtcyBmaXQgd2l0aGluIE9B RVAgd2l0aCBhIDIwNDgtYml0IFJTQSBrZXkuPGJyPg0KSldBPGJyPg0KJmd0OyBhbHJlYWR5IHNh eXMgUlNBIGtleSBzaXplcyBNVVNUIGJlIGF0IGxlYXN0IDIwNDggYml0cy48YnI+DQomZ3Q7PGJy Pg0KJmd0OyBUaGlzIGFscmVhZHkgbG9va3Mgc3VmZmljaWVudC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAtLTxicj4NCiZndDsgSmFtZXMgTWFuZ2VyPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 ICZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZyI+am9zZS1i b3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpqb3NlLWJvdW5jZXNA aWV0Zi5vcmciPmpvc2UtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZjxicj4NCiZndDsg Jmd0OyBPZiBSaWNoYXJkIEJhcm5lczxicj4NCiZndDsgJmd0OyBTZW50OiBUdWVzZGF5LCAxOSBN YXJjaCAyMDEzIDEwOjI1IEFNPGJyPg0KJmd0OyAmZ3Q7IFN1YmplY3Q6IFtqb3NlXSBXZWJDcnlw dG8gZmVlZGJhY2sgb24ga2V5IHdyYXBwaW5nPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IDIuIE1hcmsgV2F0c29uIChOZXRmbGl4KSBub3RlZCB0aGF0IGlmIHdlIHVzZSBSU0EgZGlyZWN0 bHkgdG8gZW5jcnlwdDxicj4NCndyYXBwZWQ8YnI+DQomZ3Q7IGtleSBvYmplY3RzLCB0aGVuIHdl IHdvdWxkIG5lZWQgc29tZXRoaW5nIG90aGVyIHRoYW4gT0FFUCBpbiBvcmRlciB0bzxicj4NCmNh cnJ5PGJyPg0KJmd0OyBhcmJpdHJhcnktbGVuZ3RoIHBheWxvYWRzLiAmbmJzcDtJIGFncmVlZCwg YW5kIHN1Z2dlc3RlZCB0aGF0IHNvbWV0aGluZyBsaWtlPGJyPg0KUlNBLTxicj4NCiZndDsgS0VN IHdvdWxkIGJlIG5lY2Vzc2FyeS4gJm5ic3A7UnlhbiBTbGVldmkgKEdvb2dsZSkgYW5kIFZpamF5 IG9ic2VydmVkIHRoYXQgS0VNPGJyPg0KaXM8YnI+DQomZ3Q7IHRyb3VibGVzb21lIGR1ZSB0byB0 aGUgbGFjayBvZiBzdXBwb3J0IGJ5IG5hdGl2ZSBjcnlwdG8gbGlicmFyaWVzLjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBQb2ludCBudW1iZXIgMiBsaWtlbHkgYXBwbGllcyBmb3Igc29t ZSBzY2VuYXJpb3Mgb2YgSldFLCBlc3BlY2lhbGx5IGlmPGJyPg0Kd2U8YnI+DQomZ3Q7IGFkb3B0 IHRoZSBNY0dyZXcgYXBwcm9hY2guICZuYnNwO0ZvciBleGFtcGxlLCBpZiB1c2luZyBITUFDLVNI QTEgYW5kIEFFUyB3aXRoPGJyPg0KJmd0OyBhIDI1Ni1iaXQga2V5LCB0aGUgdG90YWwga2V5IGxl bmd0aCBpcyA3ODggYml0cywgd2hpY2ggaXMgdG9vIGxvbmcgdG8gYmU8YnI+DQplbmNyeXB0ZWQ8 YnI+DQomZ3Q7IHdpdGggT0FFUCB1bmRlciBhIDEsMDI0LWJpdCBSU0Ega2V5LiAmbmJzcDtJJ20g bm90IHN1cmUgaG93IHRvIHJlc29sdmUgaXQuICZuYnNwO1RoZTxicj4NCmJlc3Q8YnI+DQomZ3Q7 IGlkZWEgSSd2ZSBnb3QgaXMgdG8gYWxsb3cgd3JhcHBlZCBrZXlzIHRvIG5lc3QsIHNvIHRoYXQg eW91IGNhbiB3cmFwIGEga2V5PGJyPg0KaW5zaWRlPGJyPg0KJmd0OyBvZiBhbm90aGVyIHdyYXBw ZWQga2V5Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAtLVJpY2hhcmQ8YnI+DQomZ3Q7 PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS0tLS0tLS0tLTxicj4NCiZndDsgJmd0OyZn dDsgU2VudDogVHVlc2RheSwgMTkgTWFyY2ggMjAxMyAxMDoyMyBBTTxicj4NCiZndDsgJmd0OyZn dDsgU3ViamVjdDogW2pvc2VdICMxNDogU3VwcG9ydCBsb25nZXIgd3JhcHBlZCBrZXlzIHRoYW4g T0FFUCBhbGxvd3M8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAjMTQ6IFN1 cHBvcnQgbG9uZ2VyIHdyYXBwZWQga2V5cyB0aGFuIE9BRVAgYWxsb3dzPGJyPg0KJmd0OyAmZ3Q7 Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7VGhlIHVzZSBvZiBSU0EtT0FFUCBmb3Iga2V5 IHdyYXBwaW5nIGltcG9zZXMgYSBsaW1pdCBvbiB0aGUgbGVuZ3RoPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBvZiAmbmJzcDt0aGUga2V5IHBhY2thZ2UgYmVpbmcgd3JhcHBlZC4gV2l0aCBTSEExLCB0aGlz IGxlbmd0aCBpcyBOLTMyMCw8YnI+DQomZ3Q7ICZndDsmZ3Q7IHdoZXJlICZuYnNwO04gaXMgdGhl IGxlbmd0aCBvZiB0aGUgUlNBIG1vZHVsdXMuICZuYnNwO0VzcGVjaWFsbHkgd2l0aCBsYXJnZXI8 YnI+DQomZ3Q7ICZndDsmZ3Q7IGhhc2ggJm5ic3A7ZnVuY3Rpb25zLCBhbmQgZXNwZWNpYWxseSBm b3Igd3JhcHBpbmcgcHJpdmF0ZSBrZXlzLCB0aGUgc2l6ZTxicj4NCiZndDsgJmd0OyZndDsgb2Yg a2V5ICZuYnNwO3BhY2thZ2VzIHdpbGwgYmUgbGFyZ2VyIHRoYW4gdGhpcyBib3VuZC4gJm5ic3A7 V2Ugc2hvdWxkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbmNvcnBvcmF0ZSBhICZuYnNwO21lY2hhbmlz bSB0byBhY2NvbW1vZGF0ZSB0aGVzZSBzaXR1YXRpb25zLjxicj4NCiZndDsgJmd0OyZndDs8YnI+ DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaWNrZXQgVVJMOiAmbHQ7PGEgaHJl Zj0iaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8xNCI+aHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8xNDwvYT4mZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgam9zZSBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpqb3NlQGlldGYub3JnIj5qb3NlQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9qb3NlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2pv c2U8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4E1F6AAD24975D4BA5B168042967394367561F27TK5EX14MBXC283r_-- From rlb@ipv.sx Tue Mar 19 10:30:28 2013 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 1D7C521F8DE1 for ; Tue, 19 Mar 2013 10:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.108 X-Spam-Level: X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[AWL=-0.683, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 oosCzYr2ixuF for ; Tue, 19 Mar 2013 10:30:26 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 9A85221F8DAE for ; Tue, 19 Mar 2013 10:30:26 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wd20so710790obb.9 for ; Tue, 19 Mar 2013 10:30:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=hfQOdmia1WRfmozGhRZfVfKBIXvYMT1eO+nAolWU1vs=; b=MFWg/zFgF/zUJyFhBlmzIJiYzrPy9O9JQoFf8WwpViaevuT3o555GQcZ3hedb4oXmN Iu9+louaIu/RCu8mkLdkclC2YF15m7i+kVFk7oWyfyil2ndeb8XxR4BFKJJx5sw2+aYI C9sLWJ0tsZEKilD8FI3vRODTrHrgiemPd2TwE7fI+dx0AYJs01M/+YorkOj5fhwZRCxS IYxj/d9eRUVzUJtrqAUbJJsgPBDSF+j0xEw3p7pP1ZmnfxfBHfSj2cGfsT1nYoyb94zS 51xuGhUXUdjD9n4T9W5msjqqLLMlDeTVzJjMTzPVDU/wBPtCwz7yhuHnixFY0VeEqdq9 SO0w== MIME-Version: 1.0 X-Received: by 10.60.14.71 with SMTP id n7mr1820488oec.135.1363714226079; Tue, 19 Mar 2013 10:30:26 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 10:30:25 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: References: Date: Tue, 19 Mar 2013 13:30:25 -0400 Message-ID: From: Richard Barnes To: "Matt Miller (mamille2)" Content-Type: multipart/alternative; boundary=e89a8f2353bf055eaa04d84a76f2 X-Gm-Message-State: ALoCoQkrKMKb/32VY4zSxu5SLyOfpdeDk0Wb2xzoawBBlat0TNMUEyVjeDgc//44opgzwRgJnypD Cc: "jose@ietf.org" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 19 Mar 2013 17:30:28 -0000 --e89a8f2353bf055eaa04d84a76f2 Content-Type: text/plain; charset=ISO-8859-1 > 1) Should JWK parameter names be absolutely unique, or are they > potentially tied to a specific JWK type? In looking at the specs to date, > I think there's only one case where a parameter name is re-used ("d" for > both private RSA and ECC keys); currently syntactically and semantically > identical, but I'm not sure that's adequate. > I think it makes sense for parameter names to be potentially contingent on key type. Emphasis on "potentially" -- there could be attributes that are the same for all key types. I would also propose that we make "kty" a mandatory attribute. > 2) Should JWK parameters be marked as private (confidential, secret, > privileged, etc etc)? The current documentation set loosely defines this > only because they are current split between multiple documents. However, I > wonder if there is value in being much more explicit about it, including in > a parameter's registration. > If we fold JPSK in to JWA (which we should do), then ISTM that we should also note which parameters are private, in the sense of "have a column in the registry that marks this as a "private" parameter". Note that designation as private would not necessarily imply that you MUST do any particular thing. One can envision, for example, cases where it might be safe to pass private keys in plaintext (e.g., over TLS). One other question: 3) Should we remove "policy" attributes from JWK? The current JWK spec includes a variety of attributes that are not directly specifying parts of the key, namely "use" and "alg". These are application-related fields, and run the risk of conflicting with existing applications' attributes. For example, the WebCrypto API has a notion of key usages and algorithm restriction, but the values they use do not map to the "use" and "alg" values. Should we align with WebCrypto (and risk conflicting with other apps), or remove the policy bits altogether (and require apps to align themselves)? FWIW, I am fine with "kid" staying there, because (1) it's opaque, and (2) it's actually used in JOSE processing. --e89a8f2353bf055eaa04d84a76f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
1) Should JWK parameter names be absolutely unique, or are they potentially= tied to a specific JWK type? =A0In looking at the specs to date, I think t= here's only one case where a parameter name is re-used ("d" f= or both private RSA and ECC keys); currently syntactically and semantically= identical, but I'm not sure that's adequate.

I think it makes sense for parameter names= to be potentially contingent on key type. =A0Emphasis on "potentially= " -- there could be attributes that are the same for all key types. = =A0I would also propose that we make "kty" a mandatory attribute.=

=A0
2) Should JWK parameters be marked as private (confidential, secret, privil= eged, etc etc)? =A0The current documentation set loosely defines this only = because they are current split between multiple documents. =A0However, I wo= nder if there is value in being much more explicit about it, including in a= parameter's registration.

If we fold JPSK in to JWA (which we should= do), then ISTM that we should also note which parameters are private, in t= he sense of "have a column in the registry that marks this as a "= private" parameter". =A0Note that designation as private would no= t necessarily imply that you MUST do any particular thing. =A0One can envis= ion, for example, cases where it might be safe to pass private keys in plai= ntext (e.g., over TLS).

One other question:

3) Should = we remove "policy" attributes from JWK? =A0The current JWK spec i= ncludes a variety of attributes that are not directly specifying parts of t= he key, namely "use" and "alg". =A0These are applicatio= n-related fields, and run the risk of conflicting with existing application= s' attributes. =A0For example, the WebCrypto API has a notion of key us= ages and algorithm restriction, but the values they use do not map to the &= quot;use" and "alg" values. =A0Should we align with WebCrypt= o (and risk conflicting with other apps), or remove the policy bits altoget= her (and require apps to align themselves)? =A0FWIW, I am fine with "k= id" staying there, because (1) it's opaque, and (2) it's actua= lly used in JOSE processing.



--e89a8f2353bf055eaa04d84a76f2-- From mamille2@cisco.com Tue Mar 19 10:59:51 2013 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 50F9D21F8B64 for ; Tue, 19 Mar 2013 10:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 YqXYSXNa4Ufp for ; Tue, 19 Mar 2013 10:59:50 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA3221F8B4C for ; Tue, 19 Mar 2013 10:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6465; q=dns/txt; s=iport; t=1363715990; x=1364925590; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9h1rBHTiAF8ucIW9gd67CAOHlOoCP9N8zdMGhgqNdTk=; b=Qi3UeHw9sqGdlm9ctVem1RYnbmtnaOf3Z+mpb7SMdFjXE6WfbO3e0OBp NrBkWoEFO/ey2dhckrNM72oNmXSbL6HwmndBRdkx0kZa95aENy/Au+lUj ubxDtDUhOMt54TdsyiDL+lNcLHQUOhUdQsXNXd7jDJnkcQKompHJH55f6 s=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADKnSFGtJV2a/2dsb2JhbABDxRuBWhZ0giQBAQEDAXkFCwIBCA4UJAIwJQIEDgUIBogABrIHkBaOXTEHgl9hA488gSiWfYMKgig X-IronPort-AV: E=Sophos;i="4.84,873,1355097600"; d="p7s'?scan'208";a="189181862" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP; 19 Mar 2013 17:59:49 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r2JHxnx1027567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 19 Mar 2013 17:59:49 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Tue, 19 Mar 2013 12:59:49 -0500 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [jose] JWK Parameter Registry Considerations Thread-Index: AQHOJKx8FqJE351Np0SzIVUR6z+Zd5itmVqAgAAINQA= Date: Tue, 19 Mar 2013 17:59:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.68] Content-Type: multipart/signed; boundary="Apple-Mail=_42EBDC70-D431-4076-BA18-D2D5ADE2D50C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 19 Mar 2013 17:59:51 -0000 --Apple-Mail=_42EBDC70-D431-4076-BA18-D2D5ADE2D50C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 19, 2013, at 11:30 AM, Richard Barnes wrote: >> 1) Should JWK parameter names be absolutely unique, or are they >> potentially tied to a specific JWK type? In looking at the specs to = date, >> I think there's only one case where a parameter name is re-used ("d" = for >> both private RSA and ECC keys); currently syntactically and = semantically >> identical, but I'm not sure that's adequate. >>=20 >=20 > I think it makes sense for parameter names to be potentially = contingent on > key type. Emphasis on "potentially" -- there could be attributes that = are > the same for all key types. I would also propose that we make "kty" a > mandatory attribute. >=20 I do think there are attributes that have identical semantics regardless = of key type ("kid", "x5c"? (-: ). Requiring "kty" is probably = necessary, but I don't have a firm opinion yet. >=20 >=20 >> 2) Should JWK parameters be marked as private (confidential, secret, >> privileged, etc etc)? The current documentation set loosely defines = this >> only because they are current split between multiple documents. = However, I >> wonder if there is value in being much more explicit about it, = including in >> a parameter's registration. >>=20 >=20 > If we fold JPSK in to JWA (which we should do), then ISTM that we = should > also note which parameters are private, in the sense of "have a column = in > the registry that marks this as a "private" parameter". Note that > designation as private would not necessarily imply that you MUST do = any > particular thing. One can envision, for example, cases where it might = be > safe to pass private keys in plaintext (e.g., over TLS). >=20 Completely agree; it's an indicator to applications and implementations = that this parameter might warrant additional considerations when = present. > One other question: >=20 > 3) Should we remove "policy" attributes from JWK? The current JWK = spec > includes a variety of attributes that are not directly specifying = parts of > the key, namely "use" and "alg". These are application-related = fields, and > run the risk of conflicting with existing applications' attributes. = For > example, the WebCrypto API has a notion of key usages and algorithm > restriction, but the values they use do not map to the "use" and "alg" > values. Should we align with WebCrypto (and risk conflicting with = other > apps), or remove the policy bits altogether (and require apps to align > themselves)? FWIW, I am fine with "kid" staying there, because (1) = it's > opaque, and (2) it's actually used in JOSE processing. I wouldn't consider "kid" a policy attribute anyway; it's pretty clear = to me this is critical in properly referencing. Otherwise, I don't have = an opinion on the others. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. --Apple-Mail=_42EBDC70-D431-4076-BA18-D2D5ADE2D50C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMxOTE3NTk0OVowIwYJKoZIhvcNAQkEMRYEFBbWmOvX1k8nSGkHOtF90T8Pu9x7MIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAnW2+9IO5SqrBWLbS5LIdZDYiCtHINsThsEK4hntIi +09cvEXUKo7LEMEZ/236vTv4QDleZ1KPhnJ11YC8yabaKXXBJa4AXYykoq5sEaaHJnjn5zj4NuMj sXxlzErB+4JoP5+KdpKQOaTIIAPEebXm/DEy3mbcOA0MUit2psgPZwR4Ko2KwyvQkpA33fC+/TjG pBsjJEQ6iOvX9qdjMnusKw/gvnPwdRZvJYLj/4UPfXU7k6xderWujzAKWuFqCWfSqkyOx7/ZKzW2 a/ffnwsKs6eAIXle+hwMx8qUEGn8RuP5JkGE7b6sgRBpF5Z1mR+efXmUCrnSO9KYjRnDo3vvAAAA AAAA --Apple-Mail=_42EBDC70-D431-4076-BA18-D2D5ADE2D50C-- From bcampbell@pingidentity.com Tue Mar 19 11:45:38 2013 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 B70F121F8CA1 for ; Tue, 19 Mar 2013 11:45:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.826 X-Spam-Level: X-Spam-Status: No, score=-5.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KL3riV4kKpEy for ; Tue, 19 Mar 2013 11:45:37 -0700 (PDT) Received: from na3sys009aog131.obsmtp.com (na3sys009aog131.obsmtp.com [74.125.149.247]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBED21F8DF1 for ; Tue, 19 Mar 2013 11:45:37 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob131.postini.com ([74.125.148.12]) with SMTP ID DSNKUUiyUAI0/T6P+XIqXcPJjSr3/jOuY9Fh@postini.com; Tue, 19 Mar 2013 11:45:37 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so4201567obb.2 for ; Tue, 19 Mar 2013 11:45:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=PiCgxooiQDpKJmYKk2YBsHPe/J0aAtvB/yg5eiwUMKM=; b=S5Y3vVGoukaLwrw2rnFShLoXBV4jrzzY/R2+iR8Y5/GAltAIRjFcMSr7XAWRzFFC5R 4MeRDqK1jWwQTY6AWraBJAFrsmKsZnUqfOz156zLk2dGskWqiH2WRQ0xDLe4u/s0JXTH ZHGWelughgku1siEaXNhl0Ddd9KtIWak0yKK/QRsJ53hZ3G1LiIh4yFFFLzPUIYh5NCG yjqLwY3+BOP5zjpMW7K5Wh8BwEClWZTn3A1U4j8Uy4zQI+Wq3ilxtXhlOxSDPjNydF/a kEpiDcU3Ygrt/Q5tstAcjJSOl//QKmhLk5k4wc8i2StEYtKIn8L86QseJ0M0nUz7a1UQ ko7A== X-Received: by 10.42.122.66 with SMTP id m2mr11751654icr.15.1363718733023; Tue, 19 Mar 2013 11:45:33 -0700 (PDT) X-Received: by 10.42.122.66 with SMTP id m2mr11751646icr.15.1363718732907; Tue, 19 Mar 2013 11:45:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Tue, 19 Mar 2013 11:45:01 -0700 (PDT) In-Reply-To: References: From: Brian Campbell Date: Tue, 19 Mar 2013 12:45:01 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=20cf3003bbb6a6219104d84b8261 X-Gm-Message-State: ALoCoQlRirnkqERF3cRigv7ofxNGfHUezycQm1tjGj0+bkZ73wQOIv5KokUvLWTm0kqUs2skhRWvz6c2adZvFz2ACBv2qG7yUSTPoWYj4xjHbUZAFv44uLrHjzoYOnkIv3FZprt0amPo Cc: "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 19 Mar 2013 18:45:38 -0000 --20cf3003bbb6a6219104d84b8261 Content-Type: text/plain; charset=ISO-8859-1 "use" is useful in the context of some entity providing its public keys in a JWK Set somewhere for some other party to consume those keys and know what to do with them. On Tue, Mar 19, 2013 at 11:30 AM, Richard Barnes wrote: > > 1) Should JWK parameter names be absolutely unique, or are they >> potentially tied to a specific JWK type? In looking at the specs to date, >> I think there's only one case where a parameter name is re-used ("d" for >> both private RSA and ECC keys); currently syntactically and semantically >> identical, but I'm not sure that's adequate. >> > > I think it makes sense for parameter names to be potentially contingent on > key type. Emphasis on "potentially" -- there could be attributes that are > the same for all key types. I would also propose that we make "kty" a > mandatory attribute. > > > >> 2) Should JWK parameters be marked as private (confidential, secret, >> privileged, etc etc)? The current documentation set loosely defines this >> only because they are current split between multiple documents. However, I >> wonder if there is value in being much more explicit about it, including in >> a parameter's registration. >> > > If we fold JPSK in to JWA (which we should do), then ISTM that we should > also note which parameters are private, in the sense of "have a column in > the registry that marks this as a "private" parameter". Note that > designation as private would not necessarily imply that you MUST do any > particular thing. One can envision, for example, cases where it might be > safe to pass private keys in plaintext (e.g., over TLS). > > One other question: > > 3) Should we remove "policy" attributes from JWK? The current JWK spec > includes a variety of attributes that are not directly specifying parts of > the key, namely "use" and "alg". These are application-related fields, and > run the risk of conflicting with existing applications' attributes. For > example, the WebCrypto API has a notion of key usages and algorithm > restriction, but the values they use do not map to the "use" and "alg" > values. Should we align with WebCrypto (and risk conflicting with other > apps), or remove the policy bits altogether (and require apps to align > themselves)? FWIW, I am fine with "kid" staying there, because (1) it's > opaque, and (2) it's actually used in JOSE processing. > > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --20cf3003bbb6a6219104d84b8261 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"use" is useful in the context of some entity pr= oviding its public keys in a JWK Set somewhere for some other party to cons= ume those keys and know what to do with them.




On Tue, Mar 19, 2013 at 11:30 AM, Richar= d Barnes <rlb@ipv.sx> wrote:

1) Should JWK parameter names be absolutely unique, or are they potentially= tied to a specific JWK type? =A0In looking at the specs to date, I think t= here's only one case where a parameter name is re-used ("d" f= or both private RSA and ECC keys); currently syntactically and semantically= identical, but I'm not sure that's adequate.

I think it makes sense for parameter names= to be potentially contingent on key type. =A0Emphasis on "potentially= " -- there could be attributes that are the same for all key types. = =A0I would also propose that we make "kty" a mandatory attribute.=

=A0
2) Should JWK parameters be marked as private (confidential, secret, privil= eged, etc etc)? =A0The current documentation set loosely defines this only = because they are current split between multiple documents. =A0However, I wo= nder if there is value in being much more explicit about it, including in a= parameter's registration.

If we fold JPSK in to JWA (which we should= do), then ISTM that we should also note which parameters are private, in t= he sense of "have a column in the registry that marks this as a "= private" parameter". =A0Note that designation as private would no= t necessarily imply that you MUST do any particular thing. =A0One can envis= ion, for example, cases where it might be safe to pass private keys in plai= ntext (e.g., over TLS).

One other question:

3) Should = we remove "policy" attributes from JWK? =A0The current JWK spec i= ncludes a variety of attributes that are not directly specifying parts of t= he key, namely "use" and "alg". =A0These are applicatio= n-related fields, and run the risk of conflicting with existing application= s' attributes. =A0For example, the WebCrypto API has a notion of key us= ages and algorithm restriction, but the values they use do not map to the &= quot;use" and "alg" values. =A0Should we align with WebCrypt= o (and risk conflicting with other apps), or remove the policy bits altoget= her (and require apps to align themselves)? =A0FWIW, I am fine with "k= id" staying there, because (1) it's opaque, and (2) it's actua= lly used in JOSE processing.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--20cf3003bbb6a6219104d84b8261-- From rlb@ipv.sx Tue Mar 19 21:25:11 2013 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 C638721F8BEB for ; Tue, 19 Mar 2013 21:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, 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 p3v98Vt2VzYE for ; Tue, 19 Mar 2013 21:25:10 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id F0A7921F8BE7 for ; Tue, 19 Mar 2013 21:25:09 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id m1so1332496oag.12 for ; Tue, 19 Mar 2013 21:25:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=H5vZJpKKbG2fEE6plSF928xemBCm5Id6yLAr0M2+qVc=; b=PU2edAbVScuHZTr5gdgF606t+MyGebmEjXiIzWiW45Fy+jzBnk81Nev+tPKv7tmYhj rkhsurLgjGvHJWGswPUXauRS0bnhbYjD88MTho6WWiZnjuuV2W8+3y1qLqobEQppRhSC XbGIPs5orIetUNm/zU/JZxYRgGTuucBiLb8pf/Wb48Bhy+tyOeKOAyd9zttxeNkIQBhI ZBxTT3oypdubmQLWLnUjZHaesKrVDsC1RfoxvXQy0iiDEkHdRGlPrHIixi9gGS7coGbB lgg/5lJW6tMedlU+pxXCIs0Eyq2RSI52WYajIiayDRxvUVVy+h/2XGsBY6GPQPEeQn6E PaTw== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr3064611oea.130.1363753509313; Tue, 19 Mar 2013 21:25:09 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 21:25:09 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <5148CDC8.4070406@rub.de> References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5142109D.7010507@mitre.org> <514264B0.5090306@rub.de> <5148CDC8.4070406@rub.de> Date: Wed, 20 Mar 2013 00:25:09 -0400 Message-ID: From: Richard Barnes To: Juraj Somorovsky Content-Type: multipart/alternative; boundary=e89a8fb203187c416104d8539be8 X-Gm-Message-State: ALoCoQmvo41IwtYRGHA4EmFCebcLiprsfp2VGyJp2M+ip+krdetVMZstJTHKO9TDPOX4kXcgJohN Cc: Tibor Jager , Mike Jones , =JeffH , Justin Richer , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 20 Mar 2013 04:25:11 -0000 --e89a8fb203187c416104d8539be8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > -- Integrity protection of the algorithm value (as part of the JWS/JWE > > header). The attacker doesn't need to change the algorithm used for an= y > > given object, only for two types of (independent, valid) objects to be > > processed. > We did not understand this, could you please clarify? > The current JWE format provides an integrity check on the header parameters, including the name of the algorithm with which the JWE should be processed. In the BC attack, the attacker does not need to modify the algorithm name on a GCM-encrypted object, he merely needs to construct CBC-encrypted objects with which to query the oracle. So the integrity check on the algorithm name does not stop the BC attack. > > > > On the other hand, the following changes to the spec WOULD mitigate BC > > attacks. > > -- Recommending the use of a random CMK wherever possible > What do you mean by "wherever possible" please? ...it is just necessary > to use this as a countermeasure against Bleichenbacher's attacks on > PKCS1.5. Reference to RFC 3218 and a short description of this > countermeasure would be enough. > An example of the case where using a random CMK is not currently possible is in JWS, which does not allow wrapped keys for MAC. One might also imagine deprecating the "alg":"dir" mode for JWE, where a static key is used (or at least putting a big warning label on it). > > -- Recommending that implementations follow the guidelines in RFC 3218 > [1] > see above. > > -- Recommending that implementations track which keys are used with whi= ch > > algorithms, and prevent key reuse > Yes, it would be nice to enforce key separation in the JOSE > implementations and libraries by default so that users cannot use the > same key for different algorithms (e.g., a library could enforce the > user to generate two key pairs: one for signature processing and one for > encryption processing). I do not know how feasible this is in general. > Note that in order to prevent the attack, the checking only needs to be in the recipient side. It seems like this could be done pretty trivially and safely. -- Every time you decrypt an object, store the tuple (hash(key), algorithm) in a table -- Before you decrypt the next object, look up hash(key) in the table and see if the algorithm is the same as the one you're about to use. > > -- Deprecating / removing the "direct" mode of encryption [2], which > > encourages key reuse by making it harder to use random, ephemeral CMK > > values. > Yes, this would be reasonable. > > But we took e.g. a look at section 4.5: > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section= -4.5 > This section does not explicitly enforce key separation. If you want to > enforce a key separation (in case you are in possession of a shared > symmetric key), you could enforce to derive a new key from the shared > symmetric key and the algorithm identifier. This would result in > different keys for AES-CBC and AES-GCM and thwart a BC attack. > > See also the last section of the paper by Kelsey et al. for more details. > > Thanks > Juraj > > > > Thanks a lot, > > --Richard > > > > [1] > > [2] < > > > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section= -4.6 > >> > > > > > > > > On Thu, Mar 14, 2013 at 8:00 PM, Juraj Somorovsky > > wrote: > > > >> Ok, thank you for mentioning. The attacks were implemented in August > >> 2012. I mean I used the old library. > >> > >> The newest library seems not to use AES-CBC. However, by taking a look > at > >> > >> > https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/69de24720368c480ee9347= 9ca84f3801a3f8909d/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java= ?at=3Dmaster#cl-153 > >> I assume it is still vulnerable to Bleichenbacher's attack (as it > >> responds with different Exceptions according to the PKCS1 validity). > >> > >> I reported this almost 1 year ago: > >> http://www.ietf.org/mail-archive/web/jose/current/msg00419.html > >> > >> Regards > >> Juraj > >> > >> On 03/14/2013 07:02 PM, Justin Richer wrote: > >>> Also, the Nimbus-JWT library has been deprecated in favor of > >>> Nimbus-JOSE-JWT: > >>> > >>> https://bitbucket.org/nimbusds/nimbus-jose-jwt/ > >>> > >>> The new library is tracking the JOSE specs even more closely, and I'd > be > >>> very interested to hear if the attack is still possible against the n= ew > >>> library. > >>> > >>> -- Justin > >>> > >>> On 03/14/2013 11:48 AM, Mike Jones wrote: > >>>> I believe that these attacks are only possible on encryption without > >>>> integrity, which in turn was only possible, because Nimbus-JWT > >>>> continued to implement encryption algorithms without integrity > >>>> protection. Someone should please correct me if I'm misunderstandin= g > >>>> the situation. > >>>> > >>>> As most of you know, JWE now only allows authenticated encryption > >>>> algorithms to be used, for reasons exactly such as these. > >>>> > >>>> -- Mike > >>>> > >>>> -----Original Message----- > >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > >>>> Of =3DJeffH > >>>> Sent: Thursday, March 14, 2013 8:17 AM > >>>> To: IETF JOSE WG > >>>> Cc: Juraj Somorovsky > >>>> Subject: [jose] backwards compatibility attack on JWT impls (was: I-= D > >>>> Action: draft-ietf-jose-json-web-algorithms-02.txt) > >>>> > >>>> back on Fri, 6 Jul 2012 Mike Jones said: > >>>> > > >>>> > Looking at this again, it seems to me that because JWE provides > >>>> integrity > protection for the algorithm, it should be impossible f= or > >>>> you to replace > "RSA-OAEP" with "RSA1_5" in the header because the= n > >>>> the integrity check will > fail. Thus, the attack that you describ= e > >>>> below is prevented by the integrity > protection of the header. > >>>> > > >>>> > Hence, correct JWE implementations do no provide the OAEP > >>>> decryption oracle > that you describe. However if I'm missing > >>>> something, please point it out to > me, since if there's an issue, > >>>> I'd like to understand it and how to mitigate > it. > >>>> > >>>> just fyi/fwiw...apologies if this has already been followed up on, b= ut > >>>> I didn't find further discussion of this after the above-quoted msg.= .. > >>>> > >>>> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) > >>>> attacks" paper [1] is now out, and it may help answer the above > >>>> questions. There's also Kenny Patterson's talk [2] from the recent > >>>> Workshop on Real-World Cryptography. > >>>> > >>>> It seems, from an admittedly cursory glance at both > >>>> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides= , > >>>> that perhaps there should be more implementation advice and security > >>>> considerations in (at least) the -json-web-algorithms spec. > >>>> > >>>> Here's some excerpts from the paper for context... > >>>> ... > >>>> In the public-key setting, we show how the well-known attack of > >>>> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] > >>>> attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 > >>>> encryption in both XML Encryption [27] and JSON Web Encryption [42], > >>>> and to forge signatures for arbitrary messages in XML Signature [30] > >>>> and JSON Web Signature [41]. The attack principle is described in > >>>> Section 4. We furthermore report on our experimental results, execut= ed > >>>> against the Java implementation of JSON Web Encryption and JSON Web > >>>> Signature Nimbus-JWT [53], in Section 5.3. > >>>> ... > >>>> > >>>> Platform for Experimental Analysis: We investigate the practicality > >>>> and performance of our attacks on JWE and JWS by applying them to th= e > >>>> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON > >>>> Web Encryption (JWE) and JSON Web Signature (JWS), developed by > >>>> NimbusDS to support their Cloud Identity management portfolio. > >>>> > >>>> Even though Nimbus-JWT claims to implement version 02 of the JWE > >>>> standard draft, it still supports usage of AESCBC (without MAC), whi= ch > >>>> was available in version 01, but not in version 02 or any subsequent > >>>> versions. > >>>> ... > >>>> > >>>> 5.2.3 Evaluation > >>>> > >>>> We evaluated performance of our attacks against both WSS4J and > >>>> Nimbus-JWT. We =EF=AC=81rst used the libraries to generate valid mes= sages > >>>> containing AES-GCM ciphertexts. Then we modi=EF=AC=81ed the algorith= m > >>>> parameters in the messages, forcing the receiver to process the > >>>> ciphertexts using AES-CBC, and executed the attack described in > >>>> Algorithm 1. The required ciphertext validity oracles were based on > >>>> error messages generated by the libraries. > >>>> ... > >>>> > >>>> Experimental Results. In order to assess the practicability and > >>>> performance of the attack, we implemented Bleichenbacher=E2=80=99s a= ttack on > >>>> XML Encryption [13, 38] and applied it to the Nimbus-JWT library. Th= e > >>>> PKCS#1 v1.5 validity oracle was provided by exceptions thrown by thi= s > >>>> library.11 > >>>> ... > >>>> > >>>> 11 In practice one would instead use the more elaborate attack > >>>> techniques of [38] to determine whether a given ciphertext is PKCS#1 > >>>> v1.5 valid. > >>>> ... > >>>> > >>>> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols > >>>> based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, > >>>> Advances in Cryptology =E2=80=93 CRYPTO=E2=80=9998, volume 1462 of L= ecture Notes in > >>>> Computer Science, pages 1=E2=80=9312. > >>>> Springer, Aug. 1998. > >>>> > >>>> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher=E2=80= =99s attack > >>>> strikes > >>>> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. > >>>> Yung, editors, Computer Security - ESORICS 2012 - 17th European > >>>> Symposium on Research in Computer Security, Pisa, Italy, September > >>>> 10-14, 2012. Proceedings, LNCS. > >>>> Springer, 2012. > >>>> > >>>> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. > >>>> https://bitbucket.org/nimbusds/nimbus-jwt. > >>>> > >>>> ### > >>>> > >>>> [1] One Bad Apple: Backwards Compatibility Attacks on > >>>> State-of-the-Art Cryptography > >>>> > >> > http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/0= 8/BackwardsCompatibilityAttacks.pdf > >>>> > >>>> > >>>> [2] Key Reuse: Theory and Practice > >>>> http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf > >>>> > >>>> > >>>> HTH, > >>>> > >>>> =3DJeffH > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> jose mailing list > >>>> jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose > >>>> _______________________________________________ > >>>> jose mailing list > >>>> jose@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/jose > >>> > >> _______________________________________________ > >> jose mailing list > >> jose@ietf.org > >> https://www.ietf.org/mailman/listinfo/jose > >> > > > --e89a8fb203187c416104d8539be8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <snip>

> -- Integrity protection of the algorithm value (as p= art of the JWS/JWE
> header). =C2=A0The attacker doesn't need to change the algorithm u= sed for any
> given object, only for two types of (independent, valid) objects to be=
> processed.
We did not understand this, could you please clarify?

The current JWE format provides an integrity check on = the header parameters, including the name of the algorithm with which the J= WE should be processed. =C2=A0In the BC attack, the attacker does not need = to modify the algorithm name on a GCM-encrypted object, he merely needs to = construct CBC-encrypted objects with which to query the oracle. =C2=A0So th= e integrity check on the algorithm name does not stop the BC attack.
=C2=A0
>
> On the other hand, the following changes to the spec WOULD mitigate BC=
> attacks.
> -- Recommending the use of a random CMK wherever possible
What do you mean by "wherever possible" please? ...it is ju= st necessary
to use this as a countermeasure against Bleichenbacher's attacks on
PKCS1.5. Reference to RFC 3218 and a short description of this
countermeasure would be enough.

An exam= ple of the case where using a random CMK is not currently possible is in JW= S, which does not allow wrapped keys for MAC. =C2=A0One might also imagine = deprecating the "alg":"dir" mode for JWE, where a stati= c key is used (or at least putting a big warning label on it).

=C2=A0
> -- Recommending that implementations follow the guid= elines in RFC 3218 [1]
see above.
> -- Recommending that implementations track which key= s are used with which
> algorithms, and prevent key reuse
Yes, it would be nice to enforce key separation in the JOSE
implementations and libraries by default so that users cannot use the
same key for different algorithms (e.g., a library could enforce the
user to generate two key pairs: one for signature processing and one for encryption processing). I do not know how feasible this is in general.
<= /blockquote>

Note that in order to prevent the attack, t= he checking only needs to be in the recipient side. =C2=A0It seems like thi= s could be done pretty trivially and safely.
-- Every time you decrypt an object, store the tuple (hash(key), algor= ithm) in a table
-- Before you decrypt the next object, look up h= ash(key) in the table and see if the algorithm is the same as the one you&#= 39;re about to use.

=C2=A0
> -- Deprecating / removing the "direct" mod= e of encryption [2], which
> encourages key reuse by making it harder to use random, ephemeral CMK<= br> > values.
Yes, this would be reasonable.

But we took e.g. a look at section 4.5:
http://tools.ietf.org/html/draft-ietf-jose= -json-web-algorithms-08#section-4.5
This section does not explicitly enforce key separation. If you want to
enforce a key separation (in case you are in possession of a shared
symmetric key), you could enforce to derive a new key from the shared
symmetric key and the algorithm identifier. This would result in
different keys for AES-CBC and AES-GCM and thwart a BC attack.

See also the last section of the paper by Kelsey et al. for more details.
Thanks
Juraj
>
> Thanks a lot,
> --Richard
>
> [1] <http://tools.ietf.org/html/rfc3218>
> [2] <
> http://tools.ietf.org/html/draft-ietf= -jose-json-web-algorithms-08#section-4.6
>>
>
>
>
> On Thu, Mar 14, 2013 at 8:00 PM, Juraj Somorovsky
> <juraj.somorovsky@rub.de= >wrote:
>
>> Ok, thank you for mentioning. The attacks were implemented in Augu= st
>> 2012. I mean I used the old library.
>>
>> The newest library seems not to use AES-CBC. However, by taking a = look at
>>
>> https://bitbucket.= org/nimbusds/nimbus-jose-jwt/src/69de24720368c480ee93479ca84f3801a3f8909d/s= rc/main/java/com/nimbusds/jose/crypto/RSADecrypter.java?at=3Dmaster#cl-153<= /a>
>> I assume it is still vulnerable to Bleichenbacher's attack (as= it
>> responds with different Exceptions according to the PKCS1 validity= ).
>>
>> I reported this almost 1 year ago:
>> http://www.ietf.org/mail-archive/web/jose/curre= nt/msg00419.html
>>
>> Regards
>> Juraj
>>
>> On 03/14/2013 07:02 PM, Justin Richer wrote:
>>> Also, the Nimbus-JWT library has been deprecated in favor of >>> Nimbus-JOSE-JWT:
>>>
>>> =C2=A0 https://bitbucket.org/nimbusds/nimbus-jose-jwt/<= br> >>>
>>> The new library is tracking the JOSE specs even more closely, = and I'd be
>>> very interested to hear if the attack is still possible agains= t the new
>>> library.
>>>
>>> =C2=A0-- Justin
>>>
>>> On 03/14/2013 11:48 AM, Mike Jones wrote:
>>>> I believe that these attacks are only possible on encrypti= on without
>>>> integrity, which in turn was only possible, because Nimbus= -JWT
>>>> continued to implement encryption algorithms without integ= rity
>>>> protection. =C2=A0Someone should please correct me if I= 9;m misunderstanding
>>>> the situation.
>>>>
>>>> As most of you know, JWE now only allows authenticated enc= ryption
>>>> algorithms to be used, for reasons exactly such as these.<= br> >>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 --= Mike
>>>>
>>>> -----Original Message-----
>>>> From: jose-bounce= s@ietf.org [mailto:jose-bounce= s@ietf.org] On Behalf
>>>> Of =3DJeffH
>>>> Sent: Thursday, March 14, 2013 8:17 AM
>>>> To: IETF JOSE WG
>>>> Cc: Juraj Somorovsky
>>>> Subject: [jose] backwards compatibility attack on JWT impl= s (was: I-D
>>>> Action: draft-ietf-jose-json-web-algorithms-02.txt)
>>>>
>>>> back on Fri, 6 Jul 2012 =C2=A0Mike Jones said:
>>>> =C2=A0 >
>>>> =C2=A0 > Looking at this again, it seems to me that bec= ause JWE provides
>>>> integrity =C2=A0> protection for the algorithm, it shou= ld be impossible for
>>>> you to replace =C2=A0> "RSA-OAEP" with "= RSA1_5" in the header because then
>>>> the integrity check will =C2=A0> fail. =C2=A0Thus, the = attack that you describe
>>>> below is prevented by the integrity =C2=A0> protection = of the header.
>>>> =C2=A0 >
>>>> =C2=A0 > Hence, correct JWE implementations do no provi= de the OAEP
>>>> decryption oracle =C2=A0> that you describe. =C2=A0Howe= ver if I'm missing
>>>> something, please point it out to =C2=A0> me, since if = there's an issue,
>>>> I'd like to understand it and how to mitigate =C2=A0&g= t; it.
>>>>
>>>> just fyi/fwiw...apologies if this has already been followe= d up on, but
>>>> I didn't find further discussion of this after the abo= ve-quoted msg...
>>>>
>>>> Juraj Somorovsky et al's NDSS-2013 "Backwards Com= patibility (BC)
>>>> attacks" paper [1] is now out, and it may help answer= the above
>>>> questions. There's also Kenny Patterson's talk [2]= from the recent
>>>> Workshop on Real-World Cryptography.
>>>>
>>>> It seems, from an admittedly cursory glance at both
>>>> draft-ietf-jose-json-web-algorithms (-08) and the above pa= per/slides,
>>>> that perhaps there should be more implementation advice an= d security
>>>> considerations in (at least) the -json-web-algorithms spec= .
>>>>
>>>> Here's some excerpts from the paper for context...
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>> In the public-key setting, we show how the well-known atta= ck of
>>>> Bleichenbacher [13] gives rise to a BC [Backwards Compatib= ility]
>>>> attack that allows an attacker to decrypt ciphertexts of P= KCS#1 v2.0
>>>> encryption in both XML Encryption [27] and JSON Web Encryp= tion [42],
>>>> and to forge signatures for arbitrary messages in XML Sign= ature [30]
>>>> and JSON Web Signature [41]. The attack principle is descr= ibed in
>>>> Section 4. We furthermore report on our experimental resul= ts, executed
>>>> against the Java implementation of JSON Web Encryption and= JSON Web
>>>> Signature Nimbus-JWT [53], in Section 5.3.
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>>
>>>> Platform for Experimental Analysis: We investigate the pra= cticality
>>>> and performance of our attacks on JWE and JWS by applying = them to the
>>>> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementati= on of JSON
>>>> Web Encryption (JWE) and JSON Web Signature (JWS), develop= ed by
>>>> NimbusDS to support their Cloud Identity management portfo= lio.
>>>>
>>>> Even though Nimbus-JWT claims to implement version 02 of t= he JWE
>>>> standard draft, it still supports usage of AESCBC (without= MAC), which
>>>> was available in version 01, but not in version 02 or any = subsequent
>>>> versions.
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>>
>>>> 5.2.3 Evaluation
>>>>
>>>> We evaluated performance of our attacks against both WSS4J= and
>>>> Nimbus-JWT. We =EF=AC=81rst used the libraries to generate= valid messages
>>>> containing AES-GCM ciphertexts. Then we modi=EF=AC=81ed th= e algorithm
>>>> parameters in the messages, forcing the receiver to proces= s the
>>>> ciphertexts using AES-CBC, and executed the attack describ= ed in
>>>> Algorithm 1. The required ciphertext validity oracles were= based on
>>>> error messages generated by the libraries.
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>>
>>>> Experimental Results. In order to assess the practicabilit= y and
>>>> performance of the attack, we implemented Bleichenbacher= =E2=80=99s attack on
>>>> XML Encryption [13, 38] and applied it to the Nimbus-JWT l= ibrary. The
>>>> PKCS#1 v1.5 validity oracle was provided by exceptions thr= own by this
>>>> library.11
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>>
>>>> 11 In practice one would instead use the more elaborate at= tack
>>>> techniques of [38] to determine whether a given ciphertext= is PKCS#1
>>>> v1.5 valid.
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0...
>>>>
>>>> [13] D. Bleichenbacher. Chosen ciphertext attacks against = protocols
>>>> based on the RSA encryption standard PKCS#1. In H. Krawczy= k, editor,
>>>> Advances in Cryptology =E2=80=93 CRYPTO=E2=80=9998, volume= 1462 of Lecture Notes in
>>>> Computer Science, pages 1=E2=80=9312.
>>>> Springer, Aug. 1998.
>>>>
>>>> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbac= her=E2=80=99s attack
>>>> strikes
>>>> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Fores= ti and M.
>>>> Yung, editors, Computer Security - ESORICS 2012 - 17th Eur= opean
>>>> Symposium on Research in Computer Security, Pisa, Italy, S= eptember
>>>> 10-14, 2012. Proceedings, LNCS.
>>>> Springer, 2012.
>>>>
>>>> [53] Nimbus Directory Services. Nimbus JSON Web Token, May= 2012.
>>>> https://bitbucket.org/nimbusds/nimbus-jwt.
>>>>
>>>> ###
>>>>
>>>> [1] One Bad Apple: Backwards Compatibility Attacks on
>>>> =C2=A0 =C2=A0State-of-the-Art Cryptography
>>>>
>> ht= tp://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/Ba= ckwardsCompatibilityAttacks.pdf
>>>>
>>>>
>>>> [2] Key Reuse: Theory and Practice
>>>> http://crypto.stanford.edu/RealWorldCrypto/= slides/kenny.pdf
>>>>
>>>>
>>>> HTH,
>>>>
>>>> =3DJeffH
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>> _______________________________________________
>>>> jose mailing list
>>>> jose@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/jose
>>>
>> _______________________________________________
>> jose mailing list
>> jose@ietf.org
>> https://www.ietf.org/mailman/listinfo/jose
>>
>

--e89a8fb203187c416104d8539be8-- From rlb@ipv.sx Tue Mar 19 21:26:45 2013 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 AB8E721F8C11 for ; Tue, 19 Mar 2013 21:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.51 X-Spam-Level: X-Spam-Status: No, score=-0.51 tagged_above=-999 required=5 tests=[AWL=-1.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 RcPJfjpY28OU for ; Tue, 19 Mar 2013 21:26:44 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3A12F21F8BEB for ; Tue, 19 Mar 2013 21:26:43 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id eh20so1185161obb.8 for ; Tue, 19 Mar 2013 21:26:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=c/d+dvjeNe8P+F9a6J6KX6Vjbt1I3cP9tLm6RRQa+DA=; b=i2f1jpJw3B1jxJcFg3H10d9ia3xsGg2EC6n8xf3ey/14PADEg/pc56+8O3q7aAjIQG gAZOYRQqnKTUVaZziCSMTBg6Sniwyzw1SNFayRhS6IZYApyeqkfHT8AvUvB8IJfIC1Ek FkG6OsGI4Ya9JPkSE1Bbfs4EzQ1lHj9DAe3/hYvuKfZO7NyNKzP/e0vSydWQsFR4QBck ItGETKC34nzQiYgkHkNuUOgFSrBQYXUFvagEod3zYSyaprK0MPnywYWQDgcmaoQXOPmv s5uGJRxoWGJYOGEnWrn9st6+uYk8RegHdPcJ0clNJc0gnItH9yC+G68JPNbz7DoPhuPB G2CQ== MIME-Version: 1.0 X-Received: by 10.182.59.20 with SMTP id v20mr3177073obq.80.1363753603495; Tue, 19 Mar 2013 21:26:43 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Tue, 19 Mar 2013 21:26:43 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: References: Date: Wed, 20 Mar 2013 00:26:43 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=14dae93a0db119078504d853a1e4 X-Gm-Message-State: ALoCoQm9oo/nPjPOzf5d7IA0LLCyKk14RGz2jIJJyJdiVb5gNweYxkktaWrjdMCJvw+rDa/hW0iD Cc: "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 20 Mar 2013 04:26:46 -0000 --14dae93a0db119078504d853a1e4 Content-Type: text/plain; charset=ISO-8859-1 Not denying it's useful (or "alg"). Just saying that the JWK core spec might not be the place to define them. Or, alternatively, that if we do define them, we should align syntax/semantics with WebCrypto to avoid conflicts. On Tue, Mar 19, 2013 at 2:45 PM, Brian Campbell wrote: > "use" is useful in the context of some entity providing its public keys in > a JWK Set somewhere for some other party to consume those keys and know > what to do with them. > > > > > On Tue, Mar 19, 2013 at 11:30 AM, Richard Barnes wrote: > >> >> 1) Should JWK parameter names be absolutely unique, or are they >>> potentially tied to a specific JWK type? In looking at the specs to date, >>> I think there's only one case where a parameter name is re-used ("d" for >>> both private RSA and ECC keys); currently syntactically and semantically >>> identical, but I'm not sure that's adequate. >>> >> >> I think it makes sense for parameter names to be potentially contingent >> on key type. Emphasis on "potentially" -- there could be attributes that >> are the same for all key types. I would also propose that we make "kty" a >> mandatory attribute. >> >> >> >>> 2) Should JWK parameters be marked as private (confidential, secret, >>> privileged, etc etc)? The current documentation set loosely defines this >>> only because they are current split between multiple documents. However, I >>> wonder if there is value in being much more explicit about it, including in >>> a parameter's registration. >>> >> >> If we fold JPSK in to JWA (which we should do), then ISTM that we should >> also note which parameters are private, in the sense of "have a column in >> the registry that marks this as a "private" parameter". Note that >> designation as private would not necessarily imply that you MUST do any >> particular thing. One can envision, for example, cases where it might be >> safe to pass private keys in plaintext (e.g., over TLS). >> >> One other question: >> >> 3) Should we remove "policy" attributes from JWK? The current JWK spec >> includes a variety of attributes that are not directly specifying parts of >> the key, namely "use" and "alg". These are application-related fields, and >> run the risk of conflicting with existing applications' attributes. For >> example, the WebCrypto API has a notion of key usages and algorithm >> restriction, but the values they use do not map to the "use" and "alg" >> values. Should we align with WebCrypto (and risk conflicting with other >> apps), or remove the policy bits altogether (and require apps to align >> themselves)? FWIW, I am fine with "kid" staying there, because (1) it's >> opaque, and (2) it's actually used in JOSE processing. >> >> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --14dae93a0db119078504d853a1e4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not denying it's useful (or "alg"). =A0Just saying that the J= WK core spec might not be the place to define them. =A0Or, alternatively, t= hat if we do define them, we should align syntax/semantics with WebCrypto t= o avoid conflicts.


On Tue, Mar 19, 2013 at 2:45 = PM, Brian Campbell <bcampbell@pingidentity.com> wro= te:
"use" is useful i= n the context of some entity providing its public keys in a JWK Set somewhe= re for some other party to consume those keys and know what to do with them= .




On Tue, Mar 19, 2= 013 at 11:30 AM, Richard Barnes <rlb@ipv.sx> wrote:
=

1) Should JWK parameter names be absolutely unique, or are they potentially= tied to a specific JWK type? =A0In looking at the specs to date, I think t= here's only one case where a parameter name is re-used ("d" f= or both private RSA and ECC keys); currently syntactically and semantically= identical, but I'm not sure that's adequate.

I think it makes sense for parameter names= to be potentially contingent on key type. =A0Emphasis on "potentially= " -- there could be attributes that are the same for all key types. = =A0I would also propose that we make "kty" a mandatory attribute.=

=A0
2) Should JWK parameters be marked as private (confidential, secret, privil= eged, etc etc)? =A0The current documentation set loosely defines this only = because they are current split between multiple documents. =A0However, I wo= nder if there is value in being much more explicit about it, including in a= parameter's registration.

If we fold JPSK in to JWA (which we should= do), then ISTM that we should also note which parameters are private, in t= he sense of "have a column in the registry that marks this as a "= private" parameter". =A0Note that designation as private would no= t necessarily imply that you MUST do any particular thing. =A0One can envis= ion, for example, cases where it might be safe to pass private keys in plai= ntext (e.g., over TLS).

One other question:

3) Should = we remove "policy" attributes from JWK? =A0The current JWK spec i= ncludes a variety of attributes that are not directly specifying parts of t= he key, namely "use" and "alg". =A0These are applicatio= n-related fields, and run the risk of conflicting with existing application= s' attributes. =A0For example, the WebCrypto API has a notion of key us= ages and algorithm restriction, but the values they use do not map to the &= quot;use" and "alg" values. =A0Should we align with WebCrypt= o (and risk conflicting with other apps), or remove the policy bits altoget= her (and require apps to align themselves)? =A0FWIW, I am fine with "k= id" staying there, because (1) it's opaque, and (2) it's actua= lly used in JOSE processing.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--14dae93a0db119078504d853a1e4-- From James.H.Manger@team.telstra.com Tue Mar 19 21:38:54 2013 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 DA8C821F8ABC for ; Tue, 19 Mar 2013 21:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.709 X-Spam-Level: X-Spam-Status: No, score=-1.709 tagged_above=-999 required=5 tests=[AWL=-0.808, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 OD5OaAuLekyT for ; Tue, 19 Mar 2013 21:38:54 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 12A4121F89DA for ; Tue, 19 Mar 2013 21:38:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,876,1355058000"; d="scan'208";a="125057637" Received: from unknown (HELO ipccvi.tcif.telstra.com.au) ([10.97.217.208]) by ipocvi.tcif.telstra.com.au with ESMTP; 20 Mar 2013 15:38:46 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7019"; a="120178133" Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipccvi.tcif.telstra.com.au with ESMTP; 20 Mar 2013 15:38:46 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) with mapi; Wed, 20 Mar 2013 15:38:46 +1100 From: "Manger, James H" To: "Matt Miller (mamille2)" , "jose@ietf.org" Date: Wed, 20 Mar 2013 15:38:44 +1100 Thread-Topic: JWK Parameter Registry Considerations Thread-Index: AQHOJKx8FqJE351Np0SzIVUR6z+Zd5itxK0g Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BBD8BEA@WSMSG3153V.srv.dir.telstra.com> References: In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [jose] JWK Parameter Registry Considerations 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, 20 Mar 2013 04:38:55 -0000 PiAyKSBTaG91bGQgSldLIHBhcmFtZXRlcnMgYmUgbWFya2VkIGFzIHByaXZhdGUgKGNvbmZpZGVu dGlhbCwgc2VjcmV0LA0KPiBwcml2aWxlZ2VkLCBldGMgZXRjKT8gIFRoZSBjdXJyZW50IGRvY3Vt ZW50YXRpb24gc2V0IGxvb3NlbHkgZGVmaW5lcw0KPiB0aGlzIG9ubHkgYmVjYXVzZSB0aGV5IGFy ZSBjdXJyZW50IHNwbGl0IGJldHdlZW4gbXVsdGlwbGUgZG9jdW1lbnRzLg0KPiBIb3dldmVyLCBJ IHdvbmRlciBpZiB0aGVyZSBpcyB2YWx1ZSBpbiBiZWluZyBtdWNoIG1vcmUgZXhwbGljaXQgYWJv dXQNCj4gaXQsIGluY2x1ZGluZyBpbiBhIHBhcmFtZXRlcidzIHJlZ2lzdHJhdGlvbi4NCg0KWWVz LCBidXQgbm90IHdpdGggYSByZWdpc3RyeSBmbGFnLg0KUHV0dGluZyB0aGUgcHJpdmF0ZSB2YWx1 ZXMgaW4gYSBzZXBhcmF0ZSBzdWItb2JqZWN0IHdvdWxkIGJlIGJldHRlciAoZWcgInByaSI6eyJk IjouLi59KS4gSXQgd291bGQgIGFsbG93IHlvdSB0byBub3RpY2UgcHJpdmF0ZSB2YWx1ZXMgd2l0 aG91dCBuZWVkaW5nIHRvIGtub3cgZXZlcnkga2V5IHR5cGUgKG9yIGxvb2tpbmcgdXAgYSByZWdp c3RyeSkuDQoNCg0KPiAxKSBTaG91bGQgSldLIHBhcmFtZXRlciBuYW1lcyBiZSBhYnNvbHV0ZWx5 IHVuaXF1ZSwgb3IgYXJlIHRoZXkNCj4gcG90ZW50aWFsbHkgdGllZCB0byBhIHNwZWNpZmljIEpX SyB0eXBlPyAgSW4gbG9va2luZyBhdCB0aGUgc3BlY3MgdG8NCj4gZGF0ZSwgSSB0aGluayB0aGVy ZSdzIG9ubHkgb25lIGNhc2Ugd2hlcmUgYSBwYXJhbWV0ZXIgbmFtZSBpcyByZS11c2VkDQo+ICgi ZCIgZm9yIGJvdGggcHJpdmF0ZSBSU0EgYW5kIEVDQyBrZXlzKTsgY3VycmVudGx5IHN5bnRhY3Rp Y2FsbHkgYW5kDQo+IHNlbWFudGljYWxseSBpZGVudGljYWwsIGJ1dCBJJ20gbm90IHN1cmUgdGhh dCdzIGFkZXF1YXRlLg0KDQpJZiBwcml2YXRlIGNvbXBvbmVudHMgYXJlIGluIGEgInByaSIgZmll bGQgYW5kIHB1YmxpYyBjb21wb25lbnRzIChhbmQgY29tbW9uIHBhcmFtZXRlcnMgc3VjaCBhcyBh IGVsbGlwdGljIGN1cnZlIGlkKSBhcmUgaW4gYSAicHViIiBmaWVsZCwgdGhlbiBpdCBpcyBmYWly bHkgb2J2aW91cyB0aGF0IHRoZXNlIGNvbXBvbmVudHMgZGVwZW5kIG9uIHRoZSB0eXBlIG9mIGtl eSBzbyB0aGVyZSBpcyBubyBuZWVkIHRvIGhhdmUgYSByZWdpc3RyeSBmb3IgdGhlbSAtLSBqdXN0 IHJlZ2lzdGVyIGtleSB0eXBlcy4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQo= From Vijay.Bharadwaj@microsoft.com Wed Mar 20 00:11:03 2013 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 BA36521F857E for ; Wed, 20 Mar 2013 00:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8Hp1Mpj29Ji4 for ; Wed, 20 Mar 2013 00:11:03 -0700 (PDT) Received: from na01-sn2-obe.outbound.o365filtering.com (na01-sn2-obe.ptr.o365filtering.com [157.55.158.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4A6FE21F8F4E for ; Wed, 20 Mar 2013 00:11:02 -0700 (PDT) Received: from BY2SR01CA105.namsdf01.sdf.exchangelabs.com (10.255.93.150) by BY2SR01MB607.namsdf01.sdf.exchangelabs.com (10.255.93.166) with Microsoft SMTP Server (TLS) id 15.0.658.4; Wed, 20 Mar 2013 07:10:59 +0000 Received: from SN2FFOFD001.ffo.gbl (157.55.158.30) by BY2SR01CA105.outlook.office365.com (10.255.93.150) with Microsoft SMTP Server (TLS) id 15.0.658.4 via Frontend Transport; Wed, 20 Mar 2013 07:10:59 +0000 Received: from hybrid.exchange.microsoft.com (131.107.1.27) by SN2FFOFD001.mail.o365filtering.com (10.111.201.20) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Wed, 20 Mar 2013 07:10:59 +0000 Received: from DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) by DF-G14-02.exchange.corp.microsoft.com (157.54.87.56) with Microsoft SMTP Server (TLS) id 14.3.123.1; Wed, 20 Mar 2013 00:10:28 -0700 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com (157.54.109.47) by DFM-TK5MBX15-06.exchange.corp.microsoft.com (157.54.109.45) with Microsoft SMTP Server (TLS) id 15.0.620.14; Wed, 20 Mar 2013 00:10:27 -0700 Received: from DFM-TK5MBX15-08.exchange.corp.microsoft.com ([169.254.8.239]) by DFM-TK5MBX15-08.exchange.corp.microsoft.com ([169.254.8.239]) with mapi id 15.00.0620.012; Wed, 20 Mar 2013 00:10:27 -0700 From: Vijay Bharadwaj To: Jim Schaad , 'Richard Barnes' , "jose@ietf.org" Thread-Topic: Re: [jose] WebCrypto feedback on key wrapping Thread-Index: Ac4lNppbu54n167OQAKGAqL/wyqkyQ== Date: Wed, 20 Mar 2013 07:10:26 +0000 Message-ID: <5cb6f00bd3d0432dbeb51ab456085893@DFM-TK5MBX15-08.exchange.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.13] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.1.27; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(51856001)(56816002)(50466001)(50986001)(16406001)(4396001)(53806001)(79102001)(44976002)(876001)(49866001)(54356001)(31966008)(47736001)(66066001)(76482001)(74502001)(77982001)(56776001)(33646001)(80022001)(23756002)(59766001)(74662001)(69226001)(46102001)(20776003)(47776003)(65816001)(63696002)(47446002)(54316002)(47976001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2SR01MB607; H:hybrid.exchange.microsoft.com; RD:mail7.exchange.microsoft.com; MX:1; A:1; LANG:en; X-Forefront-PRVS: 07915F544A X-OriginatorOrg: DuplicateDomain-7923a859-03c9-4312-a77c-440aa45aaf52.microsoft.com Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 20 Mar 2013 07:13:57 -0000 Some clarifications on the WebCrypto discussion: [RLB] 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen = out of favor with some parts of the cryptographic community. =A0People pref= er to be able to use AEAD algorithms for key wrapping, since they are perce= ived to be faster and offer a higher level of security than AES-KW. He gave= the example that IEEE 802.1 uses AES CCM. [JLS] AES Key Wrap is an AD algorithm and a variant of it exists that is an= AEAD algorithm.=A0 So this is a case of not correctly using terminology.= =A0 I would also question the issue of perceived security as with AES-KW ev= ery bit of the plain text affects every other bit of plain text in the encr= yption process and this is not true for AES-GW or AES-CCM. =A0I would agree= that there is both a speed advantage and perhaps more importantly the fact= that only one side of the AES engine is needed (i.e. you only need to encr= ypt but not decrypt) for AES CCM and AES-GCM. Perhaps "fallen out of favor" is a bit strong. It just doesn't seem to have= caught on as much as other algorithms.=20 The statement was that a number of people seem to prefer other AEAD algorit= hms for key wrapping. There are various reasons - there is a speed issue as= you mentioned, and some worry about provable security. Also, if you are do= ing a CMS-like format such as JWE, it may be simpler to have a single algor= ithm for both the content encryption and key wrapping. Regardless, one sees= more of the other AEAD algorithms in practice today than of AES key wrap a= nd its variants. [RLB] 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt= wrapped key objects, then we would need something other than OAEP in order= to carry arbitrary-length payloads. =A0I agreed, and suggested that someth= ing like RSA-KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay obse= rved that KEM is troublesome due to the lack of support by native crypto li= braries. [JLS] Note that using RSA-KEM is not using RSA directly.=A0 RSA-KEM should = be thought of as a single party key agreement algorithm and not a key trans= port algorithm.=A0 You encrypt a large integer and then run a KDF on that l= arge integer to get a key.=A0 I perceive no advantage to using RSA-KEM exce= pt for the fact that the security on it is more provable. The discussion was more mundane than that. The underlying requirement was t= o be able to use RSA keys to wrap arbitrary-sized key objects. For example,= using a 2048-bit RSA key to wrap a key object that itself contains a 2048-= bit RSA key. Our observation was that this requires either a CMS-like appro= ach where the wrapping key wraps a content encryption key which encrypts th= e inner key object, or the use of a mode like KEM, which as you note is bas= ically the same thing. From watsonm@netflix.com Wed Mar 20 06:56:00 2013 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 BEF9A21F8D3C for ; Wed, 20 Mar 2013 06:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.264 X-Spam-Level: X-Spam-Status: No, score=-10.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, 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 lKeQBEDn9nlS for ; Wed, 20 Mar 2013 06:55:57 -0700 (PDT) Received: from exout103.netflix.com (exout103.netflix.com [69.53.237.162]) by ietfa.amsl.com (Postfix) with ESMTP id 801BD21F8F73 for ; Wed, 20 Mar 2013 06:55:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; bh=7qtNJtLoHs9IDyFXvOTPot9n/2o=; b=H4PruLxyUlomNf5M/7+nQTancXQHw57xVKaOfPCXm+CzkBG4JwaVGTr871uefZ0yECHnqgWL LG1BzG3O3r7D5kXREisPVUVDwcrbiZ55wK+MgNDX3yYDDspO4s0TR2wUmq5KgU8Fv0mf4H8g loMYLzSytnWtRQUvavqT+ZwegWlnFg37kANWzWijXoflrV4agjeXhlx9CiumuZFrDGsrvANO UJlv5YGkFjejPDXwxPJLCSNccJ2DinqT4Obgn4DlurMKzvh2gSXscpHq3L9nQcaOCz7GFEqm HNcAN4FTbFNCpI3MGPqgGCF5nO/QDVv+4Srz0/O4nCAzb2hKdRAElA== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048;d=netflix.com; h=from:to:cc:subject:date:message-id:references:in-reply-to :content-type:mime-version; b=obyp3687NtCGUC7WU+DEieznfV0Vo61A/uoQeAQawNUJ6Jv+NXpPhJlDPKwuXOs7T3SiGQok Y2K65UYZ25YqSR7no9rzTzOxraJByWnCw+XKuzb06DDk+TolwdzBPpWylaqaCl/sqy9icmkJ dc5AGT7dTEuFMc8kOwUdtKhR+R2ykji30rB/MdoEZfgEKzwX1hCjQyEztQ8rHyoZ9QhCOX25 FLqUFLiesNe9uf3alb0ZaPwRX2VDcmMkWi9IPSNtmaMnYaqxyAFEy7ZD+HuJmnHSn81nMJ9O AQ8BRaj1pjL9TJinv9upiPtFLRwpVAorwWA3yplVwYC2CCiUQbolsg== Received: from EXFE104.corp.netflix.com (10.64.32.104) by exout103.netflix.com (10.64.240.73) with Microsoft SMTP Server (TLS) id 14.2.298.4; Wed, 20 Mar 2013 06:58:27 -0700 Received: from EXMB106.corp.netflix.com ([169.254.6.196]) by exfe104.corp.netflix.com ([10.64.32.104]) with mapi id 14.02.0283.003; Wed, 20 Mar 2013 06:55:53 -0700 From: Mark Watson To: Mike Jones Thread-Topic: [jose] WebCrypto feedback on key wrapping Thread-Index: AQHOJC/gHm/6YfyVNUer4VrZXdmufpislwMAgADztQCAAB+PgIAA8p+X Date: Wed, 20 Mar 2013 13:55:53 +0000 Message-ID: References: <4E1F6AAD24975D4BA5B16804296739436755A50C@TK5EX14MBXC283.redmond.corp.microsoft.com> , <4E1F6AAD24975D4BA5B168042967394367561ECB@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367561ECB@TK5EX14MBXC283.redmond.corp.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D3D9BDDFC5F54BE3AA1ADCDB058238FEnetflixcom_" MIME-Version: 1.0 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] WebCrypto feedback on key wrapping 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, 20 Mar 2013 13:56:00 -0000 --_000_D3D9BDDFC5F54BE3AA1ADCDB058238FEnetflixcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sent from my iPhone On Mar 19, 2013, at 9:27 AM, "Mike Jones" > wrote: Yes, but at least as I see it, you wouldn=92t wrap a JWK with OAEP directly= . You=92d encrypt an ephemeral symmetric key with OAEP and then use an aut= henticated symmetric key encryption algorithm to encrypt the JWK. This is = exactly what a JWE does. Yes, this is how it works in the JWE-wrapped-JWK proposal for key wrapping.= I am fine with this. I was asking how it would work with Richard's alterna= tive proposal. ...Mark -- Mike From: Mark Watson [mailto:watsonm@netflix.com] Sent: Tuesday, March 19, 2013 7:33 AM To: Mike Jones Cc: Richard Barnes; jose@ietf.org Subject: Re: [jose] WebCrypto feedback on key wrapping On Mar 18, 2013, at 5:02 PM, Mike Jones wrote: Given that we require RSA keys to be a minimum of 2048 bits in length, ther= e=92s no problem wrapping 768 bit keys with OAEP in practice. Sure, but there would be a problem if what you are wrapping is a JWK object= , which could get much bigger than 768 bits. =85Mark -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, March 18, 2013 4:25 PM To: jose@ietf.org Subject: [jose] WebCrypto feedback on key wrapping On today's call with the W3C WebCrypto working group, I reported on the di= scussion of JOSE key wrapping at the last IETF. I was asked to relay a few= bits of feedback: 1. Vijay Bharadwaj (Microsoft) observed that AES key wrap has fallen out of= favor with some parts of the cryptographic community. People prefer to be= able to use AEAD algorithms for key wrapping, since they are perceived to = be faster and offer a higher level of security than AES-KW. He gave the exa= mple that IEEE 802.1 uses AES CCM. 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt wrapp= ed key objects, then we would need something other than OAEP in order to ca= rry arbitrary-length payloads. I agreed, and suggested that something like= RSA-KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that = KEM is troublesome due to the lack of support by native crypto libraries. It seems to me that these comments have impacts on JWE and JWS (pending ISS= UE-2), as well as the wrapping discussion. The former has more impact than= the latter. Point number 1 implies that we should offer AEAD for key wrapping in JWE as= well as for wrapped keys. It seems to me that the simplest approach to th= is would be to make the "alg" field contain an object that is semantically = equivalent to an AlgorithmIdentifier in CMS/PKCS8. For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }. This syntax, incidentally, is roughly t= he same form that algorithm identifiers have in the WebCrypto API. Note th= at this type of key wrapping is supported in CMS by the use of an AEAD Algo= rithmIdentifier in the KEKRecipientInfo structure. Point number 2 likely applies for some scenarios of JWE, especially if we a= dopt the McGrew approach. For example, if using HMAC-SHA1 and AES with a 2= 56-bit key, the total key length is 788 bits, which is too long to be encry= pted with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. = The best idea I've got is to allow wrapped keys to nest, so that you can w= rap a key inside of another wrapped key. I will try to take these points into account in my forthcoming key wrapping= draft, and I've filed two issues against JWE to track them. --Richard _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_D3D9BDDFC5F54BE3AA1ADCDB058238FEnetflixcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


Sent from my iPhone

On Mar 19, 2013, at 9:27 AM, "Mike Jones" <Michael.Jones@microsoft.com> wrote:

Yes, but at least as I se= e it, you wouldn=92t wrap a JWK with OAEP directly.  You=92d encrypt a= n ephemeral symmetric key with OAEP and then use an authenticated symmetric key encryption algorithm to encrypt the JWK.  This is exact= ly what a JWE does.


Yes, this is how it works in the JWE-wrapped-JWK proposal for key wrap= ping. I am fine with this. I was asking how it would work with Richard's al= ternative proposal.

...Mark

 <= /p>

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

 <= /p>

From: Mark Wat= son [mailto:watsonm@netflix.com]
Sent: Tuesday, March 19, 2013 7:33 AM
To: Mike Jones
Cc: Richard Barnes; jose@ietf.org
Subject: Re: [jose] WebCrypto feedback on key wrapping

 

 

On Mar 18, 2013, at 5:02 PM, Mike Jones wrote:<= /o:p>



Given that we require RSA= keys to be a minimum of 2048 bits in length, there=92s no problem wrapping= 768 bit keys with OAEP in practice.

 

Sure, but there would be a problem if what you are w= rapping is a JWK object, which could get much bigger than 768 bits.

 

=85Mark



 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org= ] On Behalf Of Richard Barnes
Sent: Monday, Marc= h 18, 2013 4:25 PM
To: jose@ietf.org
Subject: [jose] We= bCrypto feedback on key wrapping

 

On today's call with the W3C WebCrypto working  = ;group, I reported on the discussion of JOSE key wrapping at the last IETF.=  I was asked to relay a few bits of feedback:

 

1. Vijay Bharadwaj (Microsoft) observed that AES key= wrap has fallen out of favor with some parts of the cryptographic communit= y.  People prefer to be able to use AEAD algorithms for key wrapping, = since they are perceived to be faster and offer a higher level of security than AES-KW. He gave the example that IEE= E 802.1 uses AES CCM.

 

2. Mark Watson (Netflix) noted that if we use RSA di= rectly to encrypt wrapped key objects, then we would need something other t= han OAEP in order to carry arbitrary-length payloads.  I agreed, and s= uggested that something like RSA-KEM would be necessary.  Ryan Sleevi (Google) and Vijay observed that KEM is tr= oublesome due to the lack of support by native crypto libraries.=

 

It seems to me that these comments have impacts on J= WE and JWS (pending ISSUE-2), as well as the wrapping discussion.  The= former has more impact than the latter. 

 

Point number 1 implies that we should offer AEAD for= key wrapping in JWE as well as for wrapped keys.  It seems to me that= the simplest approach to this would be to make the "alg" field c= ontain an object that is semantically equivalent to an AlgorithmIdentifier in CMS/PKCS8.  For example, { name: "A= 128GCM", iv: "PCIGJe0DjunuM7s0" }.  This syntax, incide= ntally, is roughly the same form that algorithm identifiers have in the Web= Crypto API.  Note that this type of key wrapping is supported in CMS by the use of an AEAD AlgorithmIdentifier in the KEKRecipientInfo s= tructure.  

 

Point number 2 likely applies for some scenarios of = JWE, especially if we adopt the McGrew approach.  For example, if usin= g HMAC-SHA1 and AES with a 256-bit key, the total key length is 788 bits, w= hich is too long to be encrypted with OAEP under a 1,024-bit RSA key.  I'm not sure how to resolve it.  The= best idea I've got is to allow wrapped keys to nest, so that you can wrap = a key inside of another wrapped key.

 

I will try to take these points into account in my f= orthcoming key wrapping draft, and I've filed two issues against JWE to tra= ck them.

 

--Richard

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

 

--_000_D3D9BDDFC5F54BE3AA1ADCDB058238FEnetflixcom_-- From rlb@ipv.sx Wed Mar 20 07:01:38 2013 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 1918021F8F76 for ; Wed, 20 Mar 2013 07:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 v9Z8WxLhbFD4 for ; Wed, 20 Mar 2013 07:01:37 -0700 (PDT) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 4C00921F8DE9 for ; Wed, 20 Mar 2013 07:01:37 -0700 (PDT) Received: by mail-oa0-f54.google.com with SMTP id n12so1770323oag.27 for ; Wed, 20 Mar 2013 07:01:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=EQ+/LKLZlIxU/tSfxJl059Dh9c/dJZh3JbP56EwIS9g=; b=OfUS80InTG1G+4iwCqmm1VpnjcGGHDx43CSeHxaNO3noC9XD8R5qg9Vafh7roff2v6 cPjCYq1WtT+svpbgoqaQgTndwFQl8/VBoQ1FHlLiyL0ihToFqAdd5ql1BC+AgcBap6wj /3DKbfeVfC7QwZ4CNfG9yZqrjalcrpcgAFlS8zTISlix5jAEzqXkP4sfgwEGrjGusSND K/vmQDo8IgixmFtfSWpbWNDLUtDPrNBTidxwfgpMbLFCZjhUXE58cBjKu6AZVUKfTPlU o8jgWL8EbwbDbQBY2jrqHkDRP77//Bkz5ceu4eXRfJAb2FdVYJhBNOC0tnwrP7MF7V5C 8cZw== MIME-Version: 1.0 X-Received: by 10.182.8.70 with SMTP id p6mr4048436oba.90.1363788096711; Wed, 20 Mar 2013 07:01:36 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Wed, 20 Mar 2013 07:01:36 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BBD8BEA@WSMSG3153V.srv.dir.telstra.com> References: <255B9BB34FB7D647A506DC292726F6E1150BBD8BEA@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 20 Mar 2013 10:01:36 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=f46d0444ea410e0df004d85ba913 X-Gm-Message-State: ALoCoQmfQoqHeVNgfb586IckIuRiWFPNtJSIPSFjXYM6kc8e5dZbtn5/ZgiGMQsyr3MTsaelchlp Cc: "jose@ietf.org" , "Matt Miller \(mamille2\)" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 20 Mar 2013 14:01:38 -0000 --f46d0444ea410e0df004d85ba913 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think what Matt was asking was less about how the recipient of an object knows which fields the sender considers private, and more about how a sender knows which fields he should mark as private. A na=EFve reader migh= t not realize that the "d" component needs to be in the private section, for example. I do think the idea of splitting private and public makes sense, but only really in the context of key wrapping -- private things go inside the wrapping, and public things outside ("wk" and "kat" in the terms of my slides at IETF86). --Richard On Wed, Mar 20, 2013 at 12:38 AM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > 2) Should JWK parameters be marked as private (confidential, secret, > > privileged, etc etc)? The current documentation set loosely defines > > this only because they are current split between multiple documents. > > However, I wonder if there is value in being much more explicit about > > it, including in a parameter's registration. > > Yes, but not with a registry flag. > Putting the private values in a separate sub-object would be better (eg > "pri":{"d":...}). It would allow you to notice private values without > needing to know every key type (or looking up a registry). > > > > 1) Should JWK parameter names be absolutely unique, or are they > > potentially tied to a specific JWK type? In looking at the specs to > > date, I think there's only one case where a parameter name is re-used > > ("d" for both private RSA and ECC keys); currently syntactically and > > semantically identical, but I'm not sure that's adequate. > > If private components are in a "pri" field and public components (and > common parameters such as a elliptic curve id) are in a "pub" field, then > it is fairly obvious that these components depend on the type of key so > there is no need to have a registry for them -- just register key types. > > -- > James Manger > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d0444ea410e0df004d85ba913 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think what Matt was asking was less about how the recipient of an object = knows which fields the sender considers private, and more about how a sende= r knows which fields he should mark as private. =A0A na=EFve reader might n= ot realize that the "d" component needs to be in the private sect= ion, for example.

I do think the idea of splitting private and public makes se= nse, but only really in the context of key wrapping -- private things go in= side the wrapping, and public things outside ("wk" and "kat&= quot; in the terms of my slides at IETF86).

--Richard



On Wed, Mar 20, 2013 at 12:38 AM, Manger, James H <James.H.Manger@team.telstra.com> wrote:
> 2) Should JWK paramet= ers be marked as private (confidential, secret,
> privileged, etc etc)? =A0The current documentation set loosely defines=
> this only because they are current split between multiple documents. > However, I wonder if there is value in being much more explicit about<= br> > it, including in a parameter's registration.

Yes, but not with a registry flag.
Putting the private values in a separate sub-object would be better (eg &qu= ot;pri":{"d":...}). It would =A0allow you to notice private = values without needing to know every key type (or looking up a registry).


> 1) Should JWK parameter names be absolutely unique, or are they
> potentially tied to a specific JWK type? =A0In looking at the specs to=
> date, I think there's only one case where a parameter name is re-u= sed
> ("d" for both private RSA and ECC keys); currently syntactic= ally and
> semantically identical, but I'm not sure that's adequate.

If private components are in a "pri" field and public compo= nents (and common parameters such as a elliptic curve id) are in a "pu= b" field, then it is fairly obvious that these components depend on th= e type of key so there is no need to have a registry for them -- just regis= ter key types.

--
James Manger

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d0444ea410e0df004d85ba913-- From dholth@gmail.com Wed Mar 20 07:07:43 2013 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 6744421F8F92 for ; Wed, 20 Mar 2013 07:07:43 -0700 (PDT) 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 UKpAnFo68o-E for ; Wed, 20 Mar 2013 07:07:42 -0700 (PDT) Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by ietfa.amsl.com (Postfix) with ESMTP id 2F75311E80A4 for ; Wed, 20 Mar 2013 07:07:42 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id e12so1324240wge.34 for ; Wed, 20 Mar 2013 07:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=R9BFoZ7h16pMSYhaOMKax4O6D5a0/pdtYfOnlBBFcc8=; b=Qmi16g0gfnhiwta3uGaNteKRJ7I3hDIzatnqi6m76KCY+Zjjqb70Dp3YH5arzZimAa F+sqr+nuCDMMMJE9dOdvaBeTZdoTpdQKpIiWyLbEOpBZm4gdloveGYzz5pG5sCo6G0v/ W4VFburltBTzmUAWNGYp7qOBclZ2i3dEZVxl+ZfQrveLlBurmRByg+QoT9+2pBAKl5d9 f8mzgcpJTHCYn7PE61Q0bC7s4kw7FLfmL0BWcRTsjztFaQrowdZZvR7UPwDN7rWUzSKv dx/uhxlSBn+l2hQ396snDKkeevv+uU5NgkOusxJ10G2ZpaWmbJQuzCGrYywzkYTN3AC3 7jRw== MIME-Version: 1.0 X-Received: by 10.180.74.131 with SMTP id t3mr1091499wiv.23.1363788461233; Wed, 20 Mar 2013 07:07:41 -0700 (PDT) Received: by 10.194.122.67 with HTTP; Wed, 20 Mar 2013 07:07:41 -0700 (PDT) In-Reply-To: References: Date: Wed, 20 Mar 2013 10:07:41 -0400 Message-ID: From: Daniel Holth To: "Matt Miller (mamille2)" Content-Type: text/plain; charset=ISO-8859-1 Cc: Richard Barnes , "jose@ietf.org" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 20 Mar 2013 14:07:43 -0000 On Tue, Mar 19, 2013 at 1:59 PM, Matt Miller (mamille2) wrote: > > On Mar 19, 2013, at 11:30 AM, Richard Barnes > wrote: > >>> 1) Should JWK parameter names be absolutely unique, or are they >>> potentially tied to a specific JWK type? In looking at the specs to date, >>> I think there's only one case where a parameter name is re-used ("d" for >>> both private RSA and ECC keys); currently syntactically and semantically >>> identical, but I'm not sure that's adequate. >>> >> >> I think it makes sense for parameter names to be potentially contingent on >> key type. Emphasis on "potentially" -- there could be attributes that are >> the same for all key types. I would also propose that we make "kty" a >> mandatory attribute. >> > > I do think there are attributes that have identical semantics regardless of key type ("kid", "x5c"? (-: ). Requiring "kty" is probably necessary, but I don't have a firm opinion yet. > >> >> >>> 2) Should JWK parameters be marked as private (confidential, secret, >>> privileged, etc etc)? The current documentation set loosely defines this >>> only because they are current split between multiple documents. However, I >>> wonder if there is value in being much more explicit about it, including in >>> a parameter's registration. >>> >> >> If we fold JPSK in to JWA (which we should do), then ISTM that we should >> also note which parameters are private, in the sense of "have a column in >> the registry that marks this as a "private" parameter". Note that >> designation as private would not necessarily imply that you MUST do any >> particular thing. One can envision, for example, cases where it might be >> safe to pass private keys in plaintext (e.g., over TLS). >> > > Completely agree; it's an indicator to applications and implementations that this parameter might warrant additional considerations when present. > >> One other question: >> >> 3) Should we remove "policy" attributes from JWK? The current JWK spec >> includes a variety of attributes that are not directly specifying parts of >> the key, namely "use" and "alg". These are application-related fields, and >> run the risk of conflicting with existing applications' attributes. For >> example, the WebCrypto API has a notion of key usages and algorithm >> restriction, but the values they use do not map to the "use" and "alg" >> values. Should we align with WebCrypto (and risk conflicting with other >> apps), or remove the policy bits altogether (and require apps to align >> themselves)? FWIW, I am fine with "kid" staying there, because (1) it's >> opaque, and (2) it's actually used in JOSE processing. > > > I wouldn't consider "kid" a policy attribute anyway; it's pretty clear to me this is critical in properly referencing. Otherwise, I don't have an opinion on the others. FWIW I think it is a little awkward having kid in the key itself, especially thinking about using a hash or fingerprint of the key as the kid. Depends on whether you think of a jwk should be more of a table-like structure or a kid : value mapping. Totally fine with leaving it in though. From mamille2@cisco.com Wed Mar 20 07:58:42 2013 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 3944021F8B9C for ; Wed, 20 Mar 2013 07:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.112, 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 cDc+22EEkuH4 for ; Wed, 20 Mar 2013 07:58:41 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7F10121F8B7C for ; Wed, 20 Mar 2013 07:58:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5920; q=dns/txt; s=iport; t=1363791521; x=1365001121; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hcwcW/nusghLOYKNSCcDucnPMc7sJu1VSLoLXReu5EI=; b=bXalr8v5IEibn44uFjKpT5e3G9gduAIKUZ97z8gktVH1oIhvcdu4qnAh pEtyK2ZV6Hc4L5+i8oUkCm1iZ6WWxxBgzruaHOPzkfHvs18wVZslTAX4+ s5pMF1dOXWuVKbvTFICHuV/u7vUiI04xlnT4iLuMKocY1dPhXX5kD1O/M Y=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAH3NSVGtJXHA/2dsb2JhbABDxRmBThZ0giQBAQEDAQEBAWsLBQsCAQgOCgokAiULJQIEDgUIBod0AwkGDLhxHYlHBI5eMQeCX2EDjz2BKJZ9gwqCKA X-IronPort-AV: E=Sophos;i="4.84,877,1355097600"; d="p7s'?scan'208";a="189580856" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 20 Mar 2013 14:58:35 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2KEwZMF010402 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Mar 2013 14:58:35 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Wed, 20 Mar 2013 09:58:35 -0500 From: "Matt Miller (mamille2)" To: Richard Barnes Thread-Topic: [jose] JWK Parameter Registry Considerations Thread-Index: AQHOJKx8FqJE351Np0SzIVUR6z+Zd5itxK0ggAEsqgCAAA/qAA== Date: Wed, 20 Mar 2013 14:58:34 +0000 Message-ID: References: <255B9BB34FB7D647A506DC292726F6E1150BBD8BEA@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.68] Content-Type: multipart/signed; boundary="Apple-Mail=_B42E63C2-8F2A-490B-9304-4FF904EB5A1E"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: "Manger, James H" , "jose@ietf.org" Subject: Re: [jose] JWK Parameter Registry Considerations 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, 20 Mar 2013 14:58:42 -0000 --Apple-Mail=_B42E63C2-8F2A-490B-9304-4FF904EB5A1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Mar 20, 2013, at 8:01 AM, Richard Barnes wrote: > I think what Matt was asking was less about how the recipient of an = object > knows which fields the sender considers private, and more about how a > sender knows which fields he should mark as private. A na=EFve reader = might > not realize that the "d" component needs to be in the private section, = for > example. >=20 Basically this. > I do think the idea of splitting private and public makes sense, but = only > really in the context of key wrapping -- private things go inside the > wrapping, and public things outside ("wk" and "kat" in the terms of my > slides at IETF86). >=20 >=20 One way or another (-: - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > On Wed, Mar 20, 2013 at 12:38 AM, Manger, James H < > James.H.Manger@team.telstra.com> wrote: >=20 >>> 2) Should JWK parameters be marked as private (confidential, secret, >>> privileged, etc etc)? The current documentation set loosely defines >>> this only because they are current split between multiple documents. >>> However, I wonder if there is value in being much more explicit = about >>> it, including in a parameter's registration. >>=20 >> Yes, but not with a registry flag. >> Putting the private values in a separate sub-object would be better = (eg >> "pri":{"d":...}). It would allow you to notice private values = without >> needing to know every key type (or looking up a registry). >>=20 >>=20 >>> 1) Should JWK parameter names be absolutely unique, or are they >>> potentially tied to a specific JWK type? In looking at the specs to >>> date, I think there's only one case where a parameter name is = re-used >>> ("d" for both private RSA and ECC keys); currently syntactically and >>> semantically identical, but I'm not sure that's adequate. >>=20 >> If private components are in a "pri" field and public components (and >> common parameters such as a elliptic curve id) are in a "pub" field, = then >> it is fairly obvious that these components depend on the type of key = so >> there is no need to have a registry for them -- just register key = types. >>=20 >> -- >> James Manger >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 --Apple-Mail=_B42E63C2-8F2A-490B-9304-4FF904EB5A1E Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMyMDE0NTgzNVowIwYJKoZIhvcNAQkEMRYEFPw6xUlsQk2J8YHVnE/HKRGayEyiMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQC5nLI6G1o/5rEfxbmEWm5WRNE6TONl/CcRSNXFEYRL XPoNTg6ljOyQPNS+m1B97XUkDA3LmbZTOwrym2HOcmRVf5s/rIqiAoKxjMNR8Dy6Oh8G2FIYAb3/ zbVXLWhSWaF2uzDKz97YET2qOffJ0U24U9dxHADJEHaOj5xwFN9h7FTKrtkYPinVPjkSvQSdort1 6WPxQWHNVq0kYgkkFwxw3xuQzGR4dRe04CThscs8EzBSyWRkvBBvwqDP0MduzJ23sQVlAz7l7RIQ zkmet6cKEbwQxkzY9ygk97LAyghF3b8H0rmkOaaSRFj40sde1caD7Tc3UEUipwUOmhYPKxTMAAAA AAAA --Apple-Mail=_B42E63C2-8F2A-490B-9304-4FF904EB5A1E-- From juraj.somorovsky@rub.de Wed Mar 20 07:15:14 2013 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 7315C21F8F50 for ; Wed, 20 Mar 2013 07:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 rcMs5wtqXuSL for ; Wed, 20 Mar 2013 07:15:13 -0700 (PDT) Received: from mx6.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.30]) by ietfa.amsl.com (Postfix) with SMTP id 6087C21F8DE9 for ; Wed, 20 Mar 2013 07:15:13 -0700 (PDT) X-Queued: (qmail 10040 invoked by alias); 20 Mar 2013 14:15:12 -0000 X-Queued: (qmail 10025 invoked from network); 20 Mar 2013 14:15:12 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx6.rz.ruhr-uni-bochum.de with SMTP; 20 Mar 2013 14:15:12 -0000 X-Queued: (qmail 15218 invoked by uid 281); 20 Mar 2013 14:15:11 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUzAjbZej/rRSg==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(134.147.40.78):. Processed in 0.042756 secs); 20 Mar 2013 14:15:11 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUzAjbZej/rRSg==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 20 Mar 2013 14:15:11 -0000 Date: 20 Mar 2013 15:15:09 +0100 Message-ID: <5149C46D.7010406@rub.de> From: "Juraj Somorovsky" To: "Richard Barnes" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5142109D.7010507@mitre.org> <514264B0.5090306@rub.de> <5148CDC8.4070406@rub.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 20 Mar 2013 08:16:38 -0700 Cc: Tibor Jager , Mike Jones , =JeffH , Justin Richer , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls 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, 20 Mar 2013 14:15:14 -0000 On 03/20/2013 05:25 AM, Richard Barnes wrote: > > >> -- Integrity protection of the algorithm value (as part of the JWS/JWE >>> header). The attacker doesn't need to change the algorithm used for any >>> given object, only for two types of (independent, valid) objects to be >>> processed. >> We did not understand this, could you please clarify? >> > > The current JWE format provides an integrity check on the header > parameters, including the name of the algorithm with which the JWE should > be processed. In the BC attack, the attacker does not need to modify the > algorithm name on a GCM-encrypted object, he merely needs to construct > CBC-encrypted objects with which to query the oracle. So the integrity > check on the algorithm name does not stop the BC attack. Correct, the attacker just needs to "include" an object encrypted with an insecure algorithm...it does not matter, if he modifies an existing secure object or creates a totally new object encrypted with an insecure algorithm and appends it to the document. > >>> -- Recommending that implementations follow the guidelines in RFC 3218 >> [1] >> see above. >>> -- Recommending that implementations track which keys are used with which >>> algorithms, and prevent key reuse >> Yes, it would be nice to enforce key separation in the JOSE >> implementations and libraries by default so that users cannot use the >> same key for different algorithms (e.g., a library could enforce the >> user to generate two key pairs: one for signature processing and one for >> encryption processing). I do not know how feasible this is in general. >> > > Note that in order to prevent the attack, the checking only needs to be in > the recipient side. It seems like this could be done pretty trivially and > safely. > -- Every time you decrypt an object, store the tuple (hash(key), algorithm) > in a table > -- Before you decrypt the next object, look up hash(key) in the table and > see if the algorithm is the same as the one you're about to use. This is in general a very bad idea. Consider e.g.: 1) an attacker who is strong enough to eavesdrop an encrypted message with AES-GCM and who is fast enough to modify this message and claim the message is encrypted with AES-CBC. In this case, the server would store the tuple (hash(key), AES-CBC) instead of (hash(key), AES-GCM) in its hash table. 2) a scenario where the same key is shared between different servers. In that case, you would have to enforce that the hashtable is updated in parallel on different servers at the same time. This could lead to serious implementation problems. Another questions, which would arise are e.g. how long should be this hash table? How many keys and for how long should be stored? What happens after server restart? Your approach would introduce new issues, but not solve the original problem. Juraj From juraj.somorovsky@rub.de Tue Mar 19 13:42:55 2013 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 0C49021F8E1A for ; Tue, 19 Mar 2013 13:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_31=0.6, 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 EnMMxEMSfAr3 for ; Tue, 19 Mar 2013 13:42:53 -0700 (PDT) Received: from mx5.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.33]) by ietfa.amsl.com (Postfix) with SMTP id 0C40721F8E15 for ; Tue, 19 Mar 2013 13:42:52 -0700 (PDT) X-Queued: (qmail 12821 invoked by alias); 19 Mar 2013 20:42:51 -0000 X-Queued: (qmail 12806 invoked from network); 19 Mar 2013 20:42:51 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx5.rz.ruhr-uni-bochum.de with SMTP; 19 Mar 2013 20:42:51 -0000 X-Queued: (qmail 7097 invoked by uid 281); 19 Mar 2013 20:42:51 -0000 X-Qmailscanner: from 88.153.216.226 (7Cil8M2CiUxCw5EobY44yQ==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(88.153.216.226):. Processed in 0.074043 secs); 19 Mar 2013 20:42:51 -0000 Received: from ip-88-153-216-226.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUxCw5EobY44yQ==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 19 Mar 2013 20:42:51 -0000 Date: 19 Mar 2013 21:42:48 +0100 Message-ID: <5148CDC8.4070406@rub.de> From: "Juraj Somorovsky" To: "Richard Barnes" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 References: <5141E9D6.6030003@KingsMountain.com> <4E1F6AAD24975D4BA5B16804296739436750F9CB@TK5EX14MBXC283.redmond.corp.microsoft.com> <5142109D.7010507@mitre.org> <514264B0.5090306@rub.de> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Wed, 20 Mar 2013 08:16:54 -0700 Cc: Tibor Jager , Mike Jones , =JeffH , Justin Richer , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 19 Mar 2013 20:42:55 -0000 Hi Richard, On 03/18/2013 06:41 PM, Richard Barnes wrote: > As I read the paper, the backward-compatibility attack arises when a > recipient R is willing to use the same key (symmetric or private) to > process both a new algorithm (GCM / OAEP) and an old algorithm (CBC / > PKCS#1). The willingness to process the old algorithm allows the necessary > oracles to be constructed, which can then be used to attack the new > algorithm, as long as the new algorithm uses the same key as the old > algorithm. I would also note that cross-protocol attacks exacerbate this > problem: A BC vulnerability arises if a key is re-used with a different > algorithm ANYWHERE -- not just for another JWE, but for any other protocol. Yes, this is true. If the server e.g. uses the same key for JWE and SSL and if JWE would be vulnerable, this could of course have an impact on the security of the SSL protocol. See also this publication by Kelsey, Schneier and Wagner on Chosen Protocol attacks: http://www.schneier.com/paper-chosen-protocol.html Last section gives a good summary of countermeasures. > > For the purposes of discussion, I would like to note that two putative > security mechanisms in the current JOSE spec do NOT mitigate BC attacks. > -- Use of only authenticated encryption. The an implementation can safely > support CBC and GCM (for example), as long as the same key is not used for > both. If "safely" means that GCM cannot be broken, this is correct. > -- Integrity protection of the algorithm value (as part of the JWS/JWE > header). The attacker doesn't need to change the algorithm used for any > given object, only for two types of (independent, valid) objects to be > processed. We did not understand this, could you please clarify? > > On the other hand, the following changes to the spec WOULD mitigate BC > attacks. > -- Recommending the use of a random CMK wherever possible What do you mean by "wherever possible" please? ...it is just necessary to use this as a countermeasure against Bleichenbacher's attacks on PKCS1.5. Reference to RFC 3218 and a short description of this countermeasure would be enough. > -- Recommending that implementations follow the guidelines in RFC 3218 [1] see above. > -- Recommending that implementations track which keys are used with which > algorithms, and prevent key reuse Yes, it would be nice to enforce key separation in the JOSE implementations and libraries by default so that users cannot use the same key for different algorithms (e.g., a library could enforce the user to generate two key pairs: one for signature processing and one for encryption processing). I do not know how feasible this is in general. > -- Deprecating / removing the "direct" mode of encryption [2], which > encourages key reuse by making it harder to use random, ephemeral CMK > values. Yes, this would be reasonable. But we took e.g. a look at section 4.5: http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.5 This section does not explicitly enforce key separation. If you want to enforce a key separation (in case you are in possession of a shared symmetric key), you could enforce to derive a new key from the shared symmetric key and the algorithm identifier. This would result in different keys for AES-CBC and AES-GCM and thwart a BC attack. See also the last section of the paper by Kelsey et al. for more details. Thanks Juraj > > Thanks a lot, > --Richard > > [1] > [2] < > http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-08#section-4.6 >> > > > > On Thu, Mar 14, 2013 at 8:00 PM, Juraj Somorovsky > wrote: > >> Ok, thank you for mentioning. The attacks were implemented in August >> 2012. I mean I used the old library. >> >> The newest library seems not to use AES-CBC. However, by taking a look at >> >> https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/69de24720368c480ee93479ca84f3801a3f8909d/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java?at=master#cl-153 >> I assume it is still vulnerable to Bleichenbacher's attack (as it >> responds with different Exceptions according to the PKCS1 validity). >> >> I reported this almost 1 year ago: >> http://www.ietf.org/mail-archive/web/jose/current/msg00419.html >> >> Regards >> Juraj >> >> On 03/14/2013 07:02 PM, Justin Richer wrote: >>> Also, the Nimbus-JWT library has been deprecated in favor of >>> Nimbus-JOSE-JWT: >>> >>> https://bitbucket.org/nimbusds/nimbus-jose-jwt/ >>> >>> The new library is tracking the JOSE specs even more closely, and I'd be >>> very interested to hear if the attack is still possible against the new >>> library. >>> >>> -- Justin >>> >>> On 03/14/2013 11:48 AM, Mike Jones wrote: >>>> I believe that these attacks are only possible on encryption without >>>> integrity, which in turn was only possible, because Nimbus-JWT >>>> continued to implement encryption algorithms without integrity >>>> protection. Someone should please correct me if I'm misunderstanding >>>> the situation. >>>> >>>> As most of you know, JWE now only allows authenticated encryption >>>> algorithms to be used, for reasons exactly such as these. >>>> >>>> -- Mike >>>> >>>> -----Original Message----- >>>> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>>> Of =JeffH >>>> Sent: Thursday, March 14, 2013 8:17 AM >>>> To: IETF JOSE WG >>>> Cc: Juraj Somorovsky >>>> Subject: [jose] backwards compatibility attack on JWT impls (was: I-D >>>> Action: draft-ietf-jose-json-web-algorithms-02.txt) >>>> >>>> back on Fri, 6 Jul 2012 Mike Jones said: >>>> > >>>> > Looking at this again, it seems to me that because JWE provides >>>> integrity > protection for the algorithm, it should be impossible for >>>> you to replace > "RSA-OAEP" with "RSA1_5" in the header because then >>>> the integrity check will > fail. Thus, the attack that you describe >>>> below is prevented by the integrity > protection of the header. >>>> > >>>> > Hence, correct JWE implementations do no provide the OAEP >>>> decryption oracle > that you describe. However if I'm missing >>>> something, please point it out to > me, since if there's an issue, >>>> I'd like to understand it and how to mitigate > it. >>>> >>>> just fyi/fwiw...apologies if this has already been followed up on, but >>>> I didn't find further discussion of this after the above-quoted msg... >>>> >>>> Juraj Somorovsky et al's NDSS-2013 "Backwards Compatibility (BC) >>>> attacks" paper [1] is now out, and it may help answer the above >>>> questions. There's also Kenny Patterson's talk [2] from the recent >>>> Workshop on Real-World Cryptography. >>>> >>>> It seems, from an admittedly cursory glance at both >>>> draft-ietf-jose-json-web-algorithms (-08) and the above paper/slides, >>>> that perhaps there should be more implementation advice and security >>>> considerations in (at least) the -json-web-algorithms spec. >>>> >>>> Here's some excerpts from the paper for context... >>>> ... >>>> In the public-key setting, we show how the well-known attack of >>>> Bleichenbacher [13] gives rise to a BC [Backwards Compatibility] >>>> attack that allows an attacker to decrypt ciphertexts of PKCS#1 v2.0 >>>> encryption in both XML Encryption [27] and JSON Web Encryption [42], >>>> and to forge signatures for arbitrary messages in XML Signature [30] >>>> and JSON Web Signature [41]. The attack principle is described in >>>> Section 4. We furthermore report on our experimental results, executed >>>> against the Java implementation of JSON Web Encryption and JSON Web >>>> Signature Nimbus-JWT [53], in Section 5.3. >>>> ... >>>> >>>> Platform for Experimental Analysis: We investigate the practicality >>>> and performance of our attacks on JWE and JWS by applying them to the >>>> Nimbus-JWT library [53]. Nimbus-JWT is a Java implementation of JSON >>>> Web Encryption (JWE) and JSON Web Signature (JWS), developed by >>>> NimbusDS to support their Cloud Identity management portfolio. >>>> >>>> Even though Nimbus-JWT claims to implement version 02 of the JWE >>>> standard draft, it still supports usage of AESCBC (without MAC), which >>>> was available in version 01, but not in version 02 or any subsequent >>>> versions. >>>> ... >>>> >>>> 5.2.3 Evaluation >>>> >>>> We evaluated performance of our attacks against both WSS4J and >>>> Nimbus-JWT. We ï¬rst used the libraries to generate valid messages >>>> containing AES-GCM ciphertexts. Then we modiï¬ed the algorithm >>>> parameters in the messages, forcing the receiver to process the >>>> ciphertexts using AES-CBC, and executed the attack described in >>>> Algorithm 1. The required ciphertext validity oracles were based on >>>> error messages generated by the libraries. >>>> ... >>>> >>>> Experimental Results. In order to assess the practicability and >>>> performance of the attack, we implemented Bleichenbacher’s attack on >>>> XML Encryption [13, 38] and applied it to the Nimbus-JWT library. The >>>> PKCS#1 v1.5 validity oracle was provided by exceptions thrown by this >>>> library.11 >>>> ... >>>> >>>> 11 In practice one would instead use the more elaborate attack >>>> techniques of [38] to determine whether a given ciphertext is PKCS#1 >>>> v1.5 valid. >>>> ... >>>> >>>> [13] D. Bleichenbacher. Chosen ciphertext attacks against protocols >>>> based on the RSA encryption standard PKCS#1. In H. Krawczyk, editor, >>>> Advances in Cryptology – CRYPTO’98, volume 1462 of Lecture Notes in >>>> Computer Science, pages 1–12. >>>> Springer, Aug. 1998. >>>> >>>> [38] T. Jager, S. Schinzel, and J. Somorovsky. Bleichenbacher’s attack >>>> strikes >>>> again: breaking PKCS#1 v1.5 in XML Encryption. In S. Foresti and M. >>>> Yung, editors, Computer Security - ESORICS 2012 - 17th European >>>> Symposium on Research in Computer Security, Pisa, Italy, September >>>> 10-14, 2012. Proceedings, LNCS. >>>> Springer, 2012. >>>> >>>> [53] Nimbus Directory Services. Nimbus JSON Web Token, May 2012. >>>> https://bitbucket.org/nimbusds/nimbus-jwt. >>>> >>>> ### >>>> >>>> [1] One Bad Apple: Backwards Compatibility Attacks on >>>> State-of-the-Art Cryptography >>>> >> http://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2013/03/08/BackwardsCompatibilityAttacks.pdf >>>> >>>> >>>> [2] Key Reuse: Theory and Practice >>>> http://crypto.stanford.edu/RealWorldCrypto/slides/kenny.pdf >>>> >>>> >>>> HTH, >>>> >>>> =JeffH >>>> >>>> >>>> >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > From internet-drafts@ietf.org Wed Mar 20 20:08:58 2013 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 5BB0221F8551; Wed, 20 Mar 2013 20:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.423 X-Spam-Level: X-Spam-Status: No, score=-102.423 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 aQ1jpm8szJT8; Wed, 20 Mar 2013 20:08:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EB22221F8512; Wed, 20 Mar 2013 20:08:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130321030857.20710.74747.idtracker@ietfa.amsl.com> Date: Wed, 20 Mar 2013 20:08:57 -0700 Cc: jose@ietf.org Subject: [jose] I-D Action: draft-ietf-jose-use-cases-00.txt 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, 21 Mar 2013 03:08:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Javascript Object Signing and Encryption = Working Group of the IETF. Title : Use Cases and Requirements for JSON Object Signing and E= ncryption (JOSE) Author(s) : Richard Barnes Filename : draft-ietf-jose-use-cases-00.txt Pages : 19 Date : 2013-03-20 Abstract: Many Internet applications have a need for object-based security mechanisms in addition to security mechanisms at the network layer or transport layer. In the past, the Cryptographic Message Syntax has provided a binary secure object format based on ASN.1. Over time, the use of binary object encodings such as ASN.1 has been overtaken by text-based encodings, for example JavaScript Object Notation. This document defines a set of use cases and requirements for a secure object format encoded using JavaScript Object Notation, drawn from a variety of application security mechanisms currently in development. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-jose-use-cases There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-jose-use-cases-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mamille2@cisco.com Thu Mar 21 07:16:20 2013 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 4A8AE21F9046 for ; Thu, 21 Mar 2013 07:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 4QQozyxV3M8N for ; Thu, 21 Mar 2013 07:16:19 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7221F8EE1 for ; Thu, 21 Mar 2013 07:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5551; q=dns/txt; s=iport; t=1363875376; x=1365084976; h=from:to:subject:date:message-id:mime-version; bh=bi3wZ0duBsRX7xcN5HWIpMqg5+fUJm1W8HyA/f6wmMM=; b=DuwL9WY2y3qt6ECMKj74vRlMXmeSXoil67OVP2F6BvIcWGeR0ccLshmt DFV5X3ZxK3yVjPCDIiv9dhz+/3CCxlLOs7xF6EhApfOokvC/JYofOvJW1 7FJErnsft9mF7eGQ2gCJM55OD3YeT6CXGsJOKhnAhnWyavfcFnXEd1Hq2 8=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFALcVS1GtJXHB/2dsb2JhbABDxTaBWBZtB4ImAQSBCwEqJjAnBBMIBogGDKFnoRSNUQqBBYMXYQOPQYEohxqPY4MKgWoJFx4 X-IronPort-AV: E=Sophos;i="4.84,886,1355097600"; d="p7s'?scan'208";a="190006190" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 21 Mar 2013 14:16:16 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2LEGFCq003363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 21 Mar 2013 14:16:15 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 21 Mar 2013 09:16:15 -0500 From: "Matt Miller (mamille2)" To: "jose@ietf.org" Thread-Topic: Discussion Minutes on draft-mcgrew-aead-aes-hmac-sha2 Thread-Index: AQHOJj6lSBBVu75SYkaLuor2uyZLzQ== Date: Thu, 21 Mar 2013 14:16:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.68] Content-Type: multipart/signed; boundary="Apple-Mail=_FB4B1FDF-3BE9-42CF-8418-E9A02F02F57A"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [jose] Discussion Minutes on draft-mcgrew-aead-aes-hmac-sha2 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, 21 Mar 2013 14:16:20 -0000 --Apple-Mail=_FB4B1FDF-3BE9-42CF-8418-E9A02F02F57A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii A short discussion was had last night (US time) regarding David McGrew's = draft < http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2 = >. Below are the minutes, but for the TL;DR crowd: small refactors to = draft-mcgrew-aead to allow for alternative formats, which JOSE is = considered to be. The goal is to drop the JWA defined composite = algorithm in favor of draft-mgcrew-aead. Thanks, - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. -----BEGIN MINUTES----- VENUE ----- WebEx on 2013-03-20T22:00:00Z, approximately 30 minutes (apologies for = not recording!) ATTENDEES --------- * Michael Jones * David McGrew * Matt Miller NOTES ----- Based on email exchanges prior to meeting, a rough consensus has been = reached. It is suggested that David's draft separate the inputs, = outputs, and process from what is encoded for the wire; this should = allow JOSE to be compliant but retain its formatting. Roughly speaking = this means: * inputs and outputs (independent of encoding) * process * encoding for RFC 5116 * test vectors David believes a new version for (limited?) review should be available = next week (03/25 - 03/29). David also directed Mike to draft-mcgrew-iv-gen[1], and will suggest = some text about how IV ought to be generated for GCM. There was a side discussion on the use of AES Key Wrap and its = accessibility to implementers, versus using existing AEAD algorithms for = key wrap. Given the general lack of support by underlying cryptographic = libraries, re-using AEAD is very desirable. ACTIONS ------- * David to provide a new revision of draft-mcgrew-aead-aes-hmac-sha2 = with suggested changes * David to provide suggested text on IV generation for GCM * Mike to review updated draft-mcgrew-aead-aes-hmac-sha2 when available * Mike to update draft-ietf-jose-json-web-algorithms with suggested text = on GCM initialization vector values when available -----END MINUTES----- --Apple-Mail=_FB4B1FDF-3BE9-42CF-8418-E9A02F02F57A Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMyMTE0MTYxNFowIwYJKoZIhvcNAQkEMRYEFE+Er8JykOXgMOb2qil5Jd4OacNjMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQCLoXpgzPiAKfMNB9qStM03VBGB+9Evut3VMg+BS2Yd vAS8fvVrq5wCGfi+13Zr2jges/zF6NAInPndYlw9nkwH2miYYPQ+BlTMs/Ytvoic7fi3aKVFNyDx j22ZIjOFhplVJF9Xpu67INtF34Prx8YePVQGyeinyYlbYj2zVYkhrkFE/DDD4U7tR8xQlZVGFmDu j76Ge8VyOZuMbAaD/dRCCi74AhtymeOB3g6mm9nHRfy9MHHVGKxbAwFmUiNQ0KOctuYEVhmXyePN Asygb56OXFnbIQYyx/oQ1jpy/9CJzkbO6Q/7s+Cbyf7u/SHqiWWbALbNSSIWDr3jTgjuOG66AAAA AAAA --Apple-Mail=_FB4B1FDF-3BE9-42CF-8418-E9A02F02F57A-- From rlb@ipv.sx Thu Mar 21 12:54:37 2013 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 E027621F8C9B for ; Thu, 21 Mar 2013 12:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 2UPjkhcVNNsc for ; Thu, 21 Mar 2013 12:54:37 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF9C21F8B58 for ; Thu, 21 Mar 2013 12:54:34 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id va7so169666obc.6 for ; Thu, 21 Mar 2013 12:54:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:content-type:x-gm-message-state; bh=P9pLWPpZf9K5oeviaG3js0iuO3t8M9QY3YMeyS5DUfE=; b=Is/ww67SRs/V5qnf3CJss0JJOn8g0yTrnsAXcPhMNmKSxGwwFzSI8WU1C6HR6fwnCA RQn62k/yr3zAOVDrxtni1NWIhXISvvrguMAn5qpMZjpgVHyZ4QZ7C4ht94PEdrUyJ0zf /W3eEJHzFdnJaZgzlF3OdZXf5g0wVowfRyoV6FcES2IVFYatN1HvBSF1yx0HaO28dkS4 iEgfO/gjbaxF/oabfghzdIXXLt1eYaSVj1HqqY/EUbvu7+8ErTS932peYTYc1nBd87Zi 9vTX0yZFn+tIdYYzksjIX9qOcY9uAazG5cQKInfqqKXYJTst+rg9/Huqtzvapa+ECcfX ywTA== MIME-Version: 1.0 X-Received: by 10.182.245.33 with SMTP id xl1mr7608330obc.91.1363895673690; Thu, 21 Mar 2013 12:54:33 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Thu, 21 Mar 2013 12:54:33 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <20130321195159.24643.85868.idtracker@ietfa.amsl.com> References: <20130321195159.24643.85868.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2013 15:54:33 -0400 Message-ID: From: Richard Barnes To: jose@ietf.org Content-Type: multipart/alternative; boundary=14dae93a19a324806b04d874b50c X-Gm-Message-State: ALoCoQm1uI6Ul8kFqulxicKrSZE3rxooorPm/2RUMAwDmeaxvAhYzqMZkxUSj3qJkFJIdpCHUr4X Subject: [jose] Fwd: New Version Notification for draft-barnes-jose-spi-00.txt 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, 21 Mar 2013 19:54:38 -0000 --14dae93a19a324806b04d874b50c Content-Type: text/plain; charset=ISO-8859-1 Hey all, As requested, I have generated a small draft describing the SPI proposal. Comments welcome. Thanks, --Richard ---------- Forwarded message ---------- From: Date: Thu, Mar 21, 2013 at 3:51 PM Subject: New Version Notification for draft-barnes-jose-spi-00.txt To: rlb@ipv.sx A new version of I-D, draft-barnes-jose-spi-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Filename: draft-barnes-jose-spi Revision: 00 Title: JOSE Security Parameters Index Creation date: 2013-03-21 Group: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-barnes-jose-spi-00.txt Status: http://datatracker.ietf.org/doc/draft-barnes-jose-spi Htmlized: http://tools.ietf.org/html/draft-barnes-jose-spi-00 Abstract: The use cases for JOSE include cases where a given sender and receiver use an out-of-band mechanism to negotiate cryptographic parameters, so that these parameters do not have to appear in a JOSE object. This document proposed a modification to the JOSE formats to allow for signaling that pre-negotiated parameters are being used, and if so, which parameters. The IETF Secretariat --14dae93a19a324806b04d874b50c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hey all,

As requested, I have genera= ted a small draft describing the SPI proposal. =A0Comments welcome.

Thanks,
--Richard



---------- Forwarded message -----= -----
From: <internet-drafts@ietf.org>
Date: Thu, Mar 21, 2013 at 3:51 PM
Subject: New Version Notification for= draft-barnes-jose-spi-00.txt
To: rlb@ipv.sx



A new version of I-D, draft-barnes-jose-spi-00.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-barnes-jose-spi
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 JOSE Security Parameters Index
Creation date: =A0 2013-03-21
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 7
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/intern= et-drafts/draft-barnes-jose-spi-00.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-b= arnes-jose-spi
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-barnes-jos= e-spi-00


Abstract:
=A0 =A0The use cases for JOSE include cases where a given sender and
=A0 =A0receiver use an out-of-band mechanism to negotiate cryptographic
=A0 =A0parameters, so that these parameters do not have to appear in a JOSE=
=A0 =A0object. =A0This document proposed a modification to the JOSE formats= to
=A0 =A0allow for signaling that pre-negotiated parameters are being used, =A0 =A0and if so, which parameters.




The IETF Secretariat


--14dae93a19a324806b04d874b50c-- From odonoghue@isoc.org Fri Mar 22 06:42:29 2013 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 DA0BC21F861B for ; Fri, 22 Mar 2013 06:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 q101Bu78SC+z for ; Fri, 22 Mar 2013 06:42:28 -0700 (PDT) Received: from smtp116.dfw.emailsrvr.com (smtp116.dfw.emailsrvr.com [67.192.241.116]) by ietfa.amsl.com (Postfix) with ESMTP id B21E421F85B4 for ; Fri, 22 Mar 2013 06:42:28 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4EC48240344 for ; Fri, 22 Mar 2013 09:42:28 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id 1E47A240332 for ; Fri, 22 Mar 2013 09:42:28 -0400 (EDT) Message-ID: <514C5FC3.20007@isoc.org> Date: Fri, 22 Mar 2013 09:42:27 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [jose] jose interim meeting planned (advance announcement) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 13:42:30 -0000 Folks, After various hallway discussions in Orlando, it was decided that a higher bandwidth discussion to resolve some of the remaining open issues would be useful. To that end, the chairs are planning an interim meeting of the jose working group. The basic logistics of the meeting are shown below. Per IETF policy, an agenda will be published at least two weeks in advance. The goal of the meeting will be to resolve open issues associated with the JWS, JWE, JWK, and JWA documents along with discussions related to the use cases document. So, get your open issues on the table now! http://trac.tools.ietf.org/wg/jose/trac/report This is an advance announcement. A formal announcement will be made via the ietf-announce list when this interim meeting is approved. Thanks, Karen JOSE WG INTERIM LOGISTICS =================== Dates/Times: 29-30 April 2013 (9:00 am - 5:00 pm MDT) Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA Registration: Send jose co-chairs an email stating intent to attend (for capacity planning purposes only as we have limited space) Remote Participation: via Webex (details forthcoming) Lodging: Individual responsibility. There appear to be several options in the $125 - $200 range within 1 mile of the meeting site. From tonynad@microsoft.com Fri Mar 22 07:41:32 2013 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 C0E5F21F8AA8 for ; Fri, 22 Mar 2013 07:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.533 X-Spam-Level: X-Spam-Status: No, score=0.533 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNRESOLVED_TEMPLATE=3.132] 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 FFtUCzOdJjeH for ; Fri, 22 Mar 2013 07:41:30 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0244.outbound.protection.outlook.com [207.46.163.244]) by ietfa.amsl.com (Postfix) with ESMTP id B6F4221F8A85 for ; Fri, 22 Mar 2013 07:41:30 -0700 (PDT) Received: from BY2FFO11FD015.protection.gbl (10.1.15.203) by BY2FFO11HUB029.protection.gbl (10.1.14.114) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 22 Mar 2013 14:41:28 +0000 Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD015.mail.protection.outlook.com (10.1.14.131) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 22 Mar 2013 14:41:28 +0000 Received: from DB8EHSOBE039.bigfish.com (157.54.51.81) by mail.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.318.3; Fri, 22 Mar 2013 14:41:07 +0000 Received: from mail109-db8-R.bigfish.com (10.174.8.250) by DB8EHSOBE039.bigfish.com (10.174.4.102) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Mar 2013 14:41:04 +0000 Received: from mail109-db8 (localhost [127.0.0.1]) by mail109-db8-R.bigfish.com (Postfix) with ESMTP id CBACC20174 for ; Fri, 22 Mar 2013 14:41:04 +0000 (UTC) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21; KIP:(null); UIP:(null); (null); H:BL2PRD0310HT005.namprd03.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -19 X-BigFish: PS-19(zz9371I542I4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ah1082kzz1033IL17326ah8275dh15d4Iz31h2a8h668h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah9a9j1155h) Received-SPF: softfail (mail109-db8: transitioning domain of microsoft.com does not designate 157.56.240.21 as permitted sender) client-ip=157.56.240.21; envelope-from=tonynad@microsoft.com; helo=BL2PRD0310HT005.namprd03.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:SKI; SFS:; DIR:OUT; SFP:; SCL:-1; SRVR:BY2PR03MB043; H:BY2PR03MB041.namprd03.prod.outlook.com; LANG:en; Received: from mail109-db8 (localhost.localdomain [127.0.0.1]) by mail109-db8 (MessageSwitch) id 1363963263159121_17585; Fri, 22 Mar 2013 14:41:03 +0000 (UTC) Received: from DB8EHSMHS027.bigfish.com (unknown [10.174.8.250]) by mail109-db8.bigfish.com (Postfix) with ESMTP id 243472C0045; Fri, 22 Mar 2013 14:41:03 +0000 (UTC) Received: from BL2PRD0310HT005.namprd03.prod.outlook.com (157.56.240.21) by DB8EHSMHS027.bigfish.com (10.174.4.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Mar 2013 14:41:02 +0000 Received: from BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) by BL2PRD0310HT005.namprd03.prod.outlook.com (10.255.97.40) with Microsoft SMTP Server (TLS) id 14.16.287.3; Fri, 22 Mar 2013 14:41:00 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com (10.255.241.145) by BY2PR03MB043.namprd03.prod.outlook.com (10.255.241.147) with Microsoft SMTP Server (TLS) id 15.0.651.13; Fri, 22 Mar 2013 14:40:58 +0000 Received: from BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) by BY2PR03MB041.namprd03.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.0651.000; Fri, 22 Mar 2013 14:40:58 +0000 From: Anthony Nadalin To: "odonoghue@isoc.org" , "jose@ietf.org" Thread-Topic: [jose] jose interim meeting planned (advance announcement) Thread-Index: AQHOJwMuVag6chDwc0SKoPsuGDo355ixxtZQ Date: Fri, 22 Mar 2013 14:40:58 +0000 Message-ID: <1a169b6755434af8854d631c84993d4b@BY2PR03MB041.namprd03.prod.outlook.com> References: <514C5FC3.20007@isoc.org> In-Reply-To: <514C5FC3.20007@isoc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.124.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OrganizationHeadersPreserved: BY2PR03MB043.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%IETF.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%ISOC.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC102.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC102.redmond.corp.microsoft.com X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(199002)(55885001)(189002)(13464002)(377454001)(164054002)(15202345001)(74502001)(46102001)(16676001)(69226001)(44976002)(51856001)(47446002)(31966008)(5343655001)(65816001)(74662001)(6806001)(49866001)(47736001)(54316002)(63696002)(46406002)(33646001)(20776003)(56776001)(47976001)(47776003)(59766001)(76482001)(56816002)(77982001)(23726001)(50986001)(54356001)(80022001)(53806001)(4396001)(79102001)(50466001)(42262001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB029; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 07935ACF08 Subject: Re: [jose] jose interim meeting planned (advance announcement) 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, 22 Mar 2013 14:41:32 -0000 So I'm not seeing an updated list of items from the Orlando meeting or a se= t of consensus calls on the items from Orlando. I would like to see a clear= set of objectives for this interim meeting. -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Kar= en O'Donoghue Sent: Friday, March 22, 2013 6:42 AM To: jose@ietf.org Subject: [jose] jose interim meeting planned (advance announcement) Folks, After various hallway discussions in Orlando, it was decided that a higher = bandwidth discussion to resolve some of the remaining open issues would be = useful. To that end, the chairs are planning an interim meeting of the jose= working group. The basic logistics of the meeting are shown below. Per IET= F policy, an agenda will be published at least two weeks in advance. The go= al of the meeting will be to resolve open issues associated with the JWS, J= WE, JWK, and JWA documents along with discussions related to the use cases = document. So, get your open issues on the table now! http://trac.tools.ietf= .org/wg/jose/trac/report This is an advance announcement. A formal announcement will be made via the= ietf-announce list when this interim meeting is approved. Thanks, Karen JOSE WG INTERIM LOGISTICS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dates/Times: 29-30 April 2013 (9:00 am - 5:00 pm MDT) Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA Registration: Send jose co-chairs an email stating intent to attend (for ca= pacity planning purposes only as we have limited space) Remote Participation: via Webex (details forthcoming) Lodging: Individual responsibility. There appear to be several options in t= he $125 - $200 range within 1 mile of the meeting site. _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From odonoghue@isoc.org Fri Mar 22 07:55:11 2013 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 0D54521F8BA1 for ; Fri, 22 Mar 2013 07:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mp9iOcMUXUnW for ; Fri, 22 Mar 2013 07:55:10 -0700 (PDT) Received: from smtp126.dfw.emailsrvr.com (smtp126.dfw.emailsrvr.com [67.192.241.126]) by ietfa.amsl.com (Postfix) with ESMTP id 793C521F8AC1 for ; Fri, 22 Mar 2013 07:55:10 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 04673781A5 for ; Fri, 22 Mar 2013 10:55:09 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp2.relay.dfw1a.emailsrvr.com (Authenticated sender: odonoghue-AT-isoc.org) with ESMTPSA id C7A9C78123 for ; Fri, 22 Mar 2013 10:55:09 -0400 (EDT) Message-ID: <514C70CD.1090701@isoc.org> Date: Fri, 22 Mar 2013 10:55:09 -0400 From: Karen O'Donoghue Organization: ISOC User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org References: <514C5FC3.20007@isoc.org> <1a169b6755434af8854d631c84993d4b@BY2PR03MB041.namprd03.prod.outlook.com> In-Reply-To: <1a169b6755434af8854d631c84993d4b@BY2PR03MB041.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [jose] jose interim meeting planned (advance announcement) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: odonoghue@isoc.org List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 14:55:11 -0000 Jim and I are working on a report out of the meeting. It should be out shortly. At the highest level, the plan is to address the remaining open issues from the tracker. On 3/22/13 10:40 AM, Anthony Nadalin wrote: > So I'm not seeing an updated list of items from the Orlando meeting or a set of consensus calls on the items from Orlando. I would like to see a clear set of objectives for this interim meeting. > > > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Karen O'Donoghue > Sent: Friday, March 22, 2013 6:42 AM > To: jose@ietf.org > Subject: [jose] jose interim meeting planned (advance announcement) > > Folks, > > After various hallway discussions in Orlando, it was decided that a higher bandwidth discussion to resolve some of the remaining open issues would be useful. To that end, the chairs are planning an interim meeting of the jose working group. The basic logistics of the meeting are shown below. Per IETF policy, an agenda will be published at least two weeks in advance. The goal of the meeting will be to resolve open issues associated with the JWS, JWE, JWK, and JWA documents along with discussions related to the use cases document. So, get your open issues on the table now! http://trac.tools.ietf.org/wg/jose/trac/report > > This is an advance announcement. A formal announcement will be made via the ietf-announce list when this interim meeting is approved. > > Thanks, > Karen > > JOSE WG INTERIM LOGISTICS > =================== > > Dates/Times: 29-30 April 2013 (9:00 am - 5:00 pm MDT) > > Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA > > Registration: Send jose co-chairs an email stating intent to attend (for capacity planning purposes only as we have limited space) > > Remote Participation: via Webex (details forthcoming) > > Lodging: Individual responsibility. There appear to be several options in the $125 - $200 range within 1 mile of the meeting site. > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Fri Mar 22 13:12:28 2013 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 3458521F8435 for ; Fri, 22 Mar 2013 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.669 X-Spam-Level: X-Spam-Status: No, score=-2.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 soQQZMG5ewbK for ; Fri, 22 Mar 2013 13:12:27 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9CF8021F8439 for ; Fri, 22 Mar 2013 13:12:27 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 7FC3438F10 for ; Fri, 22 Mar 2013 13:12:26 -0700 (PDT) From: "Jim Schaad" To: Date: Fri, 22 Mar 2013 13:11:51 -0700 Message-ID: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0101_01CE26FE.D24CCBC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4nOU6Wtn5YToVESdmS7jlWKdSc2A== Content-Language: en-us Subject: [jose] Minutes 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, 22 Mar 2013 20:12:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0101_01CE26FE.D24CCBC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Preliminary minutes have been uploaded to the site. Please review and comment back to me if you have disagreements. http://www.ietf.org/proceedings/86/minutes/minutes-86-jose Note that the minutes have an action list at the bottom of them. Jim ------=_NextPart_000_0101_01CE26FE.D24CCBC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Preliminary minutes have been uploaded to the = site.  Please review and comment back to me if you have = disagreements.

 

http://www.ietf.org/proceedings/86/minutes/minutes-86-j= ose

 

Note that the minutes have an action list at the = bottom of them.

 

Jim

 

------=_NextPart_000_0101_01CE26FE.D24CCBC0-- From iesg-secretary@ietf.org Fri Mar 22 13:44:55 2013 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 2FD0621F9037; Fri, 22 Mar 2013 13:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.444 X-Spam-Level: X-Spam-Status: No, score=-102.444 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 iJdBlvcl+xBd; Fri, 22 Mar 2013 13:44:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7FC21F8E43; Fri, 22 Mar 2013 13:44:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130322204453.19084.79722.idtracker@ietfa.amsl.com> Date: Fri, 22 Mar 2013 13:44:53 -0700 Cc: jose@ietf.org Subject: [jose] JOSE Working Group Interim Meeting April 29-30, 2013 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, 22 Mar 2013 20:44:55 -0000 JOSE WG Interim Details Dates/Times: 29-30 April 2013 (9:00 am - 5:00 pm MDT) Location: Cisco, 1899 Wynkoop Street, Suite 600, Denver, CO, USA Registration: Send jose co-chairs an email (only for capacity planning purposes as we have limited space) Remote Participation: via Webex Lodging: Individual responsibility. There appear to be several options in the $125 - $200 range within 1 mile of the meeting site. From trac+jose@trac.tools.ietf.org Fri Mar 22 14:09:26 2013 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 DB6BE21F9429 for ; Fri, 22 Mar 2013 14:09:26 -0700 (PDT) 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 7O3y8eXjnLSy for ; Fri, 22 Mar 2013 14:09:26 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 34C2021F941F for ; Fri, 22 Mar 2013 14:09:26 -0700 (PDT) Received: from localhost ([127.0.0.1]:37721 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJ9DC-0007a7-Bf; Fri, 22 Mar 2013 22:09:18 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx X-Trac-Project: jose Date: Fri, 22 Mar 2013 21:09:18 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15 Message-ID: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130322210926.34C2021F941F@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 14:09:26 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #15: Broken examples in JWE / JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 21:09:27 -0000 #15: Broken examples in JWE / JWS The examples in JWE and JWS are broken. They don't tell the recipient what key to use when processing the object. Suggest resolving this by adding a "kid" field to both object. JWE OLD: {"alg":"RSA1_5","enc":"A128CBC+HS256"} NEW: {"alg":"RSA1_5","enc":"A128CBC+HS256","kid":"1"} JWS OLD: {"typ":"JWT","alg":"HS256"} NEW: {"typ":"JWT","alg":"HS256","kid":"1"} More generally, the protocol format should make these types of objects illegal, since they don't have enough information to be used by a recipient (without pre-negotiation). -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Fri Mar 22 14:37:04 2013 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 5B22521F9445 for ; Fri, 22 Mar 2013 14:37:04 -0700 (PDT) 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=[AWL=0.000, 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 Dx6kfJpke6HE for ; Fri, 22 Mar 2013 14:37:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 691D121F943F for ; Fri, 22 Mar 2013 14:37:03 -0700 (PDT) Received: from localhost ([127.0.0.1]:38809 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJ9dy-0007B5-NC; Fri, 22 Mar 2013 22:36:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com X-Trac-Project: jose Date: Fri, 22 Mar 2013 21:36:58 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:1 Message-ID: <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130322213703.691D121F943F@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 14:37:03 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 21:37:04 -0000 #15: Broken examples in JWE / JWS Comment (by ignisvulpis@gmail.com): I think this is not an issue. The examples are NOT broken and they do not need a fix. I suggest to close this ticket. The draft should definitely not make these illegal. These objects are perfect examples for a valid JWS/JWE. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From ignisvulpis@gmail.com Fri Mar 22 14:50:33 2013 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 B7EE021F8BA1 for ; Fri, 22 Mar 2013 14:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 Wa0MLXXqy8W2 for ; Fri, 22 Mar 2013 14:50:32 -0700 (PDT) Received: from mail-vb0-x22b.google.com (mail-vb0-x22b.google.com [IPv6:2607:f8b0:400c:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7BE6F21F8CE0 for ; Fri, 22 Mar 2013 14:50:28 -0700 (PDT) Received: by mail-vb0-f43.google.com with SMTP id fs19so2896314vbb.30 for ; Fri, 22 Mar 2013 14:50:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=5vtON1Yg1SX3zXANHxftrYS97M4jHw42pkKuQBO+YsY=; b=poT39D3MIkQjwsAD7ah4fFpsLyEx8xh0OEb8AVTWVwuekbxE8ebQD3H1Bq+ZccqYEm 0RZuR5Fat7CpohDlN68AdpswVaFzOIWt+fBbvKGSf/TIg3faFW+C+19d/bgQLjgMkIv+ R7d1/ODZmPZUHRV9jOgvQxellzkrUtE1DikjvIeLDlO6r+ROqSr7TTqrtwnK5utuBt+s 9aFCvg8Ts/4/N1sqialB0VXnJ2MUsbU9y2+0ize7qRPn0Kd4OpgyALNOoLmtHP52Qttl L9X53HYZrXnB/zyOw+xBxhC7/sATvUXtHdPyPCXprzioF7hOGX1lB6jbSI7eD/MlM5An 6/Kg== MIME-Version: 1.0 X-Received: by 10.52.73.73 with SMTP id j9mr3687235vdv.124.1363989027921; Fri, 22 Mar 2013 14:50:27 -0700 (PDT) Received: by 10.220.112.198 with HTTP; Fri, 22 Mar 2013 14:50:27 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367561F27@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> <006301ce24b4$c765e4e0$5631aea0$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367561F27@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 22 Mar 2013 22:50:27 +0100 Message-ID: From: Axel Nennker To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec501c5bc7ca8b604d88a71d9 Cc: Richard Barnes , Jim Schaad , James H Manger , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 22 Mar 2013 21:50:33 -0000 --bcaec501c5bc7ca8b604d88a71d9 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable +1 2013/3/19 Mike Jones > I completely agree that documenting the engineering tradeoffs is in > scope and a worthwhile exercise. The point of my message was simply that > we needn=92t =93accept the goal that there should be one way of encryptin= g > keys=94 without doing this analysis.**** > > ** ** > > I think Matt Miller had it right when he wrote this morning =93Personally= , > I don't think it's worth discussing this much further without a more > complete counter-proposal on the table=94. Should a concrete > counter-proposal to Matt=92s draft be written, at that point we could hav= e a > much more concrete discussion.**** > > ** ** > > Cheers,**= * > * > > -- Mike**= * > * > > ** ** > > *From:* Jim Schaad [mailto:ietf@augustcellars.com] > *Sent:* Tuesday, March 19, 2013 8:17 AM > *To:* Mike Jones; 'Richard Barnes' > > *Cc:* 'James H Manger'; jose@ietf.org > *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows**= * > * > > ** ** > > **** > > ** ** > > The issue has been raised for discussion. I do not believe that > documenting what the extents of the issue are is out of scope of any and > all follow on discussion. Until that has been done it is not possible to > talk about what the costs and benefits are. If you have a full set of > costs and benefits that would be an interesting message to see.**** > > ** ** > > *From:* Mike Jones [mailto:Michael.Jones@microsoft.com] > > *Sent:* Monday, March 18, 2013 8:24 PM > *To:* Jim Schaad; Richard Barnes > *Cc:* James H Manger; jose@ietf.org > *Subject:* RE: [jose] #14: Support longer wrapped keys than OAEP allows**= * > * > > ** ** > > Since you message appears to take it as given that =93there should be onl= y > one way of encrypting keys=94, I=92ll point out that I don=92t think that= it=92s > reasonable to assume that. JOSE is first and foremost an engineering > exercise, where the cost/benefit generality/complexity tradeoffs matter, > and the goal is a ubiquitously implemented crypto format for the Web that > solves the problems that people actually have, rather than a mathematical > exercise, where the goal is completeness and generality. Complexity is t= he > enemy of adoption.**** > > **** > > So it=92s fair game to ask =93What are the costs and benefits of having o= nly > one way to encrypt keys=94, versus taking that as a given.**** > > **** > > I happen to personally believe that encrypting a bare symmetric > ephemeral Content Master Key is sufficiently different than encrypting a > key that may be public, private, or symmetric and may have additional > attributes, that it=92s at least worth asking the engineering question > whether special-casing the encryption of this bare symmetric ephemeral ke= y > results in engineering benefits.**** > > **** > > Encrypting a key with attributes for storage or dissemination is not the > same kind of operation as wrapping an ephemeral symmetric key to be used > for block encryption. I=92m personally fine with this being done > differently. The engineering benefit if we do it differently in the way > that Matt=92s draft proposed, at least as I see it, is that we have to in= vent > nothing new. We already have a great format for encrypting arbitrary dat= a, > and keys with attributes are a whole lot like arbitrary data.**** > > **** > > I respect that some with disagree with my personal view, but I=92d also a= sk > you to respect that the engineering tradeoffs may favor having two ways t= o > do things that on the surface may seem similar, but are actually fairly > different in nature.**** > > **** > > Best wishes,**** > > -- Mike**** > > **** > > *From:* Richard Barnes > *Sent:* March 18, 2013 7:36 PM > *To:* Jim Schaad > *CC:* Manger, James H, jose@ietf.org > *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows**= * > * > > **** > > Well, I got to 788 by doing math incorrectly*. **** > > ** ** > > Mike was correct on the other thread that 768 is the right number. > However, that's still too big for a 1024-bit RSA key and SHA1, since 768= + > 320 =3D 1088 > 1024. **** > > ** ** > > Regardless, there is clearly an issue here when wrapping a JWK, which is > much larger, possibly containing an RSA key itself. So if we accept the > goal that there should be one way of encrypting keys, then we'll need to > deal with getting around the OAEP size limitations.**** > > ** ** > > --Richard > > * This is why my degree is in mathematics, and not accounting.**** > > On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad > wrote:**** > > Think in terms of encrypting a JWK directly not an intermediate key.**** > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of= * > *** > > > Manger, James H > > Sent: Monday, March 18, 2013 5:17 PM > > To: rlb@ipv.sx; jose@ietf.org > > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows > > > > Richard, > > > > How do you get a 788-bit key length? > > > > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- > > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 256 > > bits to 512 bits. > > > > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and > > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. > > > > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. > JWA > > already says RSA key sizes MUST be at least 2048 bits. > > > > This already looks sufficient. > > > > -- > > James Manger > > > > > > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf > > > Of Richard Barnes > > > Sent: Tuesday, 19 March 2013 10:25 AM > > > Subject: [jose] WebCrypto feedback on key wrapping > > > > > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encrypt > wrapped > > key objects, then we would need something other than OAEP in order to > carry > > arbitrary-length payloads. I agreed, and suggested that something like > RSA- > > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that K= EM > is > > troublesome due to the lack of support by native crypto libraries. > > > > > > Point number 2 likely applies for some scenarios of JWE, especially i= f > we > > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES wit= h > > a 256-bit key, the total key length is 788 bits, which is too long to b= e > encrypted > > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. > The > best > > idea I've got is to allow wrapped keys to nest, so that you can wrap a > key > inside > > of another wrapped key. > > > > > > --Richard > > > > > > >> ---------- > > >> Sent: Tuesday, 19 March 2013 10:23 AM > > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows > > >> > > >> #14: Support longer wrapped keys than OAEP allows > > >> > > >> The use of RSA-OAEP for key wrapping imposes a limit on the length > > >> of the key package being wrapped. With SHA1, this length is N-320, > > >> where N is the length of the RSA modulus. Especially with larger > > >> hash functions, and especially for wrapping private keys, the size > > >> of key packages will be larger than this bound. We should > > >> incorporate a mechanism to accommodate these situations. > > >> > > >> > > >> Ticket URL: **** > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec501c5bc7ca8b604d88a71d9 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
+1
 --bcaec501c5bc7ca8b604d88a71d9-- From ignisvulpis@gmail.com Fri Mar 22 14:51:50 2013 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 49FF121F8CE0 for ; Fri, 22 Mar 2013 14:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 6314AMH3MGuT for ; Fri, 22 Mar 2013 14:51:49 -0700 (PDT) Received: from mail-vb0-x22e.google.com (mail-vb0-x22e.google.com [IPv6:2607:f8b0:400c:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id B659121F8BA1 for ; Fri, 22 Mar 2013 14:51:47 -0700 (PDT) Received: by mail-vb0-f46.google.com with SMTP id b13so2858322vby.33 for ; Fri, 22 Mar 2013 14:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=KM6EAG4B8zLtBZfQsEQQ6kGj8Dp93w/MeuafwD8QgPM=; b=j3c8IjiDYCrI07wbjxd2RKofDR/pkuX3gX4fPM3P6iSjYVjBVTNfOajkESCp15mxxk 8FMy1nrqQJyyh1QV1W0f3FUHUNGpGHtodMs+j9+s1/uwZGcKnwBBTta1k5W+eM6gjYMw 9XKCmQjvmvUwaO2OVdY9ORQxxYvdafl8+lOpk9h0tvUYFZJQoGQDPGqjP7YpW6h4HPPP mrHNgbec6XxDB0gdUPAl/F4+0ldKvqt0LHnFdixiraY2WNP8YbLg/uBUnJRrncrNgMUv opReYvgy33V5/dB4eBQ0POO/n4YRytgd14wkYNA/NnDL0FLLcaLHS84Q57QJn0JzH07R 28mw== MIME-Version: 1.0 X-Received: by 10.58.80.4 with SMTP id n4mr4425805vex.5.1363989106877; Fri, 22 Mar 2013 14:51:46 -0700 (PDT) Received: by 10.220.112.198 with HTTP; Fri, 22 Mar 2013 14:51:46 -0700 (PDT) In-Reply-To: References: <4E1F6AAD24975D4BA5B16804296739436755CB51@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 22 Mar 2013 22:51:46 +0100 Message-ID: From: Axel Nennker To: Richard Barnes Content-Type: multipart/alternative; boundary=047d7b5d6264316f9e04d88a7638 Cc: Mike Jones , James H Manger , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows 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, 22 Mar 2013 21:51:50 -0000 --047d7b5d6264316f9e04d88a7638 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable glows in the dark JWEs would be nice to have too. 2013/3/19 Richard Barnes > I agree that it's a fair question to ask. As I'm writing this key > wrapping document (as requested in Orlando), I'm trying to develop a > comparison of the costs of various wrapping schemes. > > It would be interesting to get feedback on the group as to how you would > measure cost in this case? For example: > -- Which algorithms can/cannot be supported > -- How large the encrypted object is > -- How many encryption formats a JOSE library has to support > > On the latter point, the request to use GCM for key wrapping has gotten m= e > thinking that perhaps we should just make JWE self-similar, by using a JW= E > to wrap the key for a JWE*. That would reduce the number of encryption > code paths from two (JWE, key wrapping) to one (JWE). Again, I'll try to > make a concrete proposal in the forthcoming document. > > --Richard > > > > > On Mon, Mar 18, 2013 at 11:23 PM, Mike Jones wrote: > >> Since you message appears to take it as given that =93there should be >> only one way of encrypting keys=94, I=92ll point out that I don=92t thin= k that >> it=92s reasonable to assume that. JOSE is first and foremost an enginee= ring >> exercise, where the cost/benefit generality/complexity tradeoffs matter, >> and the goal is a ubiquitously implemented crypto format for the Web tha= t >> solves the problems that people actually have, rather than a mathematica= l >> exercise, where the goal is completeness and generality. Complexity is = the >> enemy of adoption. >> >> So it=92s fair game to ask =93What are the costs and benefits of having = only >> one way to encrypt keys=94, versus taking that as a given. >> >> I happen to personally believe that encrypting a bare symmetric >> ephemeral Content Master Key is sufficiently different than encrypting a >> key that may be public, private, or symmetric and may have additional >> attributes, that it=92s at least worth asking the engineering question >> whether special-casing the encryption of this bare symmetric ephemeral k= ey >> results in engineering benefits. >> >> Encrypting a key with attributes for storage or dissemination is not the >> same kind of operation as wrapping an ephemeral symmetric key to be used >> for block encryption. I=92m personally fine with this being done >> differently. The engineering benefit if we do it differently in the way >> that Matt=92s draft proposed, at least as I see it, is that we have to i= nvent >> nothing new. We already have a great format for encrypting arbitrary da= ta, >> and keys with attributes are a whole lot like arbitrary data. >> >> I respect that some with disagree with my personal view, but I=92d also = ask >> you to respect that the engineering tradeoffs may favor having two ways = to >> do things that on the surface may seem similar, but are actually fairly >> different in nature. >> >> Best wishes, >> -- Mike >> >> *From:* Richard Barnes >> *Sent:* March 18, 2013 7:36 PM >> >> *To:* Jim Schaad >> *CC:* Manger, James H, jose@ietf.org >> >> *Subject:* Re: [jose] #14: Support longer wrapped keys than OAEP allows >> >> Well, I got to 788 by doing math incorrectly*. >> >> Mike was correct on the other thread that 768 is the right number. >> However, that's still too big for a 1024-bit RSA key and SHA1, since 76= 8 + >> 320 =3D 1088 > 1024. >> >> Regardless, there is clearly an issue here when wrapping a JWK, which >> is much larger, possibly containing an RSA key itself. So if we accept = the >> goal that there should be one way of encrypting keys, then we'll need to >> deal with getting around the OAEP size limitations. >> >> --Richard >> >> * This is why my degree is in mathematics, and not accounting. >> >> >> On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad wrot= e: >> >>> Think in terms of encrypting a JWK directly not an intermediate key. >>> >>> > -----Original Message----- >>> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of >>> > Manger, James H >>> > Sent: Monday, March 18, 2013 5:17 PM >>> > To: rlb@ipv.sx; jose@ietf.org >>> > Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows >>> > >>> > Richard, >>> > >>> > How do you get a 788-bit key length? >>> > >>> > draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES- >>> > 128/192/256 and SHA-1/256/384/512. The total key lengths range from 2= 56 >>> > bits to 512 bits. >>> > >>> > Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and >>> > AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >>> > >>> > Keys for all of the algorithms fit within OAEP with a 2048-bit RSA ke= y. >>> JWA >>> > already says RSA key sizes MUST be at least 2048 bits. >>> > >>> > This already looks sufficient. >>> > >>> > -- >>> > James Manger >>> > >>> > >>> > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behal= f >>> > > Of Richard Barnes >>> > > Sent: Tuesday, 19 March 2013 10:25 AM >>> > > Subject: [jose] WebCrypto feedback on key wrapping >>> > > >>> > > 2. Mark Watson (Netflix) noted that if we use RSA directly to encry= pt >>> wrapped >>> > key objects, then we would need something other than OAEP in order to >>> carry >>> > arbitrary-length payloads. I agreed, and suggested that something li= ke >>> RSA- >>> > KEM would be necessary. Ryan Sleevi (Google) and Vijay observed that >>> KEM >>> is >>> > troublesome due to the lack of support by native crypto libraries. >>> > > >>> > > Point number 2 likely applies for some scenarios of JWE, especially >>> if >>> we >>> > adopt the McGrew approach. For example, if using HMAC-SHA1 and AES >>> with >>> > a 256-bit key, the total key length is 788 bits, which is too long to >>> be >>> encrypted >>> > with OAEP under a 1,024-bit RSA key. I'm not sure how to resolve it. >>> The >>> best >>> > idea I've got is to allow wrapped keys to nest, so that you can wrap = a >>> key >>> inside >>> > of another wrapped key. >>> > > >>> > > --Richard >>> > >>> > >>> > >> ---------- >>> > >> Sent: Tuesday, 19 March 2013 10:23 AM >>> > >> Subject: [jose] #14: Support longer wrapped keys than OAEP allows >>> > >> >>> > >> #14: Support longer wrapped keys than OAEP allows >>> > >> >>> > >> The use of RSA-OAEP for key wrapping imposes a limit on the lengt= h >>> > >> of the key package being wrapped. With SHA1, this length is N-320= , >>> > >> where N is the length of the RSA modulus. Especially with larger >>> > >> hash functions, and especially for wrapping private keys, the siz= e >>> > >> of key packages will be larger than this bound. We should >>> > >> incorporate a mechanism to accommodate these situations. >>> > >> >>> > >> >>> > >> Ticket URL: >>> > _______________________________________________ >>> > jose mailing list >>> > jose@ietf.org >>> > https://www.ietf.org/mailman/listinfo/jose >>> >>> >> > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --047d7b5d6264316f9e04d88a7638 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
glows in the dark JWEs would be nice to have too.


2013/3/19 Richar= d Barnes <rlb@ipv.sx>
I agree that it's a fair question to ask= . =A0As I'm writing this key wrapping document (as requested in Orlando= ), I'm trying to develop a comparison of the costs of various wrapping = schemes.

It would be interesting to get feedback on the group as to h= ow you would measure cost in this case? =A0For example:
-- Which algorithms can/cannot be supported
-- How large the= encrypted object is
-- How many encryption formats a JOSE librar= y has to support

On the latter point, the request = to use GCM for key wrapping has gotten me thinking that perhaps we should j= ust make JWE self-similar, by using a JWE to wrap the key for a JWE*. =A0Th= at would reduce the number of encryption code paths from two (JWE, key wrap= ping) to one (JWE). =A0Again, I'll try to make a concrete proposal in t= he forthcoming document.

--Richard



<= br>
On Mon, Mar 18, 2013 at 11:= 23 PM, Mike Jones <Michael.Jones@microsoft.com> wr= ote:
Since you message appears to take it as given that=A0=93there should b= e only one way of encrypting keys=94, I=92ll point out that I don=92t think= that it=92s reasonable to assume that.=A0 JOSE is first and foremost an en= gineering exercise, where the cost/benefit generality/complexity tradeoffs matter, and the goal is a ubiquitously implemented crypto=A0form= at for the Web that solves the problems that people actually have, rather t= han a mathematical exercise, where the goal is completeness and generality.= =A0 Complexity is the enemy of adoption.
=A0
So it=92s fair game to ask=A0=93What are the costs and benefits of hav= ing only one way to encrypt keys=94, versus taking that as a given.
=A0
I happen to personally believe that encrypting a bare symmetric epheme= ral=A0Content Master Key is sufficiently different than encrypting a key th= at may be public, private, or symmetric and may have additional attributes,= that it=92s at least worth asking the engineering question whether special-casi= ng the encryption of this bare symmetric ephemeral key results in engineeri= ng benefits.
=A0
Encrypting a key with attributes for storage or dissemination is not t= he same kind of operation as wrapping an ephemeral symmetric key to be used= for block encryption.=A0 I=92m personally fine with this being done differ= ently.=A0 The engineering benefit if we do it differently in the way that Matt=92s d= raft proposed, at least as I see it, is that we have to invent nothing new.= =A0 We already have a great format for encrypting arbitrary data, and keys = with attributes are a whole lot like arbitrary data.
=A0
I respect that some with disagree with my personal view, but I=92d als= o ask you to respect that the engineering tradeoffs may favor having two wa= ys to do things that on the surface may seem similar, but are actually fair= ly different in nature.
=A0
Best wishes,
-- Mike
=A0
From:=A0Richard Barnes
Sent:=A0March 18, 2013 7:36 PM

To:=A0Jim Schaad
CC:=A0Manger, James H, jose@ietf.org

Subject:=A0Re: [jose] #14: Support longer wrapped keys tha= n OAEP allows
=A0
Well, I got to 788 by doing math incorrectly*.=A0

Mike was correct on the other thread that 768 is the right number. =A0= However, that's still too big for a 1024-bit RSA key and SHA1, since 76= 8 + 320 =3D 1088 > 1024.

Regardless, there is clearly an issue here when wrapping a JWK, which = is much larger, possibly containing an RSA key itself. =A0So if we accept t= he goal that there should be one way of encrypting keys, then we'll nee= d to deal with getting around the OAEP size limitations.

--Richard

* This is why my degree is in mathematics, and not accounting.


On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <ietf@august= cellars.com> wrote:
Think in terms of encrypting a JWK directly not an intermediate key.

> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: rlb@ipv.sx; jos= e@ietf.org
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows<= br> >
> Richard,
>
> How do you get a 788-bit key length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 25= 6
> bits to 512 bits.
>
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key= .
JWA
> already says RSA key sizes MUST be at least 2048 bits.
>
> This already looks sufficient.
>
> --
> James Manger
>
>
> > From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on key wrapping
> >
> > 2. Mark Watson (Netflix) noted that if we use RSA directly to enc= rypt
wrapped
> key objects, then we would need something other than OAEP in order to<= br> carry
> arbitrary-length payloads. =A0I agreed, and suggested that something l= ike
RSA-
> KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed tha= t KEM
is
> troublesome due to the lack of support by native crypto libraries.
> >
> > Point number 2 likely applies for some scenarios of JWE, especial= ly if
we
> adopt the McGrew approach. =A0For example, if using HMAC-SHA1 and AES = with
> a 256-bit key, the total key length is 788 bits, which is too long to = be
encrypted
> with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolv= e it. =A0The
best
> idea I've got is to allow wrapped keys to nest, so that you can wr= ap a key
inside
> of another wrapped key.
> >
> > --Richard
>
>
> >> ----------
> >> Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] #14: Support longer wrapped keys than OAEP al= lows
> >>
> >> #14: Support longer wrapped keys than OAEP allows
> >>
> >> =A0The use of RSA-OAEP for key wrapping imposes a limit on th= e length
> >> of =A0the key package being wrapped. With SHA1, this length i= s N-320,
> >> where =A0N is the length of the RSA modulus. =A0Especially wi= th larger
> >> hash =A0functions, and especially for wrapping private keys, = the size
> >> of key =A0packages will be larger than this bound. =A0We shou= ld
> >> incorporate a =A0mechanism to accommodate these situations. > >>
> >>
> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/= ticket/14>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose




2013/3/19 Mike Jones <Michael.Jones@microsoft.c= om>

I completely agree that d= ocumenting the engineering tradeoffs is in scope and a worthwhile exercise.= =A0 The point of my message was simply that we needn=92t =93accept the goal that there should be one way of encrypting keys=94 without doing this analysis.

=A0<= /p>

I think Matt Miller had i= t right when he wrote this morning =93Personally, I don't think = it's worth discussing this much further without a more complete counter-proposal on the table=94.=A0 Should a c= oncrete counter-proposal to Matt=92s draft be written, at that point we cou= ld have a much more concrete discussion.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 Cheers,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: Jim Scha= ad [mailto:ietf= @augustcellars.com]
Sent: Tuesday, March 19, 2013 8:17 AM
To: Mike Jones; 'Richard Barnes'


Cc: 'James H Manger'; jose@ietf.org
Subject: RE: [jose] #14: Support longer wrapped keys than OAEP allow= s

=A0

<personal>

=A0<= /p>

The issue has been raised= for discussion.=A0 I do not believe that documenting what the extents of t= he issue are is out of scope of any and all follow on discussion. =A0Until that has been done it is not possible to talk about what the cost= s and benefits are.=A0 If you have a full set of costs and benefits that wo= uld be an interesting message to see.

=A0<= /p>

From: Mike Jon= es [mailto= :Michael.Jones@microsoft.com]
Sent: Monday, March 18, 2013 8:24 PM
To: Jim Schaad; Richard Barnes
Cc: James H Manger; jose@ietf.org
Subject: RE: [jose] #14: Support longer wrapped keys than OAEP allow= s

=A0

Since you message appears to take it as given that=A0=93= there should be only one way of encrypting keys=94, I=92ll point out that I= don=92t think that it=92s reasonable to assume that.=A0 JOSE is first and foremost an engineering exercise, where the cost/benefit generality/co= mplexity tradeoffs matter, and the goal is a ubiquitously implemented crypt= o=A0format for the Web that solves the problems that people actually have, = rather than a mathematical exercise, where the goal is completeness and generality.=A0 Complexity is the enemy = of adoption.

=A0

So it=92s fair game to ask=A0=93What are the costs and b= enefits of having only one way to encrypt keys=94, versus taking that as a = given.

=A0

I happen to personally believe that encrypting a bare sy= mmetric ephemeral=A0Content Master Key is sufficiently different than encry= pting a key that may be public, private, or symmetric and may have additional attributes, that it=92s at least worth asking the engi= neering question whether special-casing the encryption of this bare symmetr= ic ephemeral key results in engineering benefits.

=A0

Encrypting a key with attributes for storage or dissemin= ation is not the same kind of operation as wrapping an ephemeral symmetric = key to be used for block encryption.=A0 I=92m personally fine with this being done differently.=A0 The engineering benefit if we do it d= ifferently in the way that Matt=92s draft proposed, at least as I see it, i= s that we have to invent nothing new.=A0 We already have a great format for= encrypting arbitrary data, and keys with attributes are a whole lot like arbitrary data.

=A0

I respect that some with disagree with my personal view,= but I=92d also ask you to respect that the engineering tradeoffs may favor= having two ways to do things that on the surface may seem similar, but are actually fairly different in nature.=

=A0

Best wishes,

-- Mike

=A0

From:=A0Richard Barnes
Sent:=A0March 18, 2013 7:36 PM
To:=A0Jim Schaad
CC:=A0Manger, James H, jose@ietf.org
Subject:=A0Re: [jose] #14: Support longer wrapped keys = than OAEP allows

=A0

Well, I got to 788 by doing math incorrectly*.=A0

=A0

Mike was correct on the other thread that 768 is the rig= ht number. =A0However, that's still too big for a 1024-bit RSA key and = SHA1, since 768 + 320 =3D 1088 > 1024.

=A0

Regardless, there is clearly an issue here when wrapping= a JWK, which is much larger, possibly containing an RSA key itself. =A0So = if we accept the goal that there should be one way of encrypting keys, then we'll need to deal with getting around the OAEP size limita= tions.

=A0

--Richard

* This is why my degree is in mathematics, and not accounting.

On Mon, Mar 18, 2013 at 8:40 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

Think in terms of encrypting a JWK directly not an inter= mediate key.


> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of

> Manger, James H
> Sent: Monday, March 18, 2013 5:17 PM
> To: rlb@ipv.sx; jose@ietf.org
> Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows<= br> >
> Richard,
>
> How do you get a 788-bit key length?
>
> draft-mcgrew-aead-aes-cbc-hmac-sha2 defines 5 combinations of AES-
> 128/192/256 and SHA-1/256/384/512. The total key lengths range from 25= 6
> bits to 512 bits.
>
> Keys for two of the algorithms (AEAD_AES_128_CBC_HMAC_SHA_256 and
> AEAD_AES_128_CBC_HMAC_SHA1) fit within OAEP with a 1024-bit RSA key. >
> Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key= .
JWA
> already says RSA key sizes MUST be at least 2048 bits.
>
> This already looks sufficient.
>
> --
> James Manger
>
>
> > From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf
> > Of Richard Barnes
> > Sent: Tuesday, 19 March 2013 10:25 AM
> > Subject: [jose] WebCrypto feedback on key wrapping
> >
> > 2. Mark Watson (Netflix) noted that if we use RSA directly to enc= rypt
wrapped
> key objects, then we would need something other than OAEP in order to<= br> carry
> arbitrary-length payloads. =A0I agreed, and suggested that something l= ike
RSA-
> KEM would be necessary. =A0Ryan Sleevi (Google) and Vijay observed tha= t KEM
is
> troublesome due to the lack of support by native crypto libraries.
> >
> > Point number 2 likely applies for some scenarios of JWE, especial= ly if
we
> adopt the McGrew approach. =A0For example, if using HMAC-SHA1 and AES = with
> a 256-bit key, the total key length is 788 bits, which is too long to = be
encrypted
> with OAEP under a 1,024-bit RSA key. =A0I'm not sure how to resolv= e it. =A0The
best
> idea I've got is to allow wrapped keys to nest, so that you can wr= ap a key
inside
> of another wrapped key.
> >
> > --Richard
>
>
> >> ----------
> >> Sent: Tuesday, 19 March 2013 10:23 AM
> >> Subject: [jose] #14: Support longer wrapped keys than OAEP al= lows
> >>
> >> #14: Support longer wrapped keys than OAEP allows
> >>
> >> =A0The use of RSA-OAEP for key wrapping imposes a limit on th= e length
> >> of =A0the key package being wrapped. With SHA1, this length i= s N-320,
> >> where =A0N is the length of the RSA modulus. =A0Especially wi= th larger
> >> hash =A0functions, and especially for wrapping private keys, = the size
> >> of key =A0packages will be larger than this bound. =A0We shou= ld
> >> incorporate a =A0mechanism to accommodate these situations. > >>
> >>
> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/= ticket/14>

> ____________________= ___________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--047d7b5d6264316f9e04d88a7638-- From ietf@augustcellars.com Fri Mar 22 15:14:34 2013 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 D8B9121F9470 for ; Fri, 22 Mar 2013 15:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.134 X-Spam-Level: X-Spam-Status: No, score=-3.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 ZL1vOkbtwGRG for ; Fri, 22 Mar 2013 15:14:34 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA6321F946B for ; Fri, 22 Mar 2013 15:14:34 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 1080438F15; Fri, 22 Mar 2013 15:14:33 -0700 (PDT) From: "Jim Schaad" To: , "Richard Barnes" References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> In-Reply-To: <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> Date: Fri, 22 Mar 2013 15:13:59 -0700 Message-ID: <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF2cmojIl9Hs38WmUYs74iwLrRDCgIF6v1omVGAk4A= Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 22 Mar 2013 22:14:35 -0000 My inclination is that this response is correct. What make you think that the key or key reference is required and cannot be implied? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > jose issue tracker > Sent: Friday, March 22, 2013 2:37 PM > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; ignisvulpis@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > #15: Broken examples in JWE / JWS > > > Comment (by ignisvulpis@gmail.com): > > I think this is not an issue. The examples are NOT broken and they do not > need a fix. > I suggest to close this ticket. > The draft should definitely not make these illegal. These objects are perfect > examples for a valid JWS/JWE. > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From trac+jose@trac.tools.ietf.org Fri Mar 22 15:16:52 2013 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 79B4E21F946B for ; Fri, 22 Mar 2013 15:16:52 -0700 (PDT) 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=[AWL=0.000, 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 QAko3rLk5BcG for ; Fri, 22 Mar 2013 15:16:51 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7282D21F9468 for ; Fri, 22 Mar 2013 15:16:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:40957 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJAGS-0004Ia-9V; Fri, 22 Mar 2013 23:16:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-signature@tools.ietf.org, sakimura@gmail.com, ietf@augustcellars.com X-Trac-Project: jose Date: Fri, 22 Mar 2013 22:16:44 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/2#comment:2 Message-ID: <069.eb93348ab633f5370b510a857a42206a@trac.tools.ietf.org> References: <054.c651e93bb72d1b02087aa116318b8d94@trac.tools.ietf.org> X-Trac-Ticket-ID: 2 In-Reply-To: <054.c651e93bb72d1b02087aa116318b8d94@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-signature@tools.ietf.org, sakimura@gmail.com, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com Resent-Message-Id: <20130322221651.7282D21F9468@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 15:16:51 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #2: No key management for MAC X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 22:16:52 -0000 #2: No key management for MAC Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => wontfix Comment: The working group has already considered this and has determined that it will not be addressed. Until a request for the feature comes in from a group such as the WebCrypto group it will not be re-considered. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | signature@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: Component: json-web- | Version: signature | Resolution: wontfix Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Fri Mar 22 15:24:43 2013 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 DF9DA21F9434 for ; Fri, 22 Mar 2013 15:24:43 -0700 (PDT) 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 8yivPo+MjCUu for ; Fri, 22 Mar 2013 15:24:43 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7D521F9429 for ; Fri, 22 Mar 2013 15:24:43 -0700 (PDT) Received: from localhost ([127.0.0.1]:41180 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJAO6-0008K6-Ej; Fri, 22 Mar 2013 23:24:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-barnes-jose-use-cases@tools.ietf.org, ietf@augustcellars.com X-Trac-Project: jose Date: Fri, 22 Mar 2013 22:24:38 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/1#comment:2 Message-ID: <076.d7c7ece26f899562d208797d02fe5f6e@trac.tools.ietf.org> References: <061.646f43d2729b9479b80d710a833e1cd4@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <061.646f43d2729b9479b80d710a833e1cd4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-barnes-jose-use-cases@tools.ietf.org, ietf@augustcellars.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: rlb@ipv.sx Resent-Message-Id: <20130322222443.4F7D521F9429@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 15:24:43 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #1: Change Document State X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 22:24:44 -0000 #1: Change Document State Changes (by ietf@augustcellars.com): * status: new => closed * resolution: => fixed -- -------------------------------------+------------------------------------- Reporter: ietf@augustcellars.com | Owner: draft-barnes-jose-use- Type: task | cases@tools.ietf.org Priority: major | Status: closed Component: draft-barnes-jose-use- | Milestone: milestone1 cases | Version: Severity: Candidate WG Document | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From rlb@ipv.sx Fri Mar 22 16:08:36 2013 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 4F32921F85D7 for ; Fri, 22 Mar 2013 16:08:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 SRPvhrQVTOcy for ; Fri, 22 Mar 2013 16:08:33 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 6D92521F85A4 for ; Fri, 22 Mar 2013 16:08:33 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id er7so943753obc.35 for ; Fri, 22 Mar 2013 16:08:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=/j2SeomIVmWTo67CMKhytI0EGO5lc54LICjNvhyS4BA=; b=ASe0KXmKrwQrcvoT8LYk2dT3byG5gLRHeXUa0l11vlobnIgugmAYPvxEr42HJl0Mrn IpE9g63icxxSI0Z/GzDw1BE5kAi8H4YjgdjidNGp6K6ReSpHnYAYPs8zDcKFiwb3o8ek /eTInAQuSsPt6uPbtpaVOrCEjKu0GsXp28T8gWEfk3o4mBNVUn7Pv/kY1b3Aehs0HmZ6 zABpsuLaRBmOf8O23dWJynDd1ursZepCXDCobevT0868i4m9pzhC0cLWbf4JA070vSv5 V4kEv0VT+abf8wPqerKxBZdtAevM6H4tpzgbuAcMbrfR5Ee+6cS8+iyKHYPjtJDiUZCO zziA== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr3500562oec.125.1363993712858; Fri, 22 Mar 2013 16:08:32 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 22 Mar 2013 16:08:32 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> Date: Fri, 22 Mar 2013 19:08:32 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec54b4812bb34e204d88b88ce X-Gm-Message-State: ALoCoQmHtmMIz9p//btrEBRhQqqlH2uibdKUzHpc3UV9muqKzNrnqrs68ba9VFB56hqDQLAKCAUn Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 22 Mar 2013 23:08:36 -0000 --bcaec54b4812bb34e204d88b88ce Content-Type: text/plain; charset=ISO-8859-1 I admit that they are not broken according to the current spec. However, I have a lot of trouble figuring out how I would write code to process them. If "kid" or "jwk" MUST be present to indicate what key I should use, then I can have deterministic code: if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* FAIL. can't process this object */ } As the spec stands, I have no idea what to put in that "else" clause. I'm clearly not supposed to fail, because the parameters are optional. But what else? if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* insert special magic here */ } This is actually what SPI is supposed to clear up. SPI would provide an explicit third branch for the special magic to live in. if (/* recognized "kid" or "jwk" value */) { /* use it */ } else if (/* recognized SPI value */) { /* process using stored parameters */ } else { /* FAIL. can't process this object */ } But without the concept of SPI, the spec is broken because of the non-determinism noted above. --Richard On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad wrote: > My inclination is that this response is correct. > > What make you think that the key or key reference is required and cannot be > implied? > > Jim > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > jose issue tracker > > Sent: Friday, March 22, 2013 2:37 PM > > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; > ignisvulpis@gmail.com > > Cc: jose@ietf.org > > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > > > #15: Broken examples in JWE / JWS > > > > > > Comment (by ignisvulpis@gmail.com): > > > > I think this is not an issue. The examples are NOT broken and they do > not > > need a fix. > > I suggest to close this ticket. > > The draft should definitely not make these illegal. These objects are > perfect > > examples for a valid JWS/JWE. > > > > -- > > -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: minor | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: > > > jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54b4812bb34e204d88b88ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I admit that they are not broken according to the current spec. =A0However,= I have a lot of trouble figuring out how I would write code to process the= m.

If "kid" or "jwk" MUST be present= to indicate what key I should use, then I can have deterministic code:
if (/* recognized "kid" or "jwk" value */) {=A0
=A0 =A0 /* use it */
} else {
=A0 =A0 /* FAIL. = =A0can't process this object */
}

As= the spec stands, I have no idea what to put in that "else" claus= e. =A0I'm clearly not supposed to fail, because the parameters are opti= onal. =A0But what else?
if (/* recognized "kid" or "jwk" value */) {= =A0
=A0 =A0 /* use it */
} else {
=A0 =A0 /* = insert special magic here */
}

Thi= s is actually what SPI is supposed to clear up. =A0SPI would provide an exp= licit third branch for the special magic to live in.
if (/* recognized "kid" or "jwk" value */) {= =A0
=A0 =A0 /* use it */
} else if (/* recognized SPI v= alue */) {
=A0 =A0 /* process using stored parameters */
} else {
=A0 =A0 /* FAIL. =A0can't process this object */
}
=

But without the concept of SPI, the spec is broke= n because of the non-determinism noted above.

--Ri= chard




On Fr= i, Mar 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.com>= ; wrote:
My inclination is that this response is corr= ect.

What make you think that the key or key reference is required and cannot be=
implied?

Jim


> -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: draft-ietf-jose-json-web-encryption@tools.ietf.org;
ignisvulpis@gmail.com
> Cc: jose@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken examples in JWE / JWS
>
>
> Comment (by ignisvulpis@gmail= .com):
>
> =A0I think this is not an issue. The examples are NOT broken and they = do not
> need a fix.
> =A0I suggest to close this ticket.
> =A0The draft should definitely not make these illegal. These objects a= re
perfect
> examples for a valid JWS/JWE.
>
> --
> -------------------------+--------------------------------------------= --
> -------------------------+---
> =A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: = =A0draft-ietf-jose-json-web-
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Component: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= --
> -------------------------+---
>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac= /ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose


--bcaec54b4812bb34e204d88b88ce-- From trac+jose@trac.tools.ietf.org Fri Mar 22 16:20:43 2013 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 4E12721F8CE0 for ; Fri, 22 Mar 2013 16:20:43 -0700 (PDT) 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 NpQzO1g-dn51 for ; Fri, 22 Mar 2013 16:20:42 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A99A621F8C7D for ; Fri, 22 Mar 2013 16:20:41 -0700 (PDT) Received: from localhost ([127.0.0.1]:43425 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJBGF-0000f8-Su; Sat, 23 Mar 2013 00:20:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Fri, 22 Mar 2013 23:20:35 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:2 Message-ID: <064.4c409ba17ad2c33695d941d0b7398e4f@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130322232042.A99A621F8C7D@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 16:20:41 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2013 23:20:43 -0000 #15: Broken examples in JWE / JWS Comment (by michael.jones@microsoft.com): Speaking as an individual, I'm not adverse to adding the use of the "kid" parameter to one or more of the examples, but it shouldn't be in all of them, as in many use cases, the key to be used is communicated by other means than the "kid" (including by using some of the other header parameters also defined by the specifications). I'll also point out that the working group has already determined that the "kid" parameter is adequately defined, so that aspect of this issue has already been considered and is closed. See "CLOSED: Is KID sufficently defined" at http://www.ietf.org/mail- archive/web/jose/current/msg01218.html. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Fri Mar 22 17:47:54 2013 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 67AD921F8E2C for ; Fri, 22 Mar 2013 17:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.349 X-Spam-Level: X-Spam-Status: No, score=0.349 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.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 Ke3Ma47+UIjm for ; Fri, 22 Mar 2013 17:47:53 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id B3CCE21F862D for ; Fri, 22 Mar 2013 17:47:53 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb18so4574884obb.31 for ; Fri, 22 Mar 2013 17:47:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jM7XuIG1V8OUQQFLXCMABGX4veH7zkq9BZHstuAT074=; b=iIQaKh6X0IK13Ikj6fqlnIB2/Md8n5PiwChbRHeZewKF7G8XPu9QOa2e1iUz4ztN2F Rv/Uhf+6TRoR2PuxmA3nPSbql26kD+/b8o3XUSKDP19uVqRmeh1Qtk9eVyyp9CKRwQ9+ 5YWVD1hqJcHkUbAJroC+Fm0k/LjgPZbjYYea7XWalDPNBz4fM3JDDEIcXlUiW0irZDYw 3QSqifRVLswIbwBjPY/RzrFbCAZ8CRwzQfggN3EtTgcXcwSDuhWlNoaqmP0ZtpK3a8bB 2ID+/zlCjoA6rm1xx1xV80yLryGDxNtwYcJNT6gxOD9vWwcOhoPpyZsqmt7bEpmw1cNg ti4g== MIME-Version: 1.0 X-Received: by 10.60.172.18 with SMTP id ay18mr3751548oec.126.1363999673225; Fri, 22 Mar 2013 17:47:53 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 22 Mar 2013 17:47:53 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <064.4c409ba17ad2c33695d941d0b7398e4f@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.4c409ba17ad2c33695d941d0b7398e4f@trac.tools.ietf.org> Date: Fri, 22 Mar 2013 20:47:53 -0400 Message-ID: From: Richard Barnes To: jose issue tracker Content-Type: multipart/alternative; boundary=bcaec54fae48ff7d3304d88ceb86 X-Gm-Message-State: ALoCoQmwIHkqfbNHh0Dmg179aOVQ84i7E29PcctCT+s2zyOChOAiddzIUzb5KrvpK0gn/E1pWyFR Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org, ignisvulpis@gmail.com Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 23 Mar 2013 00:47:54 -0000 --bcaec54fae48ff7d3304d88ceb86 Content-Type: text/plain; charset=ISO-8859-1 The question isn't whether the semantic of "kid" is sufficiently defined. The question is when it should be required. I'm not even saying that "kid" should be required in all cases -- just that the recipient should have clear instructions about what to do in all cases. --Richard On Fri, Mar 22, 2013 at 7:20 PM, jose issue tracker < trac+jose@trac.tools.ietf.org> wrote: > #15: Broken examples in JWE / JWS > > > Comment (by michael.jones@microsoft.com): > > Speaking as an individual, I'm not adverse to adding the use of the "kid" > parameter to one or more of the examples, but it shouldn't be in all of > them, as in many use cases, the key to be used is communicated by other > means than the "kid" (including by using some of the other header > parameters also defined by the specifications). > > I'll also point out that the working group has already determined that the > "kid" parameter is adequately defined, so that aspect of this issue has > already been considered and is closed. See "CLOSED: Is KID sufficently > defined" at http://www.ietf.org/mail- > archive/web/jose/current/msg01218.html. > > -- > -------------------------+------------------------------------------------- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+------------------------------------------------- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --bcaec54fae48ff7d3304d88ceb86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The question isn't whether the semantic of "kid" is sufficien= tly defined. =A0The question is when it should be required. =A0I'm not = even saying that "kid" should be required in all cases -- just th= at the recipient should have clear instructions about what to do in all cas= es.

--Richard=A0



= On Fri, Mar 22, 2013 at 7:20 PM, jose issue tracker <<= a href=3D"mailto:trac+jose@trac.tools.ietf.org" target=3D"_blank">trac+jose= @trac.tools.ietf.org> wrote:
#15: Broken examples in JW= E / JWS


Comment (by michael.jo= nes@microsoft.com):

=A0Speaking as an individual, I'm not adverse to adding the use of the = "kid"
=A0parameter to one or more of the examples, but it shouldn't be in all= of
=A0them, as in many use cases, the key to be used is communicated by other<= br> =A0means than the "kid" (including by using some of the other hea= der
=A0parameters also defined by the specifications).

=A0I'll also point out that the working group has already determined th= at the
=A0"kid" parameter is adequately defined, so that aspect of this = issue has
=A0already been considered and is closed. =A0See "CLOSED: Is KID suffi= cently
=A0defined" at http://www.ietf.org/mail-
=A0archive/web/jose/current/msg01218.html.

--
-------------------------+-------------------------------------------------=
=A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draft-ietf-jose-json= -web-
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
=A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
Component: =A0json-web- =A0 =A0| =A0 Milestone:
=A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
-------------------------+-------------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/tick= et/15#comment:2>
jose <http://tools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--bcaec54fae48ff7d3304d88ceb86-- From ietf@augustcellars.com Fri Mar 22 18:16:16 2013 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 7122821F88A2 for ; Fri, 22 Mar 2013 18:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.288 X-Spam-Level: X-Spam-Status: No, score=-3.288 tagged_above=-999 required=5 tests=[AWL=0.310, 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 8j-eHKlKrFtQ for ; Fri, 22 Mar 2013 18:16:15 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8783421F8620 for ; Fri, 22 Mar 2013 18:16:15 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id CE4F92CA15; Fri, 22 Mar 2013 18:16:14 -0700 (PDT) From: "Jim Schaad" To: "'Richard Barnes'" References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> In-Reply-To: Date: Fri, 22 Mar 2013 18:15:40 -0700 Message-ID: <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013D_01CE2729.4317D1E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF2cmojIl9Hs38WmUYs74iwLrRDCgIF6v1oAm/xY+kByW55f5kv6DvQ Content-Language: en-us Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 23 Mar 2013 01:16:16 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013D_01CE2729.4317D1E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This may or may not be a flaw in the specification. However the item you created in the tracker does not reflect what you have put here. I think you would be better served by saying that there is a flaw in the specifications in that there should be a MUST that some type of key or key reference is required in a JWS or JWE. I would note that your example code should be more complex in that it does not deal with jku or any of the x* methods of referencing keys. Jim From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, March 22, 2013 4:09 PM To: Jim Schaad Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I admit that they are not broken according to the current spec. However, I have a lot of trouble figuring out how I would write code to process them. If "kid" or "jwk" MUST be present to indicate what key I should use, then I can have deterministic code: if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* FAIL. can't process this object */ } As the spec stands, I have no idea what to put in that "else" clause. I'm clearly not supposed to fail, because the parameters are optional. But what else? if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* insert special magic here */ } This is actually what SPI is supposed to clear up. SPI would provide an explicit third branch for the special magic to live in. if (/* recognized "kid" or "jwk" value */) { /* use it */ } else if (/* recognized SPI value */) { /* process using stored parameters */ } else { /* FAIL. can't process this object */ } But without the concept of SPI, the spec is broken because of the non-determinism noted above. --Richard On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad wrote: My inclination is that this response is correct. What make you think that the key or key reference is required and cannot be implied? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > jose issue tracker > Sent: Friday, March 22, 2013 2:37 PM > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; ignisvulpis@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > #15: Broken examples in JWE / JWS > > > Comment (by ignisvulpis@gmail.com): > > I think this is not an issue. The examples are NOT broken and they do not > need a fix. > I suggest to close this ticket. > The draft should definitely not make these illegal. These objects are perfect > examples for a valid JWS/JWE. > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_013D_01CE2729.4317D1E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This may or may not be a flaw in the specification.  However the = item you created in the tracker does not reflect what you have put = here.  I think you would be better served by saying that there is a = flaw in the specifications in that there should be a MUST that some type = of key or key reference is required in a JWS or = JWE.

 

I would note that your example code should be more complex in that it = does not deal with jku or any of the x* methods of referencing = keys.

 

Jim

 

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, = 2013 4:09 PM
To: Jim Schaad
Cc: = draft-ietf-jose-json-web-encryption@tools.ietf.org; = jose@ietf.org
Subject: Re: [jose] #15: Broken examples in JWE = / JWS

 

I admit that = they are not broken according to the current spec.  However, I have = a lot of trouble figuring out how I would write code to process = them.

 

If "kid" or "jwk" MUST be present = to indicate what key I should use, then I can have deterministic = code:

if (/* recognized = "kid" or "jwk" value */) = { 

    /* = use it */

} else = {

    /* FAIL. =  can't process this object */

}

 

As the spec stands, I have no idea what to put in that = "else" clause.  I'm clearly not supposed to fail, because = the parameters are optional.  But what = else?

if (/* = recognized "kid" or "jwk" value */) = { 

    /* = use it */

} else = {

    /* insert = special magic here */

}

 

This is actually what SPI is supposed to clear up. =  SPI would provide an explicit third branch for the special magic = to live in.

if (/* = recognized "kid" or "jwk" value */) = { 

    /* = use it */

} else if (/* = recognized SPI value */) {

    /* process using stored parameters = */

} else = {

    /* FAIL. =  can't process this object */

}

 

But without the concept of SPI, the spec is broken = because of the non-determinism noted above.

 

--Richard

 

 

 

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:

My inclination is that this response is = correct.

What make you think that the key or key reference is = required and cannot be
implied?

Jim



> -----Original Message-----
> From: = jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On = Behalf Of
> jose issue tracker
> Sent: Friday, March 22, = 2013 2:37 PM
> To: draft-= ietf-jose-json-web-encryption@tools.ietf.org;
ignisvulpis@gmail.com
> = Cc: jose@ietf.org
> Subject: = Re: [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken = examples in JWE / JWS
>
>
> Comment (by ignisvulpis@gmail.com):
>=
>  I think this is not an issue. The examples are NOT broken = and they do not
> need a fix.
>  I suggest to close = this ticket.
>  The draft should definitely not make these = illegal. These objects are
perfect
> examples for a valid = JWS/JWE.
>
> --
> = -------------------------+----------------------------------------------<= o:p>

> = -------------------------+---

>  Reporter:  rlb@ipv.sx   |       = Owner:  draft-ietf-jose-json-web-
>      Type: =  defect       |  encryption@tools.ietf.org>  Priority:  minor        |   =    Status:  new
> Component:  json-web-   =  |   Milestone:
>   encryption       =       |     Version:
>  Severity: =  -            | =  Resolution:
>  Keywords:         =       |
> = -------------------------+----------------------------------------------<= o:p>

> = -------------------------+---

>
> Ticket = URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comme= nt:1>
> jose <http://tools.ietf.org/jose/>
>
> = _______________________________________________
> jose mailing = list
> jose@ietf.org
> = https://www.ietf.org/mailman/listinfo/jose

 

------=_NextPart_000_013D_01CE2729.4317D1E0-- From trac+jose@trac.tools.ietf.org Fri Mar 22 18:37:16 2013 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 025CB21F8FF7 for ; Fri, 22 Mar 2013 18:37:15 -0700 (PDT) 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=[AWL=0.000, 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 nePhYOxF+TRm for ; Fri, 22 Mar 2013 18:37:14 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6C62521F8E92 for ; Fri, 22 Mar 2013 18:37:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:49359 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJDOO-0007aF-Ha; Sat, 23 Mar 2013 02:37:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Sat, 23 Mar 2013 01:37:08 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:3 Message-ID: <064.fd038d682fc8bd7e9a8f8d90aa89f664@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130323013714.6C62521F8E92@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 18:37:14 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: At least one key indicator should be mandatory (was: Broken examples in JWE / JWS) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 01:37:16 -0000 #15: At least one key indicator should be mandatory -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Fri Mar 22 18:37:52 2013 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 B875021F88FB for ; Fri, 22 Mar 2013 18:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.616 X-Spam-Level: X-Spam-Status: No, score=-1.616 tagged_above=-999 required=5 tests=[AWL=1.360, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 gKlyYl4ytvQL for ; Fri, 22 Mar 2013 18:37:51 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 848BB21F87D1 for ; Fri, 22 Mar 2013 18:37:51 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so4833141oag.39 for ; Fri, 22 Mar 2013 18:37:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Oo/2c6Oq8nEQ3sbNJcbNUyCd3DH5mZQw2KA+4r109n8=; b=NM0pza4n7cDzUcly9scvD2Ocedg7qAUYSAc9OtUzIKdChiCUcyBNORkp2Gs3n05WvH +2ZbQFPZyUHqYcVQ8O8Wvg0RRpbD/ZMsTGMlllunAgFOW3AAN9yTPYBhY+k8BTWarxlh fVwA0t0b0n84C/jE26OMNwojkc+GKqU/qwPKc7pL8xUJjK5pjp//5A2mVg4uOHVLKXTW p9dVDq6fZHZG4VB/lhWTFyxVcqtliD5LyYLL4NxSY4aFAwtT+6lNJa0XSShcitQ2aXRW +SYfDEsdQR5AY5QjJfOOEw17ePU2rbikbVp8lr1FmVmMiigLnv9XEP9hIO7g0+oydIlX WBpQ== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr3968739oec.116.1364002668407; Fri, 22 Mar 2013 18:37:48 -0700 (PDT) Received: by 10.60.40.233 with HTTP; Fri, 22 Mar 2013 18:37:48 -0700 (PDT) X-Originating-IP: [108.18.40.68] In-Reply-To: <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> Date: Fri, 22 Mar 2013 21:37:48 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=bcaec5523bb6864fc004d88d9efa X-Gm-Message-State: ALoCoQkrIXlhVKSaYkzPNbfd4ZEpJUhHY5Z1HVQdNlaSq3NMYZ1Evm1WcIt4RNPhQcj8GYlQsyQe Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 23 Mar 2013 01:37:52 -0000 --bcaec5523bb6864fc004d88d9efa Content-Type: text/plain; charset=ISO-8859-1 I've renamed the issue to try to clarify. You're right that there are alternative ways to locate a key. But a JOSE object needs to contain at least one of them, or else the /* special magic */ clause applies. --Richard On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad wrote: > This may or may not be a flaw in the specification. However the item you > created in the tracker does not reflect what you have put here. I think > you would be better served by saying that there is a flaw in the > specifications in that there should be a MUST that some type of key or key > reference is required in a JWS or JWE.**** > > ** ** > > I would note that your example code should be more complex in that it does > not deal with jku or any of the x* methods of referencing keys.**** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, March 22, 2013 4:09 PM > *To:* Jim Schaad > *Cc:* draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org > > *Subject:* Re: [jose] #15: Broken examples in JWE / JWS**** > > ** ** > > I admit that they are not broken according to the current spec. However, > I have a lot of trouble figuring out how I would write code to process them. > **** > > ** ** > > If "kid" or "jwk" MUST be present to indicate what key I should use, then > I can have deterministic code:**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else {**** > > /* FAIL. can't process this object */**** > > }**** > > ** ** > > As the spec stands, I have no idea what to put in that "else" clause. I'm > clearly not supposed to fail, because the parameters are optional. But > what else?**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else {**** > > /* insert special magic here */**** > > }**** > > ** ** > > This is actually what SPI is supposed to clear up. SPI would provide an > explicit third branch for the special magic to live in.**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else if (/* recognized SPI value */) {**** > > /* process using stored parameters */**** > > } else {**** > > /* FAIL. can't process this object */**** > > }**** > > ** ** > > But without the concept of SPI, the spec is broken because of the > non-determinism noted above.**** > > ** ** > > --Richard**** > > ** ** > > ** ** > > ** ** > > On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad > wrote:**** > > My inclination is that this response is correct. > > What make you think that the key or key reference is required and cannot be > implied? > > Jim**** > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > jose issue tracker > > Sent: Friday, March 22, 2013 2:37 PM > > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; > ignisvulpis@gmail.com > > Cc: jose@ietf.org > > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > > > #15: Broken examples in JWE / JWS > > > > > > Comment (by ignisvulpis@gmail.com): > > > > I think this is not an issue. The examples are NOT broken and they do > not > > need a fix. > > I suggest to close this ticket. > > The draft should definitely not make these illegal. These objects are > perfect > > examples for a valid JWS/JWE. > > > > -- > > -------------------------+---------------------------------------------- > **** > > > -------------------------+---**** > > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: minor | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > -------------------------+---------------------------------------------- > **** > > > -------------------------+---**** > > > > > Ticket URL: > > > jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --bcaec5523bb6864fc004d88d9efa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I've renamed the issue to try to clarify.

You're= right that there are alternative ways to locate a key. =A0But a JOSE objec= t needs to contain at least one of them, or else the /* special magic */ cl= ause applies. =A0

--Richard


= On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <ietf@augustcellars.com= > wrote:

This may or m= ay not be a flaw in the specification.=A0 However the item you created in t= he tracker does not reflect what you have put here.=A0 I think you would be= better served by saying that there is a flaw in the specifications in that= there should be a MUST that some type of key or key reference is required = in a JWS or JWE.

=A0<= /p>

I would note that your= example code should be more complex in that it does not deal with jku or a= ny of the x* methods of referencing keys.

=A0<= /p>

Jim

=A0<= /p>

=A0

From:= Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
= Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org= ; jose@ietf.org


Subject: Re: [jose] #15: Broken examples = in JWE / JWS

=A0

I a= dmit that they are not broken according to the current spec. =A0However, I = have a lot of trouble figuring out how I would write code to process them.<= u>

=A0

If "kid" or "jwk" MUST be present to indicate w= hat key I should use, then I can have deterministic code:

=

if (/* recognized "kid" or "jwk&= quot; value */) {=A0

=A0= =A0 /* use it */

} else= {

=A0 =A0 /* FAIL. =A0can't process thi= s object */

}<= /u>

=A0

As the spec stands, I have no idea what to put in that "else" cla= use. =A0I'm clearly not supposed to fail, because the parameters are op= tional. =A0But what else?

if (/* recognized "kid" or "jwk" value */) {=A0<= u>

=A0 =A0 /* use it */<= /u>

} else {

=A0 =A0 /* insert special magic here */

}

= =A0

This is actually wha= t SPI is supposed to clear up. =A0SPI would provide an explicit third branc= h for the special magic to live in.

if (/* recognized "kid" or= "jwk" value */) {=A0

=A0 =A0 /* use it */

} else if (/* recognized SPI value */) {

=A0 =A0 /* process using stored parameter= s */

} else {<= /u>

=A0 =A0 /* FAIL. =A0can't proc= ess this object */

}

=A0

Bu= t without the concept of SPI, the spec is broken because of the non-determi= nism noted above.

=A0

--Richard

=A0

=A0

=A0

=

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <= ;ietf@augustcel= lars.com> wrote:

My inclination is that this response is correct.
=
What make you think that the key or key reference is required and canno= t be
implied?

Jim



> -----Original Message-----
>= From: jose-boun= ces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
>= ; To: draft-ietf-jose-json-web-encryption@tools.ietf.org;<= br> ignisvulpis@gmai= l.com
> Cc: jo= se@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / J= WS
>
> #15: Broken examples in JWE / JWS
>
>
> Comm= ent (by ignisvul= pis@gmail.com):
>
> =A0I think this is not an issue. The ex= amples are NOT broken and they do not
> need a fix.
> =A0I suggest to close this ticket.
> =A0The = draft should definitely not make these illegal. These objects are
perfec= t
> examples for a valid JWS/JWE.
>
> --
> --------= -----------------+----------------------------------------------<= /u>

> -------------------------+---

> =A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draf= t-ietf-jose-json-web-
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> = =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Co= mponent: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0S= everity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> =A0Keywords: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+-----------= -----------------------------------

> -------------------------+---

><= br>> Ticket URL: <http://trac.tools.ietf.org/wg/jose/t= rac/ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> __________________________= _____________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

=A0


--bcaec5523bb6864fc004d88d9efa-- From trac+jose@trac.tools.ietf.org Fri Mar 22 23:35:23 2013 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 4E86921F88E8 for ; Fri, 22 Mar 2013 23:35:23 -0700 (PDT) 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=[AWL=0.000, 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 1sYBrMlBgyb1 for ; Fri, 22 Mar 2013 23:35:18 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B61B121F848D for ; Fri, 22 Mar 2013 23:35:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:33125 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJI2o-0003aC-5E; Sat, 23 Mar 2013 07:35:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Sat, 23 Mar 2013 06:35:10 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:4 Message-ID: <064.fdbd8e54c5da3a701de7464c2331b03e@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130323063518.B61B121F848D@ietfa.amsl.com> Resent-Date: Fri, 22 Mar 2013 23:35:18 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: At least one key indicator should be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2013 06:35:23 -0000 #15: At least one key indicator should be mandatory Comment (by ignisvulpis@gmail.com): Example for JWE: An Email to Stan <> Dear Stan, please use SuperJWE and the password agreed upon earlier to decrypt Finally.doc.jwe. best the real slim shady ----- Example for JWS: base64url({"alg":"HS256"}).base64url({"X": "containing key info"}).sigb64 ----- Java Example JWS/JWE "jwt received through an SSL connection": {{{ final String ALLOWED_ALG = JsonCryptoLib.HS256; SSLSession sslSession = connection.getSession(); byte[] key = getKey(sslSession); JsonCryptoLib jsonCryptoLib = JsonCryptoLib.getInstance(ALLOWED_ALG); byte[] payload = jsonCryptoLib.parse(jwt, key); // the "magic" is in getKey which uses context information to determine the key // http://docs.oracle.com/javase/1.5.0/docs/api/javax/net/ssl/SSLSession.html#getPeerCertificateChain%28%29 // maybe it is timebased too }}} -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sun Mar 24 17:41:02 2013 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 A0AB221F8C93 for ; Sun, 24 Mar 2013 17:41:02 -0700 (PDT) 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=[AWL=0.000, 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 8ko-WTcjSNlU for ; Sun, 24 Mar 2013 17:41:02 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0903121F8C5D for ; Sun, 24 Mar 2013 17:41:01 -0700 (PDT) Received: from localhost ([127.0.0.1]:43806 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UJvT4-0005td-RF; Mon, 25 Mar 2013 01:40:54 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-key@tools.ietf.org, james@manger.com.au X-Trac-Project: jose Date: Mon, 25 Mar 2013 00:40:54 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/jose/trac/ticket/16 Message-ID: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-key@tools.ietf.org, james@manger.com.au, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130325004102.0903121F8C5D@ietfa.amsl.com> Resent-Date: Sun, 24 Mar 2013 17:41:01 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2013 00:41:02 -0000 #16: URI identifying a specific key in a JWK set When a public key is required to process a JOSE message, providing a URI for the key is a useful alternative to providing the actual key or a certificate. The URI needs to identify the specific individual public key required for the specific JOSE message. A URI that merely identifies a set of keys (one of which is the correct one) is not sufficient. Given that a "jku" field holds a URI pointing to a set of keys, we need to define how to use the fragment part of those URIs to identify a specific key in the set. Using the "kid" (key id) in the fragment would be a sensible choice. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- james@manger.com.au | key@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: key | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose From Michael.Jones@microsoft.com Sun Mar 24 18:03:02 2013 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 B6B9921F8E3E for ; Sun, 24 Mar 2013 18:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VZQqFb8pf1Ir for ; Sun, 24 Mar 2013 18:03:01 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0203.outbound.protection.outlook.com [207.46.163.203]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CD21F8E23 for ; Sun, 24 Mar 2013 18:03:01 -0700 (PDT) Received: from BL2FFO11FD023.protection.gbl (10.173.161.200) by BL2FFO11HUB015.protection.gbl (10.173.160.107) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 01:02:59 +0000 Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD023.mail.protection.outlook.com (10.173.161.102) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 01:02:58 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 01:02:41 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Minutes Thread-Index: Ac4nOU6Wtn5YToVESdmS7jlWKdSc2ABuH0gQ Date: Mon, 25 Mar 2013 01:02:40 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367586714@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> In-Reply-To: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367586714TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(199002)(15202345001)(79102001)(69226001)(46102001)(54316002)(76482001)(49866001)(512954001)(63696002)(33656001)(5343655001)(66066001)(47976001)(71186001)(74662001)(4396001)(5343635001)(31966008)(80022001)(55846006)(51856001)(47736001)(53806001)(54356001)(77982001)(16406001)(65816001)(20776003)(44976002)(74502001)(47446002)(56776001)(56816002)(16236675001)(50986001)(59766001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB015; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Subject: Re: [jose] Minutes 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, 25 Mar 2013 01:03:02 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367586714TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't believe that the minutes adequately capture the discussion on issue= #4 (http://trac.tools.ietf.org/wg/jose/trac/ticket/4#). I would revise as= follows: Data tracker issue #4 (Impossible to separate wrapped key from encrypted da= ta) - John Bradley's slides pointed out that it *is* possible to separate w= rapped keys from encrypted data when needed by using the direct encryption = mode and therefore asked for this issue to be closed, as it is based upon a= false premise. Mike Jones also asked for this to be closed on this basis,= and pointed out that Nat Sakimura had already described the problem with t= his issue in the issue tracker. Richard asked a question about the securit= y analysis of including the wrapped key in the integrity calculation - Does= the wrapped key need to be included in the integrity check or not? The qu= estion will be referred to CFRG but a request for possible attack modes bei= ng sent to the list is requested. Given that the problem stated in issue #4 was demonstrated to not actually = be a problem during the discussions, I would ask again that the chairs clos= e this one, and update the minutes to reflect this. Thank you, -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Friday, March 22, 2013 1:12 PM To: jose@ietf.org Subject: [jose] Minutes Preliminary minutes have been uploaded to the site. Please review and comm= ent back to me if you have disagreements. http://www.ietf.org/proceedings/86/minutes/minutes-86-jose Note that the minutes have an action list at the bottom of them. Jim --_000_4E1F6AAD24975D4BA5B168042967394367586714TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I don’t believe = that the minutes adequately capture the discussion on issue #4 (http://trac.tools.ietf.o= rg/wg/jose/trac/ticket/4#).  I would revise as follows:

 

Data tracker issue #4 = (Impossible to separate wrapped key from encrypted data) – John Bradl= ey’s slides pointed out that it *is* possible to separate wrap= ped keys from encrypted data when needed by using the direct encryption mode and therefore asked for this issue to be closed= , as it is based upon a false premise.  Mike Jones also asked for this= to be closed on this basis, and pointed out that Nat Sakimura had already = described the problem with this issue in the issue tracker.  Richard asked a question about the security an= alysis of including the wrapped key in the integrity calculation - Does the= wrapped key need to be included in the integrity check or not?  The q= uestion will be referred to CFRG but a request for possible attack modes being sent to the list is requested.<= /span>

 

Given that the problem= stated in issue #4 was demonstrated to not actually be a problem during th= e discussions, I would ask again that the chairs close this one, and update= the minutes to reflect this.

 

   &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Thank you,

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, March 22, 2013 1:12 PM
To: jose@ietf.org
Subject: [jose] Minutes

 

Preliminary minutes have been uploaded to the site.&= nbsp; Please review and comment back to me if you have disagreements.<= /o:p>

 

http://www.ietf.org/proceedings/86/minutes/minutes-86-jo= se

 

Note that the minutes have an action list at the bot= tom of them.

 

Jim

 

--_000_4E1F6AAD24975D4BA5B168042967394367586714TK5EX14MBXC283r_-- From bcampbell@pingidentity.com Mon Mar 25 05:16:40 2013 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 719A121F8C74 for ; Mon, 25 Mar 2013 05:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.769 X-Spam-Level: X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 nXoqyBwLmr+Q for ; Mon, 25 Mar 2013 05:16:39 -0700 (PDT) Received: from na3sys009aog117.obsmtp.com (na3sys009aog117.obsmtp.com [74.125.149.242]) by ietfa.amsl.com (Postfix) with ESMTP id 85BCF21F8E58 for ; Mon, 25 Mar 2013 05:16:35 -0700 (PDT) Received: from mail-ob0-f199.google.com ([209.85.214.199]) (using TLSv1) by na3sys009aob117.postini.com ([74.125.148.12]) with SMTP ID DSNKUVBAF3pFo95YrG+6c3wEQbqm97rmspbO@postini.com; Mon, 25 Mar 2013 05:16:38 PDT Received: by mail-ob0-f199.google.com with SMTP id wd20so29839691obb.6 for ; Mon, 25 Mar 2013 05:16:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=65aijBTVe83lhXAOiotwwwjFDl4wXVQxVf7BZEMIjCM=; b=ROXTWXfUquftwzqGoSsfbzl52Izr9t3v9YF59oyOylx6haJydhserz5CuITnhra9eL kE7rTXzaTNkZKWWpviTcCe+iY6FMckMykz6+fcjmhsgMoJYdmFljbfN/rlxJqp1LStmS wa25oPMwnzPkbqHuHFuOUQBdMAWkBU3WuZVSX4sE3Faz1XFJk24utst20k/OnJwsYKpY AnfIp7+S7/n0fcLHE21R1+8s/HD0OMIZQ+pkRxBSsiXzTybj6D4cSv8n9I4j4n6acfm4 pL6z+sQjJ/EM87l13mRUnLCwmqIA0gYLA/0WxsWI4E8XJUXXwB8GNdTq4gBrNTdE9jQE zMkg== X-Received: by 10.50.37.236 with SMTP id b12mr11128015igk.42.1364213783116; Mon, 25 Mar 2013 05:16:23 -0700 (PDT) X-Received: by 10.50.37.236 with SMTP id b12mr11128011igk.42.1364213783013; Mon, 25 Mar 2013 05:16:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Mon, 25 Mar 2013 05:15:52 -0700 (PDT) In-Reply-To: References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> From: Brian Campbell Date: Mon, 25 Mar 2013 06:15:52 -0600 Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=f46d044788d9ef360e04d8bec57b X-Gm-Message-State: ALoCoQnAyogDCHBhpBlZ8qAaCEXwVtY6jFH/VHfccMys/XM7pcv39csF/JNNnkx12DnxEth+YGp+Z4/oWXMoR7XTEqYiapPOFPACfWgiPxHALiXQ3tvH7jsWTC0rex0yP+QE39RSOKus Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, Jim Schaad , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 12:16:40 -0000 --f46d044788d9ef360e04d8bec57b Content-Type: text/plain; charset=ISO-8859-1 /* special magic */ is just some out of band agreement on the key to use or how to infer it. Which isn't really special or magic. But probably pretty common. On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: > I've renamed the issue to try to clarify. > > You're right that there are alternative ways to locate a key. But a JOSE > object needs to contain at least one of them, or else the /* special magic > */ clause applies. > > --Richard > > > On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad wrote: > >> This may or may not be a flaw in the specification. However the item you >> created in the tracker does not reflect what you have put here. I think >> you would be better served by saying that there is a flaw in the >> specifications in that there should be a MUST that some type of key or key >> reference is required in a JWS or JWE.**** >> >> ** ** >> >> I would note that your example code should be more complex in that it >> does not deal with jku or any of the x* methods of referencing keys.**** >> >> ** ** >> >> Jim**** >> >> ** ** >> >> ** ** >> >> *From:* Richard Barnes [mailto:rlb@ipv.sx] >> *Sent:* Friday, March 22, 2013 4:09 PM >> *To:* Jim Schaad >> *Cc:* draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org >> >> *Subject:* Re: [jose] #15: Broken examples in JWE / JWS**** >> >> ** ** >> >> I admit that they are not broken according to the current spec. However, >> I have a lot of trouble figuring out how I would write code to process them. >> **** >> >> ** ** >> >> If "kid" or "jwk" MUST be present to indicate what key I should use, then >> I can have deterministic code:**** >> >> if (/* recognized "kid" or "jwk" value */) { **** >> >> /* use it */**** >> >> } else {**** >> >> /* FAIL. can't process this object */**** >> >> }**** >> >> ** ** >> >> As the spec stands, I have no idea what to put in that "else" clause. >> I'm clearly not supposed to fail, because the parameters are optional. >> But what else?**** >> >> if (/* recognized "kid" or "jwk" value */) { **** >> >> /* use it */**** >> >> } else {**** >> >> /* insert special magic here */**** >> >> }**** >> >> ** ** >> >> This is actually what SPI is supposed to clear up. SPI would provide an >> explicit third branch for the special magic to live in.**** >> >> if (/* recognized "kid" or "jwk" value */) { **** >> >> /* use it */**** >> >> } else if (/* recognized SPI value */) {**** >> >> /* process using stored parameters */**** >> >> } else {**** >> >> /* FAIL. can't process this object */**** >> >> }**** >> >> ** ** >> >> But without the concept of SPI, the spec is broken because of the >> non-determinism noted above.**** >> >> ** ** >> >> --Richard**** >> >> ** ** >> >> ** ** >> >> ** ** >> >> On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad >> wrote:**** >> >> My inclination is that this response is correct. >> >> What make you think that the key or key reference is required and cannot >> be >> implied? >> >> Jim**** >> >> >> >> > -----Original Message----- >> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >> > jose issue tracker >> > Sent: Friday, March 22, 2013 2:37 PM >> > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; >> ignisvulpis@gmail.com >> > Cc: jose@ietf.org >> > Subject: Re: [jose] #15: Broken examples in JWE / JWS >> > >> > #15: Broken examples in JWE / JWS >> > >> > >> > Comment (by ignisvulpis@gmail.com): >> > >> > I think this is not an issue. The examples are NOT broken and they do >> not >> > need a fix. >> > I suggest to close this ticket. >> > The draft should definitely not make these illegal. These objects are >> perfect >> > examples for a valid JWS/JWE. >> > >> > -- >> > -------------------------+---------------------------------------------- >> **** >> >> > -------------------------+---**** >> >> > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- >> > Type: defect | encryption@tools.ietf.org >> > Priority: minor | Status: new >> > Component: json-web- | Milestone: >> > encryption | Version: >> > Severity: - | Resolution: >> > Keywords: | >> > -------------------------+---------------------------------------------- >> **** >> >> > -------------------------+---**** >> >> > >> > Ticket URL: < >> http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:1> >> > jose >> > >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose**** >> >> ** ** >> > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --f46d044788d9ef360e04d8bec57b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
/* special magic */ is just some out of band agreement on= the key to use or how to infer it. Which isn't really special or magic= . But probably pretty common.


<= div class=3D"gmail_quote"> On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <rlb@ipv.sx> wrote:=
I've renamed the issue to try to clarify.

You're= right that there are alternative ways to locate a key. =A0But a JOSE objec= t needs to contain at least one of them, or else the /* special magic */ cl= ause applies. =A0

--Richard


On Fri, Mar 22, 2013 = at 9:15 PM, Jim Schaad <ietf@augustcellars.com> wrote:<= br>

This may or m= ay not be a flaw in the specification.=A0 However the item you created in t= he tracker does not reflect what you have put here.=A0 I think you would be= better served by saying that there is a flaw in the specifications in that= there should be a MUST that some type of key or key reference is required = in a JWS or JWE.

=A0<= /p>

I would note that your= example code should be more complex in that it does not deal with jku or a= ny of the x* methods of referencing keys.

=A0<= /p>

Jim

=A0<= /p>

=A0

From:= Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
= Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org= ; jose@ietf.org


Subject: Re: [jose] #15: Broken examples in JWE / JWS<= u>

=A0

I admit that they are not bro= ken according to the current spec. =A0However, I have a lot of trouble figu= ring out how I would write code to process them.

=A0

If "kid" or "jwk" MUST be present to indicate w= hat key I should use, then I can have deterministic code:

=

if (/* recognized "kid" or "jwk&= quot; value */) {=A0

=A0= =A0 /* use it */

} else= {

=A0 =A0 /* FAIL. =A0can't process thi= s object */

}<= /u>

=A0

As the spec stands, I have no idea what to put in that "else" cla= use. =A0I'm clearly not supposed to fail, because the parameters are op= tional. =A0But what else?

if (/* recognized "kid" or "jwk" value */) {=A0<= u>

=A0 =A0 /* use it */<= /u>

} else {

=A0 =A0 /* insert special magic here */

}

= =A0

This is actually wha= t SPI is supposed to clear up. =A0SPI would provide an explicit third branc= h for the special magic to live in.

if (/* recognized "kid" or= "jwk" value */) {=A0

=A0 =A0 /* use it */

} else if (/* recognized SPI value */) {

=A0 =A0 /* process using stored parameter= s */

} else {<= /u>

=A0 =A0 /* FAIL. =A0can't proc= ess this object */

}

=A0

Bu= t without the concept of SPI, the spec is broken because of the non-determi= nism noted above.

=A0

--Richard

=A0

=A0

=A0

=

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <= ;ietf@augustcel= lars.com> wrote:

My inclination is that this response is correct.
=
What make you think that the key or key reference is required and canno= t be
implied?

Jim



> -----Original Message-----
>= From: jose-boun= ces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
>= ; To: draft-ietf-jose-json-web-encryption@tools.ietf.org;<= br> ignisvulpis@gmai= l.com
> Cc: jo= se@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / J= WS
>
> #15: Broken examples in JWE / JWS
>
>
> Comm= ent (by ignisvul= pis@gmail.com):
>
> =A0I think this is not an issue. The ex= amples are NOT broken and they do not
> need a fix.
> =A0I suggest to close this ticket.
> =A0The = draft should definitely not make these illegal. These objects are
perfec= t
> examples for a valid JWS/JWE.
>
> --
> --------= -----------------+----------------------------------------------<= /u>

> -------------------------+---

> =A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draf= t-ietf-jose-json-web-
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> = =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Co= mponent: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0S= everity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> =A0Keywords: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+-----------= -----------------------------------

> -------------------------+---

><= br>> Ticket URL: <http://trac.tools.ietf.org/wg/jose/t= rac/ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> __________________________= _____________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

=A0



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--f46d044788d9ef360e04d8bec57b-- From bcampbell@pingidentity.com Mon Mar 25 05:31:54 2013 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 3BF9C21F8E74 for ; Mon, 25 Mar 2013 05:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.373 X-Spam-Level: X-Spam-Status: No, score=-5.373 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Os1yNi4DJbvh for ; Mon, 25 Mar 2013 05:31:53 -0700 (PDT) Received: from na3sys009aog128.obsmtp.com (na3sys009aog128.obsmtp.com [74.125.149.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5C64121F8E66 for ; Mon, 25 Mar 2013 05:31:53 -0700 (PDT) Received: from mail-ob0-f198.google.com ([209.85.214.198]) (using TLSv1) by na3sys009aob128.postini.com ([74.125.148.12]) with SMTP ID DSNKUVBDuJuRO6Iya941vxacv50tzLdDsoV6@postini.com; Mon, 25 Mar 2013 05:31:53 PDT Received: by mail-ob0-f198.google.com with SMTP id dn14so29874245obc.9 for ; Mon, 25 Mar 2013 05:31:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=iq9Xrpeq6U9V7qVC2kWWnGgPvuEHKs4CZGroyIZaJfE=; b=CJhRfJDTw6ljJCa/TolzxyHAOZucuxbu7VRkqgO8qdjR8xL6yKqszGTLQJ18QmUxAT gEvuMy6Y2X+G6mBgR8XaNbIKrlT3qiHd/agX2EvEUU6SGnEoeyQOC8MEunS4a6xyFY8Z /+YcI46KotwENoYst7WO5b7cSuuEFFXs8Bh8x5mCqZrgcJKWmaagVSD6OfZJl9OK7b0c j3ErIA9nFRbBXKqwFJPRvkPdjZeJlBPPH6UYzL0i3A5z16BtLCMBJieCDBV0e8Q0f8hc SOjZ+3gG+XZ1XTLCzKROf9BOmaxIUVqb5sWvnsL3ek/McaSXhI8nHKqI3UjUSGV3cCVE b90Q== X-Received: by 10.42.157.199 with SMTP id e7mr6559733icx.34.1364214712335; Mon, 25 Mar 2013 05:31:52 -0700 (PDT) X-Received: by 10.42.157.199 with SMTP id e7mr6559724icx.34.1364214712223; Mon, 25 Mar 2013 05:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.32.106 with HTTP; Mon, 25 Mar 2013 05:31:22 -0700 (PDT) In-Reply-To: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> From: Brian Campbell Date: Mon, 25 Mar 2013 06:31:22 -0600 Message-ID: To: jose issue tracker Content-Type: multipart/alternative; boundary=90e6ba6e842a51f17904d8befd6b X-Gm-Message-State: ALoCoQnxHNxQM3c96/qEU0dly3mRegXbfn8ivpRwn0lEMsqB0eLr3ZEJwgC2qsyc7aPypauvy8F2j0TgvvUh1orJLjxEaSPL3OsnuNQXzjL/UkaqtrJ7kQJU6qg6jOM8DgCh3qdoKy1m Cc: draft-ietf-jose-json-web-key@tools.ietf.org, "jose@ietf.org" , james@manger.com.au Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 25 Mar 2013 12:31:54 -0000 --90e6ba6e842a51f17904d8befd6b Content-Type: text/plain; charset=ISO-8859-1 I'd always just assumed that, short of some other means of figuring it out, a kid header would accompany a jku to identify the specific key in the set. On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker < trac+jose@trac.tools.ietf.org> wrote: > #16: URI identifying a specific key in a JWK set > > When a public key is required to process a JOSE message, providing a URI > for the key is a useful alternative to providing the actual key or a > certificate. The URI needs to identify the specific individual public key > required for the specific JOSE message. A URI that merely identifies a set > of keys (one of which is the correct one) is not sufficient. > > Given that a "jku" field holds a URI pointing to a set of keys, we need to > define how to use the fragment part of those URIs to identify a specific > key in the set. > > Using the "kid" (key id) in the fragment would be a sensible choice. > > -- > -------------------------+------------------------------------------------- > Reporter: | Owner: draft-ietf-jose-json-web- > james@manger.com.au | key@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > key | Keywords: > Severity: - | > -------------------------+------------------------------------------------- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --90e6ba6e842a51f17904d8befd6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'd always just assumed that, short of some other mean= s of figuring it out, a kid header would accompany a jku to identify the sp= ecific key in the set.


On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker <<= a href=3D"mailto:trac+jose@trac.tools.ietf.org" target=3D"_blank">trac+jose= @trac.tools.ietf.org> wrote:
james@manger.com.au =A0 =A0|= =A0key@tools.ietf.org
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0json-web- =A0 =A0| =A0 =A0Version:
=A0 key =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0|
-------------------------+-------------------------------------------------=

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/16>
jose <http://t= ools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--90e6ba6e842a51f17904d8befd6b-- From vladimir@nimbusds.com Mon Mar 25 07:02:07 2013 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 90B4421F8E6B for ; Mon, 25 Mar 2013 07:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 Yzi0nWC-VFw8 for ; Mon, 25 Mar 2013 07:02:07 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id 79B6A21F8C9E for ; Mon, 25 Mar 2013 07:02:02 -0700 (PDT) Received: (qmail 29697 invoked from network); 25 Mar 2013 14:02:01 -0000 Received: from unknown (HELO localhost) (188.121.52.246) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 25 Mar 2013 14:02:01 -0000 Received: (qmail 910 invoked by uid 99); 25 Mar 2013 14:02:01 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.242.106 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Brian Campbell" , "Juraj Somorovsky" Date: Mon, 25 Mar 2013 07:02:00 -0700 Mime-Version: 1.0 Cc: Tibor Jager , Mike Jones , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 25 Mar 2013 14:02:07 -0000 Hi guys,=0A=0AJust checked in a simple counter measure as suggested below, = should=0Abecome part of the new release, probably sometime later this week.= =0A=0Ahttps://bitbucket.org/nimbusds/nimbus-jose-jwt/src/da13ee89febda936b2= 34a76da3f330e39970c240/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.= java?at=3Dmaster#cl-138=0A=0AThe actual random CMK generation also does tak= e time to do, I suppose=0Athat also has to be measured and taken into accou= nt?=0A=0A=0ACheers,=0A=0AVladimir=0A=0A--=0AVladimir Dzhuvinov : www.Nimbus= DS.com : vladimir@nimbusds.com=0A=0A=0A-------- Original Message --------= =0ASubject: Re: [jose] backwards compatibility attack on JWT impls (was:=0A= I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)=0AFrom: Brian Campb= ell =0ADate: Fri, March 15, 2013 8:03 pm=0ATo: = Juraj Somorovsky =0ACc: Tibor Jager , Mike Jones=0A, =3DJeffH ,=0AIETF JOSE WG =0A=0A+1 =0A=0A=0AThank= s Juraj.=0A=0A=0AOn Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky=0A wrote:=0A =0A Generally, such an attack could be of cou= rse *mitigated* by generating=0A random CMKs, when the RSA1_5 is invalid. T= hus, I would propose to=0A reference Eric's=0A https://tools.ietf.org/rfc/r= fc3218.txt=0A in your security considerations. Maybe, it would be even bett= er to=0A explicitly sketch these countermeasures as done in TLS1.2=0A (http= ://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.)=0A =0A Regards=0A Juraj= =0A=0A=0A=0A_______________________________________________=0Ajose mailing = list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/jose From mpeck@mitre.org Mon Mar 25 08:27:45 2013 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 F40A621F848A for ; Mon, 25 Mar 2013 08:27:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 m6y0TppBF6Ku for ; Mon, 25 Mar 2013 08:27:44 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id D5ACE21F8488 for ; Mon, 25 Mar 2013 08:27:43 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 69EFE2A50005; Mon, 25 Mar 2013 11:27:43 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 44B5A1F0437; Mon, 25 Mar 2013 11:27:43 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS03.MITRE.ORG ([129.83.29.80]) with mapi id 14.02.0342.003; Mon, 25 Mar 2013 11:27:17 -0400 From: "Peck, Michael A" To: Vladimir Dzhuvinov / NimbusDS , Brian Campbell , Juraj Somorovsky Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: AQHOKWFKFz3GxUPUKEytTE8qagUVDZi2hEXA Date: Mon, 25 Mar 2013 15:27:17 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFDEDC7@IMCMBX04.MITRE.ORG> References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> In-Reply-To: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tibor Jager , Mike Jones , =JeffH , IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 25 Mar 2013 15:27:45 -0000 I'm not certain of the status of the "mandatory to implement" discussion, b= ut all of this seems like good reason for RSA1_5 to NOT be REQUIRED to impl= ement (Table in section 4.1 of draft-ietf-jose-json-web-algorithms). RSA1_= 5 is easy to implement insecurely. There seem to be lots of caveats that h= ave to be followed to do it "securely", and do we actually know that those = will continue to be enough? Mike >-----Original Message----- >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of >Vladimir Dzhuvinov / NimbusDS >Sent: Monday, March 25, 2013 10:02 AM >To: Brian Campbell; Juraj Somorovsky >Cc: Tibor Jager; Mike Jones; IETF JOSE WG; =3DJeffH >Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D >Action: draft-ietf-jose-json-web-algorithms-02.txt) > >Hi guys, > >Just checked in a simple counter measure as suggested below, should >become part of the new release, probably sometime later this week. > >https://bitbucket.org/nimbusds/nimbus-jose- >jwt/src/da13ee89febda936b234a76da3f330e39970c240/src/main/java/com/ni >mbusds/jose/crypto/RSADecrypter.java?at=3Dmaster#cl-138 > >The actual random CMK generation also does take time to do, I suppose >that also has to be measured and taken into account? > > >Cheers, > >Vladimir > >-- >Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > >-------- Original Message -------- >Subject: Re: [jose] backwards compatibility attack on JWT impls (was: >I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) >From: Brian Campbell >Date: Fri, March 15, 2013 8:03 pm >To: Juraj Somorovsky >Cc: Tibor Jager , Mike Jones >, =3DJeffH >, >IETF JOSE WG > >+1 > > >Thanks Juraj. > > >On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky > wrote: > > Generally, such an attack could be of course *mitigated* by generating > random CMKs, when the RSA1_5 is invalid. Thus, I would propose to > reference Eric's > https://tools.ietf.org/rfc/rfc3218.txt > in your security considerations. Maybe, it would be even better to > explicitly sketch these countermeasures as done in TLS1.2 > (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.) > > Regards > Juraj > > > >_______________________________________________ >jose mailing list >jose@ietf.org >https://www.ietf.org/mailman/listinfo/jose >_______________________________________________ >jose mailing list >jose@ietf.org >https://www.ietf.org/mailman/listinfo/jose From prateek.mishra@oracle.com Mon Mar 25 09:37:42 2013 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 D266A21F8D09 for ; Mon, 25 Mar 2013 09:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 wDCs3gYoAZHj for ; Mon, 25 Mar 2013 09:37:42 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 48F1521F90B5 for ; Mon, 25 Mar 2013 09:37:42 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r2PGbHb8032582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Mar 2013 16:37:18 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r2PGbHnm004445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Mar 2013 16:37:17 GMT Received: from abhmt113.oracle.com (abhmt113.oracle.com [141.146.116.65]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id r2PGbGsU020420; Mon, 25 Mar 2013 11:37:17 -0500 Received: from [10.152.55.88] (/10.152.55.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 25 Mar 2013 09:37:16 -0700 Message-ID: <51507D2D.2010106@oracle.com> Date: Mon, 25 Mar 2013 12:37:01 -0400 From: prateek mishra Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: jose@ietf.org, ietf@augustcellars.com References: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> In-Reply-To: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> Content-Type: multipart/alternative; boundary="------------050001040204000804090701" X-Source-IP: acsinet21.oracle.com [141.146.126.237] Subject: Re: [jose] Minutes 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, 25 Mar 2013 16:37:42 -0000 This is a multi-part message in MIME format. --------------050001040204000804090701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I had asked a question from the floor concerning the *interoperability* of any existing jose implementations and also whether there was a list of implementations available someplace. The latter aspect of my comment has been captured but the part about interoperability has been removed. I would appreciate it if the minutes were amended to reflect my question in its entirety. Thx, prateek > > Preliminary minutes have been uploaded to the site. Please review and > comment back to me if you have disagreements. > > http://www.ietf.org/proceedings/86/minutes/minutes-86-jose > > Note that the minutes have an action list at the bottom of them. > > Jim > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --------------050001040204000804090701 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I had asked a question from the floor concerning the *interoperability* of any existing jose implementations and also whether
there was a list of implementations available someplace.

The latter aspect of my comment has been captured but the part about interoperability has been removed. I would appreciate it if the minutes
were amended to reflect my question in its entirety.

Thx,
prateek

Preliminary minutes have been uploaded to the site.  Please review and comment back to me if you have disagreements.

 

http://www.ietf.org/proceedings/86/minutes/minutes-86-jose

 

Note that the minutes have an action list at the bottom of them.

 

Jim

 



_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

--------------050001040204000804090701-- From juraj.somorovsky@rub.de Mon Mar 25 07:15:28 2013 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 3A92B21F8FC7 for ; Mon, 25 Mar 2013 07:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 3asrIziQzU2w for ; Mon, 25 Mar 2013 07:15:27 -0700 (PDT) Received: from mx5.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.33]) by ietfa.amsl.com (Postfix) with SMTP id 14AE921F8FC0 for ; Mon, 25 Mar 2013 07:15:26 -0700 (PDT) X-Queued: (qmail 26682 invoked by alias); 25 Mar 2013 14:15:26 -0000 X-Queued: (qmail 26667 invoked from network); 25 Mar 2013 14:15:25 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx5.rz.ruhr-uni-bochum.de with SMTP; 25 Mar 2013 14:15:25 -0000 X-Queued: (qmail 28595 invoked by uid 281); 25 Mar 2013 14:15:25 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUwbByvEKdco8g==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(134.147.40.78):. Processed in 0.08963 secs); 25 Mar 2013 14:15:25 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUwbByvEKdco8g==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 25 Mar 2013 14:15:25 -0000 Date: 25 Mar 2013 15:15:22 +0100 Message-ID: <51505BFA.7080100@rub.de> From: "Juraj Somorovsky" To: "Vladimir Dzhuvinov / NimbusDS" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> In-Reply-To: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Mar 2013 10:39:17 -0700 Cc: Tibor Jager , Mike Jones , Brian Campbell , IETF JOSE WG , =JeffH Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 25 Mar 2013 14:15:28 -0000 Hi Vladimir, you are right, the random number generation *must not* be done in the catch block, it could be measured and leak an information about ciphertext validity. I would propose this code: if (alg.equals(JWEAlgorithm.RSA1_5)) { int keyLength = cmkBitLength(readOnlyJWEHeader.getEncryptionMethod()); SecretKey randomCMK = AES.generateAESCMK(keyLength); try { cmk = RSA1_5.decryptCMK(privateKey, encryptedKey.decode(), keyLength); } catch (Exception e) { // Protect against MMA attack by generating random CMK on failure, // see http://www.ietf.org/mail-archive/web/jose/current/msg01832.html cmk = randomCMK; } } This would be perfect and also secure against timing attacks. Regards Juraj On 03/25/2013 03:02 PM, Vladimir Dzhuvinov / NimbusDS wrote: > Hi guys, > > Just checked in a simple counter measure as suggested below, should > become part of the new release, probably sometime later this week. > > https://bitbucket.org/nimbusds/nimbus-jose-jwt/src/da13ee89febda936b234a76da3f330e39970c240/src/main/java/com/nimbusds/jose/crypto/RSADecrypter.java?at=master#cl-138 > > The actual random CMK generation also does take time to do, I suppose > that also has to be measured and taken into account? > > > Cheers, > > Vladimir > > -- > Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > -------- Original Message -------- > Subject: Re: [jose] backwards compatibility attack on JWT impls (was: > I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) > From: Brian Campbell > Date: Fri, March 15, 2013 8:03 pm > To: Juraj Somorovsky > Cc: Tibor Jager , Mike Jones > , =JeffH , > IETF JOSE WG > > +1 > > > Thanks Juraj. > > > On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky > wrote: > > Generally, such an attack could be of course *mitigated* by generating > random CMKs, when the RSA1_5 is invalid. Thus, I would propose to > reference Eric's > https://tools.ietf.org/rfc/rfc3218.txt > in your security considerations. Maybe, it would be even better to > explicitly sketch these countermeasures as done in TLS1.2 > (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.) > > Regards > Juraj > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > From jricher@mitre.org Mon Mar 25 13:37:42 2013 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 8B07E21F8B11 for ; Mon, 25 Mar 2013 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.165 X-Spam-Level: X-Spam-Status: No, score=-6.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 GaoE73uZot6w for ; Mon, 25 Mar 2013 13:37:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 79C0821F86F5 for ; Mon, 25 Mar 2013 13:37:41 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F0E733250006 for ; Mon, 25 Mar 2013 16:37:37 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 6872B6250012 for ; Mon, 25 Mar 2013 16:37:35 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Mon, 25 Mar 2013 16:37:10 -0400 Message-ID: <5150B533.2080205@mitre.org> Date: Mon, 25 Mar 2013 16:36:03 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: "jose@ietf.org" Content-Type: multipart/alternative; boundary="------------090609030501070400030700" X-Originating-IP: [129.83.31.58] Subject: [jose] JWK Generator 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, 25 Mar 2013 20:37:42 -0000 --------------090609030501070400030700 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit A while ago, several folks complained that there was no toolchain for creating bare keys in the JWK/JPSK format. Indeed, my team's been using Java's keytool program and making self-signed dummy certs and pulling them out of there. That was a bit of a pain, to be honest. So now I've just written a utility program to generate JWK formatted keys from whole cloth given a set of parameters. It's a Java app built using the NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct keytypes, with an option to extract the public-only portion of the RSA as well. This is all based on the current JPSK format, which we plan to track with the aforementioned Nimbus library. You can get the code here: https://github.com/mitreid-connect/json-web-key-generator It's open sourced under an Apache 2.0 license, so feel free to pull it down and use it to your heart's content. It's a Java Maven project, so you build it with: mvn package This will create a couple of .jar files in the target/ directory, one of which is an executable fat jar, usble from the commandline: usage: java -jar json-web-key-generator.jar -t -s [-u -a -i -p] -a Algorithm. -i Key ID (optional) -p Display public key separately -s Key Size in bits, must be an integer, generally divisible by 8 -t Key Type, one of: RSA, oct -u Usage, one of: enc, sig. Defaults to sig For instance, to generate a 1024-bit RSA key with the algorithm of RS256, no key id, and display the public key separately, you would run (after doing a mvn package): java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -a RS256 -t RSA -s 1024 -p This prints out (for example, your keys should vary): Full key: { "alg": "RS256", "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0", "e": "AQAB", "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", "kty": "RSA", "use": "sig" } Public key: { "alg": "RS256", "e": "AQAB", "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", "kty": "RSA", "use": "sig" } To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey", you'd do: java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -t oct -s 256 Which outputs something like: Full key: { "kty": "oct", "use": "sig", "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME" } It doesn't do EC keys yet because I don't know the Java Magic needed to make such a thing happen, but I'd be happy to have someone help out with that with a pull request. Hopefully people find this utility useful. I've got a few features I'm planning to add (write output to files, Java GUI with dropdowns for options), but this is a minimally-useful set of functionality. -- Justin --------------090609030501070400030700 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit A while ago, several folks complained that there was no toolchain for creating bare keys in the JWK/JPSK format. Indeed, my team's been using Java's keytool program and making self-signed dummy certs and pulling them out of there. That was a bit of a pain, to be honest.

So now I've just written a utility program to generate JWK formatted keys from whole cloth given a set of parameters. It's a Java app built using the NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct keytypes, with an option to extract the public-only portion of the RSA as well. This is all based on the current JPSK format, which we plan to track with the aforementioned Nimbus library.

You can get the code here:

  https://github.com/mitreid-connect/json-web-key-generator

It's open sourced under an Apache 2.0 license, so feel free to pull it down and use it to your heart's content. It's a Java Maven project, so you build it with:

  mvn package

This will create a couple of .jar files in the target/ directory, one of which is an executable fat jar, usble from the commandline:

usage: java -jar json-web-key-generator.jar -t <keyType> -s <keySize> [-u
            <keyUsage> -a <algorithm> -i <keyId> -p]
 -a <arg>   Algorithm.
 -i <arg>   Key ID (optional)
 -p         Display public key separately
 -s <arg>   Key Size in bits, must be an integer, generally divisible by 8
 -t <arg>   Key Type, one of: RSA, oct
 -u <arg>   Usage, one of: enc, sig. Defaults to sig

For instance, to generate a 1024-bit RSA key with the algorithm of RS256, no key id, and display the public key separately, you would run (after doing a mvn package):

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -a RS256 -t RSA -s 1024 -p

This prints out (for example, your keys should vary):

Full key:
{
  "alg": "RS256",
  "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}
Public key:
{
  "alg": "RS256",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}

To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey", you'd do:

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -t oct -s 256

Which outputs something like:

Full key:
{
  "kty": "oct",
  "use": "sig",
  "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME"
}

It doesn't do EC keys yet because I don't know the Java Magic needed to make such a thing happen, but I'd be happy to have someone help out with that with a pull request.

Hopefully people find this utility useful. I've got a few features I'm planning to add (write output to files, Java GUI with dropdowns for options), but this is a minimally-useful set of functionality.

 -- Justin
--------------090609030501070400030700-- From Axel.Nennker@telekom.de Mon Mar 25 14:05:37 2013 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 7827621F9039 for ; Mon, 25 Mar 2013 14:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 c0WomlENUoqV for ; Mon, 25 Mar 2013 14:05:35 -0700 (PDT) Received: from tcmail43.telekom.de (tcmail43.telekom.de [80.149.113.173]) by ietfa.amsl.com (Postfix) with ESMTP id E001C21F9181 for ; Mon, 25 Mar 2013 14:05:34 -0700 (PDT) Received: from he111296.emea1.cds.t-internal.com ([10.125.90.14]) by tcmail41.telekom.de with ESMTP/TLS/AES128-SHA; 25 Mar 2013 22:05:29 +0100 Received: from HE100014.emea1.cds.t-internal.com (10.125.65.197) by HE111296.EMEA1.CDS.T-INTERNAL.COM (10.125.90.14) with Microsoft SMTP Server (TLS) id 8.3.297.1; Mon, 25 Mar 2013 22:05:29 +0100 Received: from HE111541.emea1.cds.t-internal.com ([10.125.90.94]) by HE100014.emea1.cds.t-internal.com ([2002:769:41c5::769:41c5]) with mapi; Mon, 25 Mar 2013 22:05:27 +0100 From: To: , Date: Mon, 25 Mar 2013 22:05:25 +0100 Thread-Topic: [jose] JWK Generator Thread-Index: Ac4pmJxXLVeixU0hSqWQrYdCf4iPFQAA18lw Message-ID: References: <5150B533.2080205@mitre.org> In-Reply-To: <5150B533.2080205@mitre.org> Accept-Language: de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: multipart/alternative; boundary="_000_CE8995AB5D178F44A2154F5C9A97CAF4025536DC09D1HE111541eme_" MIME-Version: 1.0 Subject: Re: [jose] JWK Generator 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, 25 Mar 2013 21:05:37 -0000 --_000_CE8995AB5D178F44A2154F5C9A97CAF4025536DC09D1HE111541eme_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable EC key generation can be found in http://jsoncrypto.org/ ES512 https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncr= ypto/JcBaseTest.java#2726 ES384 https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncr= ypto/JcBaseTest.java#2685 ES256 https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncr= ypto/JcBaseTest.java#2642 I guess that the println lines can be converted into JWKs. -Axel From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jus= tin Richer Sent: Monday, March 25, 2013 9:36 PM To: jose@ietf.org Subject: [jose] JWK Generator A while ago, several folks complained that there was no toolchain for creat= ing bare keys in the JWK/JPSK format. Indeed, my team's been using Java's k= eytool program and making self-signed dummy certs and pulling them out of t= here. That was a bit of a pain, to be honest. So now I've just written a utility program to generate JWK formatted keys f= rom whole cloth given a set of parameters. It's a Java app built using the = NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct k= eytypes, with an option to extract the public-only portion of the RSA as we= ll. This is all based on the current JPSK format, which we plan to track wi= th the aforementioned Nimbus library. You can get the code here: https://github.com/mitreid-connect/json-web-key-generator It's open sourced under an Apache 2.0 license, so feel free to pull it down= and use it to your heart's content. It's a Java Maven project, so you buil= d it with: mvn package This will create a couple of .jar files in the target/ directory, one of wh= ich is an executable fat jar, usble from the commandline: usage: java -jar json-web-key-generator.jar -t -s [-u -a -i -p] -a Algorithm. -i Key ID (optional) -p Display public key separately -s Key Size in bits, must be an integer, generally divisible by 8 -t Key Type, one of: RSA, oct -u Usage, one of: enc, sig. Defaults to sig For instance, to generate a 1024-bit RSA key with the algorithm of RS256, n= o key id, and display the public key separately, you would run (after doing= a mvn package): java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencie= s.jar -a RS256 -t RSA -s 1024 -p This prints out (for example, your keys should vary): Full key: { "alg": "RS256", "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryC= U4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q= -eFOEpXWUtKy7DCFymMves7ojPxY0", "e": "AQAB", "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-= OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi= 4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", "kty": "RSA", "use": "sig" } Public key: { "alg": "RS256", "e": "AQAB", "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-= OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi= 4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", "kty": "RSA", "use": "sig" } To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey= ", you'd do: java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencie= s.jar -t oct -s 256 Which outputs something like: Full key: { "kty": "oct", "use": "sig", "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME" } It doesn't do EC keys yet because I don't know the Java Magic needed to mak= e such a thing happen, but I'd be happy to have someone help out with that = with a pull request. Hopefully people find this utility useful. I've got a few features I'm plan= ning to add (write output to files, Java GUI with dropdowns for options), b= ut this is a minimally-useful set of functionality. -- Justin --_000_CE8995AB5D178F44A2154F5C9A97CAF4025536DC09D1HE111541eme_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= EC key generation can be found in http://jsoncrypto.org/

 

ES512<= /span>

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsonc= rypto/JcBaseTest.java#2726

 

ES384

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/js= oncrypto/JcBaseTest.java#2685

 

ES256<= /o:p>

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org= /jsoncrypto/JcBaseTest.java#2642

 

I guess = that the println lines can be converted into JWKs.

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>-Axel

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Beha= lf Of Justin Richer
Sent: Monday, March 25, 2013 9:36 PM
<= b>To: jose@ietf.org
Subject: [jose] JWK Generator<= /span>

 

A while ago, several folks complai= ned that there was no toolchain for creating bare keys in the JWK/JPSK form= at. Indeed, my team's been using Java's keytool program and making self-sig= ned dummy certs and pulling them out of there. That was a bit of a pain, to= be honest.

So now I've just written a utility program to generate J= WK formatted keys from whole cloth given a set of parameters. It's a Java a= pp built using the NimbusDS JWT-JOSE library, and at the moment it supports= both RSA and oct keytypes, with an option to extract the public-only porti= on of the RSA as well. This is all based on the current JPSK format, which = we plan to track with the aforementioned Nimbus library.

You can get= the code here:

  https://github.com/mitreid-connect/json-web-key-ge= nerator

It's open sourced under an Apache 2.0 license, so feel f= ree to pull it down and use it to your heart's content. It's a Java Maven p= roject, so you build it with:

  mvn package

This will cr= eate a couple of .jar files in the target/ directory, one of which is an ex= ecutable fat jar, usble from the commandline:

usage: jav=
a -jar json-web-key-generator.jar -t <keyType> -s <keySize> [-u=

         =
;   <keyUsage> -a <algorithm> -i <keyId> -p]
 -a <arg>   Algorithm.
 -i <arg>   Key ID (optional)
 -p         Display publ=
ic key separately
 -s <arg>   Key=
 Size in bits, must be an integer, generally divisible by 8
 -t <arg>   Key Type, one of: RSA, oct
 -u <arg>   Usage, one of: enc, sig. Defau=
lts to sig

For instance, to generate a 1024-bit RSA key with the algorithm of =
RS256, no key id, and display the public key separately, you would run (aft=
er doing a mvn package):

  java -jar target/json-web-key-genera=
tor-0.1-SNAPSHOT-jar-with-dependencies.jar -a RS256 -t RSA -s 1024 -p
This prints out (for example, your keys should vary):
=
Full key:
{
  "alg"=
;: "RS256",
  "d": "IXhR=
b4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvY=
HpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy=
7DCFymMves7ojPxY0",
  "e": "A=
QAB",
  "n": "kWkuetDiodUI-0j=
Z2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8=
Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQn=
q5dxp0",
  "kty": "RSA",=

  "use": "sig"
}
 
Public key:=

{
  "alg": "RS256=
",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG=
8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-B=
tahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
=

  "use": "sig"
}

To create =
a 256-bit symmetric key with algorithm HS256 and key id of "myKey"=
;, you'd do:

  java -jar target/json-web-key-generator-0.1-SNAP=
SHOT-jar-with-dependencies.jar -t oct -s 256

Which outputs something=
 like:
Full key:
{
=

  "kty": "oct",
  &=
quot;use": "sig",
  "k":=
 "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME"
}

It doesn't do EC keys yet bec=
ause I don't know the Java Magic needed to make such a thing happen, but I'=
d be happy to have someone help out with that with a pull request. 

=
Hopefully people find this utility useful. I've got a few features I'm plan=
ning to add (write output to files, Java GUI with dropdowns for options), b=
ut this is a minimally-useful set of functionality.

 -- Justin<=
o:p>
= --_000_CE8995AB5D178F44A2154F5C9A97CAF4025536DC09D1HE111541eme_-- From rlb@ipv.sx Mon Mar 25 14:26:14 2013 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 6D61321F9125 for ; Mon, 25 Mar 2013 14:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 KFgfPovEP6WX for ; Mon, 25 Mar 2013 14:26:12 -0700 (PDT) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) by ietfa.amsl.com (Postfix) with ESMTP id 6E51A21F90F8 for ; Mon, 25 Mar 2013 14:26:12 -0700 (PDT) Received: by mail-oa0-f52.google.com with SMTP id k14so7026064oag.11 for ; Mon, 25 Mar 2013 14:26:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=40Gq3n804FZvcwKkRu9wUSgq62Al/xswb6QUIRLhNmM=; b=ZPXBTmTv3XKjHew86YtOM8+tp+UAjlUdp4Y70jZOwTMTp04NlWKIO7moogg1IAaeEJ UVfSXIg4gBWR6jUgcvYwN7kQSavq4/ianvcKUS9c4XoytNSHaDelY+fqU8nq6xSwJEWt ZuBtAG0y3ZZ3rQlUsImgwKhzd7INWmY/I+/8TtePGdH1P0+ulakbrPKedDwnlPe1K4bJ a44LS+qxJxg3yQWYceBeHORcWpgstMu9o1JmCBvrH8S3QrnZemLFuKQIxHC6cgf7JZ9o lWD4/Yaf7TH5gI7bAf6r1fjh7K46UhZIONcWSV1yKhuYQMrTXecbQ5EUhTJcUdIl57fr bo1Q== MIME-Version: 1.0 X-Received: by 10.182.8.70 with SMTP id p6mr1000432oba.90.1364246771959; Mon, 25 Mar 2013 14:26:11 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 14:26:11 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <8B4C063947CD794BB6FF90C78BAE9B321EFDEDC7@IMCMBX04.MITRE.ORG> References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> <8B4C063947CD794BB6FF90C78BAE9B321EFDEDC7@IMCMBX04.MITRE.ORG> Date: Mon, 25 Mar 2013 17:26:11 -0400 Message-ID: From: Richard Barnes To: "Peck, Michael A" Content-Type: multipart/alternative; boundary=f46d0444ea413b21c404d8c674a6 X-Gm-Message-State: ALoCoQmpPDpfzWvW9Nxxwwr9jevmsIrR8hbtEEhjbQdbWt61wJWlldJips1quOVA7w4JUWgI6aKa Cc: IETF JOSE WG , Juraj Somorovsky , Mike Jones , =JeffH , Tibor Jager , Brian Campbell , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 25 Mar 2013 21:26:14 -0000 --f46d0444ea413b21c404d8c674a6 Content-Type: text/plain; charset=ISO-8859-1 +1 Maybe we can't require that everyone implement the secure thing, but we can at least NOT require that people implement the insecure thing. --Richard On Mon, Mar 25, 2013 at 11:27 AM, Peck, Michael A wrote: > I'm not certain of the status of the "mandatory to implement" discussion, > but all of this seems like good reason for RSA1_5 to NOT be REQUIRED to > implement (Table in section 4.1 of draft-ietf-jose-json-web-algorithms). > RSA1_5 is easy to implement insecurely. There seem to be lots of caveats > that have to be followed to do it "securely", and do we actually know that > those will continue to be enough? > > Mike > > > >-----Original Message----- > >From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > >Vladimir Dzhuvinov / NimbusDS > >Sent: Monday, March 25, 2013 10:02 AM > >To: Brian Campbell; Juraj Somorovsky > >Cc: Tibor Jager; Mike Jones; IETF JOSE WG; =JeffH > >Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D > >Action: draft-ietf-jose-json-web-algorithms-02.txt) > > > >Hi guys, > > > >Just checked in a simple counter measure as suggested below, should > >become part of the new release, probably sometime later this week. > > > >https://bitbucket.org/nimbusds/nimbus-jose- > >jwt/src/da13ee89febda936b234a76da3f330e39970c240/src/main/java/com/ni > >mbusds/jose/crypto/RSADecrypter.java?at=master#cl-138 > > > >The actual random CMK generation also does take time to do, I suppose > >that also has to be measured and taken into account? > > > > > >Cheers, > > > >Vladimir > > > >-- > >Vladimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com > > > > > >-------- Original Message -------- > >Subject: Re: [jose] backwards compatibility attack on JWT impls (was: > >I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) > >From: Brian Campbell > >Date: Fri, March 15, 2013 8:03 pm > >To: Juraj Somorovsky > >Cc: Tibor Jager , Mike Jones > >, =JeffH > >, > >IETF JOSE WG > > > >+1 > > > > > >Thanks Juraj. > > > > > >On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky > > wrote: > > > > Generally, such an attack could be of course *mitigated* by generating > > random CMKs, when the RSA1_5 is invalid. Thus, I would propose to > > reference Eric's > > https://tools.ietf.org/rfc/rfc3218.txt > > in your security considerations. Maybe, it would be even better to > > explicitly sketch these countermeasures as done in TLS1.2 > > (http://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.) > > > > Regards > > Juraj > > > > > > > >_______________________________________________ > >jose mailing list > >jose@ietf.org > >https://www.ietf.org/mailman/listinfo/jose > >_______________________________________________ > >jose mailing list > >jose@ietf.org > >https://www.ietf.org/mailman/listinfo/jose > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --f46d0444ea413b21c404d8c674a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1=A0

Maybe we can't require that everyone implement= the secure thing, but we can at least NOT require that people implement th= e insecure thing.

--Richard



On Mon, Mar 25, 2013 at 11:27 AM, Peck, = Michael A <mpeck@mitre.org> wrote:
I'm not certain of the status of the "mandatory to implement"= discussion, but all of this seems like good reason for RSA1_5 to NOT be RE= QUIRED to implement (Table in section 4.1 of draft-ietf-jose-json-web-algor= ithms). =A0RSA1_5 is easy to implement insecurely. =A0There seem to be lots= of caveats that have to be followed to do it "securely", and do = we actually know that those will continue to be enough?

Mike


>-----Original Message-----
>From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>Vladimir Dzhuvinov / NimbusDS
>Sent: Monday, March 25, 2013 10:02 AM
>To: Brian Campbell; Juraj Somorovsky
>Cc: Tibor Jager; Mike Jones; IETF JOSE WG; =3DJeffH
>Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I= -D
>Action: draft-ietf-jose-json-web-algorithms-02.txt)
>
>Hi guys,
>
>Just checked in a simple counter measure as suggested below, should
>become part of the new release, probably sometime later this week.
>
>https://bitbucket.org/nimbusds/nimbus-jose-
>jwt/src/da13ee89febda936b234a76da3f330e39970c240/src/main/java/com/ni >mbusds/jose/crypto/RSADecrypter.java?at=3Dmaster#cl-138
>
>The actual random CMK generation also does take time to do, I suppose >that also has to be measured and taken into account?
>
>
>Cheers,
>
>Vladimir
>
>--
>Vladimir Dzhuvinov : www.NimbusDS.com : vladimi= r@nimbusds.com
>
>
>-------- Original Message --------
>Subject: Re: [jose] backwards compatibility attack on JWT impls (was: >I-D Action: draft-ietf-jose-json-web-algorithms-02.txt)
>From: Brian Campbell <= bcampbell@pingidentity.com>
>Date: Fri, March 15, 2013 8:03 pm
>To: Juraj Somorovsky <jur= aj.somorovsky@rub.de>
>Cc: Tibor Jager <tibor.jage= r@gmail.com>, Mike Jones
><Michael.Jones@micros= oft.com>, =3DJeffH
><Jeff.Hodges@kingsm= ountain.com>,
>IETF JOSE WG <jose@ietf.org>=
>
>+1
>
>
>Thanks Juraj.
>
>
>On Thu, Mar 14, 2013 at 5:52 PM, Juraj Somorovsky
><juraj.somorovsky@rub.de<= /a>> wrote:
>
> Generally, such an attack could be of course *mitigated* by generating=
> random CMKs, when the RSA1_5 is invalid. Thus, I would propose to
> reference Eric's
> h= ttps://tools.ietf.org/rfc/rfc3218.txt
> in your security considerations. Maybe, it would be even better to
> explicitly sketch these countermeasures as done in TLS1.2
> (htt= p://www.ietf.org/rfc/rfc5246.txt Section 7.4.7.1.)
>
> Regards
> Juraj
>
>
>
>_______________________________________________
>jose mailing list
>jose@ietf.org
>https://www.ietf.org/mailman/listinfo/jose
>_______________________________________________
>jose mailing list
>jose@ietf.org
>https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--f46d0444ea413b21c404d8c674a6-- From rlb@ipv.sx Mon Mar 25 14:30:46 2013 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 3AD5F21F83EF for ; Mon, 25 Mar 2013 14:30:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=-1.094, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 BWzkkV2n6nNb for ; Mon, 25 Mar 2013 14:30:44 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B74D521F8319 for ; Mon, 25 Mar 2013 14:30:44 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id ef5so3866884obb.41 for ; Mon, 25 Mar 2013 14:30:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=XQDk+1MGyIMutlgaRgl+/TivoGW5k57xyvyD7e8zw2w=; b=MyVfxw/hEBP2fowDTRjVOK1DWCaag6IQ4TLXMNPISJCy5SF79/RSXwoAVAARavF7SK pmhMUNYAMajaG5MrVpqC3Kc3vdAeELOAPLuaEcfXvDPaxQ+Ty6Sc8vWUsBpe3x7yiysF tW0fp0dx3d1yAHRpflSBnPik1n+G4aLxePq3SQgAyokbydAhnmxVmYKabaLFb2cCP24r YtSIiv8LrQIt92IicWw1R2zHb24fs7+n6YMAQE/3m78FmZ785ccFzYvhTgMh8SYjaDLJ TNT1eEEFBPmQA0HdrJqH9O4C5+gulol9jR/5Hvax9NTSpo3lB7sRP2rrq8h+mNgKIgS0 5wtw== MIME-Version: 1.0 X-Received: by 10.182.217.10 with SMTP id ou10mr1010762obc.30.1364247044246; Mon, 25 Mar 2013 14:30:44 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 14:30:44 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> Date: Mon, 25 Mar 2013 17:30:44 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=f46d0444709d75637904d8c684fe X-Gm-Message-State: ALoCoQkk5qEPEsm8RJ5/z9DlvtkXrqujI9lqzfeWG9uaqJu29sDSncYuwiq0dyWFwfPwoRPIuf62 Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, Jim Schaad , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 21:30:46 -0000 --f46d0444709d75637904d8c684fe Content-Type: text/plain; charset=ISO-8859-1 I realize that's the common case. But the spec doesn't say that. All I'm saying is, the spec should REQUIRE that a sender include either a key indicator, or an indication that something is going on out of band. --Richard On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell wrote: > /* special magic */ is just some out of band agreement on the key to use > or how to infer it. Which isn't really special or magic. But probably > pretty common. > > > On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: > >> I've renamed the issue to try to clarify. >> >> You're right that there are alternative ways to locate a key. But a JOSE >> object needs to contain at least one of them, or else the /* special magic >> */ clause applies. >> >> --Richard >> >> >> On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad wrote: >> >>> This may or may not be a flaw in the specification. However the item >>> you created in the tracker does not reflect what you have put here. I >>> think you would be better served by saying that there is a flaw in the >>> specifications in that there should be a MUST that some type of key or key >>> reference is required in a JWS or JWE.**** >>> >>> ** ** >>> >>> I would note that your example code should be more complex in that it >>> does not deal with jku or any of the x* methods of referencing keys.**** >>> >>> ** ** >>> >>> Jim**** >>> >>> ** ** >>> >>> ** ** >>> >>> *From:* Richard Barnes [mailto:rlb@ipv.sx] >>> *Sent:* Friday, March 22, 2013 4:09 PM >>> *To:* Jim Schaad >>> *Cc:* draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org >>> >>> *Subject:* Re: [jose] #15: Broken examples in JWE / JWS**** >>> >>> ** ** >>> >>> I admit that they are not broken according to the current spec. >>> However, I have a lot of trouble figuring out how I would write code to >>> process them.**** >>> >>> ** ** >>> >>> If "kid" or "jwk" MUST be present to indicate what key I should use, >>> then I can have deterministic code:**** >>> >>> if (/* recognized "kid" or "jwk" value */) { **** >>> >>> /* use it */**** >>> >>> } else {**** >>> >>> /* FAIL. can't process this object */**** >>> >>> }**** >>> >>> ** ** >>> >>> As the spec stands, I have no idea what to put in that "else" clause. >>> I'm clearly not supposed to fail, because the parameters are optional. >>> But what else?**** >>> >>> if (/* recognized "kid" or "jwk" value */) { **** >>> >>> /* use it */**** >>> >>> } else {**** >>> >>> /* insert special magic here */**** >>> >>> }**** >>> >>> ** ** >>> >>> This is actually what SPI is supposed to clear up. SPI would provide an >>> explicit third branch for the special magic to live in.**** >>> >>> if (/* recognized "kid" or "jwk" value */) { **** >>> >>> /* use it */**** >>> >>> } else if (/* recognized SPI value */) {**** >>> >>> /* process using stored parameters */**** >>> >>> } else {**** >>> >>> /* FAIL. can't process this object */**** >>> >>> }**** >>> >>> ** ** >>> >>> But without the concept of SPI, the spec is broken because of the >>> non-determinism noted above.**** >>> >>> ** ** >>> >>> --Richard**** >>> >>> ** ** >>> >>> ** ** >>> >>> ** ** >>> >>> On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad >>> wrote:**** >>> >>> My inclination is that this response is correct. >>> >>> What make you think that the key or key reference is required and cannot >>> be >>> implied? >>> >>> Jim**** >>> >>> >>> >>> > -----Original Message----- >>> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf >>> Of >>> > jose issue tracker >>> > Sent: Friday, March 22, 2013 2:37 PM >>> > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; >>> ignisvulpis@gmail.com >>> > Cc: jose@ietf.org >>> > Subject: Re: [jose] #15: Broken examples in JWE / JWS >>> > >>> > #15: Broken examples in JWE / JWS >>> > >>> > >>> > Comment (by ignisvulpis@gmail.com): >>> > >>> > I think this is not an issue. The examples are NOT broken and they do >>> not >>> > need a fix. >>> > I suggest to close this ticket. >>> > The draft should definitely not make these illegal. These objects are >>> perfect >>> > examples for a valid JWS/JWE. >>> > >>> > -- >>> > >>> -------------------------+---------------------------------------------- >>> **** >>> >>> > -------------------------+---**** >>> >>> > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- >>> > Type: defect | encryption@tools.ietf.org >>> > Priority: minor | Status: new >>> > Component: json-web- | Milestone: >>> > encryption | Version: >>> > Severity: - | Resolution: >>> > Keywords: | >>> > >>> -------------------------+---------------------------------------------- >>> **** >>> >>> > -------------------------+---**** >>> >>> > >>> > Ticket URL: < >>> http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:1> >>> > jose >>> > >>> > _______________________________________________ >>> > jose mailing list >>> > jose@ietf.org >>> > https://www.ietf.org/mailman/listinfo/jose**** >>> >>> ** ** >>> >> >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> >> > --f46d0444709d75637904d8c684fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I realize that's the common case. =A0But the spec doesn't say that.= =A0

All I'm saying is, the spec should REQUIRE that= a sender include=A0either a key indicator, or an indication that something= is going on out of band.

--Richard



On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <bcampbell@pingidentity.com> wrote:
/* special magic */ is jus= t some out of band agreement on the key to use or how to infer it. Which is= n't really special or magic. But probably pretty common.

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <rlb@ipv.sx> wrote:=
I've renamed the issue to try to clarify.

You're= right that there are alternative ways to locate a key. =A0But a JOSE objec= t needs to contain at least one of them, or else the /* special magic */ cl= ause applies. =A0

--Richard


On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <= ietf@augustcellars.com> wrote:

This may or m= ay not be a flaw in the specification.=A0 However the item you created in t= he tracker does not reflect what you have put here.=A0 I think you would be= better served by saying that there is a flaw in the specifications in that= there should be a MUST that some type of key or key reference is required = in a JWS or JWE.

=A0<= /p>

I would note that your= example code should be more complex in that it does not deal with jku or a= ny of the x* methods of referencing keys.

=A0<= /p>

Jim

=A0<= /p>

=A0

From:= Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
= Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org= ; jose@ietf.org


Subject: Re: [jose] #15: Broken examples in JWE / JWS<= u>

=A0

I admit that they are not bro= ken according to the current spec. =A0However, I have a lot of trouble figu= ring out how I would write code to process them.

=A0

If "kid" or "jwk" MUST be present to indicate w= hat key I should use, then I can have deterministic code:

=

if (/* recognized "kid" or "jwk&= quot; value */) {=A0

=A0= =A0 /* use it */

} else= {

=A0 =A0 /* FAIL. =A0can't process thi= s object */

}<= /u>

=A0

As the spec stands, I have no idea what to put in that "else" cla= use. =A0I'm clearly not supposed to fail, because the parameters are op= tional. =A0But what else?

if (/* recognized "kid" or "jwk" value */) {=A0<= u>

=A0 =A0 /* use it */<= /u>

} else {

=A0 =A0 /* insert special magic here */

}

= =A0

This is actually wha= t SPI is supposed to clear up. =A0SPI would provide an explicit third branc= h for the special magic to live in.

if (/* recognized "kid" or= "jwk" value */) {=A0

=A0 =A0 /* use it */

} else if (/* recognized SPI value */) {

=A0 =A0 /* process using stored parameter= s */

} else {<= /u>

=A0 =A0 /* FAIL. =A0can't proc= ess this object */

}

=A0

Bu= t without the concept of SPI, the spec is broken because of the non-determi= nism noted above.

=A0

--Richard

=A0

=A0

=A0

=

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <= ;ietf@augustcel= lars.com> wrote:

My inclination is that this response is correct.
=
What make you think that the key or key reference is required and canno= t be
implied?

Jim



> -----Original Message-----
>= From: jose-boun= ces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
>= ; To: draft-ietf-jose-json-web-encryption@tools.ietf.org;<= br> ignisvulpis@gmai= l.com
> Cc: jo= se@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / J= WS
>
> #15: Broken examples in JWE / JWS
>
>
> Comm= ent (by ignisvul= pis@gmail.com):
>
> =A0I think this is not an issue. The ex= amples are NOT broken and they do not
> need a fix.
> =A0I suggest to close this ticket.
> =A0The = draft should definitely not make these illegal. These objects are
perfec= t
> examples for a valid JWS/JWE.
>
> --
> --------= -----------------+----------------------------------------------<= /u>

> -------------------------+---

> =A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draf= t-ietf-jose-json-web-
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> = =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Co= mponent: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0S= everity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> =A0Keywords: = =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+-----------= -----------------------------------

> -------------------------+---

><= br>> Ticket URL: <http://trac.tools.ietf.org/wg/jose/t= rac/ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> __________________________= _____________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

=A0



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--f46d0444709d75637904d8c684fe-- From rlb@ipv.sx Mon Mar 25 14:34:30 2013 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 06A2621F8539 for ; Mon, 25 Mar 2013 14:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.428 X-Spam-Level: X-Spam-Status: No, score=-1.428 tagged_above=-999 required=5 tests=[AWL=-1.003, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 kTJCo4yWaEQK for ; Mon, 25 Mar 2013 14:34:28 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2760821F8536 for ; Mon, 25 Mar 2013 14:34:28 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id tb18so6524692obb.3 for ; Mon, 25 Mar 2013 14:34:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=wm0Q9cU5FtqhLU4lDGa5Jqu4179W/h/6uTUY+pS4iWo=; b=SbPJx3OBphHkuWR2z+EkB7mS62sVy4iH4X6eGNzGthbHbstIJfPo48n1tOHY9xkH4F +m0yMTXKmsCS+3jH90v4ULKnR7oEp+NWtsKVFymROFZW453IHIYsj7a/iJNCXV/A71UJ GHCDKG17AuQ31U4N1hIDl/l03FAFMna3OjxMVH/O7z8qN+kNPg5FHBcmhbnSKU3Z7WA2 DJExuVtd8sjFIdU7gnuFsI6fhpHRKoFMYM3S1EzD64qMeU1WdsT6uGCIs5HZFAnF/Ygf pfCOILtlcE8R/glOT1vjtA0alPa46sSdf39h9sK8bfJZL5TA8UxmQimH23h4u/gg+ZV8 1HLQ== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr12042533oec.125.1364247262995; Mon, 25 Mar 2013 14:34:22 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 14:34:22 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <513E774C.6090605@isoc.org> References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> Date: Mon, 25 Mar 2013 17:34:22 -0400 Message-ID: From: Richard Barnes To: odonoghue@isoc.org Content-Type: multipart/alternative; boundary=bcaec54b48127f41e904d8c69179 X-Gm-Message-State: ALoCoQmjsOlqMWnkrZLvMTVc7mXelekhxag7aQjsqJ+WzeVXr35PRf3CTPEw3eZ9Y+MVQqJGwat3 Cc: jose@ietf.org Subject: Re: [jose] Proposed resolution of header criticality issue 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, 25 Mar 2013 21:34:30 -0000 --bcaec54b48127f41e904d8c69179 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trying to move this to closure... It sounds to me like there was general agreement on points 1-4. Can someone file an issue for #5 and ask the editor to implement 1-4? Thanks, --Richard On Mon, Mar 11, 2013 at 8:31 PM, Karen O'Donoghue wrote= : > > Folks, > > A side meeting was held Sunday with a number of jose working group > participants to try to resolve the open issue related to header > criticality. The following are the proposed resolutions from the meeting. > Point 5 of the proposed resolution below is actually independent of the > other 4 points, and could be considered separately. This will all be > discussed in Wednesday's meeting. > > In addition to the text below, there was some agreement to replace the > "understand" text with something a bit more explicit like "must process". > However, that text has not been rolled into the summary text below yet. > > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin > Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts > (and my apologies if I missed someone). > > Regards, > Karen > > 1: Change the language =93Additional members MAY be present in the JWK. = If > present, they MUST be understood by implementations using them.=94 to > =93Additional members MAY be present in the JWK. If not understood by > implementations encountering them, they MUST be ignored.=94 (And make th= e > same change for JWK Set as well.)******** > > 2: Characterize all existing JWS and JWE header fields as either must be > understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 must b= e understood. > =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ= =94, and =93cty=94 can be ignored > because while not using them may result in the inability to process some > signatures or encrypted content, this will not result in a security > violation =96 just degraded functionality. Other fields such as =93epk= =94, > =93apu=94, =93apv=94, =93epu=94, and =93epv=94 must be understood and use= d when =93alg=94 or > =93enc=94 values requiring them are used, and otherwise they may be ignor= ed.** > ** > **** > 3. Define a new header field that lists which additional fields not > defined in the base specifications must be understood and acted upon when > present. For instance, an expiration-time extension field could be marke= d > as must-be-understood-and-acted-upon. One possible name for this would b= e > =93crit=94 (critical). An example use, along with a hypothetical =93exp= =94 > (expiration-time) field is:**** > > {"alg":"ES256",**** > "crit":["exp"],**** > "exp=94:1363284000**** > }**** > **** > 4. All additional header fields not defined in the base specifications > and not contained in the =93crit=94 list MUST be ignored if not understoo= d.*** > ***** > > 5. Define a new header field =93asd=94 (application-specific data) whose > value is a JSON structure whose contents are opaque to and ignored by JWS > and JWE implementations but for which its contents MUST be provided to > applications using JWS or JWE, provided that the signature/MAC validation > or decryption operation succeeds. The intended use of this field is to > have a standard place to provide application-specific metadata about the > payload or plaintext.**** > **** > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec54b48127f41e904d8c69179 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Trying to move this to closure...

It sounds to me like t= here was general agreement on points 1-4. =A0Can someone file an issue for = #5 and ask the editor to implement 1-4?

Thanks,
--Richard



= On Mon, Mar 11, 2013 at 8:31 PM, Karen O'Donoghue <= ;odonoghue@isoc.org= > wrote:
=20 =20 =20

Folks,

A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has no= t been rolled into the summary text below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone).

Regards,
Karen

1:=A0 Change the language =93Additional members MAY be present in the JWK. =A0If present, they MUST be understood by implementations using them.=94 to =93Additional members MAY be present in the JWK. =A0If not understood by implementations encountering them, they MUST be ignored.=94=A0 (And make the same change for JWK Set as well.)

2:=A0 Characterize all existing JWS and JWE header fields as either must be understood or may be ignored.=A0 =93alg=94, =93enc= =94, and =93zip=94 must be understood.=A0 =93kid=94, =93x5u=94, =93x5c= =94, =93x5t=94, =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored bec= ause while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation =96 just degraded functionality.=A0 Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and = =93epv=94 must be understood and used when =93alg=94 or =93enc=94 values requiring = them are used, and otherwise they may be ignored.

3.=A0 Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present.=A0 For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon.=A0 One possible name for this would be =93crit=94 (critical).=A0 An example use, along with a hypothetical =93exp=94 (expiration-time) field is:<= br>
=A0 {"alg":"ES256",
=A0=A0 "crit":["exp"],
=A0=A0 "exp=94:1363284000
=A0 }

4.=A0 All additional header fields not defined in the base specifications and not contained in the =93crit=94 list MUST be ignored if not understood.

5.=A0 Define a new header field =93asd=94 (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.=A0 The intended use of this field is to have a standard place to provide application-specific metadata about the payload or plaintext.




_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec54b48127f41e904d8c69179-- From Michael.Jones@microsoft.com Mon Mar 25 14:55:26 2013 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 123C321F870F for ; Mon, 25 Mar 2013 14:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 VHRb-811Q7uO for ; Mon, 25 Mar 2013 14:55:24 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0207.outbound.protection.outlook.com [207.46.163.207]) by ietfa.amsl.com (Postfix) with ESMTP id E07AC21F86AF for ; Mon, 25 Mar 2013 14:55:23 -0700 (PDT) Received: from BL2FFO11FD028.protection.gbl (10.1.15.200) by BY2FFO11HUB013.protection.gbl (10.1.14.85) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 21:55:19 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD028.mail.protection.outlook.com (10.173.161.107) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 21:55:18 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 21:54:53 +0000 From: Mike Jones To: Richard Barnes , Brian Campbell Thread-Topic: [jose] #15: Broken examples in JWE / JWS Thread-Index: AQHOJ0GRGLcBFTS/L0CrF4Bh9JphKZiyPD8AgAAKWICAAA89AIAAI4YAgAAGLwCAA9bwAIAAmwcAgAAGaeA= Date: Mon, 25 Mar 2013 21:54:52 +0000 Message-ID: <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> In-Reply-To: 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_4E1F6AAD24975D4BA5B1680429673943675886B8TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(189002)(24454001)(51704002)(199002)(5343655001)(63696002)(53806001)(74662001)(79102001)(49866001)(51856001)(77982001)(512954001)(76482001)(5343635001)(54316002)(20776003)(55846006)(47446002)(54356001)(47736001)(33656001)(15202345001)(31966008)(74502001)(56816002)(47976001)(44976002)(66066001)(59766001)(16406001)(80022001)(50986001)(46102001)(4396001)(69226001)(71186001)(65816001)(16236675001)(56776001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB013; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Jim Schaad , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 21:55:26 -0000 --_000_4E1F6AAD24975D4BA5B1680429673943675886B8TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you already know that something is going on out of band, the indication = in the JOSE object would be unnecessary. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, March 25, 2013 2:31 PM To: Brian Campbell Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; jose@ie= tf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I realize that's the common case. But the spec doesn't say that. All I'm saying is, the spec should REQUIRE that a sender include either a k= ey indicator, or an indication that something is going on out of band. --Richard On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell > wrote: /* special magic */ is just some out of band agreement on the key to use or= how to infer it. Which isn't really special or magic. But probably pretty = common. On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes > wrote: I've renamed the issue to try to clarify. You're right that there are alternative ways to locate a key. But a JOSE o= bject needs to contain at least one of them, or else the /* special magic *= / clause applies. --Richard On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad > wrote: This may or may not be a flaw in the specification. However the item you c= reated in the tracker does not reflect what you have put here. I think you= would be better served by saying that there is a flaw in the specification= s in that there should be a MUST that some type of key or key reference is = required in a JWS or JWE. I would note that your example code should be more complex in that it does = not deal with jku or any of the x* methods of referencing keys. Jim From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, March 22, 2013 4:09 PM To: Jim Schaad Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I admit that they are not broken according to the current spec. However, I= have a lot of trouble figuring out how I would write code to process them. If "kid" or "jwk" MUST be present to indicate what key I should use, then I= can have deterministic code: if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* FAIL. can't process this object */ } As the spec stands, I have no idea what to put in that "else" clause. I'm = clearly not supposed to fail, because the parameters are optional. But wha= t else? if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* insert special magic here */ } This is actually what SPI is supposed to clear up. SPI would provide an ex= plicit third branch for the special magic to live in. if (/* recognized "kid" or "jwk" value */) { /* use it */ } else if (/* recognized SPI value */) { /* process using stored parameters */ } else { /* FAIL. can't process this object */ } But without the concept of SPI, the spec is broken because of the non-deter= minism noted above. --Richard On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad > wrote: My inclination is that this response is correct. What make you think that the key or key reference is required and cannot be implied? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of > jose issue tracker > Sent: Friday, March 22, 2013 2:37 PM > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; ignisvulpis@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > #15: Broken examples in JWE / JWS > > > Comment (by ignisvulpis@gmail.com): > > I think this is not an issue. The examples are NOT broken and they do no= t > need a fix. > I suggest to close this ticket. > The draft should definitely not make these illegal. These objects are perfect > examples for a valid JWS/JWE. > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jo= se-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B1680429673943675886B8TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you already know that = something is going on out of band, the indication in the JOSE object would = be unnecessary.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 2:31 PM
To: Brian Campbell
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org
Subject: Re: [jose] #15: Broken examples in JWE / JWS

 

I realize that's the common case.  But the spec= doesn't say that.  

 

All I'm saying is, the spec should REQUIRE that a se= nder include either a key indicator, or an indication that something i= s going on out of band.

 

--Richard

 

 

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

/* special magic */ is just some out of band agreeme= nt on the key to use or how to infer it. Which isn't really special or magi= c. But probably pretty common.

 

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <= rlb@ipv.sx> wrote:

I've renamed the issue to try to clarify.=

 

You're right that there are alternative ways to loca= te a key.  But a JOSE object needs to contain at least one of them, or= else the /* special magic */ clause applies.  

 

--Richard

 

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

This may or may not be a flaw in the sp= ecification.  However the item you created in the tracker does not reflect what you have put here.  I think you would be better= served by saying that there is a flaw in the specifications in that there = should be a MUST that some type of key or key reference is required in a JW= S or JWE.

 

I would note that your example code sho= uld be more complex in that it does not deal with jku or any of the x* methods of referencing keys.

 

Jim

 

 

From: Richard Barnes [mailto= :rlb@ipv.sx]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org


Subject: Re: [jose] #15: Broken examples in JWE / JWS

 

I admit that they are not broken according to the current spec. &n= bsp;However, I have a lot of trouble figuring out how I would write code to= process them.

 

If "kid" or "jwk" MUST be present to indicate = what key I should use, then I can have deterministic code:

if (/* recognized "kid" or "jwk" value */) {&n= bsp;

    /* use it */

} else {

    /* FAIL.  can't process this object */

}

 

As the spec stands, I have no idea what to put in that "else&= quot; clause.  I'm clearly not supposed to fail, because the parameter= s are optional.  But what else?

if (/* recognized "kid" or "jwk" value */) {&n= bsp;

    /* use it */

} else {

    /* insert special magic here */

}

 

This is actually what SPI is supposed to clear up.  SPI would= provide an explicit third branch for the special magic to live in.

if (/* recognized "kid" or "jwk" value */) {&n= bsp;

    /* use it */

} else if (/* recognized SPI value */) {

    /* process using stored parameters */

} else {

    /* FAIL.  can't process this object */

}

 

But without the concept of SPI, the spec is broken because of the = non-determinism noted above.

 

--Richard

 

 

 

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wr= ote:

My inclination is that this response is correct.

What make you think that the key or key reference is required and cannot be=
implied?

Jim



> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: draft-ietf-jose-json-web-encryption@tools.ietf.org;
ignisvulpis@gmai= l.com
> Cc: jose@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken examples in JWE / JWS
>
>
> Comment (by ignisvulpis@gmail.com):
>
>  I think this is not an issue. The examples are NOT broken and th= ey do not
> need a fix.
>  I suggest to close this ticket.
>  The draft should definitely not make these illegal. These object= s are
perfect
> examples for a valid JWS/JWE.
>
> --
> -------------------------+----------------------------------------= ------

> -------------------------+---

>  Reporter:  rlb@ipv.sx   |       Owner:  draft-ie= tf-jose-json-web-
>      Type:  defect       |  encryption@too= ls.ietf.org
>  Priority:  minor        |    =  Status:  new
> Component:  json-web-    |   Milestone:
>   encryption             |   &= nbsp; Version:
>  Severity:  -            | &nb= sp;Resolution:
>  Keywords:               |
> -------------------------+----------------------------------------= ------

> -------------------------+---

>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac= /ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose

 

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

 

--_000_4E1F6AAD24975D4BA5B1680429673943675886B8TK5EX14MBXC283r_-- From ietf@augustcellars.com Mon Mar 25 15:00:02 2013 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 D401021F8640 for ; Mon, 25 Mar 2013 15:00:01 -0700 (PDT) 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 yHG4vr-O7Q4J for ; Mon, 25 Mar 2013 15:00:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE1F21F8610 for ; Mon, 25 Mar 2013 15:00:00 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D2E532CA08; Mon, 25 Mar 2013 14:59:59 -0700 (PDT) From: "Jim Schaad" To: "'Richard Barnes'" , "'Brian Campbell'" References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> In-Reply-To: Date: Mon, 25 Mar 2013 14:59:24 -0700 Message-ID: <025e01ce29a4$039f7400$0ade5c00$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025F_01CE2969.5745F330" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF2cmojIl9Hs38WmUYs74iwLrRDCgIF6v1oAm/xY+kByW55fwH282dKArcIyZEB7CexKAJP1D4JmO0Yu3A= Content-Language: en-us Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org, jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:00:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025F_01CE2969.5745F330 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It may need to be noted that doing /* special magic */ is not something that a library would ever be able to do. This implies that the application needs to know that this is going to be the case and know how to pass in all of the relevant keys as part of the signature/mac verification process or the decryption process. Jim From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Monday, March 25, 2013 2:31 PM To: Brian Campbell Cc: Jim Schaad; draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I realize that's the common case. But the spec doesn't say that. All I'm saying is, the spec should REQUIRE that a sender include either a key indicator, or an indication that something is going on out of band. --Richard On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell wrote: /* special magic */ is just some out of band agreement on the key to use or how to infer it. Which isn't really special or magic. But probably pretty common. On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: I've renamed the issue to try to clarify. You're right that there are alternative ways to locate a key. But a JOSE object needs to contain at least one of them, or else the /* special magic */ clause applies. --Richard On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad wrote: This may or may not be a flaw in the specification. However the item you created in the tracker does not reflect what you have put here. I think you would be better served by saying that there is a flaw in the specifications in that there should be a MUST that some type of key or key reference is required in a JWS or JWE. I would note that your example code should be more complex in that it does not deal with jku or any of the x* methods of referencing keys. Jim From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, March 22, 2013 4:09 PM To: Jim Schaad Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I admit that they are not broken according to the current spec. However, I have a lot of trouble figuring out how I would write code to process them. If "kid" or "jwk" MUST be present to indicate what key I should use, then I can have deterministic code: if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* FAIL. can't process this object */ } As the spec stands, I have no idea what to put in that "else" clause. I'm clearly not supposed to fail, because the parameters are optional. But what else? if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* insert special magic here */ } This is actually what SPI is supposed to clear up. SPI would provide an explicit third branch for the special magic to live in. if (/* recognized "kid" or "jwk" value */) { /* use it */ } else if (/* recognized SPI value */) { /* process using stored parameters */ } else { /* FAIL. can't process this object */ } But without the concept of SPI, the spec is broken because of the non-determinism noted above. --Richard On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad wrote: My inclination is that this response is correct. What make you think that the key or key reference is required and cannot be implied? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > jose issue tracker > Sent: Friday, March 22, 2013 2:37 PM > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; ignisvulpis@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > #15: Broken examples in JWE / JWS > > > Comment (by ignisvulpis@gmail.com): > > I think this is not an issue. The examples are NOT broken and they do not > need a fix. > I suggest to close this ticket. > The draft should definitely not make these illegal. These objects are perfect > examples for a valid JWS/JWE. > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose ------=_NextPart_000_025F_01CE2969.5745F330 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It may need to be noted that doing /* special magic */ is not = something that a library would ever be able to do.  This implies = that the application needs to know that this is going to be the case and = know how to pass in all of the relevant keys as part of the = signature/mac verification process or the decryption = process.

 

Jim

 

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Monday, March 25, = 2013 2:31 PM
To: Brian Campbell
Cc: Jim Schaad; = draft-ietf-jose-json-web-encryption@tools.ietf.org; = jose@ietf.org
Subject: Re: [jose] #15: Broken examples in JWE = / JWS

 

I realize = that's the common case.  But the spec doesn't say that. =  

 

All I'm saying is, the spec should REQUIRE that a = sender include either a key indicator, or an indication that = something is going on out of band.

 

--Richard

 

 

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

/* special magic */ is = just some out of band agreement on the key to use or how to infer it. = Which isn't really special or magic. But probably pretty = common.

 

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <rlb@ipv.sx> = wrote:

I've renamed the issue to try = to clarify.

 

You're right that there are alternative ways to locate = a key.  But a JOSE object needs to contain at least one of them, or = else the /* special magic */ clause applies. =  

 

--Richard

 

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <ietf@augustcellars.com> = wrote:

This may or may not be a flaw in the specification.  However the = item you created in the tracker does not reflect what you have put = here.  I think you would be better served by saying that there is a = flaw in the specifications in that there should be a MUST that some type = of key or key reference is required in a JWS or = JWE.

 

I would note that your example code should be more complex in that it = does not deal with jku or any of the x* methods of referencing = keys.

 

Jim

 

 

From:= = Richard Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, = 2013 4:09 PM
To: Jim Schaad
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org;= jose@ietf.org


Subject: Re: [jose] #15: Broken examples in = JWE / JWS

 <= /o:p>

I admit = that they are not broken according to the current spec.  However, I = have a lot of trouble figuring out how I would write code to process = them.

 <= /o:p>

If = "kid" or "jwk" MUST be present to indicate what key = I should use, then I can have deterministic = code:

if (/* = recognized "kid" or "jwk" value */) = { 

  =   /* use it */

} else = {

  =   /* FAIL.  can't process this object = */

}=

 <= /o:p>

As the spec = stands, I have no idea what to put in that "else" clause. =  I'm clearly not supposed to fail, because the parameters are = optional.  But what else?

if (/* = recognized "kid" or "jwk" value */) = { 

  =   /* use it */

} else = {

  =   /* insert special magic here */

}=

 <= /o:p>

This is = actually what SPI is supposed to clear up.  SPI would provide an = explicit third branch for the special magic to live = in.

if (/* = recognized "kid" or "jwk" value */) = { 

  =   /* use it */

} else if = (/* recognized SPI value */) {

  =   /* process using stored parameters */

} else = {

  =   /* FAIL.  can't process this object = */

}=

 <= /o:p>

But without = the concept of SPI, the spec is broken because of the non-determinism = noted above.

 <= /o:p>

--Richard

 <= /o:p>

 <= /o:p>

 <= /p>

On Fri, Mar = 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:

My = inclination is that this response is correct.

What make you think = that the key or key reference is required and cannot = be
implied?

Jim



>= -----Original Message-----
> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose = issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: = draft-ietf-jose-json-web-encryption@tools.ietf.org;=
ignisvulpis@gmail.com
> Cc: jose@ietf.org
> Subject: Re: [jose] #15: = Broken examples in JWE / JWS
>
> #15: Broken examples in JWE = / JWS
>
>
> Comment (by ignisvulpis@gmail.com):
>
>  I = think this is not an issue. The examples are NOT broken and they do = not
> need a fix.
>  I suggest to close this = ticket.
>  The draft should definitely not make these = illegal. These objects are
perfect
> examples for a valid = JWS/JWE.
>
> --
> = -------------------------+----------------------------------------------<= o:p>

> = -------------------------+---

> =  Reporter:  rlb@ipv.sx   |       Owner: =  draft-ietf-jose-json-web-
>      Type: =  defect       |  encryption@tools.ietf.org
>  Priority: =  minor        |      Status: =  new
> Component:  json-web-    |   = Milestone:
>   encryption           =   |     Version:
>  Severity:  -   =          |  Resolution:
> =  Keywords:               = |
> = -------------------------+----------------------------------------------<= o:p>

> = -------------------------+---

>
> = Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comme= nt:1>
> jose <http://tools.ietf.org/jose/>
>
> = _______________________________________________
> jose mailing = list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

 <= /o:p>

 


______________________________________= _________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

 

------=_NextPart_000_025F_01CE2969.5745F330-- From rlb@ipv.sx Mon Mar 25 15:05:14 2013 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 981D321F8904 for ; Mon, 25 Mar 2013 15:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=-0.849, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 zPAVaLN5kA88 for ; Mon, 25 Mar 2013 15:05:13 -0700 (PDT) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 25C7E21F8903 for ; Mon, 25 Mar 2013 15:05:13 -0700 (PDT) Received: by mail-ob0-f181.google.com with SMTP id ni5so6467023obc.26 for ; Mon, 25 Mar 2013 15:05:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=SW2CUx71JiOkbWMkXRaPHQxR+yWqEo6TD4qcmwrwlGQ=; b=QyFPnLp1Eqd0Tm7AoaHOSudNrK9HTWTbpUH11rpRpCLgSBEQVgWgsssCaGptL+QlT8 dYQejW2yuTDLzegTSPf1Tq09+X6aDwaW3PX1GzC6HktWZwwgbcfJBAZu0okgnrM+GYjG wMWKS5ehRtmI/PO0xjilFQcj5bP1RAmY2g1JNtklX4kLeI/YSu2P4Zy/QJl+56Fc50NM UTXFeOBLaXjr6dZ3GcKpDbGHQz92KqZkQMjdP7T6X1/wGVIiGPyR8mK0zkzBG1tAUvtz qWmMZylsFQH0boXGWS2XEY/HXrJUxLXQYmuQ4xqFcH3/5nSXj6wByI9L6FdLTF/MbiL6 sKSA== MIME-Version: 1.0 X-Received: by 10.182.132.43 with SMTP id or11mr1072557obb.67.1364249112593; Mon, 25 Mar 2013 15:05:12 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 15:05:12 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 25 Mar 2013 18:05:12 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=14dae93a0c17be18c704d8c6ffbf X-Gm-Message-State: ALoCoQmxqEiohaSyAkzpOsVHsivbGhQ+qYhpWJUIxQ3po/26VcRyfqoIXluDPQjiNXWXK9TR/jWz Cc: "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Jim Schaad , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:05:14 -0000 --14dae93a0c17be18c704d8c6ffbf Content-Type: text/plain; charset=ISO-8859-1 IF your application is always doing something out of band, and IF every JOSE object you ever receive uses the same out of band channel, and IF the JOSE library can locate the pre-negotiated parameters based on something other than the JOSE object, .... You can see where I'm going with this. In order for just leaving things out to be workable, you have to bake some of that out-of-band logic into your JOSE library. In which case it's not really out-of-band any more, and we should specify it. And clearly specifying security negotiation protocol is not in scope for this group. If you have an explicit marking (e.g., SPI), there's a clean interface between the stuff that only knows JOSE and stuff that does negotiation. (BTW, +1 to what Jim said) On Mon, Mar 25, 2013 at 5:54 PM, Mike Jones wrote: > If you already know that something is going on out of band, the > indication in the JOSE object would be unnecessary.**** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, March 25, 2013 2:31 PM > *To:* Brian Campbell > *Cc:* draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; > jose@ietf.org > > *Subject:* Re: [jose] #15: Broken examples in JWE / JWS**** > > ** ** > > I realize that's the common case. But the spec doesn't say that. **** > > ** ** > > All I'm saying is, the spec should REQUIRE that a sender include either a > key indicator, or an indication that something is going on out of band.*** > * > > ** ** > > --Richard**** > > ** ** > > ** ** > > On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell < > bcampbell@pingidentity.com> wrote:**** > > /* special magic */ is just some out of band agreement on the key to use > or how to infer it. Which isn't really special or magic. But probably > pretty common.**** > > ** ** > > On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote:**** > > I've renamed the issue to try to clarify.**** > > ** ** > > You're right that there are alternative ways to locate a key. But a JOSE > object needs to contain at least one of them, or else the /* special magic > */ clause applies. **** > > ** ** > > --Richard**** > > ** ** > > On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad > wrote:**** > > This may or may not be a flaw in the specification. However the item you > created in the tracker does not reflect what you have put here. I think > you would be better served by saying that there is a flaw in the > specifications in that there should be a MUST that some type of key or key > reference is required in a JWS or JWE.**** > > **** > > I would note that your example code should be more complex in that it does > not deal with jku or any of the x* methods of referencing keys.**** > > **** > > Jim**** > > **** > > **** > > *From:* Richard Barnes [mailto:rlb@ipv.sx] > *Sent:* Friday, March 22, 2013 4:09 PM > *To:* Jim Schaad > *Cc:* draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org*** > * > > > *Subject:* Re: [jose] #15: Broken examples in JWE / JWS**** > > **** > > I admit that they are not broken according to the current spec. However, > I have a lot of trouble figuring out how I would write code to process them. > **** > > **** > > If "kid" or "jwk" MUST be present to indicate what key I should use, then > I can have deterministic code:**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else {**** > > /* FAIL. can't process this object */**** > > }**** > > **** > > As the spec stands, I have no idea what to put in that "else" clause. I'm > clearly not supposed to fail, because the parameters are optional. But > what else?**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else {**** > > /* insert special magic here */**** > > }**** > > **** > > This is actually what SPI is supposed to clear up. SPI would provide an > explicit third branch for the special magic to live in.**** > > if (/* recognized "kid" or "jwk" value */) { **** > > /* use it */**** > > } else if (/* recognized SPI value */) {**** > > /* process using stored parameters */**** > > } else {**** > > /* FAIL. can't process this object */**** > > }**** > > **** > > But without the concept of SPI, the spec is broken because of the > non-determinism noted above.**** > > **** > > --Richard**** > > **** > > **** > > **** > > On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad > wrote:**** > > My inclination is that this response is correct. > > What make you think that the key or key reference is required and cannot be > implied? > > Jim**** > > > > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of > > jose issue tracker > > Sent: Friday, March 22, 2013 2:37 PM > > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; > ignisvulpis@gmail.com > > Cc: jose@ietf.org > > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > > > #15: Broken examples in JWE / JWS > > > > > > Comment (by ignisvulpis@gmail.com): > > > > I think this is not an issue. The examples are NOT broken and they do > not > > need a fix. > > I suggest to close this ticket. > > The draft should definitely not make these illegal. These objects are > perfect > > examples for a valid JWS/JWE. > > > > -- > > -------------------------+---------------------------------------------- > **** > > > -------------------------+---**** > > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: minor | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > -------------------------+---------------------------------------------- > **** > > > -------------------------+---**** > > > > > Ticket URL: > > > jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose**** > > **** > > ** ** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > ** ** > --14dae93a0c17be18c704d8c6ffbf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
IF your application is always doing something out of band, and IF ever= y JOSE object you ever receive uses the same out of band channel, and IF th= e JOSE library can locate the pre-negotiated parameters based on something = other than the JOSE object, ....

You can see where I'm going with this. =A0In order = for just leaving things out to be workable, you have to bake some of that o= ut-of-band logic into your JOSE library. =A0In which case it's not real= ly out-of-band any more, and we should specify it. =A0And clearly specifyin= g security negotiation protocol is not in scope for this group.

If you have an explicit marking (e.g., SPI), there'= s a clean interface between the stuff that only knows JOSE and stuff that d= oes negotiation. =A0

(BTW, +1 to what Jim said)



On Mon, Mar 25= , 2013 at 5:54 PM, Mike Jones <Michael.Jones@microsoft.com&g= t; wrote:

If you already know that = something is going on out of band, the indication in the JOSE object would = be unnecessary.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 2:31 PM
To: Brian Campbell
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org<= /a>; Jim Schaad; jose@ie= tf.org


Subject: Re: [jose] #15: Broken examples in JWE / JWS<= /div>

=A0

I realize that's the common case. =A0But the spe= c doesn't say that. =A0

=A0

All I'm saying is, the spec should REQUIRE that = a sender include=A0either a key indicator, or an indication that something = is going on out of band.

=A0

--Richard

=A0

=A0

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <= bcampbell@p= ingidentity.com> wrote:

/* special magic */ is just some out of band agreeme= nt on the key to use or how to infer it. Which isn't really special or = magic. But probably pretty common.

=A0

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <= rlb@ipv.sx> wrote:

I've renamed the issue to try to clarify.=

=A0

You're right that there are alternative ways to = locate a key. =A0But a JOSE object needs to contain at least one of them, o= r else the /* special magic */ clause applies. =A0

=A0

--Richard

=A0

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

This may or may not be a = flaw in the specification.=A0 However the item you created in the tracker does not reflect what you have put here.=A0 I think you would be better se= rved by saying that there is a flaw in the specifications in that there sho= uld be a MUST that some type of key or key reference is required in a JWS o= r JWE.

=A0<= /p>

I would note that your ex= ample code should be more complex in that it does not deal with jku or any of the x* methods of referencing keys.

=A0<= /p>

Jim<= /p>

=A0<= /p>

=A0<= /p>

From: Richard = Barnes [mailto:rlb@ipv.sx]
Sent: Friday, March 22, 2013 4:09 PM
To: Jim Schaad
Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org


Subject: Re: [jose] #15: Broken examples in JWE / JWS<= /p>

=A0

I admit that they are not broken according to the cu= rrent spec. =A0However, I have a lot of trouble figuring out how I would wr= ite code to process them.

=A0

If "kid" or "jwk" MUST be presen= t to indicate what key I should use, then I can have deterministic code:=

if (/* recognized "kid" or "jwk"= value */) {=A0

=A0 =A0 /* use it */

} else {

=A0 =A0 /* FAIL. =A0can't process this object */=

}

=A0

As the spec stands, I have no idea what to put in th= at "else" clause. =A0I'm clearly not supposed to fail, becaus= e the parameters are optional. =A0But what else?

if (/* recognized "kid" or "jwk"= value */) {=A0

=A0 =A0 /* use it */

} else {

=A0 =A0 /* insert special magic here */

}

=A0

This is actually what SPI is supposed to clear up. = =A0SPI would provide an explicit third branch for the special magic to live= in.

if (/* recognized "kid" or "jwk"= value */) {=A0

=A0 =A0 /* use it */

} else if (/* recognized SPI value */) {

=A0 =A0 /* process using stored parameters */=

} else {

=A0 =A0 /* FAIL. =A0can't process this object */=

}

=A0

But without the concept of SPI, the spec is broken b= ecause of the non-determinism noted above.

=A0

--Richard

=A0

=A0

=A0

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.= com> wrote:

My inclination is that this response is correct.

What make you think that the key or key reference is required and cannot be=
implied?

Jim



> -----Original Message-----
> From: jose-= bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: draft-ietf-jose-json-web-encryption@tools.ietf.org;
ignisvulpis@gmai= l.com
> Cc: jose@ietf.org
> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken examples in JWE / JWS
>
>
> Comment (by ignisvulpis@gmail.com):
>
> =A0I think this is not an issue. The examples are NOT broken and they = do not
> need a fix.
> =A0I suggest to close this ticket.
> =A0The draft should definitely not make these illegal. These objects a= re
perfect
> examples for a valid JWS/JWE.
>
> --
> -------------------------+--------------------------------------------= --

> -------------------------+---

> =A0Reporter: =A0rlb@ipv.sx =A0 | =A0 =A0 =A0 Owner: =A0draft-ietf-jose= -json-web-
> =A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0encryption@tools.ietf.org
> =A0Priority: =A0minor =A0 =A0 =A0 =A0| =A0 =A0 =A0Status: =A0new
> Component: =A0json-web- =A0 =A0| =A0 Milestone:
> =A0 encryption =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
> =A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0| =A0Resolution:
> =A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
> -------------------------+--------------------------------------------= --

> -------------------------+---

>
> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac= /ticket/15#comment:1>
> jose <htt= p://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose

=A0

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0

=A0


--14dae93a0c17be18c704d8c6ffbf-- From rlb@ipv.sx Mon Mar 25 15:11:29 2013 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 CC75121F86F7 for ; Mon, 25 Mar 2013 15:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.218 X-Spam-Level: X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 vgiN3t6OqquL for ; Mon, 25 Mar 2013 15:11:28 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 87EA021F86F4 for ; Mon, 25 Mar 2013 15:11:28 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id 16so6472792obc.19 for ; Mon, 25 Mar 2013 15:11:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=Kvf0vwCDr0HIur/LIicKTSKINoBdoc3hsGvyHyALgI0=; b=kqfYfDrQRnhIMm5pzwyFdO+ED0V2/IB3KtXGd3aQQPeGVUKfeIN565+uPSxNUgrRfS 0OYe0EbCJacqfSocz0ogwzlfDWenJrSk6bw5c/ueyM15t6vivSexrTP/fv6Q1TWRCbnn ceZMnZ4QwBE/2Lghp/SkqqrqR6yf8BuvuKvTCA5LY9c8XO8TW3vBBQwao+WICrN6t5vw kVJt0SSzRIXXYCJwi1h+T58dMtAZl+4enfXoOrdD4BUm0kIhtit06qIiGj/oXXzZJWlw JaYu3O2bVNTmtmXoOGczjMGs1Xiy+ySyQgfVjlXpBK+CF/596YzNvvhpg7/WNGzHXWs2 lpgg== MIME-Version: 1.0 X-Received: by 10.60.9.1 with SMTP id v1mr12205294oea.130.1364249488099; Mon, 25 Mar 2013 15:11:28 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 15:11:28 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367586714@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367586714@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 25 Mar 2013 18:11:28 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8fb203181f9ecf04d8c716ea X-Gm-Message-State: ALoCoQn12g1CdLQQwY7AUNtCaJIEuwzaHIj8Y8wZIeAJYkLm3y6/sojYuaZlRpOo3xwhJ5Y0Zyxs Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Minutes 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, 25 Mar 2013 22:11:29 -0000 --e89a8fb203181f9ecf04d8c716ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's not accurate to say that Issue #4 is not a problem. We did clarify in the meeting that the issue could use some re-statement, to clarify that the issue is the coverage of keys by the integrity check. So there's still an issue, namely whether the key needs to be covered by the integrity check. On Sun, Mar 24, 2013 at 9:02 PM, Mike Jones wr= ote: > I don=92t believe that the minutes adequately capture the discussion on > issue #4 (http://trac.tools.ietf.org/wg/jose/trac/ticket/4#). I would > revise as follows:**** > > ** ** > > Data tracker issue #4 (Impossible to separate wrapped key from encrypted > data) =96 John Bradley=92s slides pointed out that it **is** possible to > separate wrapped keys from encrypted data when needed by using the direct > encryption mode and therefore asked for this issue to be closed, as it is > based upon a false premise. Mike Jones also asked for this to be closed = on > this basis, and pointed out that Nat Sakimura had already described the > problem with this issue in the issue tracker. Richard asked a question > about the security analysis of including the wrapped key in the integrity > calculation - Does the wrapped key need to be included in the integrity > check or not? The question will be referred to CFRG but a request for > possible attack modes being sent to the list is requested.**** > > ** ** > > Given that the problem stated in issue #4 was demonstrated to not actuall= y > be a problem during the discussions, I would ask again that the chairs > close this one, and update the minutes to reflect this.**** > > ** ** > > Thank you,***= * > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Jim Schaad > *Sent:* Friday, March 22, 2013 1:12 PM > *To:* jose@ietf.org > *Subject:* [jose] Minutes**** > > ** ** > > Preliminary minutes have been uploaded to the site. Please review and > comment back to me if you have disagreements.**** > > ** ** > > http://www.ietf.org/proceedings/86/minutes/minutes-86-jose**** > > ** ** > > Note that the minutes have an action list at the bottom of them.**** > > ** ** > > Jim**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8fb203181f9ecf04d8c716ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable It's not accurate to say that Issue #4 is not a problem. =A0We did clar= ify in the meeting that the issue could use some re-statement, to clarify t= hat the issue is the coverage of keys by the integrity check. =A0So there&#= 39;s still an issue, namely whether the key needs to be covered by the inte= grity check.



On Sun, Mar 24, 2013 at 9= :02 PM, Mike Jones <Michael.Jones@microsoft.com> w= rote:

I don=92t believe that= the minutes adequately capture the discussion on issue #4 (http://tra= c.tools.ietf.org/wg/jose/trac/ticket/4#).=A0 I would revise as follows:

=A0

Data tracker issue #4 = (Impossible to separate wrapped key from encrypted data) =96 John Bradley= =92s slides pointed out that it *is* possible to separate wrapped ke= ys from encrypted data when needed by using the direct encryption mode and therefore asked for this issue to be closed= , as it is based upon a false premise.=A0 Mike Jones also asked for this to= be closed on this basis, and pointed out that Nat Sakimura had already des= cribed the problem with this issue in the issue tracker. =A0Richard asked a question about the security analy= sis of including the wrapped key in the integrity calculation - Does the wr= apped key need to be included in the integrity check or not?=A0 The questio= n will be referred to CFRG but a request for possible attack modes being sent to the list is requested.

=A0

Given that the problem= stated in issue #4 was demonstrated to not actually be a problem during th= e discussions, I would ask again that the chairs close this one, and update= the minutes to reflect this.

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Thank you,

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Mike

=A0

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, March 22, 2013 1:12 PM
To: jose@ietf.org=
Subject: [jose] Minutes

=A0

Preliminary minutes have been uploaded to the site.= =A0 Please review and comment back to me if you have disagreements.<= u>

=A0

http://www.ietf.org/proceedings/86/min= utes/minutes-86-jose

=A0

Note that the minutes have an action list at the bot= tom of them.

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8fb203181f9ecf04d8c716ea-- From rlb@ipv.sx Mon Mar 25 15:12:26 2013 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 CA56521F86F7 for ; Mon, 25 Mar 2013 15:12:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.168 X-Spam-Level: X-Spam-Status: No, score=-1.168 tagged_above=-999 required=5 tests=[AWL=-0.743, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 gFMRGSu92fso for ; Mon, 25 Mar 2013 15:12:26 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 096ED21F85D4 for ; Mon, 25 Mar 2013 15:12:24 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id un3so6437827obb.24 for ; Mon, 25 Mar 2013 15:12:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=3Xrw8Ey+0Y/3xg0mspGM4ifSsePP7VTCK8YOlA0HSJs=; b=F/CEOJsH4q6MnAigWRcmy5Djf5WEitdc+CpCv0U+oF0vUnVh7O9MfixzSVyx5xWx5k iPLPon8gAcqflrVTtq3ANO656lcT/kHg7w3QsI3IAzpGWo4YAvFUF2cOi76UWC4OrgXr SniT8XgC38/f0oKQcbswo71FLy5JGAjp3y4U7KEZwor1p0zd1rq0w3bBEvwQicFjDMd2 cMPUFJ6MNGiABwIYsbW8jhajDC0Y9hahZMxvKIwosGiGfg9IkaT0SailAsGGzWCVYZ8n GyGtsSIcWRGfrM+RTDX1Q/SGpbdVF0kiUy+v/X2QLR7SxDu/NcS5H94LvbJALr1UYZTo Ug3w== MIME-Version: 1.0 X-Received: by 10.60.172.80 with SMTP id ba16mr12731530oec.116.1364249544557; Mon, 25 Mar 2013 15:12:24 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Mon, 25 Mar 2013 15:12:24 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> Date: Mon, 25 Mar 2013 18:12:24 -0400 Message-ID: From: Richard Barnes To: Brian Campbell Content-Type: multipart/alternative; boundary=bcaec5523bb67d65a704d8c719f3 X-Gm-Message-State: ALoCoQkDL2oYzMKrmrhSzJx1tl3Dr14zSGf8sZhc3dzFEwuRkyCMyu+OUhAL7TkUiSMrCCBMm6wR Cc: draft-ietf-jose-json-web-key@tools.ietf.org, jose issue tracker , james@manger.com.au, "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 25 Mar 2013 22:12:26 -0000 --bcaec5523bb67d65a704d8c719f3 Content-Type: text/plain; charset=ISO-8859-1 +1 Would be good to have a MUST here to clarify. On Mon, Mar 25, 2013 at 8:31 AM, Brian Campbell wrote: > I'd always just assumed that, short of some other means of figuring it > out, a kid header would accompany a jku to identify the specific key in the > set. > > > On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker < > trac+jose@trac.tools.ietf.org> wrote: > >> #16: URI identifying a specific key in a JWK set >> >> When a public key is required to process a JOSE message, providing a URI >> for the key is a useful alternative to providing the actual key or a >> certificate. The URI needs to identify the specific individual public key >> required for the specific JOSE message. A URI that merely identifies a >> set >> of keys (one of which is the correct one) is not sufficient. >> >> Given that a "jku" field holds a URI pointing to a set of keys, we need >> to >> define how to use the fragment part of those URIs to identify a specific >> key in the set. >> >> Using the "kid" (key id) in the fragment would be a sensible choice. >> >> -- >> >> -------------------------+------------------------------------------------- >> Reporter: | Owner: draft-ietf-jose-json-web- >> james@manger.com.au | key@tools.ietf.org >> Type: defect | Status: new >> Priority: major | Milestone: >> Component: json-web- | Version: >> key | Keywords: >> Severity: - | >> >> -------------------------+------------------------------------------------- >> >> Ticket URL: >> jose >> >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >> > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --bcaec5523bb67d65a704d8c719f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Would be good to have a MUST here to clarify.


On Mon, Mar 25, 2013 at 8:= 31 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:
I'd always just assumed= that, short of some other means of figuring it out, a kid header would acc= ompany a jku to identify the specific key in the set.

On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker <<= a href=3D"mailto:trac+jose@trac.tools.ietf.org" target=3D"_blank">trac+jose= @trac.tools.ietf.org> wrote:
james@manger.c= om.au =A0 =A0| =A0key@tools.ietf.org
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0json-web- =A0 =A0| =A0 =A0Version:
=A0 key =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 Keywords:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0|
-------------------------+-------------------------------------------------=

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/16>
jose <http://t= ools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--bcaec5523bb67d65a704d8c719f3-- From ve7jtb@ve7jtb.com Mon Mar 25 15:25:29 2013 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 AFED221F88D8 for ; Mon, 25 Mar 2013 15:25:29 -0700 (PDT) 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 JkMEkxPqg0tB for ; Mon, 25 Mar 2013 15:25:09 -0700 (PDT) Received: from mail-qe0-f42.google.com (mail-qe0-f42.google.com [209.85.128.42]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7CA21F86C0 for ; Mon, 25 Mar 2013 15:24:52 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id da11so2691223qeb.1 for ; Mon, 25 Mar 2013 15:24:51 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=eZgM2B4eyQDZgokqrwb8+qwSXitBv/f7HtWlv97FxVU=; b=blvfnAdZE2xBOxqh1YTQ2Vt9Wu0fpoSoCpGqd+EOVsT/WvtYSx4ecNT00Uy6RoEYjN GwpFQI0/MheBVMdoScGWOfUcoo+CRxPR/H7qxyIhp/4cyaKL0rGSLcv9pou93lS/r6fW re7DZMJLWXQ/psVqECLZQOfkUpFgGYuAyS7fXTnBE/0QW3AgJQqYu43sWTX8F8YEP+Vf aIj9OF1JOL1HgIDCrdU1Eg1Ha71hAzCJxMb+fu4e1JSMv9xCkf1mAT64cl0cYf7eklWC 7SiNfzcxyXvUW6t3gsn88XsNFWKBJHrpTdn38bRjqcXlyGLmZ0P1iP8MYpvyhZKYPEjQ +RaA== X-Received: by 10.229.193.160 with SMTP id du32mr1979387qcb.82.1364250291494; Mon, 25 Mar 2013 15:24:51 -0700 (PDT) Received: from [192.168.1.34] (190-20-41-38.baf.movistar.cl. [190.20.41.38]) by mx.google.com with ESMTPS id t7sm4076620qey.2.2013.03.25.15.24.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:24:49 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_8F0CEAD7-0F7A-4B1E-B9AC-DDC2340BCE7A"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Mon, 25 Mar 2013 19:24:58 -0300 Message-Id: References: <513E6A73.1090403@isoc.org> <513E774C.6090605@isoc.org> To: Richard Barnes X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQm8Exz1uxREG0TLqT+wGv41RPbesL2g8n7QAw0i+j4AX7sIwxlz8RS/vUMEQJrq1sG4n7Ji Cc: jose@ietf.org, odonoghue@isoc.org Subject: Re: [jose] Proposed resolution of header criticality issue 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, 25 Mar 2013 22:25:30 -0000 --Apple-Mail=_8F0CEAD7-0F7A-4B1E-B9AC-DDC2340BCE7A Content-Type: multipart/alternative; boundary="Apple-Mail=_44C1C1B4-D393-43B6-B245-290184A769F7" --Apple-Mail=_44C1C1B4-D393-43B6-B245-290184A769F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Agreed, I think I said that in the meeting:) =20 On 2013-03-25, at 6:34 PM, Richard Barnes wrote: > Trying to move this to closure... >=20 > It sounds to me like there was general agreement on points 1-4. Can = someone file an issue for #5 and ask the editor to implement 1-4? >=20 > Thanks, > --Richard >=20 >=20 >=20 > On Mon, Mar 11, 2013 at 8:31 PM, Karen O'Donoghue = wrote: >=20 > Folks, >=20 > A side meeting was held Sunday with a number of jose working group = participants to try to resolve the open issue related to header = criticality. The following are the proposed resolutions from the = meeting. Point 5 of the proposed resolution below is actually = independent of the other 4 points, and could be considered separately. = This will all be discussed in Wednesday's meeting.=20 >=20 > In addition to the text below, there was some agreement to replace the = "understand" text with something a bit more explicit like "must = process". However, that text has not been rolled into the summary text = below yet.=20 >=20 > Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, = Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your = efforts (and my apologies if I missed someone).=20 >=20 > Regards,=20 > Karen >=20 > 1: Change the language =93Additional members MAY be present in the = JWK. If present, they MUST be understood by implementations using = them.=94 to =93Additional members MAY be present in the JWK. If not = understood by implementations encountering them, they MUST be ignored.=94 = (And make the same change for JWK Set as well.) >=20 > 2: Characterize all existing JWS and JWE header fields as either must = be understood or may be ignored. =93alg=94, =93enc=94, and =93zip=94 = must be understood. =93kid=94, =93x5u=94, =93x5c=94, =93x5t=94, =93jwk=94= , =93jku=94, =93typ=94, and =93cty=94 can be ignored because while not = using them may result in the inability to process some signatures or = encrypted content, this will not result in a security violation =96 just = degraded functionality. Other fields such as =93epk=94, =93apu=94, = =93apv=94, =93epu=94, and =93epv=94 must be understood and used when = =93alg=94 or =93enc=94 values requiring them are used, and otherwise = they may be ignored. >=20 > 3. Define a new header field that lists which additional fields not = defined in the base specifications must be understood and acted upon = when present. For instance, an expiration-time extension field could be = marked as must-be-understood-and-acted-upon. One possible name for this = would be =93crit=94 (critical). An example use, along with a = hypothetical =93exp=94 (expiration-time) field is: >=20 > {"alg":"ES256", > "crit":["exp"], > "exp=94:1363284000 > } >=20 > 4. All additional header fields not defined in the base = specifications and not contained in the =93crit=94 list MUST be ignored = if not understood. >=20 > 5. Define a new header field =93asd=94 (application-specific data) = whose value is a JSON structure whose contents are opaque to and ignored = by JWS and JWE implementations but for which its contents MUST be = provided to applications using JWS or JWE, provided that the = signature/MAC validation or decryption operation succeeds. The intended = use of this field is to have a standard place to provide = application-specific metadata about the payload or plaintext. >=20 >=20 >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_44C1C1B4-D393-43B6-B245-290184A769F7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 rlb@ipv.sx> wrote:
Trying to = move this to closure...

It sounds to me like there = was general agreement on points 1-4.  Can someone file an issue for = #5 and ask the editor to implement = 1-4?

Thanks,
--Richard



On Mon, Mar 11, 2013 at 8:31 PM, Karen O'Donoghue = <odonoghue@isoc.org> wrote:
=20 =20 =20

Folks,

A side meeting was held Sunday with a number of jose working group participants to try to resolve the open issue related to header criticality. The following are the proposed resolutions from the meeting. Point 5 of the proposed resolution below is actually independent of the other 4 points, and could be considered separately. This will all be discussed in Wednesday's meeting.

In addition to the text below, there was some agreement to replace the "understand" text with something a bit more explicit like "must process". However, that text has not been rolled into the summary text below yet.

Thank you to Jim Schaad, Mike Jones, John Bradley, Nat Sakimura, Martin Thomas, Eric Rescorla, Matt Miller, and Richard Barnes for your efforts (and my apologies if I missed someone).

Regards,
Karen

1:  Change the language =93Additional members MAY be = present in the JWK.  If present, they MUST be understood by implementations using them.=94 to =93Additional members MAY be present in the JWK.  If not understood by implementations encountering them, they MUST be ignored.=94  (And make = the same change for JWK Set as well.)

2:  Characterize all existing JWS and JWE header fields = as either must be understood or may be ignored.  =93alg=94, = =93enc=94, and =93zip=94 must be understood.  =93kid=94, =93x5u=94, = =93x5c=94, =93x5t=94, =93jwk=94, =93jku=94, =93typ=94, and =93cty=94 can be ignored = because while not using them may result in the inability to process some signatures or encrypted content, this will not result in a security violation =96 just degraded functionality.  = Other fields such as =93epk=94, =93apu=94, =93apv=94, =93epu=94, and = =93epv=94 must be understood and used when =93alg=94 or =93enc=94 values = requiring them are used, and otherwise they may be ignored.

3.  Define a new header field that lists which additional fields not defined in the base specifications must be understood and acted upon when present.  For instance, an expiration-time extension field could be marked as must-be-understood-and-acted-upon.  One possible name for = this would be =93crit=94 (critical).  An example use, along = with a hypothetical =93exp=94 (expiration-time) field = is:

  {"alg":"ES256",
   "crit":["exp"],
   "exp=94:1363284000
  }

4.  All additional header fields not defined in the base specifications and not contained in the =93crit=94 list MUST = be ignored if not understood.

5.  Define a new header field =93asd=94 = (application-specific data) whose value is a JSON structure whose contents are opaque to and ignored by JWS and JWE implementations but for which its contents MUST be provided to applications using JWS or JWE, provided that the signature/MAC validation or decryption operation succeeds.  The intended use of this = field is to have a standard place to provide application-specific metadata about the payload or plaintext.




_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose


_______________________________________________
jose mailing = list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_44C1C1B4-D393-43B6-B245-290184A769F7-- --Apple-Mail=_8F0CEAD7-0F7A-4B1E-B9AC-DDC2340BCE7A Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI1MjIyNDU4WjAjBgkqhkiG9w0BCQQxFgQUtaw1W5El 33J76aO/a63qfBvsfaUwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAKL3zV2frlCrkcp9SLxKhnNK0gYHUDeS5gBMH9iw1 UCjax3TGz1EGFA1xd5pMQnlcTylu9XM2AfUziGwabNWCg0ItEoqXOFYwKQJZcwtZwFfh6sZ5hLHf 3FPa00TR8I9XZDhHXYNO9iqFvkyFeXPtt0LR5rWfXmdUKi9/cuSVq/O7IAyqkjhDmY7EtR4QodkB VWdaUTxao4WktzUr2NIKCp1YFbBPzFPsGFwgYs+6fAVoy3Aee2VwgoAVDY+IR2R678cYDKPzPHjQ 0yfD67zkxYVHqFdnPtFzoFiS08EB3iEQMwLheB7yLQN7KIlcNiUDwRqu+C6kFTHq7j3aownJvAAA AAAAAA== --Apple-Mail=_8F0CEAD7-0F7A-4B1E-B9AC-DDC2340BCE7A-- From dick.hardt@gmail.com Mon Mar 25 15:42:50 2013 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 3C1F421F84A9 for ; Mon, 25 Mar 2013 15:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.049 X-Spam-Level: X-Spam-Status: No, score=0.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 vzC3UTV8UtzW for ; Mon, 25 Mar 2013 15:42:49 -0700 (PDT) Received: from mail-da0-x22e.google.com (mail-da0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 181D821F84A7 for ; Mon, 25 Mar 2013 15:42:49 -0700 (PDT) Received: by mail-da0-f46.google.com with SMTP id y19so3365028dan.5 for ; Mon, 25 Mar 2013 15:42:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=YKBQx1Zd/AWJ/nzVaU5ckKoZhXPctAfpnLk2WlqD7+c=; b=L0R84aPG0IpgBZFi0Aoj//PRK72Y9z0t5qZQ9hLTGwcmjYNSzF9QFWONoNBbOg+ZxN ffNKFGAgYiw/IsYPGLgTqWAvpYJsXEHHwlYn07xAG0OF0GBQgp9vgTSthuSAg1JHGSEN FgRDJwOqcqZvG+KC3C5wG56XbdmyU1w3drDnCJd0fjS90c7ZmC/DvP5UJlPX6j67vhX2 OJJkDDDeXi5q5fpALoe562cxTVNh5ktroj7KLI2xIWhJXrspR7oz/CBuUITASRnDjkoy 1el70xHtnIsz1rWmfANu+o0DHavlXCrljHPm63yug3inEut10lNG97yIJxjFDyT6x9J/ cOEw== X-Received: by 10.68.27.164 with SMTP id u4mr20374054pbg.69.1364251368843; Mon, 25 Mar 2013 15:42:48 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id wi7sm16418869pac.9.2013.03.25.15.42.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:42:46 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_4BA09940-1ADC-4025-980E-D85C68B60D7B" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 25 Mar 2013 15:42:43 -0700 Message-Id: <2D50F89B-5A07-4379-A532-CDC6B5E1BB33@gmail.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Richard Barnes , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Jim Schaad , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:42:50 -0000 --Apple-Mail=_4BA09940-1ADC-4025-980E-D85C68B60D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think the example should contain the KID as one would expect that to = be the common case. On Mar 25, 2013, at 2:54 PM, Mike Jones = wrote: > If you already know that something is going on out of band, the = indication in the JOSE object would be unnecessary. > =20 > -- = Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Monday, March 25, 2013 2:31 PM > To: Brian Campbell > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > =20 > I realize that's the common case. But the spec doesn't say that. =20 > =20 > All I'm saying is, the spec should REQUIRE that a sender include = either a key indicator, or an indication that something is going on out = of band. > =20 > --Richard > =20 > =20 >=20 > On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell = wrote: > /* special magic */ is just some out of band agreement on the key to = use or how to infer it. Which isn't really special or magic. But = probably pretty common. > =20 >=20 > On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: > I've renamed the issue to try to clarify. > =20 > You're right that there are alternative ways to locate a key. But a = JOSE object needs to contain at least one of them, or else the /* = special magic */ clause applies. =20 > =20 > --Richard > =20 >=20 > On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad = wrote: > This may or may not be a flaw in the specification. However the item = you created in the tracker does not reflect what you have put here. I = think you would be better served by saying that there is a flaw in the = specifications in that there should be a MUST that some type of key or = key reference is required in a JWS or JWE. > =20 > I would note that your example code should be more complex in that it = does not deal with jku or any of the x* methods of referencing keys. > =20 > Jim > =20 > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, March 22, 2013 4:09 PM > To: Jim Schaad > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org >=20 > Subject: Re: [jose] #15: Broken examples in JWE / JWS > =20 > I admit that they are not broken according to the current spec. = However, I have a lot of trouble figuring out how I would write code to = process them. > =20 > If "kid" or "jwk" MUST be present to indicate what key I should use, = then I can have deterministic code: > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else { > /* FAIL. can't process this object */ > } > =20 > As the spec stands, I have no idea what to put in that "else" clause. = I'm clearly not supposed to fail, because the parameters are optional. = But what else? > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else { > /* insert special magic here */ > } > =20 > This is actually what SPI is supposed to clear up. SPI would provide = an explicit third branch for the special magic to live in. > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else if (/* recognized SPI value */) { > /* process using stored parameters */ > } else { > /* FAIL. can't process this object */ > } > =20 > But without the concept of SPI, the spec is broken because of the = non-determinism noted above. > =20 > --Richard > =20 > =20 > =20 >=20 > On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad = wrote: > My inclination is that this response is correct. >=20 > What make you think that the key or key reference is required and = cannot be > implied? >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > > jose issue tracker > > Sent: Friday, March 22, 2013 2:37 PM > > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; > ignisvulpis@gmail.com > > Cc: jose@ietf.org > > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > > > #15: Broken examples in JWE / JWS > > > > > > Comment (by ignisvulpis@gmail.com): > > > > I think this is not an issue. The examples are NOT broken and they = do not > > need a fix. > > I suggest to close this ticket. > > The draft should definitely not make these illegal. These objects = are > perfect > > examples for a valid JWS/JWE. > > > > -- > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: minor | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: = > > jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_4BA09940-1ADC-4025-980E-D85C68B60D7B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I think the example should = contain the KID as one would expect that to be the common = case.

On Mar 25, 2013, at 2:54 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

If you already know that = something is going on out of band, the indication in the JOSE object = would be unnecessary.
 
 
 jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Monday, March 25, 2013 2:31 = PM
To: Brian = Campbell
Cc: draft-i= etf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; jose@ietf.org
Subject: Re: [jose] #15: Broken = examples in JWE / JWS
I realize = that's the common case.  But the spec doesn't say that. =  
All = I'm saying is, the spec should REQUIRE that a sender include either = a key indicator, or an indication that something is going on out of = band.
 

This may or may not be a flaw in the = specification.  However the item you created in the tracker does = not reflect what you have put here.  I think you would be better = served by saying that there is a flaw in the specifications in that = there should be a MUST that some type of key or key reference is = required in a JWS or JWE.
I would note that your example code should be more = complex in that it does not deal with jku or any of the x* methods of = referencing keys.
 
 
From: Richard Barnes [mailto:rlb@ipv.sx] 
Sent: Friday, March 22, 2013 4:09 = PM
To: Jim = Schaad
Cc:  
Subject: Re: [jose] #15: Broken = examples in JWE / JWS

 

My inclination = is that this response is correct.

What make you think that the = key or key reference is required and cannot be
implied?
 jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of
> jose issue tracker
> Sent: Friday, March 22, = 2013 2:37 PM
> To: ignisvulpis@gmail.com
> = Cc: jose@ietf.org
> Subject: Re: = [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken = examples in JWE / JWS
>
>
> Comment (by > = -------------------------+---

jose@ietf.org
 

jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_4BA09940-1ADC-4025-980E-D85C68B60D7B-- From James.H.Manger@team.telstra.com Mon Mar 25 15:46:59 2013 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 D85C421F8630 for ; Mon, 25 Mar 2013 15:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 gXAzmSDOWugs for ; Mon, 25 Mar 2013 15:46:59 -0700 (PDT) Received: from ipxano.tcif.telstra.com.au (ipxano.tcif.telstra.com.au [203.35.82.200]) by ietfa.amsl.com (Postfix) with ESMTP id 2790421F862A for ; Mon, 25 Mar 2013 15:46:54 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,897,1355058000"; d="scan'208,217";a="129988646" Received: from unknown (HELO ipcani.tcif.telstra.com.au) ([10.97.216.200]) by ipoani.tcif.telstra.com.au with ESMTP; 26 Mar 2013 09:47:17 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7025"; a="72004181" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcani.tcif.telstra.com.au with ESMTP; 26 Mar 2013 09:46:53 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Tue, 26 Mar 2013 09:46:53 +1100 From: "Manger, James H" To: Brian Campbell , "jose@ietf.org" Date: Tue, 26 Mar 2013 09:46:51 +1100 Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: Ac4pVMYtS4b0Kq3yREeGGJsIkBdFRQAUqjQQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150BE3C554WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 25 Mar 2013 22:47:00 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150BE3C554WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ2QgYWx3YXlzIGp1c3QgYXNzdW1lZCB0aGF0LCBzaG9ydCBvZiBzb21lIG90aGVyIG1lYW5z IG9mIGZpZ3VyaW5nIGl0IG91dCwgYSBraWQgaGVhZGVyIHdvdWxkIGFjY29tcGFueSBhIGprdSB0 byBpZGVudGlmeSB0aGUgc3BlY2lmaWMga2V5IGluIHRoZSBzZXQuDQoNCkluZGVlZCwg4oCcamt1 4oCdIG5lZWRzIHRvIGJlIGFjY29tcGFuaWVkIGJ5IOKAnGtpZOKAnSB0byB3b3JrIGluIGdlbmVy YWwg4oCUIGJ1dCB0aGlzIGlzIGEgY3JhcHB5IHNvbHV0aW9uLiA5OSUgb2YgdGhlIHRpbWUgdGhh dCBhIOKAnGprdeKAnSBpcyB1c2VkIHlvdSB3YW50IHRvIGlkZW50aWZ5IGEgc2luZ2xlIHNwZWNp ZmljIGtleSBzbyDigJxqa3XigJ0gc2hvdWxkIGJlIGNhcGFibGUgb2YgZG9pbmcgdGhhdCB3aXRo b3V0IHJlcXVpcmluZyBhbiBleHRyYSBmaWVsZC4NCg0KQSBKT1NFIGhlYWRlciBkb2VzIGhhdmUg cm9vbSBmb3Ig4oCca2lk4oCdIGFzIHdlbGwgYXMg4oCcamt14oCdLiBIb3dldmVyLCBtYW55IGNv bnRleHRzIHRoYXQgdXNlIFVSSXMgYXMgaWRlbnRpZmllcnMgZXhwZWN0IGEgVVJJIHRvIGJlIFRI RSBpZGVudGlmaWVyLiBOZWVkaW5nIHR3byBmaWVsZHMgdG8gZG8gb25lIHRhc2sgaXMgaW5ldml0 YWJseSBhd2t3YXJkLg0KDQpGaW5hbGx5LCBpZGVudGlmeWluZyAxIGl0ZW0gZnJvbSBhIHNldCBp cyBhIHBlcmZlY3QgbWF0Y2ggZm9yIHRoZSB3aG9sZSBwdXJwb3NlIG9mIFVSSSBmcmFnbWVudHMg c28gbWVyZWx5IGJ5IHRoZSBwcmluY2lwbGUgb2YgbGVhc3QgYXN0b25pc2htZW50IEpXSyBzaG91 bGQgc3BlY2lmeSBob3cgdGhlIGZyYWdtZW50IHBpY2tzIDEga2V5Lg0KDQotLQ0KSmFtZXMgTWFu Z2VyDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIENhbXBiZWxsDQpTZW50OiBNb25kYXksIDI1IE1h cmNoIDIwMTMgMTE6MzEgUE0NClRvOiBqb3NlIGlzc3VlIHRyYWNrZXINCkNjOiBkcmFmdC1pZXRm LWpvc2UtanNvbi13ZWIta2V5QHRvb2xzLmlldGYub3JnOyBqb3NlQGlldGYub3JnOyBqYW1lc0Bt YW5nZXIuY29tLmF1DQpTdWJqZWN0OiBSZTogW2pvc2VdICMxNjogVVJJIGlkZW50aWZ5aW5nIGEg c3BlY2lmaWMga2V5IGluIGEgSldLIHNldA0KDQpJJ2QgYWx3YXlzIGp1c3QgYXNzdW1lZCB0aGF0 LCBzaG9ydCBvZiBzb21lIG90aGVyIG1lYW5zIG9mIGZpZ3VyaW5nIGl0IG91dCwgYSBraWQgaGVh ZGVyIHdvdWxkIGFjY29tcGFueSBhIGprdSB0byBpZGVudGlmeSB0aGUgc3BlY2lmaWMga2V5IGlu IHRoZSBzZXQuDQoNCk9uIFN1biwgTWFyIDI0LCAyMDEzIGF0IDY6NDAgUE0sIGpvc2UgaXNzdWUg dHJhY2tlciA8dHJhYytqb3NlQHRyYWMudG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnRyYWMram9zZUB0 cmFjLnRvb2xzLmlldGYub3JnPj4gd3JvdGU6DQojMTY6IFVSSSBpZGVudGlmeWluZyBhIHNwZWNp ZmljIGtleSBpbiBhIEpXSyBzZXQNCg0KIFdoZW4gYSBwdWJsaWMga2V5IGlzIHJlcXVpcmVkIHRv IHByb2Nlc3MgYSBKT1NFIG1lc3NhZ2UsIHByb3ZpZGluZyBhIFVSSQ0KIGZvciB0aGUga2V5IGlz IGEgdXNlZnVsIGFsdGVybmF0aXZlIHRvIHByb3ZpZGluZyB0aGUgYWN0dWFsIGtleSBvciBhDQog Y2VydGlmaWNhdGUuIFRoZSBVUkkgbmVlZHMgdG8gaWRlbnRpZnkgdGhlIHNwZWNpZmljIGluZGl2 aWR1YWwgcHVibGljIGtleQ0KIHJlcXVpcmVkIGZvciB0aGUgc3BlY2lmaWMgSk9TRSBtZXNzYWdl LiBBIFVSSSB0aGF0IG1lcmVseSBpZGVudGlmaWVzIGEgc2V0DQogb2Yga2V5cyAob25lIG9mIHdo aWNoIGlzIHRoZSBjb3JyZWN0IG9uZSkgaXMgbm90IHN1ZmZpY2llbnQuDQoNCiBHaXZlbiB0aGF0 IGEgImprdSIgZmllbGQgaG9sZHMgYSBVUkkgcG9pbnRpbmcgdG8gYSBzZXQgb2Yga2V5cywgd2Ug bmVlZCB0bw0KIGRlZmluZSBob3cgdG8gdXNlIHRoZSBmcmFnbWVudCBwYXJ0IG9mIHRob3NlIFVS SXMgdG8gaWRlbnRpZnkgYSBzcGVjaWZpYw0KIGtleSBpbiB0aGUgc2V0Lg0KDQogVXNpbmcgdGhl ICJraWQiIChrZXkgaWQpIGluIHRoZSBmcmFnbWVudCB3b3VsZCBiZSBhIHNlbnNpYmxlIGNob2lj ZS4NCg0KLS0NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KIFJlcG9ydGVyOiAgICAgICAgICAgICAgIHwg ICAgICBPd25lcjogIGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi0NCiAgamFtZXNAbWFuZ2VyLmNv bS5hdTxtYWlsdG86amFtZXNAbWFuZ2VyLmNvbS5hdT4gICAgfCAga2V5QHRvb2xzLmlldGYub3Jn PG1haWx0bzprZXlAdG9vbHMuaWV0Zi5vcmc+DQogICAgIFR5cGU6ICBkZWZlY3QgICAgICAgfCAg ICAgU3RhdHVzOiAgbmV3DQogUHJpb3JpdHk6ICBtYWpvciAgICAgICAgfCAgTWlsZXN0b25lOg0K Q29tcG9uZW50OiAganNvbi13ZWItICAgIHwgICAgVmVyc2lvbjoNCiAga2V5ICAgICAgICAgICAg ICAgICAgICB8ICAgS2V5d29yZHM6DQogU2V2ZXJpdHk6ICAtICAgICAgICAgICAgfA0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNClRpY2tldCBVUkw6IDxodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL2pv c2UvdHJhYy90aWNrZXQvMTY+DQpqb3NlIDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvam9zZS8+DQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpqb3NlIG1h aWxpbmcgbGlzdA0Kam9zZUBpZXRmLm9yZzxtYWlsdG86am9zZUBpZXRmLm9yZz4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vam9zZQ0KDQo= --_000_255B9BB34FB7D647A506DC292726F6E1150BE3C554WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD4mZ3Q7IEknZCBhbHdheXMganVzdCBhc3N1bWVkIHRoYXQsIHNob3J0IG9m IHNvbWUgb3RoZXIgbWVhbnMgb2YgZmlndXJpbmcgaXQgb3V0LCBhIGtpZCBoZWFkZXIgd291bGQg YWNjb21wYW55IGEgamt1IHRvIGlkZW50aWZ5IHRoZSBzcGVjaWZpYyBrZXkgaW4gdGhlIHNldC4g PG86cD48L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPkluZGVlZCwg4oCcamt14oCdIG5lZWRzIHRvIGJlIGFjY29tcGFuaWVkIGJ5 IOKAnGtpZOKAnSB0byB3b3JrIGluIGdlbmVyYWwg4oCUIGJ1dCB0aGlzIGlzIGEgY3JhcHB5IHNv bHV0aW9uLiA5OSUgb2YgdGhlIHRpbWUgdGhhdCBhIOKAnGprdeKAnSBpcyB1c2VkIHlvdSB3YW50 IHRvIGlkZW50aWZ5IGEgc2luZ2xlIHNwZWNpZmljIGtleSBzbyDigJxqa3XigJ0gc2hvdWxkIGJl IGNhcGFibGUgb2YgZG9pbmcgdGhhdCB3aXRob3V0IHJlcXVpcmluZyBhbiBleHRyYSBmaWVsZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkEgSk9TRSBoZWFkZXIgZG9lcyBoYXZlIHJvb20gZm9yIOKAnGtp ZOKAnSBhcyB3ZWxsIGFzIOKAnGprdeKAnS4gSG93ZXZlciwgbWFueSBjb250ZXh0cyB0aGF0IHVz ZSBVUklzIGFzIGlkZW50aWZpZXJzIGV4cGVjdCBhIFVSSSB0byBiZSBUSEUgaWRlbnRpZmllci4g TmVlZGluZyB0d28gZmllbGRzIHRvIGRvIG9uZSB0YXNrIGlzIGluZXZpdGFibHkgYXdrd2FyZC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPkZpbmFsbHksIGlkZW50aWZ5aW5nIDEgaXRlbSBmcm9tIGEgc2V0 IGlzIGEgcGVyZmVjdCBtYXRjaCBmb3IgdGhlIHdob2xlIHB1cnBvc2Ugb2YgVVJJIGZyYWdtZW50 cyBzbyBtZXJlbHkgYnkgdGhlIHByaW5jaXBsZSBvZiBsZWFzdCBhc3RvbmlzaG1lbnQgSldLIHNo b3VsZCBzcGVjaWZ5IGhvdyB0aGUgZnJhZ21lbnQgcGlja3MgMSBrZXkuPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0 OTdEJz4tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5KYW1lcyBNYW5nZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSc+ PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo b21hIiwic2Fucy1zZXJpZiInPiBqb3NlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpqb3NlLWJv dW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+QnJpYW4gQ2FtcGJlbGw8YnI+PGI+ U2VudDo8L2I+IE1vbmRheSwgMjUgTWFyY2ggMjAxMyAxMTozMSBQTTxicj48Yj5Ubzo8L2I+IGpv c2UgaXNzdWUgdHJhY2tlcjxicj48Yj5DYzo8L2I+IGRyYWZ0LWlldGYtam9zZS1qc29uLXdlYi1r ZXlAdG9vbHMuaWV0Zi5vcmc7IGpvc2VAaWV0Zi5vcmc7IGphbWVzQG1hbmdlci5jb20uYXU8YnI+ PGI+U3ViamVjdDo8L2I+IFJlOiBbam9zZV0gIzE2OiBVUkkgaWRlbnRpZnlpbmcgYSBzcGVjaWZp YyBrZXkgaW4gYSBKV0sgc2V0PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD5JJ2QgYWx3YXlzIGp1c3QgYXNzdW1lZCB0aGF0LCBzaG9ydCBvZiBzb21lIG90aGVyIG1lYW5z IG9mIGZpZ3VyaW5nIGl0IG91dCwgYSBraWQgaGVhZGVyIHdvdWxkIGFjY29tcGFueSBhIGprdSB0 byBpZGVudGlmeSB0aGUgc3BlY2lmaWMga2V5IGluIHRoZSBzZXQuIDxvOnA+PC9vOnA+PC9wPjwv ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+T24gU3VuLCBNYXIg MjQsIDIwMTMgYXQgNjo0MCBQTSwgam9zZSBpc3N1ZSB0cmFja2VyICZsdDs8YSBocmVmPSJtYWls dG86dHJhYytqb3NlQHRyYWMudG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj50cmFjK2pv c2VAdHJhYy50b29scy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD4jMTY6IFVSSSBpZGVudGlmeWluZyBhIHNwZWNpZmljIGtleSBpbiBhIEpX SyBzZXQ8YnI+PGJyPiZuYnNwO1doZW4gYSBwdWJsaWMga2V5IGlzIHJlcXVpcmVkIHRvIHByb2Nl c3MgYSBKT1NFIG1lc3NhZ2UsIHByb3ZpZGluZyBhIFVSSTxicj4mbmJzcDtmb3IgdGhlIGtleSBp cyBhIHVzZWZ1bCBhbHRlcm5hdGl2ZSB0byBwcm92aWRpbmcgdGhlIGFjdHVhbCBrZXkgb3IgYTxi cj4mbmJzcDtjZXJ0aWZpY2F0ZS4gVGhlIFVSSSBuZWVkcyB0byBpZGVudGlmeSB0aGUgc3BlY2lm aWMgaW5kaXZpZHVhbCBwdWJsaWMga2V5PGJyPiZuYnNwO3JlcXVpcmVkIGZvciB0aGUgc3BlY2lm aWMgSk9TRSBtZXNzYWdlLiBBIFVSSSB0aGF0IG1lcmVseSBpZGVudGlmaWVzIGEgc2V0PGJyPiZu YnNwO29mIGtleXMgKG9uZSBvZiB3aGljaCBpcyB0aGUgY29ycmVjdCBvbmUpIGlzIG5vdCBzdWZm aWNpZW50Ljxicj48YnI+Jm5ic3A7R2l2ZW4gdGhhdCBhICZxdW90O2prdSZxdW90OyBmaWVsZCBo b2xkcyBhIFVSSSBwb2ludGluZyB0byBhIHNldCBvZiBrZXlzLCB3ZSBuZWVkIHRvPGJyPiZuYnNw O2RlZmluZSBob3cgdG8gdXNlIHRoZSBmcmFnbWVudCBwYXJ0IG9mIHRob3NlIFVSSXMgdG8gaWRl bnRpZnkgYSBzcGVjaWZpYzxicj4mbmJzcDtrZXkgaW4gdGhlIHNldC48YnI+PGJyPiZuYnNwO1Vz aW5nIHRoZSAmcXVvdDtraWQmcXVvdDsgKGtleSBpZCkgaW4gdGhlIGZyYWdtZW50IHdvdWxkIGJl IGEgc2Vuc2libGUgY2hvaWNlLjxicj48YnI+LS08YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZu YnNwO1JlcG9ydGVyOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZuYnNwO093bmVyOiAmbmJzcDtkcmFmdC1pZXRmLWpvc2Ut anNvbi13ZWItPGJyPiZuYnNwOyA8YSBocmVmPSJtYWlsdG86amFtZXNAbWFuZ2VyLmNvbS5hdSI+ amFtZXNAbWFuZ2VyLmNvbS5hdTwvYT4gJm5ic3A7ICZuYnNwO3wgJm5ic3A7PGEgaHJlZj0ibWFp bHRvOmtleUB0b29scy5pZXRmLm9yZyI+a2V5QHRvb2xzLmlldGYub3JnPC9hPjxicj4mbmJzcDsg Jm5ic3A7ICZuYnNwO1R5cGU6ICZuYnNwO2RlZmVjdCAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICZu YnNwOyAmbmJzcDsgU3RhdHVzOiAmbmJzcDtuZXc8YnI+Jm5ic3A7UHJpb3JpdHk6ICZuYnNwO21h am9yICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7TWlsZXN0b25lOjxicj5Db21w b25lbnQ6ICZuYnNwO2pzb24td2ViLSAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7VmVyc2lv bjo8YnI+Jm5ic3A7IGtleSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyBLZXl3b3Jkczo8YnI+Jm5ic3A7 U2V2ZXJpdHk6ICZuYnNwOy0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8PGJyPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj48YnI+VGlja2V0IFVSTDogJmx0OzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8xNiIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvam9zZS90cmFjL3RpY2tldC8xNjwvYT4m Z3Q7PGJyPmpvc2UgJmx0OzxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9qb3NlLyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHA6Ly90b29scy5pZXRmLm9yZy9qb3NlLzwvYT4mZ3Q7PGJyPjxicj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5qb3NlIG1h aWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86am9zZUBpZXRmLm9yZyI+am9zZUBpZXRmLm9y ZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9q b3NlIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9qb3NlPC9hPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_255B9BB34FB7D647A506DC292726F6E1150BE3C554WSMSG3153Vsrv_-- From Michael.Jones@microsoft.com Mon Mar 25 15:49:38 2013 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 7C6A321F863B for ; Mon, 25 Mar 2013 15:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1GeCuLqL8YAk for ; Mon, 25 Mar 2013 15:49:34 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0212.outbound.protection.outlook.com [207.46.163.212]) by ietfa.amsl.com (Postfix) with ESMTP id 60DE221F8623 for ; Mon, 25 Mar 2013 15:49:34 -0700 (PDT) Received: from BY2FFO11FD007.protection.gbl (10.173.161.204) by BL2FFO11HUB027.protection.gbl (10.173.161.51) with Microsoft SMTP Server (TLS) id 15.0.651.3; Mon, 25 Mar 2013 22:49:26 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD007.mail.protection.outlook.com (10.1.14.128) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Mon, 25 Mar 2013 22:49:25 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Mon, 25 Mar 2013 22:49:11 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] #15: Broken examples in JWE / JWS Thread-Index: AQHOJ0GRGLcBFTS/L0CrF4Bh9JphKZiyPD8AgAAKWICAAA89AIAAI4YAgAAGLwCAA9bwAIAAmwcAgAAGaeCAAA2zgIAAAVjA Date: Mon, 25 Mar 2013 22:49:10 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367588A40@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> <2D50F89B-5A07-4379-A532-CDC6B5E1BB33@gmail.com> In-Reply-To: <2D50F89B-5A07-4379-A532-CDC6B5E1BB33@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367588A40TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(199002)(24454001)(51704002)(377454001)(13464002)(512954001)(54356001)(74502001)(47976001)(69226001)(76482001)(54316002)(51856001)(80022001)(65816001)(15202345001)(16236675001)(56816002)(77982001)(56776001)(4396001)(49866001)(33656001)(59766001)(50986001)(44976002)(66066001)(5343655001)(55846006)(79102001)(71186001)(74662001)(31966008)(63696002)(5343635001)(46102001)(16406001)(47446002)(53806001)(20776003)(47736001)(550254004); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB027; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0796EBEDE1 Cc: Richard Barnes , "draft-ietf-jose-json-web-encryption@tools.ietf.org" , Jim Schaad , Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:49:38 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367588A40TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As I'd already written, I have no problem with some of the examples contain= ing a Key ID. But it's also the case in many deployment environments that = keys are pre-shared and known by both parties in advance of any tokens bein= g exchanged. This is often true when per-client symmetric keys are used wi= th OAuth, for instance. -- Mike From: Dick Hardt [mailto:dick.hardt@gmail.com] Sent: Monday, March 25, 2013 3:43 PM To: Mike Jones Cc: Richard Barnes; Brian Campbell; draft-ietf-jose-json-web-encryption@too= ls.ietf.org; Jim Schaad; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I think the example should contain the KID as one would expect that to be t= he common case. On Mar 25, 2013, at 2:54 PM, Mike Jones > wrote: If you already know that something is going on out of band, the indication = in the JOSE object would be unnecessary. -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Richard Barnes Sent: Monday, March 25, 2013 2:31 PM To: Brian Campbell Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I realize that's the common case. But the spec doesn't say that. All I'm saying is, the spec should REQUIRE that a sender include either a k= ey indicator, or an indication that something is going on out of band. --Richard On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell > wrote: /* special magic */ is just some out of band agreement on the key to use or= how to infer it. Which isn't really special or magic. But probably pretty = common. On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes > wrote: I've renamed the issue to try to clarify. You're right that there are alternative ways to locate a key. But a JOSE o= bject needs to contain at least one of them, or else the /* special magic *= / clause applies. --Richard On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad > wrote: This may or may not be a flaw in the specification. However the item you c= reated in the tracker does not reflect what you have put here. I think you= would be better served by saying that there is a flaw in the specification= s in that there should be a MUST that some type of key or key reference is = required in a JWS or JWE. I would note that your example code should be more complex in that it does = not deal with jku or any of the x* methods of referencing keys. Jim From: Richard Barnes [mailto:rlb@ipv.sx] Sent: Friday, March 22, 2013 4:09 PM To: Jim Schaad Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS I admit that they are not broken according to the current spec. However, I= have a lot of trouble figuring out how I would write code to process them. If "kid" or "jwk" MUST be present to indicate what key I should use, then I= can have deterministic code: if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* FAIL. can't process this object */ } As the spec stands, I have no idea what to put in that "else" clause. I'm = clearly not supposed to fail, because the parameters are optional. But wha= t else? if (/* recognized "kid" or "jwk" value */) { /* use it */ } else { /* insert special magic here */ } This is actually what SPI is supposed to clear up. SPI would provide an ex= plicit third branch for the special magic to live in. if (/* recognized "kid" or "jwk" value */) { /* use it */ } else if (/* recognized SPI value */) { /* process using stored parameters */ } else { /* FAIL. can't process this object */ } But without the concept of SPI, the spec is broken because of the non-deter= minism noted above. --Richard On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad > wrote: My inclination is that this response is correct. What make you think that the key or key reference is required and cannot be implied? Jim > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bo= unces@ietf.org] On Behalf Of > jose issue tracker > Sent: Friday, March 22, 2013 2:37 PM > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; ignisvulpis@gmail.com > Cc: jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > #15: Broken examples in JWE / JWS > > > Comment (by ignisvulpis@gmail.com): > > I think this is not an issue. The examples are NOT broken and they do no= t > need a fix. > I suggest to close this ticket. > The draft should definitely not make these illegal. These objects are perfect > examples for a valid JWS/JWE. > > -- > -------------------------+---------------------------------------------- > -------------------------+--- > Reporter: rlb@ipv.sx | Owner: draft-ietf-jo= se-json-web- > Type: defect | encryption@tools.ietf.org > Priority: minor | Status: new > Component: json-web- | Milestone: > encryption | Version: > Severity: - | Resolution: > Keywords: | > -------------------------+---------------------------------------------- > -------------------------+--- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367588A40TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

As I’d already writ= ten, I have no problem with some of the examples containing a Key ID. = But it’s also the case in many deployment environments that keys are pre-shared and known by both parties in advance of any tokens being exchan= ged.  This is often true when per-client symmetric keys are used with = OAuth, for instance.

 <= /p>

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

 <= /p>

From: Dick Har= dt [mailto:dick.hardt@gmail.com]
Sent: Monday, March 25, 2013 3:43 PM
To: Mike Jones
Cc: Richard Barnes; Brian Campbell; draft-ietf-jose-json-web-encrypt= ion@tools.ietf.org; Jim Schaad; jose@ietf.org
Subject: Re: [jose] #15: Broken examples in JWE / JWS

 

I think the example should contain the KID as one wo= uld expect that to be the common case.

 

On Mar 25, 2013, at 2:54 PM, Mike Jones <Michael.Jones@microsoft.com>= wrote:



If you already know that = something is going on out of band, the indication in the JOSE object would = be unnecessary.

 <= /p>

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

 <= /p>

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, Marc= h 25, 2013 2:31 PM
To: Brian Campbell=
Cc: draft-ietf-jose-jso= n-web-encryption@tools.ietf.org; Jim Schaad; jose@ietf.org
Subject: Re: [jose= ] #15: Broken examples in JWE / JWS

 

I realize that's the common case.  But the spec= doesn't say that.  

 

All I'm saying is, the spec should REQUIRE that a se= nder include either a key indicator, or an indication that something i= s going on out of band.

 

--Richard

 

 

On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell <= bcampbell@pingidentity.com> wrote:

/* special magic */ is just some out of band agreeme= nt on the key to use or how to infer it. Which isn't really special or magi= c. But probably pretty common.

 

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <= rlb@ipv.sx> wrote:

I've renamed the issue to try to clarify.=

 

You're right that there are alternative ways to loca= te a key.  But a JOSE object needs to contain at least one of them, or= else the /* special magic */ clause applies.  

 

--Richard<= /o:p>

 

On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad <ietf@augustcellars.com> wrote:

This may or may not be a = flaw in the specification.  However the item you created in the tracke= r does not reflect what you have put here.  I think you would be better served by saying that there is a flaw in the specifications in t= hat there should be a MUST that some type of key or key reference is requir= ed in a JWS or JWE.

 <= /p>

I would note that your ex= ample code should be more complex in that it does not deal with jku or any = of the x* methods of referencing keys.

 <= /p>

Jim

 <= /p>

 <= /p>

From: Richard Barnes [mailto:rlb@ipv.sx] 
Sent: Friday, Marc= h 22, 2013 4:09 PM
To: Jim Schaad
Cc: <= span style=3D"color:purple">draft-ietf-jose-json-web-encryption@tools.ietf.= org; jo= se@ietf.org


Subject: Re: [jose= ] #15: Broken examples in JWE / JWS

 

I admit that they are not broken according to the cu= rrent spec.  However, I have a lot of trouble figuring out how I would= write code to process them.

 

If "kid" or "jwk" MUST be presen= t to indicate what key I should use, then I can have deterministic code:

if (/* recognized "kid" or "jwk"= value */) { 

    /* use it */

} else {

    /* FAIL.  can't process this obje= ct */

}

 

As the spec stands, I have no idea what to put in th= at "else" clause.  I'm clearly not supposed to fail, because= the parameters are optional.  But what else?

if (/* recognized "kid" or "jwk"= value */) { 

    /* use it */

} else {

    /* insert special magic here */

}

 

This is actually what SPI is supposed to clear up. &= nbsp;SPI would provide an explicit third branch for the special magic to li= ve in.

if (/* recognized "kid" or "jwk"= value */) { 

    /* use it */

} else if (/* recognized SPI value */) {<= /p>

    /* process using stored parameters */<= o:p>

} else {

    /* FAIL.  can't process this obje= ct */

}

 

But without the concept of SPI, the spec is broken b= ecause of the non-determinism noted above.

 

--Richard

 

 

 

On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad <ietf@augustcellars.com> wrote:

My inclination is that this response is correct.

What make you think that the key or key reference is required and cannot be=
implied?

Jim



> -----Original Message-----
> From: j= ose-bounces@ietf.org = [mailto:<= span style=3D"color:purple">jose-bounces@ietf.org] On Behalf Of
> jose issue tracker
> Sent: Friday, March 22, 2013 2:37 PM
> To: draft-ietf-jose-json-web-encryption@tools.ietf.or= g;
ignisvulpis@gmail.com
> Cc: jose@ietf.o= rg
> Subject: Re: [jose] #15: Broken examples in JWE / JWS
>
> #15: Broken examples in JWE / JWS
>
>
> Comment (by ignisvulpis@gmail.com):
>
>  I think this is not an issue. The examples are NOT broken and th= ey do not
> need a fix.
>  I suggest to close this ticket.
>  The draft should definitely not make these illegal. These object= s are
perfect
> examples for a valid JWS/JWE.
>
> --
> -------------------------+----------------------------------------= ------

> -------------------------+---

>  Reporter:  rlb@ipv.sx   |     &nb= sp; Owner:  draft-ietf-jose-json-web-
>      Type:  defect       |  encryption@tools.ietf.org
>  Priority:  minor        |    =  Status:  new
> Component:  json-web-    |   Milestone:
>   encryption             |   &= nbsp; Version:
>  Severity:  -            | &nb= sp;Resolution:
>  Keywords:               |
> -------------------------+----------------------------------------= ------

> -------------------------+---

>
> Ticket URL: <http://tra= c.tools.ietf.org/wg/jose/trac/ticket/15#comment:1>
> jose <http://tools.ietf.org/jose/>
>
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose

 

 


_______________________________________________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose

 

 

_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org= /mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367588A40TK5EX14MBXC283r_-- From dick.hardt@gmail.com Mon Mar 25 15:53:15 2013 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 BAF8921F866E for ; Mon, 25 Mar 2013 15:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=1.824, 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 8uunEOYBkice for ; Mon, 25 Mar 2013 15:53:15 -0700 (PDT) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC5421F8606 for ; Mon, 25 Mar 2013 15:53:15 -0700 (PDT) Received: by mail-pb0-f49.google.com with SMTP id um15so651821pbc.8 for ; Mon, 25 Mar 2013 15:53:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=1QQUsYUbwYi7cbjfzVa961Dxv5oo3EMWvO1W6+wNhaA=; b=zQVm1MpcQOlqr3KC1F2zJBXZfXyzh8zjiOuHU8KEtwvQqTZ1BHz/+B+ggw09UQyeLr Poboc0MvpH8rg/eDE1FcIW9ePAdenVhbTf7AZOX83XyC4pTCL4aOYEV+zGrgEPTL0LM+ ZJNHQTADO+Wz47gdwyTr5uaMn4V+sNKMUYy5MKSlP/5yNizE5hebmivU0H59FmiOznep MC8+R7UbDLZQ/ibmR5aBhC5jnSl3MFSZlWn37LA7ioOuisqt3gz/vOH+owTedebxgEEf 6gXfaMxjaZI16g5dnuqNCfjnKCoFKDTKE31sdZA+K+0/XTJbzQkQ5UVdhfKJFAu66EQb Qg7A== X-Received: by 10.66.155.135 with SMTP id vw7mr9891793pab.22.1364251994916; Mon, 25 Mar 2013 15:53:14 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id qh4sm10098250pac.8.2013.03.25.15.53.12 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:53:13 -0700 (PDT) From: Dick Hardt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> Date: Mon, 25 Mar 2013 15:53:11 -0700 To: jose@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Subject: [jose] 'aud' and 'iss' in JWE header 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, 25 Mar 2013 22:53:16 -0000 Hello everyone As I am implementing JOSE JWE, I would like to know who the 'iss' and = 'aud' is. I am using symmetric, shared keys and the 'aud' party would = like to know they really are the intended 'aud' and who the 'isa' is. = Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. I don't see an issue with disclosure of who 'iss' and 'aud' are as any = party able to intercept the token will have a pretty good idea of where = it is coming from and where it is going to. Knowing the 'iss' and 'aud' = allows the 'aud' to return an error before doing any crypto if the 'aud' = does not match or if there is no 'kid' for the 'iss'. Is there a reason why I cannot have 'iss' and 'aud' in the header? This is not an issue with JWS since the payload is clear and the 'aud' = can evaluate the 'iss' and 'aud' properties before doing crypto. -- Dick= From dick.hardt@gmail.com Mon Mar 25 15:56:26 2013 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 215F921F868E for ; Mon, 25 Mar 2013 15:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[AWL=0.911, 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 gPRfLVaddRwG for ; Mon, 25 Mar 2013 15:56:24 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3E95221F8558 for ; Mon, 25 Mar 2013 15:56:24 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bi5so1285195pad.3 for ; Mon, 25 Mar 2013 15:56:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=CJkkcNtphx1WBOuKazTEKJ/J1FkI/VbHvc85nJgPJAc=; b=Oeedo1dxexdLVIQXk7tTf8NdSNadkcFfYg0MqqI0j77MAS/V3dXQsHjZdygfK++qD0 GOYVHHnNlalCXtutefAuSTQXy1gPBFuaCY205XvE00suSRxF+Ai3vad6oVGU25p2/om5 zEXbjXQKzhmw7mTalPqKETxsR+Nca7+GQpS3ISFwNC9ediyYe9pGOqOC1tkocOenVHC+ H+2/1+Gs/S0vJcIIGSOhrhq3+StLTEiWrva4k/iI8Yb6Bbk4g5M4Ijxv9T3pZUz5MKRB 1acn4xgG42isTsLIzCdyShL8d+j44ZVVz2/KicOS4NmQYIxAkbH9cAdoyToM7g/4oT8r WEvw== X-Received: by 10.66.217.226 with SMTP id pb2mr20720148pac.142.1364252183969; Mon, 25 Mar 2013 15:56:23 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id y13sm14964205pbv.0.2013.03.25.15.56.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:56:22 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CD83D76B-1A75-44AE-87A7-965AC3976354" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367588A40@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Mon, 25 Mar 2013 15:56:19 -0700 Message-Id: <5D8CF39F-62AC-408B-A85A-1DF3319AD18A@gmail.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> <2D50F89B-5A07-4379-A532-CDC6B5E1BB33@gmail.com> <4E1F6AAD24975D4BA5B168042967394367588A40@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Richard Barnes , draft-ietf-jose-json-web-encryption@tools.ietf.org, Jim Schaad , Brian Campbell , jose@ietf.org Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:56:26 -0000 --Apple-Mail=_CD83D76B-1A75-44AE-87A7-965AC3976354 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I wish we would have put KID into OAuth 2.0.=20 Now if someone rotates the key without deploying everywhere they are = stored, then the app starts failing without a good error message. = Including a key id allows the server to give a more intelligent response = beside an authentication failure. On Mar 25, 2013, at 3:49 PM, Mike Jones = wrote: > As I=92d already written, I have no problem with some of the examples = containing a Key ID. But it=92s also the case in many deployment = environments that keys are pre-shared and known by both parties in = advance of any tokens being exchanged. This is often true when = per-client symmetric keys are used with OAuth, for instance. > =20 > -- Mike > =20 > From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 > Sent: Monday, March 25, 2013 3:43 PM > To: Mike Jones > Cc: Richard Barnes; Brian Campbell; = draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > =20 > I think the example should contain the KID as one would expect that to = be the common case. > =20 > On Mar 25, 2013, at 2:54 PM, Mike Jones = wrote: >=20 >=20 > If you already know that something is going on out of band, the = indication in the JOSE object would be unnecessary. > =20 > -- = Mike > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes > Sent: Monday, March 25, 2013 2:31 PM > To: Brian Campbell > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org > Subject: Re: [jose] #15: Broken examples in JWE / JWS > =20 > I realize that's the common case. But the spec doesn't say that. =20 > =20 > All I'm saying is, the spec should REQUIRE that a sender include = either a key indicator, or an indication that something is going on out = of band. > =20 > --Richard > =20 > =20 >=20 > On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell = wrote: > /* special magic */ is just some out of band agreement on the key to = use or how to infer it. Which isn't really special or magic. But = probably pretty common. > =20 >=20 > On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: > I've renamed the issue to try to clarify. > =20 > You're right that there are alternative ways to locate a key. But a = JOSE object needs to contain at least one of them, or else the /* = special magic */ clause applies. =20 > =20 > --Richard > =20 >=20 > On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad = wrote: > This may or may not be a flaw in the specification. However the item = you created in the tracker does not reflect what you have put here. I = think you would be better served by saying that there is a flaw in the = specifications in that there should be a MUST that some type of key or = key reference is required in a JWS or JWE. > =20 > I would note that your example code should be more complex in that it = does not deal with jku or any of the x* methods of referencing keys. > =20 > Jim > =20 > =20 > From: Richard Barnes [mailto:rlb@ipv.sx]=20 > Sent: Friday, March 22, 2013 4:09 PM > To: Jim Schaad > Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org >=20 > Subject: Re: [jose] #15: Broken examples in JWE / JWS > =20 > I admit that they are not broken according to the current spec. = However, I have a lot of trouble figuring out how I would write code to = process them. > =20 > If "kid" or "jwk" MUST be present to indicate what key I should use, = then I can have deterministic code: > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else { > /* FAIL. can't process this object */ > } > =20 > As the spec stands, I have no idea what to put in that "else" clause. = I'm clearly not supposed to fail, because the parameters are optional. = But what else? > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else { > /* insert special magic here */ > } > =20 > This is actually what SPI is supposed to clear up. SPI would provide = an explicit third branch for the special magic to live in. > if (/* recognized "kid" or "jwk" value */) {=20 > /* use it */ > } else if (/* recognized SPI value */) { > /* process using stored parameters */ > } else { > /* FAIL. can't process this object */ > } > =20 > But without the concept of SPI, the spec is broken because of the = non-determinism noted above. > =20 > --Richard > =20 > =20 > =20 >=20 > On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad = wrote: > My inclination is that this response is correct. >=20 > What make you think that the key or key reference is required and = cannot be > implied? >=20 > Jim >=20 >=20 > > -----Original Message----- > > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of > > jose issue tracker > > Sent: Friday, March 22, 2013 2:37 PM > > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; > ignisvulpis@gmail.com > > Cc: jose@ietf.org > > Subject: Re: [jose] #15: Broken examples in JWE / JWS > > > > #15: Broken examples in JWE / JWS > > > > > > Comment (by ignisvulpis@gmail.com): > > > > I think this is not an issue. The examples are NOT broken and they = do not > > need a fix. > > I suggest to close this ticket. > > The draft should definitely not make these illegal. These objects = are > perfect > > examples for a valid JWS/JWE. > > > > -- > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- > > Type: defect | encryption@tools.ietf.org > > Priority: minor | Status: new > > Component: json-web- | Milestone: > > encryption | Version: > > Severity: - | Resolution: > > Keywords: | > > = -------------------------+---------------------------------------------- > > -------------------------+--- > > > > Ticket URL: = > > jose > > > > _______________________________________________ > > jose mailing list > > jose@ietf.org > > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > =20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >=20 > =20 > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_CD83D76B-1A75-44AE-87A7-965AC3976354 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I wish we would have put KID = into OAuth 2.0. 

Now if someone rotates the key = without deploying everywhere they are stored, then the app starts = failing without a good error message. Including a key id allows the = server to give a more intelligent response beside an authentication = failure.

On Mar 25, 2013, at 3:49 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

If you already know that something is going = on out of band, the indication in the JOSE object would be = unnecessary.
 
 [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Monday, March 25, 2013 2:31 = PM
To: Brian = Campbell
Cc:  jose@ietf.org
Subject: Re: [jose] #15: Broken = examples in JWE / JWS
 
I realize that's the common case.  But the = spec doesn't say that.  
 
All I'm saying is, the spec should REQUIRE that a = sender include either a key indicator, or an indication that = something is going on out of band.
 
--Richard
 

On Mon, Mar = 25, 2013 at 8:15 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

/* = special magic */ is just some out of band agreement on the key to use or = how to infer it. Which isn't really special or magic. But probably = pretty common.

 

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <I've renamed the issue to try to = clarify.
 

>  Reporter:     |     =   Owner:  draft-ietf-jose-json-web-
>     =  Type:  defect       |  encryption@tools.ietf.org
> =  Priority:  minor        |     =  Status:  new
> Component:  json-web-   =  |   Milestone:
>   encryption       =       |     Version:
>  Severity: =  -            | =  Resolution:
>  Keywords:         =       |
> = -------------------------+----------------------------------------------
> = -------------------------+---

>
> Ticket URL: <   

 

_______________________________________________
jose = mailing list
jose@ietf.org
, "jose@ietf.org" Subject: Re: [jose] Minutes 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, 25 Mar 2013 22:57:18 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367588B2DTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "Impossible to separate wrapped key from encrypted data" (the title of issu= e #4) is a false statement. Nat pointed that out over a month ago in the i= ssue tracker. If that remains the title of the issue, it should be closed = on the merits of the issue. If you want to change the title of this one to "Should the encrypted key el= ement of a JWE no longer be included in the integrity check?" I'd have no p= roblem with the issue, because then it would be making a neutral statement = about a possible change. But right now, it's highly misleading, at best. None of that was captured in the minutes, even though it was all discussed = in Orlando. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Monday, March 25, 2013 3:11 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Minutes It's not accurate to say that Issue #4 is not a problem. We did clarify in= the meeting that the issue could use some re-statement, to clarify that th= e issue is the coverage of keys by the integrity check. So there's still a= n issue, namely whether the key needs to be covered by the integrity check. On Sun, Mar 24, 2013 at 9:02 PM, Mike Jones > wrote: I don't believe that the minutes adequately capture the discussion on issue= #4 (http://trac.tools.ietf.org/wg/jose/trac/ticket/4#). I would revise as follows: Data tracker issue #4 (Impossible to separate wrapped key from encrypted da= ta) - John Bradley's slides pointed out that it *is* possible to separate w= rapped keys from encrypted data when needed by using the direct encryption = mode and therefore asked for this issue to be closed, as it is based upon a= false premise. Mike Jones also asked for this to be closed on this basis,= and pointed out that Nat Sakimura had already described the problem with t= his issue in the issue tracker. Richard asked a question about the securit= y analysis of including the wrapped key in the integrity calculation - Does= the wrapped key need to be included in the integrity check or not? The qu= estion will be referred to CFRG but a request for possible attack modes bei= ng sent to the list is requested. Given that the problem stated in issue #4 was demonstrated to not actually = be a problem during the discussions, I would ask again that the chairs clos= e this one, and update the minutes to reflect this. Thank you, -- Mike From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, March 22, 2013 1:12 PM To: jose@ietf.org Subject: [jose] Minutes Preliminary minutes have been uploaded to the site. Please review and comm= ent back to me if you have disagreements. http://www.ietf.org/proceedings/86/minutes/minutes-86-jose Note that the minutes have an action list at the bottom of them. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_4E1F6AAD24975D4BA5B168042967394367588B2DTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

“Impossible to separate wrapped key from encrypted data” (the title of issue #4) is a false statement.  Nat pointed that out o= ver a month ago in the issue tracker.  If that remains the title of th= e issue, it should be closed on the merits of the issue.<= /p>

 <= /p>

If you want to change the= title of this one to “Should the encrypted key element of a JWE no l= onger be included in the integrity check?” I’d have no problem with the issue, because then it would be making a neutral statement about = a possible change.  But right now, it’s highly misleading, at be= st.

 <= /p>

None of that was captured= in the minutes, even though it was all discussed in Orlando.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 3:11 PM
To: Mike Jones
Cc: Jim Schaad; jose@ietf.org
Subject: Re: [jose] Minutes

 

It's not accurate to say that Issue #4 is not a prob= lem.  We did clarify in the meeting that the issue could use some re-s= tatement, to clarify that the issue is the coverage of keys by the integrit= y check.  So there's still an issue, namely whether the key needs to be covered by the integrity check.

 

 

On Sun, Mar 24, 2013 at 9:02 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I don’t believe that the minut= es adequately capture the discussion on issue #4 (http://trac.tools.iet= f.org/wg/jose/trac/ticket/4#).  I would revise as follows:

 

Data tracker issue #4 (Impossible to= separate wrapped key from encrypted data) – John Bradley’s sli= des pointed out that it *is* possible to separate wrapped keys from encrypted data when needed by using the direct encryptio= n mode and therefore asked for this issue to be closed, as it is based upon= a false premise.  Mike Jones also asked for this to be closed on this= basis, and pointed out that Nat Sakimura had already described the problem with this issue in the issue tracker. &n= bsp;Richard asked a question about the security analysis of including the w= rapped key in the integrity calculation - Does the wrapped key need to be i= ncluded in the integrity check or not?  The question will be referred to CFRG but a request for possible attack mo= des being sent to the list is requested.

 

Given that the problem stated in iss= ue #4 was demonstrated to not actually be a problem during the discussions,= I would ask again that the chairs close this one, and update the minutes to reflect this.

 

      =             &nb= sp;            =             &nb= sp;            =     Thank you,

      =             &nb= sp;            =             &nb= sp;            =     -- Mike

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, March 22, 2013 1:12 PM
To: jose@ietf.org=
Subject: [jose] Minutes

 

Preliminary minutes have been uploaded to the site.  Please r= eview and comment back to me if you have disagreements.

 

http://www.ietf.org/proceedings/86/minutes/minutes-8= 6-jose

 

Note that the minutes have an action list at the bottom of them.

 

Jim

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_4E1F6AAD24975D4BA5B168042967394367588B2DTK5EX14MBXC283r_-- From dick.hardt@gmail.com Mon Mar 25 15:58:24 2013 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 8C65521F862D for ; Mon, 25 Mar 2013 15:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=0.608, 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 plZ0UBU9TW34 for ; Mon, 25 Mar 2013 15:58:23 -0700 (PDT) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 518F121F8626 for ; Mon, 25 Mar 2013 15:58:18 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id fa10so1269611pad.41 for ; Mon, 25 Mar 2013 15:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=L1AmlytddcRgrb2vkeuPNzupjBcPtW2/7q5aeBnKAIU=; b=lI8A170ivj2lN/5EW/TdLzNGVAzfGnllEXnLvGN2OrJDarVHLCd7FZETWz99Ph5afJ tuyA4EHhfhvCDN8+KXibBhsrgARsfGZ6thehZZ+zRTelP86nPeCldv5X9t756H9xdyHa Ypq5jCV94AiBjVSyAF5PAk2tWwJYoNgceZDDsjzMp5YS1+Z/yq6YhxiSbghkcjO4CwNW wjdKfWeRZkjULHcqSyUB1j/Dg2oi5DAtg9AdMJw3cZw42Q2LWGl8lipZ7kdXpoPTtDbH VfI6F5dqhjOlWTbn9NHKJ4xOYsO7cu+uzaQPWXbMc4KLaolSYiqFVkpmtOwfh277+fVy HLBw== X-Received: by 10.68.212.233 with SMTP id nn9mr19746087pbc.144.1364252298080; Mon, 25 Mar 2013 15:58:18 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ky17sm16420500pab.23.2013.03.25.15.58.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 15:58:16 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_D99D1743-0735-42BB-B23B-E186D3CD17D2" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <5D8CF39F-62AC-408B-A85A-1DF3319AD18A@gmail.com> Date: Mon, 25 Mar 2013 15:58:13 -0700 Message-Id: <89C8B626-2BC9-4E3E-AADA-AD72A9D2F996@gmail.com> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> <064.854734170572ce8e0ba10611390025ce@trac.tools.ietf.org> <012701ce274a$8e17ca30$aa475e90$@augustcellars.com> <013c01ce2763$ef72d950$ce588bf0$@augustcellars.com> <4E1F6AAD24975D4BA5B1680429673943675886B8@TK5EX14MBXC283.redmond.corp.microsoft.com> <2D50F89B-5A07-4379-A532-CDC6B5E1BB33@gmail.com> <4E1F6AAD24975D4BA5B168042967394367588A40@TK5EX14MBXC283.redmond.corp.microsoft.com> <5D8CF39F-62AC-408B-A85A-1DF3319AD18A@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1503) Cc: Richard Barnes , draft-ietf-jose-json-web-encryption@tools.ietf.org, Jim Schaad , Mike Jones , jose@ietf.org, Brian Campbell Subject: Re: [jose] #15: Broken examples in JWE / JWS 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, 25 Mar 2013 22:58:24 -0000 --Apple-Mail=_D99D1743-0735-42BB-B23B-E186D3CD17D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 btw: good OAuth 2.0 implementations embed KID into the opaque token so = that they can give a meaningful error message On Mar 25, 2013, at 3:56 PM, Dick Hardt wrote: > I wish we would have put KID into OAuth 2.0.=20 >=20 > Now if someone rotates the key without deploying everywhere they are = stored, then the app starts failing without a good error message. = Including a key id allows the server to give a more intelligent response = beside an authentication failure. >=20 > On Mar 25, 2013, at 3:49 PM, Mike Jones = wrote: >=20 >> As I=92d already written, I have no problem with some of the examples = containing a Key ID. But it=92s also the case in many deployment = environments that keys are pre-shared and known by both parties in = advance of any tokens being exchanged. This is often true when = per-client symmetric keys are used with OAuth, for instance. >> =20 >> -- Mike >> =20 >> From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 >> Sent: Monday, March 25, 2013 3:43 PM >> To: Mike Jones >> Cc: Richard Barnes; Brian Campbell; = draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org >> Subject: Re: [jose] #15: Broken examples in JWE / JWS >> =20 >> I think the example should contain the KID as one would expect that = to be the common case. >> =20 >> On Mar 25, 2013, at 2:54 PM, Mike Jones = wrote: >>=20 >>=20 >> If you already know that something is going on out of band, the = indication in the JOSE object would be unnecessary. >> =20 >> -- = Mike >> =20 >> From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Richard Barnes >> Sent: Monday, March 25, 2013 2:31 PM >> To: Brian Campbell >> Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; Jim Schaad; = jose@ietf.org >> Subject: Re: [jose] #15: Broken examples in JWE / JWS >> =20 >> I realize that's the common case. But the spec doesn't say that. =20 >> =20 >> All I'm saying is, the spec should REQUIRE that a sender include = either a key indicator, or an indication that something is going on out = of band. >> =20 >> --Richard >> =20 >> =20 >>=20 >> On Mon, Mar 25, 2013 at 8:15 AM, Brian Campbell = wrote: >> /* special magic */ is just some out of band agreement on the key to = use or how to infer it. Which isn't really special or magic. But = probably pretty common. >> =20 >>=20 >> On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes wrote: >> I've renamed the issue to try to clarify. >> =20 >> You're right that there are alternative ways to locate a key. But a = JOSE object needs to contain at least one of them, or else the /* = special magic */ clause applies. =20 >> =20 >> --Richard >> =20 >>=20 >> On Fri, Mar 22, 2013 at 9:15 PM, Jim Schaad = wrote: >> This may or may not be a flaw in the specification. However the item = you created in the tracker does not reflect what you have put here. I = think you would be better served by saying that there is a flaw in the = specifications in that there should be a MUST that some type of key or = key reference is required in a JWS or JWE. >> =20 >> I would note that your example code should be more complex in that it = does not deal with jku or any of the x* methods of referencing keys. >> =20 >> Jim >> =20 >> =20 >> From: Richard Barnes [mailto:rlb@ipv.sx]=20 >> Sent: Friday, March 22, 2013 4:09 PM >> To: Jim Schaad >> Cc: draft-ietf-jose-json-web-encryption@tools.ietf.org; jose@ietf.org >>=20 >> Subject: Re: [jose] #15: Broken examples in JWE / JWS >> =20 >> I admit that they are not broken according to the current spec. = However, I have a lot of trouble figuring out how I would write code to = process them. >> =20 >> If "kid" or "jwk" MUST be present to indicate what key I should use, = then I can have deterministic code: >> if (/* recognized "kid" or "jwk" value */) {=20 >> /* use it */ >> } else { >> /* FAIL. can't process this object */ >> } >> =20 >> As the spec stands, I have no idea what to put in that "else" clause. = I'm clearly not supposed to fail, because the parameters are optional. = But what else? >> if (/* recognized "kid" or "jwk" value */) {=20 >> /* use it */ >> } else { >> /* insert special magic here */ >> } >> =20 >> This is actually what SPI is supposed to clear up. SPI would provide = an explicit third branch for the special magic to live in. >> if (/* recognized "kid" or "jwk" value */) {=20 >> /* use it */ >> } else if (/* recognized SPI value */) { >> /* process using stored parameters */ >> } else { >> /* FAIL. can't process this object */ >> } >> =20 >> But without the concept of SPI, the spec is broken because of the = non-determinism noted above. >> =20 >> --Richard >> =20 >> =20 >> =20 >>=20 >> On Fri, Mar 22, 2013 at 6:13 PM, Jim Schaad = wrote: >> My inclination is that this response is correct. >>=20 >> What make you think that the key or key reference is required and = cannot be >> implied? >>=20 >> Jim >>=20 >>=20 >> > -----Original Message----- >> > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On = Behalf Of >> > jose issue tracker >> > Sent: Friday, March 22, 2013 2:37 PM >> > To: draft-ietf-jose-json-web-encryption@tools.ietf.org; >> ignisvulpis@gmail.com >> > Cc: jose@ietf.org >> > Subject: Re: [jose] #15: Broken examples in JWE / JWS >> > >> > #15: Broken examples in JWE / JWS >> > >> > >> > Comment (by ignisvulpis@gmail.com): >> > >> > I think this is not an issue. The examples are NOT broken and they = do not >> > need a fix. >> > I suggest to close this ticket. >> > The draft should definitely not make these illegal. These objects = are >> perfect >> > examples for a valid JWS/JWE. >> > >> > -- >> > = -------------------------+---------------------------------------------- >> > -------------------------+--- >> > Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- >> > Type: defect | encryption@tools.ietf.org >> > Priority: minor | Status: new >> > Component: json-web- | Milestone: >> > encryption | Version: >> > Severity: - | Resolution: >> > Keywords: | >> > = -------------------------+---------------------------------------------- >> > -------------------------+--- >> > >> > Ticket URL: = >> > jose >> > >> > _______________________________________________ >> > jose mailing list >> > jose@ietf.org >> > https://www.ietf.org/mailman/listinfo/jose >>=20 >> =20 >> =20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >>=20 >> =20 >> =20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 --Apple-Mail=_D99D1743-0735-42BB-B23B-E186D3CD17D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 btw: = good OAuth 2.0 implementations embed KID into the opaque token so that = they can give a meaningful error message

On Mar 25, = 2013, at 3:56 PM, Dick Hardt <dick.hardt@gmail.com> = wrote:

I wish we would have put KID = into OAuth 2.0. 

Now if someone rotates the key = without deploying everywhere they are stored, then the app starts = failing without a good error message. Including a key id allows the = server to give a more intelligent response beside an authentication = failure.

On Mar 25, 2013, at 3:49 PM, Mike Jones = <Michael.Jones@microsoft.com> wrote:

If you already know that something is going = on out of band, the indication in the JOSE object would be = unnecessary.
 
 [mailto:jose-bounces@ietf.org] On Behalf Of Richard = Barnes
Sent: Monday, March 25, 2013 2:31 = PM
To: Brian = Campbell
Cc:  jose@ietf.org
Subject: Re: [jose] #15: Broken = examples in JWE / JWS
 
I realize that's the common case.  But the = spec doesn't say that.  
 
All I'm saying is, the spec should REQUIRE that a = sender include either a key indicator, or an indication that = something is going on out of band.
 
--Richard
 

On Mon, Mar = 25, 2013 at 8:15 AM, Brian Campbell <bcampbell@pingidentity.com> = wrote:

/* = special magic */ is just some out of band agreement on the key to use or = how to infer it. Which isn't really special or magic. But probably = pretty common.

 

On Fri, Mar 22, 2013 at 7:37 PM, Richard Barnes <I've renamed the issue to try to = clarify.
 

>  Reporter:     |     =   Owner:  draft-ietf-jose-json-web-
>     =  Type:  defect       |  encryption@tools.ietf.org
> =  Priority:  minor        |     =  Status:  new
> Component:  json-web-   =  |   Milestone:
>   encryption       =       |     Version:
>  Severity: =  -            | =  Resolution:
>  Keywords:         =       |
> = -------------------------+----------------------------------------------
> = -------------------------+---

>
> Ticket URL: <   

 

_______________________________________________
jose = mailing list
jose@ietf.org
To: Juraj Somorovsky , Vladimir Dzhuvinov / NimbusDS Date: Tue, 26 Mar 2013 09:58:48 +1100 Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: Ac4pf6/coh0J+HSdRw2NZs5VrrJdhgAK7dtQ Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BE3C5A5@WSMSG3153V.srv.dir.telstra.com> References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> <51505BFA.7080100@rub.de> In-Reply-To: <51505BFA.7080100@rub.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 25 Mar 2013 22:58:50 -0000 PiB5b3UgYXJlIHJpZ2h0LCB0aGUgcmFuZG9tIG51bWJlciBnZW5lcmF0aW9uICptdXN0IG5vdCog YmUgZG9uZSBpbiB0aGUNCj4gY2F0Y2ggYmxvY2ssIGl0IGNvdWxkIGJlIG1lYXN1cmVkIGFuZCBs ZWFrIGFuIGluZm9ybWF0aW9uIGFib3V0DQo+IGNpcGhlcnRleHQgdmFsaWRpdHkuDQo+IA0KPiBJ IHdvdWxkIHByb3Bvc2UgdGhpcyBjb2RlOg0KPiANCj4gaWYgKGFsZy5lcXVhbHMoSldFQWxnb3Jp dGhtLlJTQTFfNSkpIHsNCj4gCWludCBrZXlMZW5ndGggPQ0KPiBjbWtCaXRMZW5ndGgocmVhZE9u bHlKV0VIZWFkZXIuZ2V0RW5jcnlwdGlvbk1ldGhvZCgpKTsNCj4gCVNlY3JldEtleSByYW5kb21D TUsgPSBBRVMuZ2VuZXJhdGVBRVNDTUsoa2V5TGVuZ3RoKTsNCj4gDQo+IAl0cnkgew0KPiAJCWNt ayA9IFJTQTFfNS5kZWNyeXB0Q01LKHByaXZhdGVLZXksIGVuY3J5cHRlZEtleS5kZWNvZGUoKSwN Cj4ga2V5TGVuZ3RoKTsNCj4gCX0gY2F0Y2ggKEV4Y2VwdGlvbiBlKSB7DQo+IAkJLy8gUHJvdGVj dCBhZ2FpbnN0IE1NQSBhdHRhY2sgYnkgZ2VuZXJhdGluZyByYW5kb20gQ01LIG9uDQo+IGZhaWx1 cmUsDQo+IAkJLy8gc2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC0NCj4gYXJjaGl2ZS93ZWIv am9zZS9jdXJyZW50L21zZzAxODMyLmh0bWwNCj4gCQljbWsgPSByYW5kb21DTUs7DQo+IAl9DQo+ IH0NCj4gDQo+IA0KPiBUaGlzIHdvdWxkIGJlIHBlcmZlY3QgYW5kIGFsc28gc2VjdXJlIGFnYWlu c3QgdGltaW5nIGF0dGFja3MuDQoNCg0KVGhpcyBjb2RlIG1heSBiZSBhIGJpdCBtb3JlIHJlc2lz dGFudCB0byB0aW1pbmcgYXR0YWNrcywgYnV0IGl0IGlzIG5vd2hlcmUgbmVhciBwZXJmZWN0Lg0K DQpUYWtlIGF0IGxvb2sgYXQgaHR0cDovL3d3dy5pbXBlcmlhbHZpb2xldC5vcmcvMjAxMy8wMi8w NC9sdWNreXRoaXJ0ZWVuLmh0bWwgZm9yIHNvbWUgaWRlYSBhYm91dCB0aGUgY2FyZSByZXF1aXJl ZCB0byBhY3R1YWxseSByZXNpc3QgdGltaW5nIGF0dGFja3MuDQoNCi0tDQpKYW1lcyBNYW5nZXIN Cg== From ve7jtb@ve7jtb.com Mon Mar 25 16:02:42 2013 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 E201D21F8628 for ; Mon, 25 Mar 2013 16:02:42 -0700 (PDT) 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=[AWL=0.001, 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 tZjF1XpwhTYz for ; Mon, 25 Mar 2013 16:02:42 -0700 (PDT) Received: from mail-qe0-f45.google.com (mail-qe0-f45.google.com [209.85.128.45]) by ietfa.amsl.com (Postfix) with ESMTP id 12A5221F86BC for ; Mon, 25 Mar 2013 16:02:28 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id b4so3579442qen.32 for ; Mon, 25 Mar 2013 16:02:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=cRgE/GngOQoFiD8///Xr5Vr0oi1huDPujgaNvfikdMM=; b=kXZlMc8OZqWVJFhjT1ZwpQlkgEQJi5uQNyADCGFFMTG0HfQBLVECwik1Kjh1ATIPqI OSD4fBdR2jbs0DUPUHfXaUkvmHCnOl6gse+JQa9ZFYV3e5bc8T6L58sEiDho+WMXOfEZ Qx7XLrms2MNRYfcbA3SDe3myZCmNRWKGgm6tY2mnX03QtZDDe/gInPj92NFysntzwztI eY+i9aWj2M9Re0KmhPdgdlDUY3PT59YSs3W3tLL+tBdyhQKUvxcM2YcLV9th8dHttqNU 10WxvDx1QNqZcxxUH2IahxOSzb4mQqd8egafN/ukNN+FDvDaMk9K5TCvr7rMmx5+JSkT 1C8A== X-Received: by 10.229.112.81 with SMTP id v17mr1383559qcp.93.1364252548396; Mon, 25 Mar 2013 16:02:28 -0700 (PDT) Received: from [192.168.1.34] (190-20-41-38.baf.movistar.cl. [190.20.41.38]) by mx.google.com with ESMTPS id az3sm4125971qeb.7.2013.03.25.16.02.23 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 16:02:26 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_B52E8796-1F92-4605-A6E5-47C994E429E2"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> Date: Mon, 25 Mar 2013 20:02:35 -0300 Message-Id: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlLDY72jqy860BWjyoSi9aEvmIUghUljVQ17zMTnYRaBX7Kdm3IegBm1czq6h1d32+a4MYM Cc: jose@ietf.org Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 25 Mar 2013 23:02:43 -0000 --Apple-Mail=_B52E8796-1F92-4605-A6E5-47C994E429E2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Once the change to ignore additional elements in the header there is = nothing to stop you from doing that. You make a good point about scoping the 'kid' to the 'iss'.=20 John B. On 2013-03-25, at 7:53 PM, Dick Hardt wrote: > Hello everyone >=20 > As I am implementing JOSE JWE, I would like to know who the 'iss' and = 'aud' is. I am using symmetric, shared keys and the 'aud' party would = like to know they really are the intended 'aud' and who the 'isa' is. = Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >=20 > I don't see an issue with disclosure of who 'iss' and 'aud' are as any = party able to intercept the token will have a pretty good idea of where = it is coming from and where it is going to. Knowing the 'iss' and 'aud' = allows the 'aud' to return an error before doing any crypto if the 'aud' = does not match or if there is no 'kid' for the 'iss'. >=20 > Is there a reason why I cannot have 'iss' and 'aud' in the header? >=20 > This is not an issue with JWS since the payload is clear and the 'aud' = can evaluate the 'iss' and 'aud' properties before doing crypto. >=20 > -- Dick > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_B52E8796-1F92-4605-A6E5-47C994E429E2 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI1MjMwMjM1WjAjBgkqhkiG9w0BCQQxFgQUpe0hq3HJ TRwlD4ru8FeAFP4O6cAwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAeYn7H6Y+PTacx+ILESy98a7SC8/Y+6Jf64gwg+bM dBg7W/1LpLZl78Rpo2xjgCavrffB+dv3ND2rDMS6yykZ9xLWq8x0qNEQTOXMJt4et7fqkvxBmjYQ vo5Qqlrgqlme6Ba6j8W5Vb5XozGnNSvXGockxHjQQZ1S2df29IJ5oukrDr+sGMFOZyr3nCyt86eq vHCkqFOGFkgFqQyJgP4R82OJSGqFA8EBjengczDg9fWAw2O1PbrdZTgH220gDTR2tLMawT/x2rWf VN8gAhRoMLn2YmooxnP6UU4c3nDHt819OBcXHVWMyT+9geE7amtnNItbHEEDEXoAqfdlcKM2cgAA AAAAAA== --Apple-Mail=_B52E8796-1F92-4605-A6E5-47C994E429E2-- From dick.hardt@gmail.com Mon Mar 25 16:09:08 2013 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 2BD2221F8804 for ; Mon, 25 Mar 2013 16:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.143 X-Spam-Level: X-Spam-Status: No, score=-3.143 tagged_above=-999 required=5 tests=[AWL=0.456, 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 DrnBNK-1G7yy for ; Mon, 25 Mar 2013 16:09:07 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9694E21F87B6 for ; Mon, 25 Mar 2013 16:09:07 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4414444pbb.18 for ; Mon, 25 Mar 2013 16:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=WAFl/nNbSPivpQBSY6DS6rZVh7xCSwQGoSAdvKPJeqM=; b=MHlA4MPXQnYLanyZ0ztyWI53yrQu88NR/HsOhLN7c45zil12tpmx5AKtyGhoHLwKtj /1olpknVWn4dlHylelZCPADt0Xq5LNXh7Jx9AiycFfzKiGQFr+WN5Cuo3R33MUtODkcG Zi3yoygbTIxH8xy4A+eXoHHezndyXwJleti7B4t/GzsPFPlFeMf9A9P8g7RgZId8Wvn2 VM+CMdyA7zRBx55Rb9pBuyYe2Jq3DAn6DbihX4tJ+AW4MizHmp3i0Mkmg9SZ1wI+knD2 npgX8m2rKiPOGJtUSEhzC7VHd9BVRQi8JO65BRDn2cf4aeggywxnxEFrlL/qfLCNlGvW 78Vg== X-Received: by 10.66.252.162 with SMTP id zt2mr21010288pac.1.1364252947429; Mon, 25 Mar 2013 16:09:07 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id rl3sm14951676pbb.28.2013.03.25.16.09.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 16:09:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: Date: Mon, 25 Mar 2013 16:09:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 25 Mar 2013 23:09:08 -0000 Will that be compliant though? I would like to spec to say that I can = optionally include those properties in the header of a JWE. On Mar 25, 2013, at 4:02 PM, John Bradley wrote: > Once the change to ignore additional elements in the header there is = nothing to stop you from doing that. >=20 > You make a good point about scoping the 'kid' to the 'iss'.=20 >=20 > John B. >=20 > On 2013-03-25, at 7:53 PM, Dick Hardt wrote: >=20 >> Hello everyone >>=20 >> As I am implementing JOSE JWE, I would like to know who the 'iss' and = 'aud' is. I am using symmetric, shared keys and the 'aud' party would = like to know they really are the intended 'aud' and who the 'isa' is. = Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>=20 >> I don't see an issue with disclosure of who 'iss' and 'aud' are as = any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>=20 >> Is there a reason why I cannot have 'iss' and 'aud' in the header? >>=20 >> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>=20 >> -- Dick >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From ve7jtb@ve7jtb.com Mon Mar 25 16:19:29 2013 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 0028D21F8573 for ; Mon, 25 Mar 2013 16:19:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=-1.829, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.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 GeBf2UQLcFCg for ; Mon, 25 Mar 2013 16:19:27 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECED21F8570 for ; Mon, 25 Mar 2013 16:19:27 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id j3so2870263qcs.20 for ; Mon, 25 Mar 2013 16:19:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=PaHtyAUHwwclxGQToBwzKR5mjPu0uP5Oi/ce2t4apt0=; b=cegORfFrGZBl9P78URbL9r+OEPrLzUVFr5ccgT/k8EEDH5foA4LXnMkDRY2hUf7/j4 tBpEIdWmyN4pj3rXLknu/OqTAOB9VU1nCuA7cinKjFJkYVM5r0ZTKu88nnw+lzK3UJZC IYx5s9tqKWz/ICyupNJ6L8TWIpjuj5FreDwpUWqB/Bni5Uo42TpRYJ1rsRLtms+kcDld UChcc7UTqSe3YoXOn0zjML5jtdelVeR837trcuE7L2mwOkRSoWlFQ551gguccG8QDXFR D1KcmOx2L+1xVxcGKpXTTgJycKH9HWYoqRJwiuJp8ac24SwK+N2C6M8N2VaHRZuGdRO3 8B1w== X-Received: by 10.49.3.134 with SMTP id c6mr1673555qec.41.1364253566963; Mon, 25 Mar 2013 16:19:26 -0700 (PDT) Received: from [192.168.1.34] (190-20-41-38.baf.movistar.cl. [190.20.41.38]) by mx.google.com with ESMTPS id dt10sm4282260qab.0.2013.03.25.16.19.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 16:19:25 -0700 (PDT) Content-Type: multipart/signed; boundary="Apple-Mail=_7DF6881E-3B78-496F-9B99-B2045C720CEE"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: John Bradley In-Reply-To: Date: Mon, 25 Mar 2013 20:19:34 -0300 Message-Id: <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> To: Dick Hardt X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQmdtcAMqQNZyXi1sGqqcY77FA67Nm3keH9PKxYMfh2BvrBu2PCEnljWej3UT1Bo8E7+coDk Cc: jose@ietf.org Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 25 Mar 2013 23:19:29 -0000 --Apple-Mail=_7DF6881E-3B78-496F-9B99-B2045C720CEE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii That will be compliant. The spec won't call out those particular = properties from JWT. =20 If you think that they should be called out as optional parameters that = could be considered. However that is not a open issue at this point. John B. On 2013-03-25, at 8:09 PM, Dick Hardt wrote: > Will that be compliant though? I would like to spec to say that I can = optionally include those properties in the header of a JWE. >=20 >=20 > On Mar 25, 2013, at 4:02 PM, John Bradley wrote: >=20 >> Once the change to ignore additional elements in the header there is = nothing to stop you from doing that. >>=20 >> You make a good point about scoping the 'kid' to the 'iss'.=20 >>=20 >> John B. >>=20 >> On 2013-03-25, at 7:53 PM, Dick Hardt wrote: >>=20 >>> Hello everyone >>>=20 >>> As I am implementing JOSE JWE, I would like to know who the 'iss' = and 'aud' is. I am using symmetric, shared keys and the 'aud' party = would like to know they really are the intended 'aud' and who the 'isa' = is. Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>>=20 >>> I don't see an issue with disclosure of who 'iss' and 'aud' are as = any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>>=20 >>> Is there a reason why I cannot have 'iss' and 'aud' in the header? >>>=20 >>> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>>=20 >>> -- Dick >>> _______________________________________________ >>> jose mailing list >>> jose@ietf.org >>> https://www.ietf.org/mailman/listinfo/jose >>=20 >=20 --Apple-Mail=_7DF6881E-3B78-496F-9B99-B2045C720CEE Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIN8TCCBjQw ggQcoAMCAQICASAwDQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAn BgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3MTAyNDIxMDI1NVoX DTE3MTAyNDIxMDI1NVowgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSsw KQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFy dENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAMsohUWcASz7GfKrpTOMKqANy9BV7V0igWdGxA8IU77L3aTxErQ+ fcxtDYZ36Z6GH0YFn7fq5RADteP0AYzrCA+EQTfi8q1+kA3m0nwtwXG94M5sIqsvs7lRP1aycBke /s5g9hJHryZ2acScnzczjBCAo7X1v5G3yw8MDP2m2RCye0KfgZ4nODerZJVzhAlOD9YejvAXZqHk sw56HzElVIoYSZ3q4+RJuPXXfIoyby+Y2m1E+YzX5iCZXBx05gk6MKAW1vaw4/v2OOLy6FZH3XHH tOkzUreG//CsFnB9+uaYSlR65cdGzTsmoIK8WH1ygoXhRBm98SD7Hf/r3FELNvUCAwEAAaOCAa0w ggGpMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSuVYNv7DHKufcd +q9rMfPIHeOsuzAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRa MFgwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYh aHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5j b20vc2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0 dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93d3cu c3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQEFBQADggIBADqpJw3I07QW ke9plNBpxUxcffc7nUrIQpJHDci91DFG7fVhHRkMZ1J+BKg5UNUxIFJ2Z9B90Micc/NXcs7kPBRd n6XGO/vPc87Y6R+cWS9Nc9+fp3Enmsm94OxOwI9wn8qnr/6o3mD4noP9JphwUPTXwHovjavRnhUQ HLfo/i2NG0XXgTHXS2Xm0kVUozXqpYpAdumMiB/vezj1QHQJDmUdPYMcp+reg9901zkyT3fDW/iv JVv6pWtkh6Pw2ytZT7mvg7YhX3V50Nv860cV11mocUVcqBLv0gcT+HBDYtbuvexNftwNQKD5193A 7zN4vG7CTYkXxytSjKuXrpEatEiFPxWgb84nVj25SU5q/r1Xhwby6mLhkbaXslkVtwEWT3Van49r KjlK4XrUKYYWtnfzq6aSak5u0Vpxd1rY79tWhD3EdCvOhNz/QplNa+VkIsrcp7+8ZhP1l1b2U6Ma xIVteuVMD3X0vziIwr7jxYae9FZjbxlpUemqXjcC0QaFfN7qI0JsQMALL7iGRBg7K0CoOBzECdD3 fuZil5kU/LP9cr1BK31U0Uy651bFnAMMMkqhAChIbn0ei72VnbpSsrrSdF0BAGYQ8vyHae5aCg+H 75dVCV33K6FuxZrf09yTz+Vx/PkdRUYkXmZz/OTfyJXsUOUXrym6KvI2rYpccSk5MIIHtTCCBp2g AwIBAgICHlwwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENv bSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYD VQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0x MjAzMTgwNDMyNDhaFw0xNDAzMTkxMTA3MzJaMIGbMRkwFwYDVQQNExBHclRNNkxTN1gzNTc3OHM5 MQswCQYDVQQGEwJDTDEiMCAGA1UECBMZTWV0cm9wb2xpdGFuYSBkZSBTYW50aWFnbzEWMBQGA1UE BxMNSXNsYSBkZSBNYWlwbzEVMBMGA1UEAxMMSm9obiBCcmFkbGV5MR4wHAYJKoZIhvcNAQkBFg9q YnJhZGxleUBtZS5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCySuUEj3esFMs5 AZLAhPpyjp0DD+vAM+tFeXr8XahzgoOf5A3oJ0V4ejTwfzjpUlL0IOMsq+cr2NvHGzjBip6cp09v eODO3yhztv1le1aQ6CzGAx/p0Fn8g+biVYGkJtKvex4MYNcSmITaVNleejtzbk6C5HgTpBqFykcA FmN4RYrrmYwfbmCahF/kxjWTeq67nL4UJgIcTaLBTmPOr6YjceYbn35QwUvHV+NX7NOyVHDbpxAM L+56nCN5hKnxLbqF9aKlVbBCPiOz8LtGg+2+3aLJ5T4tIfzWMbjCUBae2I4bVa2hdS5dZJwTGFyI p4pYKd6bL2qqbFF8moFE54aVAgMBAAGjggQOMIIECjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD8Dv8LEoSfOmqZmUvP2JpAz Lbh5MB8GA1UdIwQYMBaAFK5Vg2/sMcq59x36r2sx88gd46y7MH4GA1UdEQR3MHWBD2picmFkbGV5 QG1lLmNvbYEPamJyYWRsZXlAbWUuY29tgRBqYnJhZGxleUBtYWMuY29tgRF2ZTdqdGJAdmU3anRi LmNvbYETamJyYWRsZXlAd2luZ2FhLmNvbYEXam9obi5icmFkbGV5QHdpbmdhYS5jb20wggIhBgNV HSAEggIYMIICFDCCAhAGCysGAQQBgbU3AQICMIIB/zAuBggrBgEFBQcCARYiaHR0cDovL3d3dy5z dGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5j b20vaW50ZXJtZWRpYXRlLnBkZjCB9wYIKwYBBQUHAgIwgeowJxYgU3RhcnRDb20gQ2VydGlmaWNh dGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUgd2FzIGlzc3VlZCBhY2NvcmRp bmcgdG8gdGhlIENsYXNzIDIgVmFsaWRhdGlvbiByZXF1aXJlbWVudHMgb2YgdGhlIFN0YXJ0Q29t IENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVuZGVkIHB1cnBvc2UgaW4gY29t cGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9ucy4wgZwGCCsGAQUFBwICMIGP MCcWIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MAMCAQIaZExpYWJpbGl0eSBhbmQg d2FycmFudGllcyBhcmUgbGltaXRlZCEgU2VlIHNlY3Rpb24gIkxlZ2FsIGFuZCBMaW1pdGF0aW9u cyIgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeS4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2Ny bC5zdGFydHNzbC5jb20vY3J0dTItY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcw AYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczIvY2xpZW50L2NhMEIGCCsGAQUF BzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MyLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IB AQARx8Pg+Yetf5bfNo/8qxHiDAsAvRRNozPXhIieDpr0XeRvxkNtNSd5L25uCmp4lA/YgVzRTmBC cndd4Ifqn0jzya+bU2opDDxa9+CVLRohLX29+lOBclI90g7Ykk9GpoG1d/fOR1cnByRf3900yssZ 4a9oVP19Q11B0dTgEjWlVSmAqvv3pPstNz8RF8fyIWnX4KZ1WQnpjaIl1ZSniHXteZvFshPQJ1Lh JKT9VbwsWyf+ZXPqEHvdW2HCMawiS7nhanilG6rUpf6kBOdGTekdFrXPebEkyars4RcQ1wJWb5sC fJSthtSKU1L1RVNhLz/d1WwqI26kFo5k7686AmpUMYIDbDCCA2gCAQEwgZMwgYwxCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJt ZWRpYXRlIENsaWVudCBDQQICHlwwCQYFKw4DAhoFAKCCAa0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwMzI1MjMxOTM0WjAjBgkqhkiG9w0BCQQxFgQUNkiGy5+C vyU2aJ5KlU74YVVON0kwgaQGCSsGAQQBgjcQBDGBljCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp Z25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDIgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xp ZW50IENBAgIeXDCBpgYLKoZIhvcNAQkQAgsxgZaggZMwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAyIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVu dCBDQQICHlwwDQYJKoZIhvcNAQEBBQAEggEAZT/v2hebnTmSHwK60GGkX7G7d/ZS0QBRpI3brfWa HTXKN+YgI2pjzH762zf1mLmRdVcCnnud/LP2mdQ+RDstlNvvPCAGoUwxzTipIiz/x1FhNgdSnptu zMZVy4BILsv2THxokTpIYfIhBtYHnGMoBC6lvn6raG2LpEfKDzQ0EbY15D4MXyOnYpJFDc1G58EA W1IfxMA0U+5BGAnajbV9eBJjiYe087kyEbz6VrrU0aEKWMxIDdgtCzvuNXUpMpN+XNomZvuUXggM km3ZRnCoVTP8mdZSxl0uePcqH1ydFPDSWSePS6+D78JHkfN2B9jtdOjUH42grR/9wH04CSYAGgAA AAAAAA== --Apple-Mail=_7DF6881E-3B78-496F-9B99-B2045C720CEE-- From dick.hardt@gmail.com Mon Mar 25 16:27:09 2013 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 9708C21F8632 for ; Mon, 25 Mar 2013 16:27:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.234 X-Spam-Level: X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=0.365, 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 CUuurVuyAcQ2 for ; Mon, 25 Mar 2013 16:27:09 -0700 (PDT) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id EB2F021F8630 for ; Mon, 25 Mar 2013 16:27:08 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id ro8so4447106pbb.4 for ; Mon, 25 Mar 2013 16:27:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=/KpIWWssHyrfAgNSVH1OLoYJo271CbYAwDTgOtukP/E=; b=nL4i/+biSkFmE3d/NAq2gnD99m1QaQOq18QwkPl463U/jpsJ+6rrcd2ATWX3SNnhWa klTVX1cOC2MI//Yvr+3CNa5jnyVVctwgjpXAktqGiuI1gDbPHqMImV6X7zgmBb79aoK3 8Wl1xMSnsQiBWtnIRrPrlQintW3tb5j5VYMFMDC/yZFvNJZlgN86acd9xykAjta9Xay2 EjQLqDivd3k7rZbypGZE9nhGCZWkukxpVtz5Zou8H05snw5YlKHXczUdAqlQfLz8/Rgn i9ZHKywdEMVQWB1C+5KTOdaYW2nrGWYboyQdXzdvy+/zN/IDo/kRPjxG59bl1P70uZVo 3kGg== X-Received: by 10.66.158.232 with SMTP id wx8mr2473703pab.156.1364254028734; Mon, 25 Mar 2013 16:27:08 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id 4sm15005346pbn.23.2013.03.25.16.27.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 25 Mar 2013 16:27:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> Date: Mon, 25 Mar 2013 16:27:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> To: John Bradley X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 25 Mar 2013 23:27:09 -0000 'iss' and 'aud' are not reserved header parameter names, so if I used = them, then they would be private names subject to collision.=20 Unless there is a reason why they should not be allowed, I'd like them = to be reserved header parameter names so that their meaning is clear to = an implementation or library. I would like to write my libraries to look = at the header for those parameters if they are there. On Mar 25, 2013, at 4:19 PM, John Bradley wrote: > That will be compliant. The spec won't call out those particular = properties from JWT. =20 >=20 > If you think that they should be called out as optional parameters = that could be considered. However that is not a open issue at this = point. >=20 > John B. > On 2013-03-25, at 8:09 PM, Dick Hardt wrote: >=20 >> Will that be compliant though? I would like to spec to say that I can = optionally include those properties in the header of a JWE. >>=20 >>=20 >> On Mar 25, 2013, at 4:02 PM, John Bradley wrote: >>=20 >>> Once the change to ignore additional elements in the header there is = nothing to stop you from doing that. >>>=20 >>> You make a good point about scoping the 'kid' to the 'iss'.=20 >>>=20 >>> John B. >>>=20 >>> On 2013-03-25, at 7:53 PM, Dick Hardt wrote: >>>=20 >>>> Hello everyone >>>>=20 >>>> As I am implementing JOSE JWE, I would like to know who the 'iss' = and 'aud' is. I am using symmetric, shared keys and the 'aud' party = would like to know they really are the intended 'aud' and who the 'isa' = is. Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>>>=20 >>>> I don't see an issue with disclosure of who 'iss' and 'aud' are as = any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>>>=20 >>>> Is there a reason why I cannot have 'iss' and 'aud' in the header? >>>>=20 >>>> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>>>=20 >>>> -- Dick >>>> _______________________________________________ >>>> jose mailing list >>>> jose@ietf.org >>>> https://www.ietf.org/mailman/listinfo/jose >>>=20 >>=20 >=20 From James.H.Manger@team.telstra.com Mon Mar 25 18:31:09 2013 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 0E8D321F8873 for ; Mon, 25 Mar 2013 18:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 4QTF3AphBEYX for ; Mon, 25 Mar 2013 18:31:08 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4D88B21F886D for ; Mon, 25 Mar 2013 18:31:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,909,1355058000"; d="scan'208";a="125429907" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 26 Mar 2013 12:30:59 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7025"; a="173917265" Received: from wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) by ipcavi.tcif.telstra.com.au with ESMTP; 26 Mar 2013 12:30:59 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3757.srv.dir.telstra.com ([172.49.40.85]) with mapi; Tue, 26 Mar 2013 12:30:58 +1100 From: "Manger, James H" To: Juraj Somorovsky Date: Tue, 26 Mar 2013 12:30:57 +1100 Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: Ac4pt3V9QiRBWEWkTgiF2PXrvXorjQABd1zg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BEFF2FC@WSMSG3153V.srv.dir.telstra.com> References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> <51505BFA.7080100@rub.de> <255B9BB34FB7D647A506DC292726F6E1150BE3C5A5@WSMSG3153V.srv.dir.telstra.com> <5150E950.5060301@rub.de> In-Reply-To: <5150E950.5060301@rub.de> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF JOSE WG , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 26 Mar 2013 01:31:09 -0000 PiA+PiAJU2VjcmV0S2V5IHJhbmRvbUNNSyA9IEFFUy5nZW5lcmF0ZUFFU0NNSyhrZXlMZW5ndGgp Ow0KPiA+Pg0KPiA+PiAJdHJ5IHsNCj4gPj4gCQljbWsgPSBSU0ExXzUuZGVjcnlwdENNSyhwcml2 YXRlS2V5LCBlbmNyeXB0ZWRLZXkuZGVjb2RlKCksDQo+ID4+IGtleUxlbmd0aCk7DQo+ID4+IAl9 IGNhdGNoIChFeGNlcHRpb24gZSkgew0KPiA+PiAJCS8vIFByb3RlY3QgYWdhaW5zdCBNTUEgYXR0 YWNrIGJ5IGdlbmVyYXRpbmcgcmFuZG9tIENNSyBvbg0KPiBmYWlsdXJlLA0KPiA+PiAJCS8vIHNl ZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtDQo+ID4+IGFyY2hpdmUvd2ViL2pvc2UvY3VycmVu dC9tc2cwMTgzMi5odG1sDQo+ID4+IAkJY21rID0gcmFuZG9tQ01LOw0KPiA+PiAJfQ0KPiA+PiB9 DQo+ID4+DQo+ID4+DQo+ID4+IFRoaXMgd291bGQgYmUgcGVyZmVjdCBhbmQgYWxzbyBzZWN1cmUg YWdhaW5zdCB0aW1pbmcgYXR0YWNrcy4NCj4gPg0KPiA+DQo+ID4gVGhpcyBjb2RlIG1heSBiZSBh IGJpdCBtb3JlIHJlc2lzdGFudCB0byB0aW1pbmcgYXR0YWNrcywgYnV0IGl0IGlzDQo+IG5vd2hl cmUgbmVhciBwZXJmZWN0Lg0KPiBBZ3JlZWQsICJwZXJmZWN0IiB3YXMgYSBwcmV0dHkgc3Ryb25n IHdvcmQgZm9yIHRoYXQgY29kZS4NCj4gDQo+IEkga25vdyB0aGF0IHRoZXJlIGNvdWxkIGFwcGVh ciBkaWZmZXJlbnQgcHJvY2Vzc2luZyB0aW1lcyBkdWUgdG8gdGhlDQo+IGRlY29kZWQga2V5IGxl bmd0aCBjaGVjaywgdGhyb3dpbmcgYW5kIGNhdGNoaW5nIHRoZSBleGNlcHRpb24sIG9yDQo+IHJh bmRvbUNNSyBhc3NpZ25tZW50LiBCdXQgSSB3b3VsZCBzYXkgdGhhdCB0aGV5IHdvdWxkIGNvbnN1 bWUgbXVjaCBsZXNzDQo+IHByb2Nlc3NpbmcgdGltZSB0aGFuIHRoZSByYW5kb20gbnVtYmVyIGdl bmVyYXRpb24uDQo+IA0KPiBEbyB5b3UgaGF2ZSBhbnkgbWVhc3VyZW1lbnRzIC8gdGhvdWdodHMg b24gdGhpcz8NCj4gDQo+IEJ0dywgV2UgbWVhc3VyZWQgZS5nLiB0aGUgdGltaW5nIGRpZmZlcmVu Y2VzIG9mIFBLQ1MxIHByb2Nlc3NpbmcuDQo+IERlY3J5cHRpb24gb2YgdmFsaWQgKHdpdGhvdXQg cmFuZG9tIG51bWJlciBnZW5lcmF0aW9uKSBhbmQgaW52YWxpZA0KPiAod2l0aCByYW5kb20gbnVt YmVyIGdlbmVyYXRpb24pIFBLQ1MxIG1lc3NhZ2VzIHlpZWxkZWQgYSBkaWZmZXJlbmNlIG9mDQo+ IGFib3V0DQo+IDExIG1pY3Jvc2Vjb25kcy4NCj4gDQo+IEkgd291bGQgYmUgYWxzbyB2ZXJ5IGlu dGVyZXN0ZWQgdG8ga25vdywgaWYgeW91IGhhdmUgYW55IG1ham9yDQo+IGltcHJvdmVtZW50cyBm b3IgdGhlIGNvZGUgSSBwcm92aWRlZC4NCj4gDQo+IFRoYW5rcw0KPiBKdXJhag0KDQpGb3IgYSBz dGFydCB0aGUgZml4ZXMgbmVlZCB0byBiZSBtdWNoIGxvd2VyIGRvd24gd2hlcmUgdGhlIFBLQ1Mj MSBwYWRkaW5nIGlzIGZpcnN0IGhhbmRsZWQsIG5vdCB3YXkgdXAgdGhlIHN0YWNrIHdlcmUgeW91 IHNlZSBhbiBleGNlcHRpb24gdnMgYSBub3JtYWwgcmV0dXJuLg0KDQpUaGUgR28gbGFuZ3VhZ2Ug YXBwZWFycyB0byBoYXZlIGNvZGUgd2l0aCBkZWNlbnQgcHJvdGVjdGlvbnMgdG8gYXZvaWQgbGVh a2luZyBjcnVjaWFsIHRpbWluZyBkZXRhaWxzOiBodHRwOi8vZ29sYW5nLm9yZy9zcmMvcGtnL2Ny eXB0by9yc2EvcGtjczF2MTUuZ28uDQoNClRoZSBKYXZhIGNvZGUgSSBmb3VuZCBpbiBhIHF1aWNr IHNlYXJjaCAoc3VuLnNlY3VyaXR5LnJzYS5SU0FQYWRkaW5nI3VucGFkVjE1KSBtYWtlcyBubyBl ZmZvcnQgdG8gYmUgY29uc3RhbnQgdGltZS4gSSBkb3VidCB0aGVyZSBpcyBhbnl0aGluZyAocmVh c29uYWJsZSkgdGhhdCBjYW4gYmUgZG9uZSBhdCBhIGhpZ2hlciBsYXllciAoc3VjaCBhcyBjb20u bmltYnVzZHMuam9zZS5jcnlwdG8uUlNBMV81KSB0byBtYWtlIFJTQUVTLVBLQ1MxLVYxXzUgc2Fm ZSB3aXRoIHRoYXQgZm91bmRhdGlvbi4NCltodHRwOi8vZ3JlcGNvZGUuY29tL2ZpbGUvcmVwb3Np dG9yeS5ncmVwY29kZS5jb20vamF2YS9yb290L2pkay9vcGVuamRrLzctYjE0Ny9zdW4vc2VjdXJp dHkvcnNhL1JTQVBhZGRpbmcuamF2YSNSU0FQYWRkaW5nLnVucGFkVjE1JTI4Ynl0ZSU1QiU1RCUy OV0NCg0KTWluZCB5b3UsIHN3aXRjaGluZyB0byBSU0EtT0FFUCBtaWdodCBub3QgaGVscCBhcyB0 aGUgdW5wYWRPQUVQKC4uKSBmdW5jdGlvbiBpbiB0aGUgc2FtZSBzb3VyY2UgZmlsZSBkb2Vzbid0 IGxvb2sgbXVjaCBzYWZlciAoaXQgY2hlY2tzIHRoZSAxc3QgYnl0ZSBpcyAwIGJlZm9yZSBkb2lu ZyB0aGUgT0FFUCB2ZXJpZmljYXRpb24pLg0KDQotLQ0KSmFtZXMgTWFuZ2VyDQoNCg== From juraj.somorovsky@rub.de Mon Mar 25 17:18:31 2013 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 C46ED21F875A for ; Mon, 25 Mar 2013 17:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 MDi--fZntRog for ; Mon, 25 Mar 2013 17:18:31 -0700 (PDT) Received: from mx5.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.33]) by ietfa.amsl.com (Postfix) with SMTP id 85B9D21F874E for ; Mon, 25 Mar 2013 17:18:30 -0700 (PDT) X-Queued: (qmail 19824 invoked by alias); 26 Mar 2013 00:18:29 -0000 X-Queued: (qmail 19808 invoked from network); 26 Mar 2013 00:18:29 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx5.rz.ruhr-uni-bochum.de with SMTP; 26 Mar 2013 00:18:29 -0000 X-Queued: (qmail 922 invoked by uid 281); 26 Mar 2013 00:18:29 -0000 X-Qmailscanner: from 88.153.216.226 (7Cil8M2CiUzDjr9snKEsXw==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(88.153.216.226):. Processed in 0.072229 secs); 26 Mar 2013 00:18:29 -0000 Received: from ip-88-153-216-226.unitymediagroup.de (HELO ?192.168.0.104?) (7Cil8M2CiUzDjr9snKEsXw==@88.153.216.226) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 26 Mar 2013 00:18:28 -0000 Date: 26 Mar 2013 01:18:24 +0100 Message-ID: <5150E950.5060301@rub.de> From: "Juraj Somorovsky" To: "Manger, James H" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> <51505BFA.7080100@rub.de> <255B9BB34FB7D647A506DC292726F6E1150BE3C5A5@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BE3C5A5@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 25 Mar 2013 21:32:51 -0700 Cc: IETF JOSE WG , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 26 Mar 2013 00:18:32 -0000 On 03/25/2013 11:58 PM, Manger, James H wrote: >> you are right, the random number generation *must not* be done in the >> catch block, it could be measured and leak an information about >> ciphertext validity. >> >> I would propose this code: >> >> if (alg.equals(JWEAlgorithm.RSA1_5)) { >> int keyLength = >> cmkBitLength(readOnlyJWEHeader.getEncryptionMethod()); >> SecretKey randomCMK = AES.generateAESCMK(keyLength); >> >> try { >> cmk = RSA1_5.decryptCMK(privateKey, encryptedKey.decode(), >> keyLength); >> } catch (Exception e) { >> // Protect against MMA attack by generating random CMK on >> failure, >> // see http://www.ietf.org/mail- >> archive/web/jose/current/msg01832.html >> cmk = randomCMK; >> } >> } >> >> >> This would be perfect and also secure against timing attacks. > > > This code may be a bit more resistant to timing attacks, but it is nowhere near perfect. Agreed, "perfect" was a pretty strong word for that code. I know that there could appear different processing times due to the decoded key length check, throwing and catching the exception, or randomCMK assignment. But I would say that they would consume much less processing time than the random number generation. Do you have any measurements / thoughts on this? Btw, We measured e.g. the timing differences of PKCS1 processing. Decryption of valid (without random number generation) and invalid (with random number generation) PKCS1 messages yielded a difference of about 11 microseconds. I would be also very interested to know, if you have any major improvements for the code I provided. Thanks Juraj From vladimir@nimbusds.com Mon Mar 25 23:08:41 2013 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 4E73021F87D5 for ; Mon, 25 Mar 2013 23:08:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] 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 aGgTyo9gcD0u for ; Mon, 25 Mar 2013 23:08:40 -0700 (PDT) Received: from n1plwbeout07-01.prod.ams1.secureserver.net (n1plsmtp07-01-02.prod.ams1.secureserver.net [188.121.52.106]) by ietfa.amsl.com (Postfix) with SMTP id CD66321F8707 for ; Mon, 25 Mar 2013 23:08:38 -0700 (PDT) Received: (qmail 3592 invoked from network); 26 Mar 2013 06:08:37 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plwbeout07-01.prod.ams1.secureserver.net with SMTP; 26 Mar 2013 06:08:37 -0000 Received: (qmail 18147 invoked by uid 99); 26 Mar 2013 06:08:37 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 79.100.242.106 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130325230836.cc40c4f3d92d2001859047cd8cabb9ab.1243c28b28.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Manger, James H" , "Juraj Somorovsky" Date: Mon, 25 Mar 2013 23:08:36 -0700 Mime-Version: 1.0 Cc: IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 26 Mar 2013 06:08:41 -0000 On Tue, 2013-03-26 at 12:30 +1100, Manger, James H wrote:=0A> >> =09SecretK= ey randomCMK =3D AES.generateAESCMK(keyLength);=0A> > >>=0A> > >> =09try {= =0A> > >> =09=09cmk =3D RSA1_5.decryptCMK(privateKey, encryptedKey.decode()= ,=0A> > >> keyLength);=0A> > >> =09} catch (Exception e) {=0A> > >> =09=09/= / Protect against MMA attack by generating random CMK on=0A> > failure,=0A>= > >> =09=09// see http://www.ietf.org/mail-=0A> > >> archive/web/jose/curr= ent/msg01832.html=0A> > >> =09=09cmk =3D randomCMK;=0A> > >> =09}=0A> > >> = }=0A> > >>=0A> > >>=0A> > >> This would be perfect and also secure against = timing attacks.=0A> > >=0A> > >=0A> > > This code may be a bit more resista= nt to timing attacks, but it is=0A> > nowhere near perfect.=0A> > Agreed, "= perfect" was a pretty strong word for that code.=0A> > =0A> > I know that t= here could appear different processing times due to the=0A> > decoded key l= ength check, throwing and catching the exception, or=0A> > randomCMK assign= ment. But I would say that they would consume much less=0A> > processing ti= me than the random number generation.=0A> > =0A> > Do you have any measurem= ents / thoughts on this?=0A> > =0A> > Btw, We measured e.g. the timing diff= erences of PKCS1 processing.=0A> > Decryption of valid (without random numb= er generation) and invalid=0A> > (with random number generation) PKCS1 mess= ages yielded a difference of=0A> > about=0A> > 11 microseconds.=0A> > =0A> = > I would be also very interested to know, if you have any major=0A> > impr= ovements for the code I provided.=0A> > =0A> > Thanks=0A> > Juraj=0A> =0A> = For a start the fixes need to be much lower down where the PKCS#1 padding i= s first handled, not way up the stack were you see an exception vs a normal= return.=0A> =0A> The Go language appears to have code with decent protecti= ons to avoid leaking crucial timing details: http://golang.org/src/pkg/cryp= to/rsa/pkcs1v15.go.=0A> =0A> The Java code I found in a quick search (sun.s= ecurity.rsa.RSAPadding#unpadV15) makes no effort to be constant time. I dou= bt there is anything (reasonable) that can be done at a higher layer (such = as com.nimbusds.jose.crypto.RSA1_5) to make RSAES-PKCS1-V1_5 safe with that= foundation.=0A> [http://grepcode.com/file/repository.grepcode.com/java/roo= t/jdk/openjdk/7-b147/sun/security/rsa/RSAPadding.java#RSAPadding.unpadV15%2= 8byte%5B%5D%29]=0A> =0A> Mind you, switching to RSA-OAEP might not help as = the unpadOAEP(..) function in the same source file doesn't look much safer = (it checks the 1st byte is 0 before doing the OAEP verification).=0A> =0AWh= at do you guys think of precomputing a set of CMKs, e.g. during=0Adecrypter= construction, so the actual random number generation doesn't=0Ahappen when= decrypt requests are served?=0A=0AI read the paper James suggested, and it= advocates achieving constant=0Atime to solve timing attacks. How about doi= ng the opposite, injecting=0Arandom duration no-ops in the decryption code?= =0A=0AVladimir From jricher@mitre.org Tue Mar 26 07:37:12 2013 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 9F9B721F8C1F for ; Tue, 26 Mar 2013 07:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 hKZT1-Kro8H5 for ; Tue, 26 Mar 2013 07:37:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5547321F8C2C for ; Tue, 26 Mar 2013 07:37:08 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id D32A21F0260; Tue, 26 Mar 2013 10:37:07 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id BC5821F0467; Tue, 26 Mar 2013 10:37:07 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS01.MITRE.ORG (129.83.29.78) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 26 Mar 2013 10:36:43 -0400 Message-ID: <5151B236.2080001@mitre.org> Date: Tue, 26 Mar 2013 10:35:34 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: <5150B533.2080205@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020902030305090708070208" X-Originating-IP: [129.83.31.58] Cc: jose@ietf.org Subject: Re: [jose] JWK Generator 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, 26 Mar 2013 14:37:12 -0000 --------------020902030305090708070208 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Thanks, that's exactly what I was looking for. I keep forgetting to check the unit tests of jsoncrypto for things like this. Once I have the actual java.security objects in hand, I can construct the JWKs fairly easily. I'll get this added and released soon! -- Justin On 03/25/2013 05:05 PM, Axel.Nennker@telekom.de wrote: > > EC key generation can be found in http://jsoncrypto.org/ > > ES512 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2726 > > ES384 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2685 > > ES256 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2642 > > I guess that the println lines can be converted into JWKs. > > -Axel > > *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Justin Richer > *Sent:* Monday, March 25, 2013 9:36 PM > *To:* jose@ietf.org > *Subject:* [jose] JWK Generator > > A while ago, several folks complained that there was no toolchain for > creating bare keys in the JWK/JPSK format. Indeed, my team's been > using Java's keytool program and making self-signed dummy certs and > pulling them out of there. That was a bit of a pain, to be honest. > > So now I've just written a utility program to generate JWK formatted > keys from whole cloth given a set of parameters. It's a Java app built > using the NimbusDS JWT-JOSE library, and at the moment it supports > both RSA and oct keytypes, with an option to extract the public-only > portion of the RSA as well. This is all based on the current JPSK > format, which we plan to track with the aforementioned Nimbus library. > > You can get the code here: > > https://github.com/mitreid-connect/json-web-key-generator > > It's open sourced under an Apache 2.0 license, so feel free to pull it > down and use it to your heart's content. It's a Java Maven project, so > you build it with: > > mvn package > > This will create a couple of .jar files in the target/ directory, one > of which is an executable fat jar, usble from the commandline: > > usage: java -jar json-web-key-generator.jar -t -s [-u > -a -i -p] > -a Algorithm. > -i Key ID (optional) > -p Display public key separately > -s Key Size in bits, must be an integer, generally divisible by 8 > -t Key Type, one of: RSA, oct > -u Usage, one of: enc, sig. Defaults to sig > > > For instance, to generate a 1024-bit RSA key with the algorithm of > RS256, no key id, and display the public key separately, you would run > (after doing a mvn package): > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar > -a RS256 -t RSA -s 1024 -p > > This prints out (for example, your keys should vary): > > Full key: > { > "alg": "RS256", > "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0", > "e": "AQAB", > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", > "kty": "RSA", > "use": "sig" > } > > Public key: > { > "alg": "RS256", > "e": "AQAB", > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", > "kty": "RSA", > "use": "sig" > } > > > To create a 256-bit symmetric key with algorithm HS256 and key id of > "myKey", you'd do: > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar > -t oct -s 256 > > Which outputs something like: > > Full key: > { > "kty": "oct", > "use": "sig", > "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME" > } > > > It doesn't do EC keys yet because I don't know the Java Magic needed > to make such a thing happen, but I'd be happy to have someone help out > with that with a pull request. > > Hopefully people find this utility useful. I've got a few features I'm > planning to add (write output to files, Java GUI with dropdowns for > options), but this is a minimally-useful set of functionality. > > -- Justin > --------------020902030305090708070208 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Thanks, that's exactly what I was looking for. I keep forgetting to check the unit tests of jsoncrypto for things like this.

Once I have the actual java.security objects in hand, I can construct the JWKs fairly easily.

I'll get this added and released soon!

 -- Justin

On 03/25/2013 05:05 PM, Axel.Nennker@telekom.de wrote:

EC key generation can be found in http://jsoncrypto.org/

 

ES512

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2726

 

ES384

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2685

 

ES256

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2642

 

I guess that the println lines can be converted into JWKs.

 

-Axel

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, March 25, 2013 9:36 PM
To: jose@ietf.org
Subject: [jose] JWK Generator

 

A while ago, several folks complained that there was no toolchain for creating bare keys in the JWK/JPSK format. Indeed, my team's been using Java's keytool program and making self-signed dummy certs and pulling them out of there. That was a bit of a pain, to be honest.

So now I've just written a utility program to generate JWK formatted keys from whole cloth given a set of parameters. It's a Java app built using the NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct keytypes, with an option to extract the public-only portion of the RSA as well. This is all based on the current JPSK format, which we plan to track with the aforementioned Nimbus library.

You can get the code here:

  https://github.com/mitreid-connect/json-web-key-generator

It's open sourced under an Apache 2.0 license, so feel free to pull it down and use it to your heart's content. It's a Java Maven project, so you build it with:

  mvn package

This will create a couple of .jar files in the target/ directory, one of which is an executable fat jar, usble from the commandline:

usage: java -jar json-web-key-generator.jar -t <keyType> -s <keySize> [-u
            <keyUsage> -a <algorithm> -i <keyId> -p]
 -a <arg>   Algorithm.
 -i <arg>   Key ID (optional)
 -p         Display public key separately
 -s <arg>   Key Size in bits, must be an integer, generally divisible by 8
 -t <arg>   Key Type, one of: RSA, oct
 -u <arg>   Usage, one of: enc, sig. Defaults to sig


For instance, to generate a 1024-bit RSA key with the algorithm of RS256, no key id, and display the public key separately, you would run (after doing a mvn package):

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -a RS256 -t RSA -s 1024 -p

This prints out (for example, your keys should vary):

Full key:
{
  "alg": "RS256",
  "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}
 
Public key:
{
  "alg": "RS256",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}


To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey", you'd do:

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -t oct -s 256

Which outputs something like:

Full key:
{
  "kty": "oct",
  "use": "sig",
  "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME"
}


It doesn't do EC keys yet because I don't know the Java Magic needed to make such a thing happen, but I'd be happy to have someone help out with that with a pull request.

Hopefully people find this utility useful. I've got a few features I'm planning to add (write output to files, Java GUI with dropdowns for options), but this is a minimally-useful set of functionality.

 -- Justin


--------------020902030305090708070208-- From rlb@ipv.sx Tue Mar 26 10:02:19 2013 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 6FACD21F8B7E for ; Tue, 26 Mar 2013 10:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.576, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Mb9FwhCYV8rn for ; Tue, 26 Mar 2013 10:02:18 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 983FC21F8786 for ; Tue, 26 Mar 2013 10:02:17 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id h1so7904206oag.3 for ; Tue, 26 Mar 2013 10:02:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=GUrt0zu3fsUbo5w4ThPeS42e69xhIXkQxpheT9S9E/Y=; b=CQTDG33kZQzO1uq4u2V6+v90bQHzgvk8WooMQrc23S6oZ6tvdoOKoHiwDiseL2M9vK xxSflr3LVlFz7zycGFYZ6LqAAQ54F1R9mC1VP9fVYE4faYZZoRbg1w/0XToUGTM5K1Gf RyVi9t0WsaEZi59WQ72NabZdrjUZUobwWljyiOC4jnKgK5N3zADn0lP9MBzM6oz/NGwb 6vfLNUNZ5Eizz0Z9QYPit6BegJ5HwEpP7wdojehThRY3NWFzD4LsiFmFN5uQAmv/Xjjz iOU5IzYS6O1ebmkQsFs8QIctlK8qQAUmKeTjEmxutK38QttXXZrSV1DQDckvN37AZP9q 4l+Q== MIME-Version: 1.0 X-Received: by 10.182.134.138 with SMTP id pk10mr2512285obb.80.1364317336692; Tue, 26 Mar 2013 10:02:16 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Tue, 26 Mar 2013 10:02:16 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: <5151B236.2080001@mitre.org> References: <5150B533.2080205@mitre.org> <5151B236.2080001@mitre.org> Date: Tue, 26 Mar 2013 13:02:16 -0400 Message-ID: From: Richard Barnes To: Justin Richer Content-Type: multipart/alternative; boundary=001a11c297163747e604d8d6e287 X-Gm-Message-State: ALoCoQkmFeHGXkjA3ZEibRmFsxvlFau1SB3amIg2H1SH5PI6hMFa2HFwEAgfXvIXjQJdOkQYW7JW Cc: jose@ietf.org, Axel.Nennker@telekom.de Subject: Re: [jose] JWK Generator 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, 26 Mar 2013 17:02:19 -0000 --001a11c297163747e604d8d6e287 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've got some similar tools in PolyCrypt, our WebCrypto polyfill [1]. One of the demos is a self-signed certificate generator, which outputs private key as a pseudo-JWK [2]. I was going to put a code snippet here to demonstrate how to generate an RSA JWK with PolyCrypt. Instead I just threw up a new demo page that will do it for you [3]. Sample output: {"n":"a9_H5i8T7Zg65CUYPGRd4R-Lw7UFiH7guIJ5gQgjJUdnlo6edyVSCux_xV43T-Qe2-SGk= RbUirZczdCegfAVjAegVMtnrsgOe_EqhN1CFlmPJ8wwC5Ooyc6u1_FBdu4FL3Kl7jWpII-ikOhZ= m05xUnj_M7CMMJo6w4PvAAzn-is=3D","e":"AQAB","d":"ETm1sPL5iqoRVVb7DMG2H_mqlsC= 0NnyUI8Jp5onHGu_RAcCaW0oxVJ85M-n8iRxTNSfDuS1dGR1PqmnStcsBlZnkwc99vl9gtUW2zA= s0J-W3YP88Tk3hNM-6vS2So9-LRMashcWruHBPmLudN-UxGzanvS3G58jkK1BLQCW6xVE=3D","= p":"w8ZngvLVkE3reWvra6vDd3KLJqDHIK602h8yl40vLqX0u5UmXojIqL7k9WpmEn5gvVPsp-X= DtkV-50ON9NZD8w=3D=3D","q":"jQ8KzZ3gHPz-yISa0EbRdI_cmeI03Kq1aAj7bSHDcyr4Ojn= kI4K6lTVNTGUazf10BrJZ5_2Yj5zOfujV803W6Q=3D=3D","dp":"m4-Mco3YStjPceTh5OVP5R= rcHO6GK58Gz4cYoTmrMwrlYyRJn7Zak1NUBPntb2aCIg6MroCwuaWRB9wy8UhMJw=3D=3D","dq= ":"CgIpOBGdlzD0OvH9sg10SxryAhEkwwtxt6H7hPDCV2eTGT6GS2a5KmEPzP3Xewois17wNh-u= NXJgzGxk0dCSEQ=3D=3D","qi":"kZ9MFAYRZKPloUprijuKsJxqfsAVJNINFqqrWr5ycqHLtpm= hk6l58wkxFpcU94TJPgf1CaJOj2pGRTyijPa3-w=3D=3D"} If you want to use PolyCrypt and need EC, let me know, and I can probably get it implemented pretty quickly. Hope this helps, --Richard [1] [2] [3] On Tue, Mar 26, 2013 at 10:35 AM, Justin Richer wrote: > Thanks, that's exactly what I was looking for. I keep forgetting to chec= k > the unit tests of jsoncrypto for things like this. > > Once I have the actual java.security objects in hand, I can construct the > JWKs fairly easily. > > I'll get this added and released soon! > > -- Justin > > > On 03/25/2013 05:05 PM, Axel.Nennker@telekom.de wrote: > > EC key generation can be found in http://jsoncrypto.org/**** > > ** ** > > ES512**** > > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/json= crypto/JcBaseTest.java#2726 > **** > > ** ** > > ES384**** > > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/json= crypto/JcBaseTest.java#2685 > **** > > ** ** > > ES256**** > > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/json= crypto/JcBaseTest.java#2642 > **** > > ** ** > > I guess that the println lines can be converted into JWKs.**** > > ** ** > > -Axel**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] > *On Behalf Of *Justin Richer > *Sent:* Monday, March 25, 2013 9:36 PM > *To:* jose@ietf.org > *Subject:* [jose] JWK Generator**** > > ** ** > > A while ago, several folks complained that there was no toolchain for > creating bare keys in the JWK/JPSK format. Indeed, my team's been using > Java's keytool program and making self-signed dummy certs and pulling the= m > out of there. That was a bit of a pain, to be honest. > > So now I've just written a utility program to generate JWK formatted keys > from whole cloth given a set of parameters. It's a Java app built using t= he > NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct > keytypes, with an option to extract the public-only portion of the RSA as > well. This is all based on the current JPSK format, which we plan to trac= k > with the aforementioned Nimbus library. > > You can get the code here: > > https://github.com/mitreid-connect/json-web-key-generator > > It's open sourced under an Apache 2.0 license, so feel free to pull it > down and use it to your heart's content. It's a Java Maven project, so yo= u > build it with: > > mvn package > > This will create a couple of .jar files in the target/ directory, one of > which is an executable fat jar, usble from the commandline:**** > > usage: java -jar json-web-key-generator.jar -t -s [-u= **** > > -a -i -p]**** > > -a Algorithm.**** > > -i Key ID (optional)**** > > -p Display public key separately**** > > -s Key Size in bits, must be an integer, generally divisible by = 8**** > > -t Key Type, one of: RSA, oct**** > > -u Usage, one of: enc, sig. Defaults to sig**** > > > For instance, to generate a 1024-bit RSA key with the algorithm of RS256, > no key id, and display the public key separately, you would run (after > doing a mvn package): > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -a > RS256 -t RSA -s 1024 -p > > This prints out (for example, your keys should vary):**** > > Full key:**** > > {**** > > "alg": "RS256",**** > > "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtr= yCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh= 1q-eFOEpXWUtKy7DCFymMves7ojPxY0",**** > > "e": "AQAB",**** > > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJR= E-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAM= Ni4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",**** > > "kty": "RSA",**** > > "use": "sig"**** > > }**** > > ** ** > > Public key:**** > > {**** > > "alg": "RS256",**** > > "e": "AQAB",**** > > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJR= E-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAM= Ni4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",**** > > "kty": "RSA",**** > > "use": "sig"**** > > }**** > > > To create a 256-bit symmetric key with algorithm HS256 and key id of > "myKey", you'd do: > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -t o= ct > -s 256 > > Which outputs something like:**** > > Full key:**** > > {**** > > "kty": "oct",**** > > "use": "sig",**** > > "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME"**** > > }**** > > > It doesn't do EC keys yet because I don't know the Java Magic needed to > make such a thing happen, but I'd be happy to have someone help out with > that with a pull request. > > Hopefully people find this utility useful. I've got a few features I'm > planning to add (write output to files, Java GUI with dropdowns for > options), but this is a minimally-useful set of functionality. > > -- Justin**** > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a11c297163747e604d8d6e287 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We've got some similar tools in PolyCrypt, our WebCrypto polyfill [1]. = =A0One of the demos is a self-signed certificate generator, which outputs p= rivate key as a pseudo-JWK [2]. =A0

I was going to = put a code snippet here to demonstrate how to generate an RSA JWK with Poly= Crypt. =A0Instead I just threw up a new demo page that will do it for you [= 3]. =A0Sample output:
{"n":"a9_H5i8T7Zg65CUYPGRd4R-Lw7UFiH7guIJ5gQgjJUdnlo6ed= yVSCux_xV43T-Qe2-SGkRbUirZczdCegfAVjAegVMtnrsgOe_EqhN1CFlmPJ8wwC5Ooyc6u1_FB= du4FL3Kl7jWpII-ikOhZm05xUnj_M7CMMJo6w4PvAAzn-is=3D","e":&quo= t;AQAB","d":"ETm1sPL5iqoRVVb7DMG2H_mqlsC0NnyUI8Jp5onHGu= _RAcCaW0oxVJ85M-n8iRxTNSfDuS1dGR1PqmnStcsBlZnkwc99vl9gtUW2zAs0J-W3YP88Tk3hN= M-6vS2So9-LRMashcWruHBPmLudN-UxGzanvS3G58jkK1BLQCW6xVE=3D","p&quo= t;:"w8ZngvLVkE3reWvra6vDd3KLJqDHIK602h8yl40vLqX0u5UmXojIqL7k9WpmEn5gvV= Psp-XDtkV-50ON9NZD8w=3D=3D","q":"jQ8KzZ3gHPz-yISa0EbRdI= _cmeI03Kq1aAj7bSHDcyr4OjnkI4K6lTVNTGUazf10BrJZ5_2Yj5zOfujV803W6Q=3D=3D"= ;,"dp":"m4-Mco3YStjPceTh5OVP5RrcHO6GK58Gz4cYoTmrMwrlYyRJn7Za= k1NUBPntb2aCIg6MroCwuaWRB9wy8UhMJw=3D=3D","dq":"CgIpOBG= dlzD0OvH9sg10SxryAhEkwwtxt6H7hPDCV2eTGT6GS2a5KmEPzP3Xewois17wNh-uNXJgzGxk0d= CSEQ=3D=3D","qi":"kZ9MFAYRZKPloUprijuKsJxqfsAVJNINFqqrW= r5ycqHLtpmhk6l58wkxFpcU94TJPgf1CaJOj2pGRTyijPa3-w=3D=3D"}

If you want to use PolyCrypt and need EC, let me know, = and I can probably get it implemented pretty quickly.

<= div>Hope this helps,
--Richard






On Tu= e, Mar 26, 2013 at 10:35 AM, Justin Richer <jricher@mitre.org> wrote:
=20 =20 =20
Thanks, that's exactly what I was looking for. I keep forgetting to check the unit tests of jsoncrypto for things like this.

Once I have the actual java.security objects in hand, I can construct the JWKs fairly easily.

I'll get this added and released soon!

=A0-- Justin


On 03/25/2013 05:05 PM, Axel.Nen= nker@telekom.de wrote:
=20 =20 =20

EC key generation can be found in http://jsoncrypto.org/

=A0=

ES512

https://code.google.com/p/jsoncrypto= /source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2726=

=A0=

ES384

https://code.google.com/p/jsoncrypto= /source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2685=

=A0=

ES256

https://code.google.com/p/jsoncrypto= /source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2642=

=A0=

I guess that the println lines can be converted into JWKs.=

=A0=

-Axel

=A0=

From: = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, March 25, 2013 9:36 PM
To: jose@ietf.org
Subject: [jose] JWK Generator

=A0

A while ago, several folks complained that there was no toolchain for creating bare keys in the JWK/JPSK format. Indeed, my team's been using Java's keytool program and making self-signed dumm= y certs and pulling them out of there. That was a bit of a pain, to be honest.

So now I've just written a utility program to generate JWK formatted keys from whole cloth given a set of parameters. It's a Java app built using the NimbusDS JWT-JOSE library, an= d at the moment it supports both RSA and oct keytypes, with an option to extract the public-only portion of the RSA as well. This is all based on the current JPSK format, which we plan to track with the aforementioned Nimbus library.

You can get the code here:

=A0 https://github.com/mitreid-connect/json-web-key-= generator

It's open sourced under an Apache 2.0 license, so feel free t= o pull it down and use it to your heart's content. It's a J= ava Maven project, so you build it with:

=A0 mvn package

This will create a couple of .jar files in the target/ directory, one of which is an executable fat jar, usble from the commandline:

usage: java -jar json-web-key-generator.jar -t <keyType>=
 -s <keySize> [-u
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 <keyUsage> -a <algo=
rithm> -i <keyId> -p]
=A0-a <arg>=A0=A0 Algorithm.
=A0-i <arg>=A0=A0 Key ID (optional)
=A0-p=A0=A0=A0=A0=A0=A0=A0=A0 Display public key separately=

=A0-s <arg>=A0=A0 Key Size in bits, must be an integer, =
generally divisible by 8
=A0-t <arg>=A0=A0 Key Type, one of: RSA, oct
=A0-u <arg>=A0=A0 Usage, one of: enc, sig. Defaults to s=
ig


For instance, to generate a 1024-bit RSA key with the algorithm of RS256, no key id, and display the public key separately, you would run (after doing a mvn package):

=A0 java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.= jar -a RS256 -t RSA -s 1024 -p

This prints out (for example, your keys should vary):

Full key:
{
=A0 "alg": "RS256",
=A0 "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qI=
g-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeC=
U3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0",
=A0 "e": "AQAB",
=A0 "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs=
7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHp=
FJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
=A0 "kty": "RSA",
=A0 "use": "sig"
}
=A0
Public key:
{
=A0 "alg": "RS256",
=A0 "e": "AQAB",
=A0 "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs=
7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHp=
FJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
=A0 "kty": "RSA",
=A0 "use": "sig"
}


To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey", you'd do:

=A0 java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.= jar -t oct -s 256

Which outputs something like:

Full key:
{
=A0 "kty": "oct",
=A0 "use": "sig",
=A0 "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2U=
mbphME"
}


It doesn't do EC keys yet because I don't know the Java M= agic needed to make such a thing happen, but I'd be happy to have someone help out with that with a pull request.

Hopefully people find this utility useful. I've got a few features I'm planning to add (write output to files, Java GUI with dropdowns for options), but this is a minimally-useful set of functionality.

=A0-- Justin



_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a11c297163747e604d8d6e287-- From trac+jose@trac.tools.ietf.org Tue Mar 26 10:42:15 2013 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 C432D21F8C2A for ; Tue, 26 Mar 2013 10:42:15 -0700 (PDT) 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 DK97XtPJSHDc for ; Tue, 26 Mar 2013 10:42:15 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 1A88621F8C22 for ; Tue, 26 Mar 2013 10:42:14 -0700 (PDT) Received: from localhost ([127.0.0.1]:58224 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UKXsr-00064X-0A; Tue, 26 Mar 2013 18:42:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx X-Trac-Project: jose Date: Tue, 26 Mar 2013 17:42:04 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/4#comment:2 Message-ID: <069.73ebcacad01391cf885d49382446665c@trac.tools.ietf.org> References: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <054.24cd2b074db2dc2bbbcb828a8456fbe9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130326174215.1A88621F8C22@ietfa.amsl.com> Resent-Date: Tue, 26 Mar 2013 10:42:14 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #4: Remove wrapped keys from integrity check (allow separation of keys from data) (was: Impossible to separate wrapped key from encrypted data) X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2013 17:42:15 -0000 #4: Remove wrapped keys from integrity check (allow separation of keys from data) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From rlb@ipv.sx Tue Mar 26 10:42:24 2013 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 309D721F8C4C for ; Tue, 26 Mar 2013 10:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.177 X-Spam-Level: X-Spam-Status: No, score=-1.177 tagged_above=-999 required=5 tests=[AWL=-0.752, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 rwgfpkNH7AZK for ; Tue, 26 Mar 2013 10:42:23 -0700 (PDT) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 53B7F21F8B7E for ; Tue, 26 Mar 2013 10:42:23 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id 16so7328237obc.5 for ; Tue, 26 Mar 2013 10:42:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=ygeko0k3KLgkD8DI7BRcC+Il3Fmv00naRE2N+SCPLvw=; b=iIPi8KgD68/u8YPCbwIp4bMkiwBGL0Nx55fNN0I1Nxe/tDYz6nA2vqFuW5gY5SjaUK rL1Q2onitKretiRzeEbf7X4AIqbKd4GRm9kLRpEkMHd7vv2DF3Gml2Iz4fZtNb7QmW/t n9ksfZtlAAyJIwvCetfYqZJ3CRkgeUp5rWT0J1+DNKF646iHgnfhVSZPVpvC3v/4zMxu cKJNf1v3c5n/MDpWSWo8orch+iyAy5A2Y1jLjhSnB20jZgIC705+F8m7jNlwOtbJ0Frj 5b7ITzvHiDUOv6EZP8DkMTuQCw8Nb+G57vYjOCTZ8AkKUBlEKXSh+yQqntxgMzKw9Zu9 cWEA== MIME-Version: 1.0 X-Received: by 10.60.170.140 with SMTP id am12mr13522316oec.125.1364319742583; Tue, 26 Mar 2013 10:42:22 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Tue, 26 Mar 2013 10:42:22 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367588B2D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <010001ce2739$7eaae070$7c00a150$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367586714@TK5EX14MBXC283.redmond.corp.microsoft.com> <4E1F6AAD24975D4BA5B168042967394367588B2D@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Tue, 26 Mar 2013 13:42:22 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=bcaec54b48129df4a604d8d771d6 X-Gm-Message-State: ALoCoQnbS5JWbv+920dZXu0x02He4uX3DetlCduqlBlpzEDaq7GQKfDw0zo0ha9k2YujcgziE3pP Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Minutes 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, 26 Mar 2013 17:42:24 -0000 --bcaec54b48129df4a604d8d771d6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fixed title of issue in tracker. On Mon, Mar 25, 2013 at 6:56 PM, Mike Jones wr= ote: > =93Impossible to separate wrapped key from encrypted data=94 (the title = of > issue #4) is a false statement. Nat pointed that out over a month ago in > the issue tracker. If that remains the title of the issue, it should be > closed on the merits of the issue.**** > > ** ** > > If you want to change the title of this one to =93Should the encrypted ke= y > element of a JWE no longer be included in the integrity check?=94 I=92d h= ave no > problem with the issue, because then it would be making a neutral stateme= nt > about a possible change. But right now, it=92s highly misleading, at bes= t.* > *** > > ** ** > > None of that was captured in the minutes, even though it was all discusse= d > in Orlando.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Richard Barnes > *Sent:* Monday, March 25, 2013 3:11 PM > *To:* Mike Jones > *Cc:* Jim Schaad; jose@ietf.org > *Subject:* Re: [jose] Minutes**** > > ** ** > > It's not accurate to say that Issue #4 is not a problem. We did clarify > in the meeting that the issue could use some re-statement, to clarify tha= t > the issue is the coverage of keys by the integrity check. So there's sti= ll > an issue, namely whether the key needs to be covered by the integrity che= ck. > **** > > ** ** > > ** ** > > On Sun, Mar 24, 2013 at 9:02 PM, Mike Jones > wrote:**** > > I don=92t believe that the minutes adequately capture the discussion on > issue #4 (http://trac.tools.ietf.org/wg/jose/trac/ticket/4#). > I would revise as follows:**** > > **** > > Data tracker issue #4 (Impossible to separate wrapped key from encrypted > data) =96 John Bradley=92s slides pointed out that it **is** possible to > separate wrapped keys from encrypted data when needed by using the direct > encryption mode and therefore asked for this issue to be closed, as it is > based upon a false premise. Mike Jones also asked for this to be closed = on > this basis, and pointed out that Nat Sakimura had already described the > problem with this issue in the issue tracker. Richard asked a question > about the security analysis of including the wrapped key in the integrity > calculation - Does the wrapped key need to be included in the integrity > check or not? The question will be referred to CFRG but a request for > possible attack modes being sent to the list is requested.**** > > **** > > Given that the problem stated in issue #4 was demonstrated to not actuall= y > be a problem during the discussions, I would ask again that the chairs > close this one, and update the minutes to reflect this.**** > > **** > > Thank you,***= * > > -- Mike**** > > **** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Jim Schaad > *Sent:* Friday, March 22, 2013 1:12 PM > *To:* jose@ietf.org > *Subject:* [jose] Minutes**** > > **** > > Preliminary minutes have been uploaded to the site. Please review and > comment back to me if you have disagreements.**** > > **** > > http://www.ietf.org/proceedings/86/minutes/minutes-86-jose**** > > **** > > Note that the minutes have an action list at the bottom of them.**** > > **** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > --bcaec54b48129df4a604d8d771d6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Fixed title of issue in tracker.

On Mon, = Mar 25, 2013 at 6:56 PM, Mike Jones <Michael.Jones@microsoft.com= > wrote:

=93Imp= ossible to separate wrapped key from encrypted data=94 (the title of issue #4) is a false statement.=A0 Nat pointed that out over= a month ago in the issue tracker.=A0 If that remains the title of the issu= e, it should be closed on the merits of the issue.

=A0<= /p>

If you want to change the= title of this one to =93Should the encrypted key element of a JWE no longe= r be included in the integrity check?=94 I=92d have no problem with the issue, because then it would be making a neutral statement about = a possible change.=A0 But right now, it=92s highly misleading, at best.<= /u>

=A0<= /p>

None of that was captured= in the minutes, even though it was all discussed in Orlando.=

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Monday, March 25, 2013 3:11 PM
To: Mike Jones
Cc: Jim Schaad; j= ose@ietf.org
Subject: Re: [jose] Minutes

=A0

It's not accurate to say that Issue #4 is not a = problem. =A0We did clarify in the meeting that the issue could use some re-= statement, to clarify that the issue is the coverage of keys by the integri= ty check. =A0So there's still an issue, namely whether the key needs to be covered by the integrity check.<= /p>

=A0

=A0

On Sun, Mar 24, 2013 at 9:02 PM, Mike Jones <Michael.Jones@= microsoft.com> wrote:

I don=92t believe that= the minutes adequately capture the discussion on issue #4 (http://trac= .tools.ietf.org/wg/jose/trac/ticket/4#).=A0 I would revise as follows:

=A0

Data tracker issue #4 = (Impossible to separate wrapped key from encrypted data) =96 John Bradley= =92s slides pointed out that it *is* possible to separate wrapped keys from encrypted data when needed by using the direct encryptio= n mode and therefore asked for this issue to be closed, as it is based upon= a false premise.=A0 Mike Jones also asked for this to be closed on this ba= sis, and pointed out that Nat Sakimura had already described the problem with this issue in the issue tracker. = =A0Richard asked a question about the security analysis of including the wr= apped key in the integrity calculation - Does the wrapped key need to be in= cluded in the integrity check or not?=A0 The question will be referred to CFRG but a request for possible attack mo= des being sent to the list is requested.

=A0

Given that the problem= stated in issue #4 was demonstrated to not actually be a problem during th= e discussions, I would ask again that the chairs close this one, and update the minutes to reflect this.

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 Thank you,

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Mike

=A0

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Friday, March 22, 2013 1:12 PM
To: jose@ietf.org=
Subject: [jose] Minutes

=A0

Preliminary minutes have been uploaded to the site.= =A0 Please review and comment back to me if you have disagreements.<= u>

=A0

http://www.ietf.org/proceedings/86/min= utes/minutes-86-jose

=A0

Note that the minutes have an action list at the bot= tom of them.

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

=A0


--bcaec54b48129df4a604d8d771d6-- From dick.hardt@gmail.com Tue Mar 26 10:58:05 2013 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 1880621F84F9 for ; Tue, 26 Mar 2013 10:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.795 X-Spam-Level: X-Spam-Status: No, score=-2.795 tagged_above=-999 required=5 tests=[AWL=-0.196, BAYES_00=-2.599] 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 9hDZzui3rtuF for ; Tue, 26 Mar 2013 10:58:04 -0700 (PDT) Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDD521F84F8 for ; Tue, 26 Mar 2013 10:58:04 -0700 (PDT) Received: by mail-pd0-f172.google.com with SMTP id w10so3160410pde.31 for ; Tue, 26 Mar 2013 10:58:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=G1DgcThCPeYbsmDbQtHFX8EH8QhmvUdDdQpuoUnutRg=; b=RRGOO79jmRRxyy5kd/G+as9zzIcvfqSBk/b7g8mw1KbBE+g36RlHXLApY/oLfhz8zT v/6C3KiW3Ya/ONaJjMtSG02q8yHJYhYp+7VwiULpIZLgQY9ERTj3HhBrOleHqo+lLy/l Xreg0mt2QRsprF9sk/HH+CisntFKD9G2DMzrUTwY5S/3Q/eKO7Aa7a7jBu0eJ+AC2ykX Ej4EzlJJGnnH+C+IeXkABvyAFykRRHTGigUnOROgjr8leETAiFiWY0uz86iqfyZGTqbA 1q+6aCDqXucOjSWvyFh4qVqGI6aGuatGUXgKBe3ZY885Oe4je7jysdmLdPDSkP9kMcU0 Fphg== X-Received: by 10.68.12.103 with SMTP id x7mr8542199pbb.37.1364320682650; Tue, 26 Mar 2013 10:58:02 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ip8sm18251800pbc.39.2013.03.26.10.57.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 10:58:00 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: Date: Tue, 26 Mar 2013 10:57:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> To: "jose@ietf.org" X-Mailer: Apple Mail (2.1503) Cc: John Bradley Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 26 Mar 2013 17:58:05 -0000 My other option would be to hack the 'kid' value to include both the = 'iss' value and the 'aud' value so that a recipient would be able to = determine if they are the audience and who the issuer is by cracking the = 'kid' =3D> but that seems like such a hack given that I have the ability = to put the 'aud' and 'iss' in the header. Am I the only one that sees the value in having the 'aud' and 'iss' in = the header for JWE? -- Dick On Mar 25, 2013, at 4:27 PM, Dick Hardt wrote: > 'iss' and 'aud' are not reserved header parameter names, so if I used = them, then they would be private names subject to collision.=20 >=20 > Unless there is a reason why they should not be allowed, I'd like them = to be reserved header parameter names so that their meaning is clear to = an implementation or library. I would like to write my libraries to look = at the header for those parameters if they are there. >=20 > On Mar 25, 2013, at 4:19 PM, John Bradley wrote: >=20 >> That will be compliant. The spec won't call out those particular = properties from JWT. =20 >>=20 >> If you think that they should be called out as optional parameters = that could be considered. However that is not a open issue at this = point. >>=20 >> John B. >> On 2013-03-25, at 8:09 PM, Dick Hardt wrote: >>=20 >>> Will that be compliant though? I would like to spec to say that I = can optionally include those properties in the header of a JWE. >>>=20 >>>=20 >>> On Mar 25, 2013, at 4:02 PM, John Bradley wrote: >>>=20 >>>> Once the change to ignore additional elements in the header there = is nothing to stop you from doing that. >>>>=20 >>>> You make a good point about scoping the 'kid' to the 'iss'.=20 >>>>=20 >>>> John B. >>>>=20 >>>> On 2013-03-25, at 7:53 PM, Dick Hardt wrote: >>>>=20 >>>>> Hello everyone >>>>>=20 >>>>> As I am implementing JOSE JWE, I would like to know who the 'iss' = and 'aud' is. I am using symmetric, shared keys and the 'aud' party = would like to know they really are the intended 'aud' and who the 'isa' = is. Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>>>>=20 >>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are as = any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>>>>=20 >>>>> Is there a reason why I cannot have 'iss' and 'aud' in the header? >>>>>=20 >>>>> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>>>>=20 >>>>> -- Dick >>>>> _______________________________________________ >>>>> jose mailing list >>>>> jose@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/jose >>>>=20 >>>=20 >>=20 >=20 From rlb@ipv.sx Tue Mar 26 10:58:14 2013 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 7A4B921F84F8 for ; Tue, 26 Mar 2013 10:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.415 X-Spam-Level: X-Spam-Status: No, score=-2.415 tagged_above=-999 required=5 tests=[AWL=0.561, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4gWzSaPIXpw5 for ; Tue, 26 Mar 2013 10:58:13 -0700 (PDT) Received: from mail-oa0-f51.google.com (mail-oa0-f51.google.com [209.85.219.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA9C21F8512 for ; Tue, 26 Mar 2013 10:58:13 -0700 (PDT) Received: by mail-oa0-f51.google.com with SMTP id g12so4553200oah.10 for ; Tue, 26 Mar 2013 10:58:13 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=4bJx5Vn9Qth09E+8drOgIkY5nOpXbMxbzNeLb1fiXlg=; b=JldsBF1sGnYK2XKyWSZtz08vCwcnl97A/yskPKrY4R3btYfnz0yvP863iiIB8slbqD kP6T3TaP5jCFdAPVbo9AQeEQ10F7I9rPxzeF+LEkjisTPuPWHbGyJM1nUd6+ZdYVB2d4 doAJpolNiNu5rp5t8o44rTsC93DkgWNIgcA3xG3ejT2HaanE9z0WEokB92u8jxOJnyxY oWFXbTICuJh+fO7PogsTf7EIqX2NCMlIzvdFf5wDzeg+IZRfRRTcFXS3ZBL8YcfnxzkK 81S+W0LzyIRVUWZyJPlzwswhfLLEwtHCTL7RLYyZp4BerJMpZWwF7dYH/Ko20zdrKAGL aI5g== MIME-Version: 1.0 X-Received: by 10.182.134.138 with SMTP id pk10mr2612021obb.80.1364320692856; Tue, 26 Mar 2013 10:58:12 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Tue, 26 Mar 2013 10:58:12 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> Date: Tue, 26 Mar 2013 13:58:12 -0400 Message-ID: From: Richard Barnes To: "Manger, James H" Content-Type: multipart/alternative; boundary=001a11c2971642576b04d8d7aac1 X-Gm-Message-State: ALoCoQnxma1hmaKCzZY0yPrDR6gcJMTjRI73wWOs3abpgl0yQeJ0zsomO8g+itLgeiaKnKcn2xf1 Cc: Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 26 Mar 2013 17:58:14 -0000 --001a11c2971642576b04d8d7aac1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable How about this change to Section 4.1.5 of JWE (and corresponding text in JWS): "If the JWK Set referenced by the URI contains more than one key, then the JWE object MUST contain a "kid" parameter to identify which key should be used." Also, while we're on the topic of "jku": The following text should be removed: """ The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. """ TLS does not need to be mandatory here. The only thing an adversary can do by changing the key set is cause decryption or signature validation to fail. [1] At most, these MUSTs should be SHOULDs. --Richard [1] Under the assumption that the attacker cannot modify the JWS. If this assumption is false, there's not reason to protect "jku" dereferences either. For JWS, the only reason an attacker would modify "jku" is to make it point to a key for which the attacker controls the private key. If the attacker controls the private key and can modify the JWS/JWE, then he could just as well remove the "jku" and replace it with a "jwk", and recompute the signature under his key. So "jku" protections add nothing. For JWE, it's not clear that there's any useful objective for the attacker at all. On Mon, Mar 25, 2013 at 6:46 PM, Manger, James H < James.H.Manger@team.telstra.com> wrote: > > I'd always just assumed that, short of some other means of figuring it > out, a kid header would accompany a jku to identify the specific key in t= he > set. **** > > ** ** > > Indeed, =93jku=94 needs to be accompanied by =93kid=94 to work in general= =97 but > this is a crappy solution. 99% of the time that a =93jku=94 is used you w= ant to > identify a single specific key so =93jku=94 should be capable of doing th= at > without requiring an extra field.**** > > ** ** > > A JOSE header does have room for =93kid=94 as well as =93jku=94. However,= many > contexts that use URIs as identifiers expect a URI to be THE identifier. > Needing two fields to do one task is inevitably awkward.**** > > ** ** > > Finally, identifying 1 item from a set is a perfect match for the whole > purpose of URI fragments so merely by the principle of least astonishment > JWK should specify how the fragment picks 1 key.**** > > ** ** > > --**** > > James Manger**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Brian Campbell > *Sent:* Monday, 25 March 2013 11:31 PM > *To:* jose issue tracker > *Cc:* draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org; > james@manger.com.au > *Subject:* Re: [jose] #16: URI identifying a specific key in a JWK set***= * > > ** ** > > I'd always just assumed that, short of some other means of figuring it > out, a kid header would accompany a jku to identify the specific key in t= he > set. **** > > ** ** > > On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker < > trac+jose@trac.tools.ietf.org> wrote:**** > > #16: URI identifying a specific key in a JWK set > > When a public key is required to process a JOSE message, providing a URI > for the key is a useful alternative to providing the actual key or a > certificate. The URI needs to identify the specific individual public ke= y > required for the specific JOSE message. A URI that merely identifies a s= et > of keys (one of which is the correct one) is not sufficient. > > Given that a "jku" field holds a URI pointing to a set of keys, we need = to > define how to use the fragment part of those URIs to identify a specific > key in the set. > > Using the "kid" (key id) in the fragment would be a sensible choice. > > -- > -------------------------+-----------------------------------------------= -- > Reporter: | Owner: draft-ietf-jose-json-web- > james@manger.com.au | key@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > key | Keywords: > Severity: - | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > jose > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > ** ** > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --001a11c2971642576b04d8d7aac1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable How about this change to Section 4.1.5 of JWE (and corresponding text in JW= S): =A0"If the JWK Set referenced by the URI contains more than one ke= y, then the JWE object MUST contain a "kid" parameter to identify= which key should be used."

Also, while we're on the topic of "jku": The f= ollowing text should be removed:
"""
=A0 =A0The
=A0 =A0protocol used to acquire the resource MUST pr= ovide integrity
=A0 =A0protection; an HTTP GET request to retrieve the certificate MUS= T use
=A0 =A0TLS [RFC2818] [RFC5246]; the identity of the server = MUST be
=A0 =A0validated, as per Section 3.1 of HTTP Over TLS [RF= C2818].
"""
TLS does not need to be mandatory h= ere. =A0The only thing an adversary can do by changing the key set is cause= decryption or signature validation to fail. [1] =A0At most, these MUSTs sh= ould be SHOULDs.

--Richard


[1] U= nder the assumption that the attacker cannot modify the JWS. =A0If this ass= umption is false, there's not reason to protect "jku" derefer= ences either. =A0For JWS, the only reason an attacker would modify "jk= u" is to make it point to a key for which the attacker controls the pr= ivate key. =A0If the attacker controls the private key and can modify the J= WS/JWE, then he could just as well remove the "jku" and replace i= t with a "jwk", and recompute the signature under his key. So &qu= ot;jku" protections add nothing. =A0For JWE, it's not clear that t= here's any useful objective for the attacker at all.





<= br>
On Mon, Mar 25, 2013 at 6:46 PM, Manger, Jame= s H <James.H.Manger@team.telstra.com> wrote:

> I'd always ju= st assumed that, short of some other means of figuring it out, a kid header= would accompany a jku to identify the specific key in the set. <= /u>

=A0<= /p>

Indeed, =93jku= =94 needs to be accompanied by =93kid=94 to work in general =97 but this is= a crappy solution. 99% of the time that a =93jku=94 is used you want to id= entify a single specific key so =93jku=94 should be capable of doing that w= ithout requiring an extra field.

=A0<= /p>

A JOSE header does hav= e room for =93kid=94 as well as =93jku=94. However, many contexts that use = URIs as identifiers expect a URI to be THE identifier. Needing two fields t= o do one task is inevitably awkward.

=A0<= /p>

Finally, identifying 1= item from a set is a perfect match for the whole purpose of URI fragments = so merely by the principle of least astonishment JWK should specify how the= fragment picks 1 key.

=A0<= /p>

--

James Manger

=A0=

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] <= b>On Behalf Of Brian Campbell
Sent: Monday, 25 March 2013 11:31 PM
To: jose issue tracke= r
Cc: draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org; james@manger.com.au Subject: Re: [jose] #16: URI identifying a specific key in a JWK set=

=A0

I'd always jus= t assumed that, short of some other means of figuring it out, a kid header = would accompany a jku to identify the specific key in the set.

=A0=

On Sun, Mar 24, 2013 at 6:40 PM, jos= e issue tracker <trac+jose@trac.tools.ietf.org> wrote:

#16: URI identifying a specific key in a JWK set
=
=A0When a public key is required to process a JOSE message, providing a= URI
=A0for the key is a useful alternative to providing the actual key = or a
=A0certificate. The URI needs to identify the specific individual public ke= y
=A0required for the specific JOSE message. A URI that merely identifie= s a set
=A0of keys (one of which is the correct one) is not sufficient.<= br>
=A0Given that a "jku" field holds a URI pointing to a set of = keys, we need to
=A0define how to use the fragment part of those URIs to= identify a specific
=A0key in the set.

=A0Using the "kid&qu= ot; (key id) in the fragment would be a sensible choice.

--
-------------------------+---------------------------------------= ----------
=A0Reporter: =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Owner: = =A0draft-ietf-jose-json-web-
=A0 james@manger.com.au =A0 =A0| =A0key@tools.ietf.org
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 | =A0 =A0 Status: =A0new
=A0Prior= ity: =A0major =A0 =A0 =A0 =A0| =A0Milestone:
Component: =A0json-web- =A0= =A0| =A0 =A0Version:
=A0 key =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| = =A0 Keywords:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0|
------------= -------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/16><= br>jose <http:= //tools.ietf.org/jose/>

_______________________________________________
jose mailing listjose@ietf.org
http= s://www.ietf.org/mailman/listinfo/jose

=A0

<= /div>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--001a11c2971642576b04d8d7aac1-- From rlb@ipv.sx Tue Mar 26 11:01:29 2013 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 806B921F8512 for ; Tue, 26 Mar 2013 11:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.166 X-Spam-Level: X-Spam-Status: No, score=-1.166 tagged_above=-999 required=5 tests=[AWL=-0.741, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 KcRa5+QSrHZN for ; Tue, 26 Mar 2013 11:01:28 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 9664221F8510 for ; Tue, 26 Mar 2013 11:01:28 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id wo10so4987493obc.39 for ; Tue, 26 Mar 2013 11:01:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=smUC7CluPulKAJiIzRQwyUIMSiWEq96fTzeKXTmRWhg=; b=i//2PYHeg8wBAUokjmdKFGBpaIbqeJQ/zQgz5Vb7J9FO8MHEyrCZ4haJKJDmjWi4+k hm2ZEZJ2vb3Se/9Py+PP+4imJu0tCKsPNGlkr5fBTBOopfuFuOdK9qkJ2BfAmtkftqTh 5xbLNUKpq61LKBYqrA0S76SIxiJANsXo4eI4T+qgl4oDCwwHor3vmei8l9nEPynOlg1p bRq/ZxFLKwrrn+F6+CLHbt2sUhDf+Z7EjZ6gosQTWUPhWHUAGFVSvvJ0M0VKjdKnijhC FJ0qyhN3ai9r1g+GDNoXd96AX8fO7F6W0U7BmNrNKriCFDLzyOQAnTaq5WigBlFwtohy dAJg== MIME-Version: 1.0 X-Received: by 10.60.171.50 with SMTP id ar18mr13602293oec.24.1364320888097; Tue, 26 Mar 2013 11:01:28 -0700 (PDT) Received: by 10.60.172.146 with HTTP; Tue, 26 Mar 2013 11:01:28 -0700 (PDT) X-Originating-IP: [192.1.255.184] In-Reply-To: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> Date: Tue, 26 Mar 2013 14:01:28 -0400 Message-ID: From: Richard Barnes To: Dick Hardt Content-Type: multipart/alternative; boundary=bcaec550af3ae5787904d8d7b50e X-Gm-Message-State: ALoCoQlbqWnTsiOQn5t/VEqM8Ix3DzV0IlRV1Kolx3hVSlQwelxs/VLQtg89/fRwzaYAexq9+u09 Cc: John Bradley , "jose@ietf.org" Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 26 Mar 2013 18:01:29 -0000 --bcaec550af3ae5787904d8d7b50e Content-Type: text/plain; charset=ISO-8859-1 It doesn't seem harmful to me to have these parameters in there. It just seems like they won't be useful in a lot of cases. Is there any particular reason that these fields have to be in the header itself? John Bradley had proposed earlier defining a separate container for things that aren't necessarily of general use for JWE. Perhaps we should set up a registry for JWE/JWS header parameters, with a liberal inclusion policy (e.g., Specification Required), so that things like this could be added easily. --Richard On Tue, Mar 26, 2013 at 1:57 PM, Dick Hardt wrote: > My other option would be to hack the 'kid' value to include both the 'iss' > value and the 'aud' value so that a recipient would be able to determine if > they are the audience and who the issuer is by cracking the 'kid' => but > that seems like such a hack given that I have the ability to put the 'aud' > and 'iss' in the header. > > Am I the only one that sees the value in having the 'aud' and 'iss' in the > header for JWE? > > -- Dick > > On Mar 25, 2013, at 4:27 PM, Dick Hardt wrote: > > > 'iss' and 'aud' are not reserved header parameter names, so if I used > them, then they would be private names subject to collision. > > > > Unless there is a reason why they should not be allowed, I'd like them > to be reserved header parameter names so that their meaning is clear to an > implementation or library. I would like to write my libraries to look at > the header for those parameters if they are there. > > > > On Mar 25, 2013, at 4:19 PM, John Bradley wrote: > > > >> That will be compliant. The spec won't call out those particular > properties from JWT. > >> > >> If you think that they should be called out as optional parameters that > could be considered. However that is not a open issue at this point. > >> > >> John B. > >> On 2013-03-25, at 8:09 PM, Dick Hardt wrote: > >> > >>> Will that be compliant though? I would like to spec to say that I can > optionally include those properties in the header of a JWE. > >>> > >>> > >>> On Mar 25, 2013, at 4:02 PM, John Bradley wrote: > >>> > >>>> Once the change to ignore additional elements in the header there is > nothing to stop you from doing that. > >>>> > >>>> You make a good point about scoping the 'kid' to the 'iss'. > >>>> > >>>> John B. > >>>> > >>>> On 2013-03-25, at 7:53 PM, Dick Hardt wrote: > >>>> > >>>>> Hello everyone > >>>>> > >>>>> As I am implementing JOSE JWE, I would like to know who the 'iss' > and 'aud' is. I am using symmetric, shared keys and the 'aud' party would > like to know they really are the intended 'aud' and who the 'isa' is. > Otherwise the 'iss' is inferred from the 'kid', and there is no guarantee > that two 'iss' won't have the same 'kid' for different keys from different > 'iss'. > >>>>> > >>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are as > any party able to intercept the token will have a pretty good idea of where > it is coming from and where it is going to. Knowing the 'iss' and 'aud' > allows the 'aud' to return an error before doing any crypto if the 'aud' > does not match or if there is no 'kid' for the 'iss'. > >>>>> > >>>>> Is there a reason why I cannot have 'iss' and 'aud' in the header? > >>>>> > >>>>> This is not an issue with JWS since the payload is clear and the > 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. > >>>>> > >>>>> -- Dick > >>>>> _______________________________________________ > >>>>> jose mailing list > >>>>> jose@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/jose > >>>> > >>> > >> > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --bcaec550af3ae5787904d8d7b50e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It doesn't seem harmful to me to have these parameters in there. =A0It = just seems like they won't be useful in a lot of cases.

<= div>Is there any particular reason that these fields have to be in the head= er itself? =A0John Bradley had proposed earlier defining a separate contain= er for things that aren't necessarily of general use for JWE.

Perhaps we should set up a registry for JWE/JWS header = parameters, with a liberal inclusion policy (e.g., Specification Required),= so that things like this could be added easily.

--Richard



On Tu= e, Mar 26, 2013 at 1:57 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
My other option would be to hack the 'ki= d' value to include both the 'iss' value and the 'aud' = value so that a recipient would be able to determine if they are the audien= ce and who the issuer is by cracking the 'kid' =3D> but that see= ms like such a hack given that I have the ability to put the 'aud' = and 'iss' in the header.

Am I the only one that sees the value in having the 'aud' and '= iss' in the header for JWE?

-- Dick

On Mar 25, 2013, at 4:27 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> 'iss' and 'aud' are not reserved header parameter name= s, so if I used them, then they would be private names subject to collision= .
>
> Unless there is a reason why they should not be allowed, I'd like = them to be reserved header parameter names so that their meaning is clear t= o an implementation or library. I would like to write my libraries to look = at the header for those parameters if they are there.
>
> On Mar 25, 2013, at 4:19 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
>> That will be compliant. =A0The spec won't call out those parti= cular properties from JWT.
>>
>> If you think that they should be called out as optional parameters= that could be considered. =A0However that is not a open issue at this poin= t.
>>
>> John B.
>> On 2013-03-25, at 8:09 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>
>>> Will that be compliant though? I would like to spec to say tha= t I can optionally include those properties in the header of a JWE.
>>>
>>>
>>> On Mar 25, 2013, at 4:02 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>>>
>>>> Once the change to ignore additional elements in the heade= r there is nothing to stop you from doing that.
>>>>
>>>> You make a good point about scoping the 'kid' to t= he 'iss'.
>>>>
>>>> John B.
>>>>
>>>> On 2013-03-25, at 7:53 PM, Dick Hardt <dick.hardt@gmail.com> wrote:
>>>>
>>>>> Hello everyone
>>>>>
>>>>> As I am implementing JOSE JWE, I would like to know wh= o the 'iss' and 'aud' is. I am using symmetric, shared keys= and the 'aud' party would like to know they really are the intende= d 'aud' and who the 'isa' is. Otherwise the 'iss' i= s inferred from the 'kid', and there is no guarantee that two '= iss' won't have the same 'kid' for different keys from diff= erent 'iss'.
>>>>>
>>>>> I don't see an issue with disclosure of who 'i= ss' and 'aud' are as any party able to intercept the token will= have a pretty good idea of where it is coming from and where it is going t= o. Knowing the 'iss' and 'aud' allows the 'aud' to = return an error before doing any crypto if the 'aud' does not match= or if there is no 'kid' for the 'iss'.
>>>>>
>>>>> Is there a reason why I cannot have 'iss' and = 'aud' in the header?
>>>>>
>>>>> This is not an issue with JWS since the payload is cle= ar and the 'aud' can evaluate the 'iss' and 'aud' p= roperties before doing crypto.
>>>>>
>>>>> -- Dick
>>>>> _______________________________________________
>>>>> jose mailing list
>>>>> jose@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/jose
>>>>
>>>
>>
>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--bcaec550af3ae5787904d8d7b50e-- From mamille2@cisco.com Tue Mar 26 11:12:08 2013 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 4DA0021F8895 for ; Tue, 26 Mar 2013 11:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 yH7C0zxLgJ-6 for ; Tue, 26 Mar 2013 11:12:07 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 43F4421F877B for ; Tue, 26 Mar 2013 11:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7310; q=dns/txt; s=iport; t=1364321527; x=1365531127; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ObpR9TbxNFg4ZT+1BvxbZNL6wHWqrf6EyJTgKVzuEpM=; b=gLXkxiiMo9I/6WtAEGbhyfGTlzTmi8E/V7drOLh6iGRnWCapr9++A1+X mu/Q5jn0bQpgU6ePM2cYgLsrVh/lfalRMiRSb2YO3is9oEvkeIfDFttHH uG7wgZKcgcsLP++QEgNoXE5xYGVupR9ro2U1QJMW925lZjx9O+MgMrXHe w=; X-Files: smime.p7s : 2283 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHjjUVGtJXHB/2dsb2JhbABDxAWBBhaBKoIfAQEBAwEBAQFrCwULAgEIGAokAh8GCyUCBA4FCAaHdAMJBgyxDYYPDYlXBIxHghoxB4JfYQOPQ4EohByNTIUbgwqCKA X-IronPort-AV: E=Sophos;i="4.84,913,1355097600"; d="p7s'?scan'208";a="191686233" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 26 Mar 2013 18:12:06 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r2QIC6fk001482 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 Mar 2013 18:12:06 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.203]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Tue, 26 Mar 2013 13:12:06 -0500 From: "Matt Miller (mamille2)" To: Dick Hardt Thread-Topic: [jose] 'aud' and 'iss' in JWE header Thread-Index: AQHOKauYGOdFznwqs0eXm3AIm8+stpi3WieAgAABzICAAALzAIAAAheAgAE2YwCAAAPygA== Date: Tue, 26 Mar 2013 18:12:05 +0000 Message-ID: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.129.24.61] Content-Type: multipart/signed; boundary="Apple-Mail=_90517C15-DC6E-4285-BE56-E01475343EC2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: John Bradley , "jose@ietf.org" Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 26 Mar 2013 18:12:08 -0000 --Apple-Mail=_90517C15-DC6E-4285-BE56-E01475343EC2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Mar 26, 2013, at 11:57 AM, Dick Hardt wrote: > My other option would be to hack the 'kid' value to include both the = 'iss' value and the 'aud' value so that a recipient would be able to = determine if they are the audience and who the issuer is by cracking the = 'kid' =3D> but that seems like such a hack given that I have the ability = to put the 'aud' and 'iss' in the header. >=20 > Am I the only one that sees the value in having the 'aud' and 'iss' in = the header for JWE? >=20 In my case (XMPP E2E), I have addressing information that exists = completely separate from the protected. Including 'aud' and 'iss' is of = no benefit to me. That doesn't mean it causes me harm, provided I can = ignore them. - m&m Matt Miller < mamille2@cisco.com > Cisco Systems, Inc. > -- Dick >=20 > On Mar 25, 2013, at 4:27 PM, Dick Hardt wrote: >=20 >> 'iss' and 'aud' are not reserved header parameter names, so if I used = them, then they would be private names subject to collision.=20 >>=20 >> Unless there is a reason why they should not be allowed, I'd like = them to be reserved header parameter names so that their meaning is = clear to an implementation or library. I would like to write my = libraries to look at the header for those parameters if they are there. >>=20 >> On Mar 25, 2013, at 4:19 PM, John Bradley wrote: >>=20 >>> That will be compliant. The spec won't call out those particular = properties from JWT. =20 >>>=20 >>> If you think that they should be called out as optional parameters = that could be considered. However that is not a open issue at this = point. >>>=20 >>> John B. >>> On 2013-03-25, at 8:09 PM, Dick Hardt wrote: >>>=20 >>>> Will that be compliant though? I would like to spec to say that I = can optionally include those properties in the header of a JWE. >>>>=20 >>>>=20 >>>> On Mar 25, 2013, at 4:02 PM, John Bradley = wrote: >>>>=20 >>>>> Once the change to ignore additional elements in the header there = is nothing to stop you from doing that. >>>>>=20 >>>>> You make a good point about scoping the 'kid' to the 'iss'.=20 >>>>>=20 >>>>> John B. >>>>>=20 >>>>> On 2013-03-25, at 7:53 PM, Dick Hardt = wrote: >>>>>=20 >>>>>> Hello everyone >>>>>>=20 >>>>>> As I am implementing JOSE JWE, I would like to know who the 'iss' = and 'aud' is. I am using symmetric, shared keys and the 'aud' party = would like to know they really are the intended 'aud' and who the 'isa' = is. Otherwise the 'iss' is inferred from the 'kid', and there is no = guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>>>>>=20 >>>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are = as any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>>>>>=20 >>>>>> Is there a reason why I cannot have 'iss' and 'aud' in the = header? >>>>>>=20 >>>>>> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>>>>>=20 >>>>>> -- Dick >>>>>> _______________________________________________ >>>>>> jose mailing list >>>>>> jose@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_90517C15-DC6E-4285-BE56-E01475343EC2 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFejCCBXYw ggNeoAMCAQICAwyLmDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQL ExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3Jp dHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjExMjgxNzQ5MzFaFw0x NDExMjgxNzQ5MzFaMDwxFzAVBgNVBAMTDk1hdHRoZXcgTWlsbGVyMSEwHwYJKoZIhvcNAQkBFhJt YW1pbGxlMkBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC7Sh5cQYtd /kfoG3KjXd8i2esxt+BtHCmuiSku2VECC6msLKzA08cGJ31GfyX7+996TV3D5omh51j5fznfFikk cVGsuKe+omo70Aidw48ISGygQk8ZJrU8JVVfTjKVJRX39wgj8w8CI/BCz4kXLirIBWKTv1ARuqsO 7I1aqT7pWHAwlAKIbYYEwfz46OjyzmqknglOecy/1PR09nXwAAIepSo0Jk9edqsU8Pdqsbx8cPUV jlFtVkk+58ORjefl+4BoGrzW24rGG2B04sNPrycNqZEaJLmdk5J9ie/FMV10H8wFW8syomuacPxv NhoUgNnkYsJiO7zJEKUUmbmW1GPFAgMBAAGjggFCMIIBPjAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG +EIBDQRJFkdUbyBnZXQgeW91ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRv IGh0dHA6Ly93d3cuQ0FjZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUH AQEEJjAkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB0GA1UdEQQWMBSBEm1hbWlsbGUy QGNpc2NvLmNvbTANBgkqhkiG9w0BAQUFAAOCAgEAKZeEUJTYYt15cxR3xYospy8OqOLn+03auURM X3eFTrbBy+vJEnEtDS5ffCKbzAho6XqGrgRg/7Frg2wtdfIJvcYnPsWjlF+TIWe69i9r7EfPZI6A DCWHeu5cK3t9h7WsF3iC+lBARWEE49QJcu6ASY4SpVnElADpUZkBLsKnp2vWEVvXdeFg0CCo9UgH gPnE5mUsUaERW0WGIbyR+gkUkfMUsnOj2yvdZzC55UqAfFGqb4ibVlpWMJihaTYaSuN7SOImcJ5V Ya1w4yPRY2GStiHtmwPKtxlMVwMIsj1DQ/knVPpyJ0N67y8TK3R077HMInjk8wF6yCJ7W29mGtsA Y74bHEwn4rMdPDAHK1aHvIhf5KZFBuDYm5Ii6yweR8mpUv66r11h1G9vZKpJyKqR0yikdJfQ+kGN C1mAFN6ZKfQexnzzAPUClzcrJQsLWGl1tss+LHWFEhSq0240bvUqPVNl52WGwMrgzP/W32HZz62W 1CUaWiy3Xr8cHEY3fTSqxPLJiEuRsUmg1+6cjtz9+Ya+IDZwPRtcqzmJFQq+Q1xHLKfS8uf/jxHP xVOzbPpF/O0E0A8Z9ShmfdhgrHNJExXMVerISlzQY6Aq+XzGyOXVwUVyfTnTj7orMacBAVUJNl4s MHEJ02oUeALFMoa2TvwtGEw6Ou7/UlNXt/E1iUkxggMzMIIDLwIBATCBgDB5MRAwDgYDVQQKEwdS b290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQg U2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZwIDDIuY MAkGBSsOAwIaBQCgggGHMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8X DTEzMDMyNjE4MTIwNlowIwYJKoZIhvcNAQkEMRYEFC96fHqFNa6EkpdNLYECuRWNl+ORMIGRBgkr BgEEAYI3EAQxgYMwgYAweTEQMA4GA1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5j YWNlcnQub3JnMSIwIAYDVQQDExlDQSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcN AQkBFhJzdXBwb3J0QGNhY2VydC5vcmcCAwyLmDCBkwYLKoZIhvcNAQkQAgsxgYOggYAweTEQMA4G A1UEChMHUm9vdCBDQTEeMBwGA1UECxMVaHR0cDovL3d3dy5jYWNlcnQub3JnMSIwIAYDVQQDExlD QSBDZXJ0IFNpZ25pbmcgQXV0aG9yaXR5MSEwHwYJKoZIhvcNAQkBFhJzdXBwb3J0QGNhY2VydC5v cmcCAwyLmDANBgkqhkiG9w0BAQEFAASCAQAK+LBCgVS3t6D6dGwo1qEfRvsh5s9efg/jUXinQoSm NbB0nfRn3TN2b4ys1mh6BWhF2yRPQvd1B+7kiRIrJ/DnmVsa9Jm4K8yEKky4CoEBYzgcTNeq12RF d95tvHnPgF1+q9MmcyxCtSFGv2CnivVAn5tFYyOsQRPIE7L/oKYv+1ssoBHdCI1I1ZCsalytQzvF 2+EtiNlZ0DEXt7o5+WEJ647ljPYbEJUDhRlMYviBAJn8L4VRXggGG2R0pOD3/5dTgq9ESlfX7rdz EXa4cnvcIPwLuM/6jJtQAdyUs0SRBzNYd4afTdXZou6WGxiKRKwgqIZv6kySKKR/12TXxAaCAAAA AAAA --Apple-Mail=_90517C15-DC6E-4285-BE56-E01475343EC2-- From mpeck@mitre.org Tue Mar 26 11:36:41 2013 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 2AD8421F8BDE for ; Tue, 26 Mar 2013 11:36:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 Gtj5ngxYoPQb for ; Tue, 26 Mar 2013 11:36:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 20DF121F8BD9 for ; Tue, 26 Mar 2013 11:36:37 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AC5142260047; Tue, 26 Mar 2013 14:36:36 -0400 (EDT) Received: from IMCCAS02.MITRE.ORG (imccas02.mitre.org [129.83.29.79]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 7FC111F0521; Tue, 26 Mar 2013 14:36:36 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.94]) by IMCCAS02.MITRE.ORG ([129.83.29.69]) with mapi id 14.02.0342.003; Tue, 26 Mar 2013 14:36:13 -0400 From: "Peck, Michael A" To: Richard Barnes , "Manger, James H" Thread-Topic: [jose] #16: URI identifying a specific key in a JWK set Thread-Index: AQHOKVSvM96ioyHukkWznLqrec216Ji3RayAgAFBrwD//8On0A== Date: Tue, 26 Mar 2013 18:36:12 +0000 Message-ID: <8B4C063947CD794BB6FF90C78BAE9B321EFDFFBA@IMCMBX04.MITRE.ORG> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [129.83.31.57] Content-Type: multipart/alternative; boundary="_000_8B4C063947CD794BB6FF90C78BAE9B321EFDFFBAIMCMBX04MITREOR_" MIME-Version: 1.0 Cc: Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 26 Mar 2013 18:36:41 -0000 --_000_8B4C063947CD794BB6FF90C78BAE9B321EFDFFBAIMCMBX04MITREOR_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm confused about how the jku and jwk public key dereference mechanisms wi= ll be used safely. An attacker can obviously put any public key at an attacker-controlled URI = and point the recipient there (jku). I already complained about jwk. The recipient needs to do something to associate the public key with the se= nder's identity / decide to trust it - I guess this would be an out-of-band= list of trusted public keys, trusted public key fingerprints, or whatever = - though in that case, why does the recipient need to fetch the public key?= Just store it and refer to it with "kid"? I suppose I agree with Richard that TLS doesn't add value, unless the trust= mechanism is based on the URI (i.e. I trust public keys from https://examp= le.com), in which case it would add value - the whole picture isn't in here= though maybe it doesn't need to be. I would think there are also security considerations around forcing the rec= ipient to go to arbitrary URIs in order to verify the signature, but I supp= ose this risk already exists on the web in general so maybe it's not worth = complaining about. From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Ric= hard Barnes Sent: Tuesday, March 26, 2013 1:58 PM To: Manger, James H Cc: Brian Campbell; jose@ietf.org Subject: Re: [jose] #16: URI identifying a specific key in a JWK set How about this change to Section 4.1.5 of JWE (and corresponding text in JW= S): "If the JWK Set referenced by the URI contains more than one key, then= the JWE object MUST contain a "kid" parameter to identify which key should= be used." Also, while we're on the topic of "jku": The following text should be remov= ed: """ The protocol used to acquire the resource MUST provide integrity protection; an HTTP GET request to retrieve the certificate MUST use TLS [RFC2818] [RFC5246]; the identity of the server MUST be validated, as per Section 3.1 of HTTP Over TLS [RFC2818]. """ TLS does not need to be mandatory here. The only thing an adversary can do= by changing the key set is cause decryption or signature validation to fai= l. [1] At most, these MUSTs should be SHOULDs. --Richard [1] Under the assumption that the attacker cannot modify the JWS. If this = assumption is false, there's not reason to protect "jku" dereferences eithe= r. For JWS, the only reason an attacker would modify "jku" is to make it p= oint to a key for which the attacker controls the private key. If the atta= cker controls the private key and can modify the JWS/JWE, then he could jus= t as well remove the "jku" and replace it with a "jwk", and recompute the s= ignature under his key. So "jku" protections add nothing. For JWE, it's no= t clear that there's any useful objective for the attacker at all. On Mon, Mar 25, 2013 at 6:46 PM, Manger, James H > wrote: > I'd always just assumed that, short of some other means of figuring it ou= t, a kid header would accompany a jku to identify the specific key in the s= et. Indeed, "jku" needs to be accompanied by "kid" to work in general - but thi= s is a crappy solution. 99% of the time that a "jku" is used you want to id= entify a single specific key so "jku" should be capable of doing that witho= ut requiring an extra field. A JOSE header does have room for "kid" as well as "jku". However, many cont= exts that use URIs as identifiers expect a URI to be THE identifier. Needin= g two fields to do one task is inevitably awkward. Finally, identifying 1 item from a set is a perfect match for the whole pur= pose of URI fragments so merely by the principle of least astonishment JWK = should specify how the fragment picks 1 key. -- James Manger From: jose-bounces@ietf.org [mailto:jose-boun= ces@ietf.org] On Behalf Of Brian Campbell Sent: Monday, 25 March 2013 11:31 PM To: jose issue tracker Cc: draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org; james@manger= .com.au Subject: Re: [jose] #16: URI identifying a specific key in a JWK set I'd always just assumed that, short of some other means of figuring it out,= a kid header would accompany a jku to identify the specific key in the set= . On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker > wrote: #16: URI identifying a specific key in a JWK set When a public key is required to process a JOSE message, providing a URI for the key is a useful alternative to providing the actual key or a certificate. The URI needs to identify the specific individual public key required for the specific JOSE message. A URI that merely identifies a set of keys (one of which is the correct one) is not sufficient. Given that a "jku" field holds a URI pointing to a set of keys, we need to define how to use the fragment part of those URIs to identify a specific key in the set. Using the "kid" (key id) in the fragment would be a sensible choice. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- james@manger.com.au | key@tools.ietf.org<= mailto:key@tools.ietf.org> Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: key | Keywords: Severity: - | -------------------------+------------------------------------------------- Ticket URL: jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose --_000_8B4C063947CD794BB6FF90C78BAE9B321EFDFFBAIMCMBX04MITREOR_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m confused about = how the jku and jwk public key dereference mechanisms will be used safely.<= o:p>

An attacker can obviously= put any public key at an attacker-controlled URI and point the recipient t= here (jku). I already complained about jwk.

 <= /p>

The recipient needs to do= something to associate the public key with the sender’s identity / d= ecide to trust it – I guess this would be an out-of-band list of trusted public keys, trusted public key fingerprints, or whatever - tho= ugh in that case, why does the recipient need to fetch the public key? Just= store it and refer to it with “kid”?

 <= /p>

I suppose I agree with Ri= chard that TLS doesn’t add value, unless the trust mechanism is based= on the URI (i.e. I trust public keys from https://example.com), in which case it = would add value – the whole picture isn’t in here though maybe = it doesn’t need to be.

 <= /p>

I would think there are a= lso security considerations around forcing the recipient to go to arbitrary= URIs in order to verify the signature, but I suppose this risk already exists on the web in general so maybe it’s not worth co= mplaining about.

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
Sent: Tuesday, March 26, 2013 1:58 PM
To: Manger, James H
Cc: Brian Campbell; jose@ietf.org
Subject: Re: [jose] #16: URI identifying a specific key in a JWK set=

 

How about this change to Section 4.1.5 of JWE (and c= orresponding text in JWS):  "If the JWK Set referenced by the URI= contains more than one key, then the JWE object MUST contain a "kid&q= uot; parameter to identify which key should be used."

 

Also, while we're on the topic of "jku": T= he following text should be removed:

"""

   The

   protocol used to acquire the resource M= UST provide integrity

   protection; an HTTP GET request to retr= ieve the certificate MUST use

   TLS [RFC2818] [RFC5246]; the identity o= f the server MUST be

   validated, as per Section 3.1 of HTTP O= ver TLS [RFC2818].

"""

TLS does not need to be mandatory here.  The on= ly thing an adversary can do by changing the key set is cause decryption or= signature validation to fail. [1]  At most, these MUSTs should be SHO= ULDs.

 

--Richard

 

 

[1] Under the assumption that the attacker cannot mo= dify the JWS.  If this assumption is false, there's not reason to prot= ect "jku" dereferences either.  For JWS, the only reason an = attacker would modify "jku" is to make it point to a key for which the attacker controls the private key.  If the attacker con= trols the private key and can modify the JWS/JWE, then he could just as wel= l remove the "jku" and replace it with a "jwk", and rec= ompute the signature under his key. So "jku" protections add nothing.  For JWE, it's not clear that there's any useful objecti= ve for the attacker at all.

 

 

 

 

 

 

On Mon, Mar 25, 2013 at 6:46 PM, Manger, James H <= ;James= .H.Manger@team.telstra.com> wrote:

> I'd always just assumed that, short of s= ome other means of figuring it out, a kid header would accompany a jku to i= dentify the specific key in the set.

 

Indeed, “jku”= ; needs to be accompanied by “kid” to work in general — b= ut this is a crappy solution. 99% of the time that a “jku” is used you want to ide= ntify a single specific key so “jku” should be capable of doing= that without requiring an extra field.

 

A JOSE header does have = room for “kid” as well as “jku”. However, many cont= exts that use URIs as identifiers expect a URI to be THE identifier. Needing two fie= lds to do one task is inevitably awkward.<= /o:p>

 

Finally, identifying 1 i= tem from a set is a perfect match for the whole purpose of URI fragments so merely by the principle of least astonishment JWK should spec= ify how the fragment picks 1 key.

 

--

James Manger

 

From: jose-bounces@iet= f.org [mailto:jose-bounces@ietf.org] On Behalf Of Brian Campbell
Sent: Monday, 25 March 2013 11:31 PM
To: jose issue tracker
Cc: draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org; james@manger.com.au
Subject: Re: [jose] #16: URI identifying a specific key in a JWK set=

 

I'd always just assumed that, short of some o= ther means of figuring it out, a kid header would accompany a jku to identi= fy the specific key in the set.

 

On Sun, Mar 24, 2013 at 6:40 PM, jose issue t= racker <trac+jose@trac.tools.ietf.org> wrote:

#16: URI identifying a specific key in a JWK = set

 When a public key is required to process a JOSE message, providing a = URI
 for the key is a useful alternative to providing the actual key or a<= br>  certificate. The URI needs to identify the specific individual public= key
 required for the specific JOSE message. A URI that merely identifies = a set
 of keys (one of which is the correct one) is not sufficient.

 Given that a "jku" field holds a URI pointing to a set of k= eys, we need to
 define how to use the fragment part of those URIs to identify a speci= fic
 key in the set.

 Using the "kid" (key id) in the fragment would be a sensibl= e choice.

--
-------------------------+---------------------------------------------= ----
 Reporter:               |   &= nbsp;  Owner:  draft-ietf-jose-json-web-
  james@mange= r.com.au    |  key@tools.ietf.org
     Type:  defect       |    = Status:  new
 Priority:  major        |  Milestone: Component:  json-web-    |    Version:
  key                   &= nbsp;|   Keywords:
 Severity:  -            |
-------------------------+---------------------------------------------= ----

Ticket URL: <https://tools.ietf.org/wg/jose/trac/ticket/16>
jose <http://t= ools.ietf.org/jose/>

_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

 

--_000_8B4C063947CD794BB6FF90C78BAE9B321EFDFFBAIMCMBX04MITREOR_-- From dick.hardt@gmail.com Tue Mar 26 11:44:11 2013 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 D4BF721F877B for ; Tue, 26 Mar 2013 11:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[AWL=0.332, 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 9r+rIuuKsT88 for ; Tue, 26 Mar 2013 11:44:11 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id DCF3A21F8765 for ; Tue, 26 Mar 2013 11:44:08 -0700 (PDT) Received: by mail-pa0-f44.google.com with SMTP id bi5so1754600pad.17 for ; Tue, 26 Mar 2013 11:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=fzXTCoHeQzP2nWO0p9ONnu9Q/pzR7W5X3+MxCxm0Vnw=; b=Dw9DGCYGtgSwPFcCz57NpG8VQCJl9fKENdZiLlNHgjJTKREh4mTXipCrfXMp8H7HrH WPplH35uTJSwthpNTeWX0m7gy+o/MQvoiSirlVmEtIo9TFdE8E2pjvyeKmKVzVLJewex 4LoZT6iZsvYFdh/Cxo00CPr2FQPKGortEIi9avTl1qgEb1AfbWFfimXeW1vp0UbgcNXt 0LzUhgLINzM6npu6Ak2wlK4sJaqHNr8ekLNjMmxIhEVeqaQYma0R8crhNV9NW4zR8izi mM84iN9mIR14olXm5kQ0IgQAS1bJIWRB3OCHl0PUlGbxWL/eWTGF6RARaGlaTDOoPKRZ 001w== X-Received: by 10.68.204.164 with SMTP id kz4mr22791625pbc.158.1364323446538; Tue, 26 Mar 2013 11:44:06 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id zm1sm18384703pbc.26.2013.03.26.11.44.01 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Mar 2013 11:44:02 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: Date: Tue, 26 Mar 2013 11:43:59 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <57A4986E-4AA7-4E96-8EE6-53F3CE2D73EA@gmail.com> <942E1B2E-1469-4472-83A4-3884CF21F5EB@ve7jtb.com> To: "Matt Miller (mamille2)" X-Mailer: Apple Mail (2.1503) Cc: John Bradley , jose@ietf.org Subject: Re: [jose] 'aud' and 'iss' in JWE header 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, 26 Mar 2013 18:44:12 -0000 I would expect that you could ignore them, but if they were present, = would you not want to check that they are the same values as what is in = the payload? For example, if 'kid' is present, then one would expect that to be = needed and that you would not ignore it as a signal as to what key was = used to encrypt the JWE. If there is no 'kid', then you must know what = key to use without it. On Mar 26, 2013, at 11:12 AM, "Matt Miller (mamille2)" = wrote: >=20 > On Mar 26, 2013, at 11:57 AM, Dick Hardt > wrote: >=20 >> My other option would be to hack the 'kid' value to include both the = 'iss' value and the 'aud' value so that a recipient would be able to = determine if they are the audience and who the issuer is by cracking the = 'kid' =3D> but that seems like such a hack given that I have the ability = to put the 'aud' and 'iss' in the header. >>=20 >> Am I the only one that sees the value in having the 'aud' and 'iss' = in the header for JWE? >>=20 >=20 > In my case (XMPP E2E), I have addressing information that exists = completely separate from the protected. Including 'aud' and 'iss' is of = no benefit to me. That doesn't mean it causes me harm, provided I can = ignore them. >=20 >=20 > - m&m >=20 > Matt Miller < mamille2@cisco.com > > Cisco Systems, Inc. >=20 >> -- Dick >>=20 >> On Mar 25, 2013, at 4:27 PM, Dick Hardt wrote: >>=20 >>> 'iss' and 'aud' are not reserved header parameter names, so if I = used them, then they would be private names subject to collision.=20 >>>=20 >>> Unless there is a reason why they should not be allowed, I'd like = them to be reserved header parameter names so that their meaning is = clear to an implementation or library. I would like to write my = libraries to look at the header for those parameters if they are there. >>>=20 >>> On Mar 25, 2013, at 4:19 PM, John Bradley wrote: >>>=20 >>>> That will be compliant. The spec won't call out those particular = properties from JWT. =20 >>>>=20 >>>> If you think that they should be called out as optional parameters = that could be considered. However that is not a open issue at this = point. >>>>=20 >>>> John B. >>>> On 2013-03-25, at 8:09 PM, Dick Hardt wrote: >>>>=20 >>>>> Will that be compliant though? I would like to spec to say that I = can optionally include those properties in the header of a JWE. >>>>>=20 >>>>>=20 >>>>> On Mar 25, 2013, at 4:02 PM, John Bradley = wrote: >>>>>=20 >>>>>> Once the change to ignore additional elements in the header there = is nothing to stop you from doing that. >>>>>>=20 >>>>>> You make a good point about scoping the 'kid' to the 'iss'.=20 >>>>>>=20 >>>>>> John B. >>>>>>=20 >>>>>> On 2013-03-25, at 7:53 PM, Dick Hardt = wrote: >>>>>>=20 >>>>>>> Hello everyone >>>>>>>=20 >>>>>>> As I am implementing JOSE JWE, I would like to know who the = 'iss' and 'aud' is. I am using symmetric, shared keys and the 'aud' = party would like to know they really are the intended 'aud' and who the = 'isa' is. Otherwise the 'iss' is inferred from the 'kid', and there is = no guarantee that two 'iss' won't have the same 'kid' for different keys = from different 'iss'. >>>>>>>=20 >>>>>>> I don't see an issue with disclosure of who 'iss' and 'aud' are = as any party able to intercept the token will have a pretty good idea of = where it is coming from and where it is going to. Knowing the 'iss' and = 'aud' allows the 'aud' to return an error before doing any crypto if the = 'aud' does not match or if there is no 'kid' for the 'iss'. >>>>>>>=20 >>>>>>> Is there a reason why I cannot have 'iss' and 'aud' in the = header? >>>>>>>=20 >>>>>>> This is not an issue with JWS since the payload is clear and the = 'aud' can evaluate the 'iss' and 'aud' properties before doing crypto. >>>>>>>=20 >>>>>>> -- Dick >>>>>>> _______________________________________________ >>>>>>> jose mailing list >>>>>>> jose@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/jose >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> jose mailing list >> jose@ietf.org >> https://www.ietf.org/mailman/listinfo/jose >=20 From James.H.Manger@team.telstra.com Tue Mar 26 15:32:23 2013 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 9CEC921F85C3 for ; Tue, 26 Mar 2013 15:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] 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 Bcyf4Ea6+WAp for ; Tue, 26 Mar 2013 15:32:23 -0700 (PDT) Received: from ipxavo.tcif.telstra.com.au (ipxavo.tcif.telstra.com.au [203.35.135.200]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED1521F85BC for ; Tue, 26 Mar 2013 15:32:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,915,1355058000"; d="scan'208";a="125653696" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipoavi.tcif.telstra.com.au with ESMTP; 27 Mar 2013 09:32:22 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7026"; a="174188700" Received: from wsmsg3754.srv.dir.telstra.com ([172.49.40.198]) by ipcavi.tcif.telstra.com.au with ESMTP; 27 Mar 2013 09:32:21 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3754.srv.dir.telstra.com ([172.49.40.198]) with mapi; Wed, 27 Mar 2013 09:32:21 +1100 From: "Manger, James H" To: Vladimir Dzhuvinov / NimbusDS , Juraj Somorovsky Date: Wed, 27 Mar 2013 09:32:19 +1100 Thread-Topic: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) Thread-Index: Ac4p6GNTFlaTABSKQLWjM67ALK71HwAiGgGg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BEFFD2B@WSMSG3153V.srv.dir.telstra.com> References: <20130325230836.cc40c4f3d92d2001859047cd8cabb9ab.1243c28b28.wbe@email07.europe.secureserver.net> In-Reply-To: <20130325230836.cc40c4f3d92d2001859047cd8cabb9ab.1243c28b28.wbe@email07.europe.secureserver.net> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: IETF JOSE WG Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 26 Mar 2013 22:32:23 -0000 PiBJIHJlYWQgdGhlIHBhcGVyIEphbWVzIHN1Z2dlc3RlZCwgYW5kIGl0IGFkdm9jYXRlcyBhY2hp ZXZpbmcgY29uc3RhbnQNCj4gdGltZSB0byBzb2x2ZSB0aW1pbmcgYXR0YWNrcy4gSG93IGFib3V0 IGRvaW5nIHRoZSBvcHBvc2l0ZSwgaW5qZWN0aW5nDQo+IHJhbmRvbSBkdXJhdGlvbiBuby1vcHMg aW4gdGhlIGRlY3J5cHRpb24gY29kZT8NCg0KVGhhdCBkb2Vzbid0IHNvbHZlIHRoZSBwcm9ibGVt LiBJdCBtYWtlcyBhbiBhdHRhY2tlcuKAmXMgam9iIGhhcmRlciwgYnV0IGJ5IG1ha2luZyBtb3Jl IHJlcXVlc3RzIGFuZCBhcHBseWluZyBzdGF0aXN0aWNzIHRoZSBhdHRhY2tlciBjYW4gcmVtb3Zl IHRoZSBhZmZlY3Qgb2YgdGhlIHJhbmRvbS1kdXJhdGlvbiBuby1vcHMuIEFuZCBpdCBzbG93cyB5 b3VyIGNvZGUgZG93bi4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCj4+IFRha2UgYXQgbG9vayBh dCBodHRwOi8vd3d3LmltcGVyaWFsdmlvbGV0Lm9yZy8yMDEzLzAyLzA0L2x1Y2t5dGhpcnRlZW4u aHRtbCBmb3Igc29tZSBpZGVhIGFib3V0IHRoZSBjYXJlIHJlcXVpcmVkIHRvIGFjdHVhbGx5IHJl c2lzdCB0aW1pbmcgYXR0YWNrcy4NCg0KPj4gVGhlIEdvIGxhbmd1YWdlIGFwcGVhcnMgdG8gaGF2 ZSBjb2RlIHdpdGggZGVjZW50IHByb3RlY3Rpb25zIHRvIGF2b2lkIGxlYWtpbmcgY3J1Y2lhbCB0 aW1pbmcgZGV0YWlsczogaHR0cDovL2dvbGFuZy5vcmcvc3JjL3BrZy9jcnlwdG8vcnNhL3BrY3Mx djE1LmdvLiANCg== From James.H.Manger@team.telstra.com Tue Mar 26 22:33:45 2013 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 A9D1421F902B for ; Tue, 26 Mar 2013 22:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, HTML_MESSAGE=0.001, RELAY_IS_203=0.994] 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 WGRuwBFj20G8 for ; Tue, 26 Mar 2013 22:33:45 -0700 (PDT) Received: from ipxbvo.tcif.telstra.com.au (ipxbvo.tcif.telstra.com.au [203.35.135.204]) by ietfa.amsl.com (Postfix) with ESMTP id 2570821F8EAC for ; Tue, 26 Mar 2013 22:33:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,915,1355058000"; d="scan'208,217";a="126222353" Received: from unknown (HELO ipcbvi.tcif.telstra.com.au) ([10.97.217.204]) by ipobvi.tcif.telstra.com.au with ESMTP; 27 Mar 2013 16:33:40 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7026"; a="121868352" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipcbvi.tcif.telstra.com.au with ESMTP; 27 Mar 2013 16:33:40 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Wed, 27 Mar 2013 16:33:40 +1100 From: "Manger, James H" To: Richard Barnes , "jose@ietf.org" Date: Wed, 27 Mar 2013 16:33:39 +1100 Thread-Topic: [jose] JWK Generator - base64url padding Thread-Index: Ac4qQ7LTcYSCEeUmSIi5PpSWO84GtgAaFItg Message-ID: <255B9BB34FB7D647A506DC292726F6E1150BFAA2C0@WSMSG3153V.srv.dir.telstra.com> References: <5150B533.2080205@mitre.org> <5151B236.2080001@mitre.org> In-Reply-To: Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: multipart/alternative; boundary="_000_255B9BB34FB7D647A506DC292726F6E1150BFAA2C0WSMSG3153Vsrv_" MIME-Version: 1.0 Subject: Re: [jose] JWK Generator - base64url padding 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, 27 Mar 2013 05:33:45 -0000 --_000_255B9BB34FB7D647A506DC292726F6E1150BFAA2C0WSMSG3153Vsrv_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmljaGFyZCwNCg0KWW91ciBiYXNlNjR1cmwgZW5jb2RlZCBmaWVsZHMgaW5jbHVkZSDigJw94oCd IHBhZGRpbmcgY2hhcmFjdGVycy4NCldlIHNob3VsZCBvbWl0IHRob3NlLiBQcm9iYWJseSBuZWVk IGEgZmV3IGV4dHJhIHdvcmRzIGluIHRoZSBzcGVjLCBlZyDigJxiYXNlNjR1cmwtZW5jb2Rpbmcg KHdpdGhvdXQgcGFkZGluZyBjaGFyYWN0ZXJzKeKAnS4gVGhlIEpXRSBzcGVjIG1lbnRpb25zIG9t aXR0aW5nIHRoZSBwYWRkaW5nIGluIHRoZSB0ZXJtaW5vbG9neSBzZWN0aW9uLg0KDQotLQ0KSmFt ZXMgTWFuZ2VyDQoNCkZyb206IGpvc2UtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJpY2hhcmQgQmFybmVzDQpTZW50OiBXZWRuZXNk YXksIDI3IE1hcmNoIDIwMTMgNDowMiBBTQ0KVG86IEp1c3RpbiBSaWNoZXINCkNjOiBqb3NlQGll dGYub3JnOyBBeGVsLk5lbm5rZXJAdGVsZWtvbS5kZQ0KU3ViamVjdDogUmU6IFtqb3NlXSBKV0sg R2VuZXJhdG9yDQoNCldlJ3ZlIGdvdCBzb21lIHNpbWlsYXIgdG9vbHMgaW4gUG9seUNyeXB0LCBv dXIgV2ViQ3J5cHRvIHBvbHlmaWxsIFsxXS4gIE9uZSBvZiB0aGUgZGVtb3MgaXMgYSBzZWxmLXNp Z25lZCBjZXJ0aWZpY2F0ZSBnZW5lcmF0b3IsIHdoaWNoIG91dHB1dHMgcHJpdmF0ZSBrZXkgYXMg YSBwc2V1ZG8tSldLIFsyXS4NCg0KSSB3YXMgZ29pbmcgdG8gcHV0IGEgY29kZSBzbmlwcGV0IGhl cmUgdG8gZGVtb25zdHJhdGUgaG93IHRvIGdlbmVyYXRlIGFuIFJTQSBKV0sgd2l0aCBQb2x5Q3J5 cHQuICBJbnN0ZWFkIEkganVzdCB0aHJldyB1cCBhIG5ldyBkZW1vIHBhZ2UgdGhhdCB3aWxsIGRv IGl0IGZvciB5b3UgWzNdLiAgU2FtcGxlIG91dHB1dDoNCnsibiI6ImE5X0g1aThUN1pnNjVDVVlQ R1JkNFItTHc3VUZpSDdndUlKNWdRZ2pKVWRubG82ZWR5VlNDdXhfeFY0M1QtUWUyLVNHa1JiVWly WmN6ZENlZ2ZBVmpBZWdWTXRucnNnT2VfRXFoTjFDRmxtUEo4d3dDNU9veWM2dTFfRkJkdTRGTDNL bDdqV3BJSS1pa09oWm0wNXhVbmpfTTdDTU1KbzZ3NFB2QUF6bi1pcz0iLCJlIjoiQVFBQiIsImQi OiJFVG0xc1BMNWlxb1JWVmI3RE1HMkhfbXFsc0MwTm55VUk4SnA1b25IR3VfUkFjQ2FXMG94Vko4 NU0tbjhpUnhUTlNmRHVTMWRHUjFQcW1uU3Rjc0JsWm5rd2M5OXZsOWd0VVcyekFzMEotVzNZUDg4 VGszaE5NLTZ2UzJTbzktTFJNYXNoY1dydUhCUG1MdWROLVV4R3phbnZTM0c1OGprSzFCTFFDVzZ4 VkU9IiwicCI6Inc4Wm5ndkxWa0UzcmVXdnJhNnZEZDNLTEpxREhJSzYwMmg4eWw0MHZMcVgwdTVV bVhvaklxTDdrOVdwbUVuNWd2VlBzcC1YRHRrVi01ME9OOU5aRDh3PT0iLCJxIjoialE4S3paM2dI UHoteUlTYTBFYlJkSV9jbWVJMDNLcTFhQWo3YlNIRGN5cjRPam5rSTRLNmxUVk5UR1VhemYxMEJy Slo1XzJZajV6T2Z1alY4MDNXNlE9PSIsImRwIjoibTQtTWNvM1lTdGpQY2VUaDVPVlA1UnJjSE82 R0s1OEd6NGNZb1Rtck13cmxZeVJKbjdaYWsxTlVCUG50YjJhQ0lnNk1yb0N3dWFXUkI5d3k4VWhN Snc9PSIsImRxIjoiQ2dJcE9CR2RsekQwT3ZIOXNnMTBTeHJ5QWhFa3d3dHh0Nkg3aFBEQ1YyZVRH VDZHUzJhNUttRVB6UDNYZXdvaXMxN3dOaC11TlhKZ3pHeGswZENTRVE9PSIsInFpIjoia1o5TUZB WVJaS1Bsb1VwcmlqdUtzSnhxZnNBVkpOSU5GcXFyV3I1eWNxSEx0cG1oazZsNTh3a3hGcGNVOTRU SlBnZjFDYUpPajJwR1JUeWlqUGEzLXc9PSJ9DQoNCklmIHlvdSB3YW50IHRvIHVzZSBQb2x5Q3J5 cHQgYW5kIG5lZWQgRUMsIGxldCBtZSBrbm93LCBhbmQgSSBjYW4gcHJvYmFibHkgZ2V0IGl0IGlt cGxlbWVudGVkIHByZXR0eSBxdWlja2x5Lg0KDQpIb3BlIHRoaXMgaGVscHMsDQotLVJpY2hhcmQN Cg0KDQpbMV0gPGh0dHA6Ly9wb2x5Y3J5cHQubmV0Pg0KWzJdIDxodHRwOi8vZGVtby5wb2x5Y3J5 cHQubmV0L3g1MDkvPg0KWzNdIDxodHRwOi8vZGVtby5wb2x5Y3J5cHQubmV0L2p3ay8+DQoNCg0K DQo= --_000_255B9BB34FB7D647A506DC292726F6E1150BFAA2C0WSMSG3153Vsrv_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0 IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6 MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1p bHk6Q29uc29sYXM7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJh bGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30N CnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0t Pjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0 PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4 dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48 L2hlYWQ+PGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9 V29yZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlJp Y2hhcmQsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Zb3VyIGJhc2U2NHVybCBlbmNvZGVkIGZpZWxkcyBp bmNsdWRlIOKAnD3igJ0gcGFkZGluZyBjaGFyYWN0ZXJzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5XZSBzaG91bGQgb21pdCB0 aG9zZS4gUHJvYmFibHkgbmVlZCBhIGZldyBleHRyYSB3b3JkcyBpbiB0aGUgc3BlYywgZWcg4oCc YmFzZTY0dXJsLWVuY29kaW5nICh3aXRob3V0IHBhZGRpbmcgY2hhcmFjdGVycynigJ0uIFRoZSBK V0Ugc3BlYyBtZW50aW9ucyBvbWl0dGluZyB0aGUgcGFkZGluZyBpbiB0aGUgdGVybWlub2xvZ3kg c2VjdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0tPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkphbWVzIE1hbmdlcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2Pjxk aXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IGpvc2UtYm91bmNlc0Bp ZXRmLm9yZyBbbWFpbHRvOmpvc2UtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwv Yj5SaWNoYXJkIEJhcm5lczxicj48Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCAyNyBNYXJjaCAyMDEz IDQ6MDIgQU08YnI+PGI+VG86PC9iPiBKdXN0aW4gUmljaGVyPGJyPjxiPkNjOjwvYj4gam9zZUBp ZXRmLm9yZzsgQXhlbC5OZW5ua2VyQHRlbGVrb20uZGU8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBb am9zZV0gSldLIEdlbmVyYXRvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBj bGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPldl J3ZlIGdvdCBzb21lIHNpbWlsYXIgdG9vbHMgaW4gUG9seUNyeXB0LCBvdXIgV2ViQ3J5cHRvIHBv bHlmaWxsIFsxXS4gJm5ic3A7T25lIG9mIHRoZSBkZW1vcyBpcyBhIHNlbGYtc2lnbmVkIGNlcnRp ZmljYXRlIGdlbmVyYXRvciwgd2hpY2ggb3V0cHV0cyBwcml2YXRlIGtleSBhcyBhIHBzZXVkby1K V0sgWzJdLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkkgd2Fz IGdvaW5nIHRvIHB1dCBhIGNvZGUgc25pcHBldCBoZXJlIHRvIGRlbW9uc3RyYXRlIGhvdyB0byBn ZW5lcmF0ZSBhbiBSU0EgSldLIHdpdGggUG9seUNyeXB0LiAmbmJzcDtJbnN0ZWFkIEkganVzdCB0 aHJldyB1cCBhIG5ldyBkZW1vIHBhZ2UgdGhhdCB3aWxsIGRvIGl0IGZvciB5b3UgWzNdLiAmbmJz cDtTYW1wbGUgb3V0cHV0OjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9y bWFsPnsmcXVvdDtuJnF1b3Q7OiZxdW90O2E5X0g1aThUN1pnNjVDVVlQR1JkNFItTHc3VUZpSDdn dUlKNWdRZ2pKVWRubG82ZWR5VlNDdXhfeFY0M1QtUWUyLVNHa1JiVWlyWmN6ZENlZ2ZBVmpBZWdW TXRucnNnT2VfRXFoTjFDRmxtUEo4d3dDNU9veWM2dTFfRkJkdTRGTDNLbDdqV3BJSS1pa09oWm0w NXhVbmpfTTdDTU1KbzZ3NFB2QUF6bi1pcz0mcXVvdDssJnF1b3Q7ZSZxdW90OzomcXVvdDtBUUFC JnF1b3Q7LCZxdW90O2QmcXVvdDs6JnF1b3Q7RVRtMXNQTDVpcW9SVlZiN0RNRzJIX21xbHNDME5u eVVJOEpwNW9uSEd1X1JBY0NhVzBveFZKODVNLW44aVJ4VE5TZkR1UzFkR1IxUHFtblN0Y3NCbFpu a3djOTl2bDlndFVXMnpBczBKLVczWVA4OFRrM2hOTS02dlMyU285LUxSTWFzaGNXcnVIQlBtTHVk Ti1VeEd6YW52UzNHNThqa0sxQkxRQ1c2eFZFPSZxdW90OywmcXVvdDtwJnF1b3Q7OiZxdW90O3c4 Wm5ndkxWa0UzcmVXdnJhNnZEZDNLTEpxREhJSzYwMmg4eWw0MHZMcVgwdTVVbVhvaklxTDdrOVdw bUVuNWd2VlBzcC1YRHRrVi01ME9OOU5aRDh3PT0mcXVvdDssJnF1b3Q7cSZxdW90OzomcXVvdDtq UThLelozZ0hQei15SVNhMEViUmRJX2NtZUkwM0txMWFBajdiU0hEY3lyNE9qbmtJNEs2bFRWTlRH VWF6ZjEwQnJKWjVfMllqNXpPZnVqVjgwM1c2UT09JnF1b3Q7LCZxdW90O2RwJnF1b3Q7OiZxdW90 O200LU1jbzNZU3RqUGNlVGg1T1ZQNVJyY0hPNkdLNThHejRjWW9UbXJNd3JsWXlSSm43WmFrMU5V QlBudGIyYUNJZzZNcm9Dd3VhV1JCOXd5OFVoTUp3PT0mcXVvdDssJnF1b3Q7ZHEmcXVvdDs6JnF1 b3Q7Q2dJcE9CR2RsekQwT3ZIOXNnMTBTeHJ5QWhFa3d3dHh0Nkg3aFBEQ1YyZVRHVDZHUzJhNUtt RVB6UDNYZXdvaXMxN3dOaC11TlhKZ3pHeGswZENTRVE9PSZxdW90OywmcXVvdDtxaSZxdW90Ozom cXVvdDtrWjlNRkFZUlpLUGxvVXByaWp1S3NKeHFmc0FWSk5JTkZxcXJXcjV5Y3FITHRwbWhrNmw1 OHdreEZwY1U5NFRKUGdmMUNhSk9qMnBHUlR5aWpQYTMtdz09JnF1b3Q7fTxvOnA+PC9vOnA+PC9w PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPklmIHlvdSB3YW50IHRvIHVzZSBQb2x5Q3J5cHQgYW5k IG5lZWQgRUMsIGxldCBtZSBrbm93LCBhbmQgSSBjYW4gcHJvYmFibHkgZ2V0IGl0IGltcGxlbWVu dGVkIHByZXR0eSBxdWlja2x5LjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNv Tm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs PkhvcGUgdGhpcyBoZWxwcyw8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05v cm1hbD4tLVJpY2hhcmQ8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1h bD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD5bMV0gJmx0OzxhIGhyZWY9 Imh0dHA6Ly9wb2x5Y3J5cHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3BvbHljcnlwdC5u ZXQ8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlsy XSAmbHQ7PGEgaHJlZj0iaHR0cDovL2RlbW8ucG9seWNyeXB0Lm5ldC94NTA5LyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHA6Ly9kZW1vLnBvbHljcnlwdC5uZXQveDUwOS88L2E+Jmd0OzxvOnA+PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPlszXSAmbHQ7PGEgaHJlZj0iaHR0cDov L2RlbW8ucG9seWNyeXB0Lm5ldC9qd2svIj5odHRwOi8vZGVtby5wb2x5Y3J5cHQubmV0L2p3ay88 L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4m bmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9ib2R5PjwvaHRt bD4= --_000_255B9BB34FB7D647A506DC292726F6E1150BFAA2C0WSMSG3153Vsrv_-- From ietf@augustcellars.com Wed Mar 27 15:21:28 2013 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 9F64521F8F68 for ; Wed, 27 Mar 2013 15:21:28 -0700 (PDT) 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=[AWL=0.000, 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 FefZHt8TE08g for ; Wed, 27 Mar 2013 15:21:27 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 116DB21F86DC for ; Wed, 27 Mar 2013 15:21:27 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id C1EE238F06 for ; Wed, 27 Mar 2013 15:21:18 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 27 Mar 2013 15:20:42 -0700 Message-ID: <006801ce2b39$52595700$f70c0500$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4nS9Dlxfl1UeEXRp6aXJeHoQZF0Q== Content-Language: en-us Subject: [jose] Use of AES-HMAC algorithm 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, 27 Mar 2013 22:21:28 -0000 After spending time looking at and thinking about how to resolve this issue since I was unable to do so at the last F2F meeting. I have come up with the following set of issues that might need to be addressed as part of resolving this issue. 1. Do we change from using KDC to having a double size key for the algorithm? I think that there is probably a consensus that this should be done. 2. Should IVs be prepended to the encrypted body as part of the encoding steps? If so then this change should be universal. Doing so would eliminate one field from all of the encoding formats which should be considered a plus. Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item. 3. Should Authentication Tags be appended to the encrypted body as part of the encoding steps? Doing so would eliminate one field from all of the encoding formats which should be considered a plus. Doing so would force code writers to understand how large the IV is for all algorithms as the IV would no longer be a separate item. Doing so would force a re-organization for the multiple recipient case as either all recipient specific data would need to be excluded from the authentication step or all of the recipient data would need to be included for by all recipients. Changing how the recipient info is process is going to give a performance benefit for sending encrypted items for multiple recipients. The current strategy of a single IV and key pair with AES-GCM and different authentication data needs to have CFRG look at it. I am worried that it might be a serious security flaw. 4. Should we reference the McGrew draft and provide text on how things are changed or should we "copy" the draft into our text? 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, does this change how we think about any of the above questions? Allowing for AES-GCM for key wrapping has a benefit for hardware situations as only the encrypt and not the decrypt functions need to be placed in hardware. However allowing for this key wrapping give a problem as there is no way to encode the three fields into the encrypted value unless with use either a JSON structure in this location or we do use the single appended binary output stream. The first approach leads to an expansion of the field by double base64 encoding which is highly undesirable. Jim From ietf@augustcellars.com Wed Mar 27 15:25:30 2013 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 E13A121F8904 for ; Wed, 27 Mar 2013 15:25:30 -0700 (PDT) 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=[AWL=0.000, 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 akt+Q5iXf6Rr for ; Wed, 27 Mar 2013 15:25:30 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6740B21F88F1 for ; Wed, 27 Mar 2013 15:25:30 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id CEFB82CA2B for ; Wed, 27 Mar 2013 15:25:29 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 27 Mar 2013 15:24:53 -0700 Message-ID: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4rMM//FnZzL+f2TX67H9zVPdX2bA== Content-Language: en-us Subject: [jose] Consensus calls 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, 27 Mar 2013 22:25:31 -0000 The following "decisions" were made at the face to face meeting. This message is to ratify these decisions on the list. You have one week to object and provide a solid defense of your objection or the actions will be considered as adopted. Note that for some of these we are running slightly ahead of our charter changes but this is not expected to be a problem 1. Adopt the proposed compromise language from John Bradley's presentation dealing with the critical language. This is to adopt points 1, 2, 3 and 4 but not point 5. (presentation is available on the materials website http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). 2. The private fields of public/private key algorithms and the symmetric key field are to be folded into the mail JWA draft. 3. The multiple recipient/signer serialization drafts are to be folded into the JWE and JWS drafts respectively. Jim From dick.hardt@gmail.com Wed Mar 27 15:28:10 2013 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 B2A5F21F8FCD for ; Wed, 27 Mar 2013 15:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.308 X-Spam-Level: X-Spam-Status: No, score=-3.308 tagged_above=-999 required=5 tests=[AWL=0.291, 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 yD-NQBGdTabC for ; Wed, 27 Mar 2013 15:28:10 -0700 (PDT) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id E5E0221F8FC6 for ; Wed, 27 Mar 2013 15:28:09 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id hz11so1201600pad.16 for ; Wed, 27 Mar 2013 15:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=MQVVxw7L2cpFKJ9JzU+G8ZkvY9o69JJbQuF3Mqv04HI=; b=kkF1QeK8lprgMvIVyc48ZfVnDcw1rq851KWJsLa6aCj4sQCRQLWbIlr6lA06kfEgSk 11dC6t1m0EGt2tepyEkNz2A8i7M7/XU9h8OqhHl3yOWOQVfDl3uCAtDOag/XR6ZyV8dt wwd+2EO6HmsWl48/9SarS8trtWyev9Xc6Ug6B6gtzc4ae4Jumzz0Efl99GfCzJn9OfGT SK/LMIV3q/7kM1HZvkoGOkwET07X5XB5OC+rXfGbkRZo8mWmG/AC/wY+8dm5SyHpc+eA 7HdZ3s3idf0ab/pakfijS609gNGwXQnckBvhh/onUXZ4xRk9sbeOkCi7MZn+wZcIS/Vm Ue6A== X-Received: by 10.68.7.106 with SMTP id i10mr1988730pba.43.1364423289499; Wed, 27 Mar 2013 15:28:09 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ef3sm24890584pad.20.2013.03.27.15.28.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 15:28:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <006801ce2b39$52595700$f70c0500$@augustcellars.com> Date: Wed, 27 Mar 2013 15:28:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> To: "Jim Schaad" X-Mailer: Apple Mail (2.1503) Cc: jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm 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, 27 Mar 2013 22:28:10 -0000 Hi Jim Not being at the meeting, I don't have the background to understand what = the issue was in order to interpret your email. Having implementations that use AES-HMAC, I want to understand. Any pointers so that I can understand would be greatly appreciated. -- Dick On Mar 27, 2013, at 3:20 PM, "Jim Schaad" = wrote: > > After spending time looking at and thinking about how to resolve this = issue > since I was unable to do so at the last F2F meeting. I have come up = with > the following set of issues that might need to be addressed as part of > resolving this issue. >=20 > 1. Do we change from using KDC to having a double size key for the > algorithm? I think that there is probably a consensus that this = should be > done.=20 >=20 > 2. Should IVs be prepended to the encrypted body as part of the = encoding > steps? If so then this change should be universal.=20 >=20 > Doing so would eliminate one field from all of the encoding formats = which > should be considered a plus. > Doing so would force code writers to understand how large the IV is = for all > algorithms as the IV would no longer be a separate item. >=20 > 3. Should Authentication Tags be appended to the encrypted body as = part of > the encoding steps? >=20 > Doing so would eliminate one field from all of the encoding formats = which > should be considered a plus. > Doing so would force code writers to understand how large the IV is = for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case = as > either all recipient specific data would need to be excluded from the > authentication step or all of the recipient data would need to be = included > for by all recipients. > Changing how the recipient info is process is going to give a = performance > benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and = different > authentication data needs to have CFRG look at it. I am worried that = it > might be a serious security flaw. >=20 > 4. Should we reference the McGrew draft and provide text on how things = are > changed or should we "copy" the draft into our text? >=20 > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key = wrapping, > does this change how we think about any of the above questions? >=20 > Allowing for AES-GCM for key wrapping has a benefit for hardware = situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as = there is > no way to encode the three fields into the encrypted value unless with = use > either a JSON structure in this location or we do use the single = appended > binary output stream. The first approach leads to an expansion of the = field > by double base64 encoding which is highly undesirable. >=20 > Jim >=20 >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From Michael.Jones@microsoft.com Wed Mar 27 17:21:24 2013 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 8E10B21F9338 for ; Wed, 27 Mar 2013 17:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 Ah4OyqsDhK3Q for ; Wed, 27 Mar 2013 17:21:23 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF7621F9333 for ; Wed, 27 Mar 2013 17:21:23 -0700 (PDT) Received: from BN1BFFO11FD026.protection.gbl (10.58.52.200) by BN1BFFO11HUB021.protection.gbl (10.58.53.131) with Microsoft SMTP Server (TLS) id 15.0.651.3; Thu, 28 Mar 2013 00:21:21 +0000 Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.37) by BN1BFFO11FD026.mail.protection.outlook.com (10.58.53.86) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Thu, 28 Mar 2013 00:21:21 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.02.0318.003; Thu, 28 Mar 2013 00:21:20 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] Use of AES-HMAC algorithm Thread-Index: Ac4nS9Dlxfl1UeEXRp6aXJeHoQZF0QD+cy9A Date: Thu, 28 Mar 2013 00:21:19 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> In-Reply-To: <006801ce2b39$52595700$f70c0500$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(377454001)(35754002)(199002)(51444002)(189002)(50466001)(47446002)(63696002)(47776003)(20776003)(79102001)(5343655001)(561944001)(23726001)(31966008)(47736001)(69226001)(49866001)(74502001)(15202345001)(4396001)(50986001)(74662001)(54316002)(16406001)(80022001)(46406002)(55846006)(51856001)(33656001)(47976001)(59766001)(56776001)(77982001)(65816001)(54356001)(56816002)(46102001)(81342001)(66066001)(76482001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB021; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0799B1B2D7 Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 00:21:24 -0000 Per your point 1, I don't think anyone was advocating doubling the key size= . The proposal in John's slides for issue #3 (http://trac.tools.ietf.org/w= g/jose/trac/ticket/3) was to use a CMK that is the concatenation of the AES= -CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-aes-hmac-sha2 does. For ins= tance, when using A128CBC with HS256, the key size would be 384 bits and wh= en using A256CBC with HS512, the key size would be 768 bits. This would mu= ltiply the current key sizes by 1.5, with the compensating benefit being th= e elimination of the use of the KDF. Your point 2 wasn't part of issue #3. This seems like an unnecessary chang= e, particularly for GCM, where the IV is specified as a separate value from= the ciphertext. Your point 3 wasn't part of issue #3. This seems like an unnecessary chang= e, particularly for GCM, where the Authentication Tag is specified as a sep= arate value from the ciphertext. Per your point 4, after a conversation initiated by Joe Hildebrand and a ca= ll scheduled by Matt Miller, David McGrew has agreed refactor his draft so = that the inputs and outputs are specified separately and independently from= the RFC 5116 encoding of those values. While RFC 5116 specifies a binary = serialization for authenticated encryption algorithms, JWE specifies a text= ual serialization. This refactoring would make it easy for JOSE to use the= McGrew draft, since the computation would be specified separately from the= serialization, should the working group choose to do so. I suspect that once the refactoring is done, should the working group choos= e to use the McGrew algorithm, JWA could reference the appropriate sections= of draft-mcgrew-aead-aes-hmac-sha2 and JWE could include an example comput= ation for this algorithm, making it easy for developers to build. Per your point 5, I think the term "key wrapping" is being used for two dif= ferent things: (1) Encrypting the ephemeral symmetric Content Master Key f= or a JWE and (2) encrypting a JWK or JWK Set containing symmetric and/or pr= ivate key information and potentially other key attributes, enabling the en= crypted JWK or JWK Set to be safely stored or transported. It think it wou= ld clarify the discussions to keep these operations distinct. I don't thin= k anyone is proposing using AES-GCM or A128CBC+HS256 for (1), whereas they = can already be used as part of (2) if the JWK is encrypted in a JWE, per Ma= tt's draft. Given the opinions voiced at the CFRG meeting that it's fine t= o use approved authenticated encryption algorithms to encrypt keys, I belie= ve that there's already no problem with using these algorithms for (2). -- Mike -----Original Message----- From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Wednesday, March 27, 2013 3:21 PM To: jose@ietf.org Subject: [jose] Use of AES-HMAC algorithm After spending time looking at and thinking about how to resolve this issue= since I was unable to do so at the last F2F meeting. I have come up with = the following set of issues that might need to be addressed as part of reso= lving this issue. 1. Do we change from using KDC to having a double size key for the algorit= hm? I think that there is probably a consensus that this should be done.=20 2. Should IVs be prepended to the encrypted body as part of the encoding st= eps? If so then this change should be universal.=20 Doing so would eliminate one field from all of the encoding formats which s= hould be considered a plus. Doing so would force code writers to understand how large the IV is for all= algorithms as the IV would no longer be a separate item. 3. Should Authentication Tags be appended to the encrypted body as part of = the encoding steps? Doing so would eliminate one field from all of the encoding formats which s= hould be considered a plus. Doing so would force code writers to understand how large the IV is for all= algorithms as the IV would no longer be a separate item. Doing so would force a re-organization for the multiple recipient case as e= ither all recipient specific data would need to be excluded from the authen= tication step or all of the recipient data would need to be included for by= all recipients. Changing how the recipient info is process is going to give a performance b= enefit for sending encrypted items for multiple recipients. The current strategy of a single IV and key pair with AES-GCM and different= authentication data needs to have CFRG look at it. I am worried that it m= ight be a serious security flaw. 4. Should we reference the McGrew draft and provide text on how things are = changed or should we "copy" the draft into our text? 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, = does this change how we think about any of the above questions? Allowing for AES-GCM for key wrapping has a benefit for hardware situations= as only the encrypt and not the decrypt functions need to be placed in har= dware. However allowing for this key wrapping give a problem as there is n= o way to encode the three fields into the encrypted value unless with use e= ither a JSON structure in this location or we do use the single appended bi= nary output stream. The first approach leads to an expansion of the field = by double base64 encoding which is highly undesirable. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose From dick.hardt@gmail.com Wed Mar 27 17:30:12 2013 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 AB3E221F919D for ; Wed, 27 Mar 2013 17:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.341 X-Spam-Level: X-Spam-Status: No, score=-3.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 lkTj3zSeW0+d for ; Wed, 27 Mar 2013 17:30:12 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id BF6BF21F9195 for ; Wed, 27 Mar 2013 17:30:07 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo1so1652944pbc.5 for ; Wed, 27 Mar 2013 17:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=SodbF/h5p+YEO3dgY69s4X5Y2Nkv4uDq4obIwtECBh8=; b=oWWqBII6UjXzUfyVAOxbYzHQa3ePSd8lmV1sSVba8obQ8k5e7tweENev7GnfbS8R9r jXQPuI2UdYIANhhx4YYpuZhgF9UvkeeVCDKdufrQvZ45RuJ0kDmVDSNvudE26fNbatqX fbcQgxCeWfba/i3eCxE9oAKXeWnIEJcX3zpWqjNACzd+BeOU0n2uF0jFxHx2G+RKutw0 tthb19MPjXC/wzvv8eNJMN0HIdmkBBdP4rkNeMc2TtyO8OaIG5FBK39wODrC8FsyXXPk NJu5hOho/erLvixrDOGH3P4pyj6JkS3U6IYHts1QuRZLWRwtXmOOM+OXBTzqwBI9kUai A0Iw== X-Received: by 10.66.160.106 with SMTP id xj10mr2659609pab.139.1364430607492; Wed, 27 Mar 2013 17:30:07 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id yp2sm12862892pab.10.2013.03.27.17.30.05 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 17:30:05 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Mar 2013 17:30:03 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 00:30:12 -0000 On Mar 27, 2013, at 5:21 PM, Mike Jones = wrote: > Per your point 1, I don't think anyone was advocating doubling the key = size. The proposal in John's slides for issue #3 = (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that = is the concatenation of the AES-CBC and HMAC-SHA-2 keys, as = draft-mcgrew-aead-aes-hmac-sha2 does. For instance, when using A128CBC = with HS256, the key size would be 384 bits and when using A256CBC with = HS512, the key size would be 768 bits. This would multiply the current = key sizes by 1.5, with the compensating benefit being the elimination of = the use of the KDF. Was this because people thought KDF was hard? I managed to implement it = in JavaScript, can't be that hard! ;-) =85 or was there a security = reason? This is a breaking change to my implementation.=20 FWIW: I cache the results of the KDF so that I only incur the = calculation the first time I see a key.= From Michael.Jones@microsoft.com Wed Mar 27 17:39:13 2013 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 C2A8F21F938F for ; Wed, 27 Mar 2013 17:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 2Z2Fc9WUfY8w for ; Wed, 27 Mar 2013 17:39:13 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0208.outbound.protection.outlook.com [207.46.163.208]) by ietfa.amsl.com (Postfix) with ESMTP id DD8E521F938E for ; Wed, 27 Mar 2013 17:39:12 -0700 (PDT) Received: from BL2FFO11FD022.protection.gbl (10.1.15.202) by BY2FFO11HUB030.protection.gbl (10.1.14.115) with Microsoft SMTP Server (TLS) id 15.0.651.3; Thu, 28 Mar 2013 00:39:09 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD022.mail.protection.outlook.com (10.173.161.101) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Thu, 28 Mar 2013 00:39:10 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Thu, 28 Mar 2013 00:39:01 +0000 From: Mike Jones To: Dick Hardt Thread-Topic: [jose] Use of AES-HMAC algorithm Thread-Index: Ac4nS9Dlxfl1UeEXRp6aXJeHoQZF0QD+cy9AAAFxb4AAAAnDEA== Date: Thu, 28 Mar 2013 00:39:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> In-Reply-To: <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(13464002)(24454001)(199002)(189002)(377454001)(50986001)(47976001)(81342001)(66066001)(51856001)(47446002)(63696002)(47736001)(49866001)(46102001)(69226001)(20776003)(47776003)(54316002)(50466001)(74502001)(4396001)(65816001)(46406002)(44976002)(53806001)(59766001)(54356001)(76482001)(31966008)(56816002)(77982001)(5343635001)(55846006)(56776001)(74662001)(33656001)(15202345001)(5343655001)(80022001)(561944001)(79102001)(16406001)(23726001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB030; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0799B1B2D7 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 00:39:13 -0000 I think the reason the working group is thinking about this algorithm is a = combination of three things: 1. Using the KDF could lead to interoperability problems. Some early impl= ementations have gotten this wrong. 2. Apparently we're not using the Concat KDF for an approved use, as "appr= oved" is defined by the NIST specs. If we stop using it, this criticism wo= uld go away. 3. Some have pushed back on us "inventing a new cryptographic algorithm". = While I believe that the composition of two establish algorithms - AES-CBC= and HMAC SHA-2 is easily defensible, with David McGrew being the co-chair = of the Crypto Forum Research Group (CFRG) - the group that IETF people go t= o when wanting to validate the use of crypto algorithms - if his algorithm = is approved, using it would likely be considered to be above reproach, in t= erms of getting JWE through the IETF approval processes. So it's really "spec approval" reasons - not security reasons that the chan= ge is being considered. -- Mike P.S. For what it's worth, you could distinguish the two algorithms by the = key sizes if you wanted to run both algorithms side-by-side for a while. =20 -----Original Message----- From: Dick Hardt [mailto:dick.hardt@gmail.com]=20 Sent: Wednesday, March 27, 2013 5:30 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm On Mar 27, 2013, at 5:21 PM, Mike Jones wrote= : > Per your point 1, I don't think anyone was advocating doubling the key si= ze. The proposal in John's slides for issue #3 (http://trac.tools.ietf.org= /wg/jose/trac/ticket/3) was to use a CMK that is the concatenation of the A= ES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead-aes-hmac-sha2 does. For i= nstance, when using A128CBC with HS256, the key size would be 384 bits and = when using A256CBC with HS512, the key size would be 768 bits. This would = multiply the current key sizes by 1.5, with the compensating benefit being = the elimination of the use of the KDF. Was this because people thought KDF was hard? I managed to implement it in = JavaScript, can't be that hard! ;-) ... or was there a security reason? This is a breaking change to my implementation.=20 FWIW: I cache the results of the KDF so that I only incur the calculation t= he first time I see a key. From dick.hardt@gmail.com Wed Mar 27 18:06:09 2013 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 9870E21F936A for ; Wed, 27 Mar 2013 18:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.233, 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 C2MPWw3erTL0 for ; Wed, 27 Mar 2013 18:06:09 -0700 (PDT) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id 23BAD21F9369 for ; Wed, 27 Mar 2013 18:05:59 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id uo1so1674820pbc.33 for ; Wed, 27 Mar 2013 18:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=gi2SfHQiKsx0GGrqr/wEQGqbtD/bBx4JoL0Yk1y4+lo=; b=rWkllaL/Ct0N81vDK+3BmrDf00CVa2V1oeU0P5J8gXNr33iPfczMOTfvPEVGnW/IEf lnL4D5m54nC4qmT/LMQhAefHWe1S5jtf7RGr6L/iQMck88NO2OQvFrEGFUyRjVaMqAj/ vRxgUCuKZPOmESOj6toxcI5XjcfzKrT1z2S4y1jgeAVNsh4X793uaf5xT8mTuRWUCAc+ eEZcn/trv4JJqIK66BdP/84+CRzL3z1SQHe67elP6cOucSaNLwLw4+cb+l+j7TBSK8ay AUI8LXx7wlMw9mkOoTT0BEuefdDsaHjCKNyWCmGlz9vJYD+WZyN4og/kfwcVgR3irtsT P4Mw== X-Received: by 10.68.243.66 with SMTP id ww2mr32304317pbc.109.1364432758931; Wed, 27 Mar 2013 18:05:58 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id kt5sm23297776pbc.30.2013.03.27.18.05.56 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 18:05:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Wed, 27 Mar 2013 18:05:54 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <366657CD-2349-4AA8-B5BC-2A08A136ED08@gmail.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> To: Mike Jones X-Mailer: Apple Mail (2.1503) Cc: Jim Schaad , "jose@ietf.org" , Dick Hardt Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 01:06:09 -0000 On Mar 27, 2013, at 5:39 PM, Mike Jones = wrote: > I think the reason the working group is thinking about this algorithm = is a combination of three things: >=20 > 1. Using the KDF could lead to interoperability problems. Some early = implementations have gotten this wrong. Were these improper implementations, or different interpretations? The = first is a bug in the software, the second is a bug in the spec. >=20 > 2. Apparently we're not using the Concat KDF for an approved use, as = "approved" is defined by the NIST specs. If we stop using it, this = criticism would go away. Not relevant for me, but I understand the motivation. >=20 > 3. Some have pushed back on us "inventing a new cryptographic = algorithm". While I believe that the composition of two establish = algorithms - AES-CBC and HMAC SHA-2 is easily defensible, with David = McGrew being the co-chair of the Crypto Forum Research Group (CFRG) - = the group that IETF people go to when wanting to validate the use of = crypto algorithms - if his algorithm is approved, using it would likely = be considered to be above reproach, in terms of getting JWE through the = IETF approval processes. What is David's algorithm? >=20 > So it's really "spec approval" reasons - not security reasons that the = change is being considered. A smaller key is better than a larger key, but it is not that much = larger.=20 >=20 > -- Mike >=20 > P.S. For what it's worth, you could distinguish the two algorithms by = the key sizes if you wanted to run both algorithms side-by-side for a = while. Thanks for the suggestion. I can still change the implementation for the = next couple weeks without impacting a third party. Would be useful to = know where this will land so I can change or not. P.S. thanks for the explanation Mike! -- Dick From James.H.Manger@team.telstra.com Wed Mar 27 19:49:07 2013 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 0D95621F9421 for ; Wed, 27 Mar 2013 19:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_34=0.6, RELAY_IS_203=0.994] 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 0UqZyCUUlSHg for ; Wed, 27 Mar 2013 19:49:06 -0700 (PDT) Received: from ipxcno.tcif.telstra.com.au (ipxcno.tcif.telstra.com.au [203.35.82.208]) by ietfa.amsl.com (Postfix) with ESMTP id 38BD621F9420 for ; Wed, 27 Mar 2013 19:49:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,922,1355058000"; d="scan'208";a="122160026" Received: from unknown (HELO ipccni.tcif.telstra.com.au) ([10.97.216.208]) by ipocni.tcif.telstra.com.au with ESMTP; 28 Mar 2013 13:49:04 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7027"; a="125640723" Received: from wsmsg3755.srv.dir.telstra.com ([172.49.40.196]) by ipccni.tcif.telstra.com.au with ESMTP; 28 Mar 2013 13:49:04 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by WSMSG3755.srv.dir.telstra.com ([172.49.40.196]) with mapi; Thu, 28 Mar 2013 13:49:03 +1100 From: "Manger, James H" To: Dick Hardt , Mike Jones Date: Thu, 28 Mar 2013 13:49:02 +1100 Thread-Topic: [jose] Use of AES-HMAC algorithm Thread-Index: Ac4rUHIUAgboNdzdRvCadOPSdY5bmQAAD/xA Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C06E272@WSMSG3153V.srv.dir.telstra.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> <366657CD-2349-4AA8-B5BC-2A08A136ED08@gmail.com> In-Reply-To: <366657CD-2349-4AA8-B5BC-2A08A136ED08@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 02:49:07 -0000 RGljaywNCg0KZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFjLXNoYTIgIkF1dGhlbnRpY2F0 ZWQgRW5jcnlwdGlvbiB3aXRoIEFFUy1DQkMgYW5kIEhNQUMtU0hBIiA8IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LW1jZ3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyPiBpcyAiRGF2 aWQncyBhbGdvcml0aG0iLg0KDQoNCkJvdGggZHJhZnQtbWNncmV3LWFlYWQtYWVzLWNiYy1obWFj LXNoYTIgYW5kICJBMTI4Q0JDK0hTMjU2IiBpbiBKV0EgZGVmaW5lIGEgd2F5IHRvIGNvbWJpbmUg Q0JDIGFuZCBITUFDIHRvIGdldCBhdXRoZW50aWNhdGVkIGVuY3J5cHRpb24uIFRoZXkgbWFrZSBz b21lIGRpZmZlcmVudCBjaG9pY2VzOg0KDQpBLiBDb25jYXRlbmF0ZSBDQkMgJiBITUFDIGtleXMg dnMgdXNlIGEgS0RGIHRvIGRlcml2ZSBDQkMgJiBITUFDIGtleXM7DQoNCkIuIDEyOCsxMjggYml0 IGtleSBzaXplcyB2cyAxMjgrMjU2IGJpdCBrZXlzIHNpemUgKGZvciBBRVMtMTI4ICYgSE1BQy0y NTYpDQoNCkMuIEF1dGhlbnRpY2F0aW9uIHRhZyBoYWxmIHRoZSBoYXNoIHNpemUgdnMgdGhlIGZ1 bGwgaGFzaCBzaXplDQoNCkQuIEF1dGggdGFnIGNvbmNhdGVuYXRlZCB0byBjaXBoZXJ0ZXh0IHZz IHNlcGFyYXRlIGZpZWxkDQoNCkUuIElWIGNvbmNhdGVuYXRlZCB3aXRoIGNpcGhlcnRleHQgdnMg c2VwYXJhdGUgZmllbGQNCg0KRi4gSE1BQyBjYWxjdWxhdGVkIG92ZXIgdGhlIHJhdyBjaXBoZXJ0 ZXh0IHZzIGJhc2U2NHVybC1lbmNvZGVkIGNpcGhlcnRleHQNCg0KTWlrZSBpcyByaWdodCB0aGF0 IHRoZSBjcnlwdG8gY2hvaWNlcyAoQSwgQiwgQykgd2lsbCBiZSBtb3JlIGFjY2VwdGFibGUgY29t aW5nIGZyb20gdGhlIENyeXB0byBGb3J1bSBSZXNlYXJjaCBHcm91cCAoQ1JGRykgZ3JvdXAgaW4g YSBzcGVjIHNwZWNpZmljYWxseSBkZXNjcmliaW5nIENCQytITUFDICh3aXRoIHNlY3VyaXR5IGNv bnNpZGVyYXRpb25zIGFuZCByYXRpb25hbGVzIGZvciBpdHMgY2hvaWNlcywgcGx1cyB0ZXN0IHZl Y3RvcnMgZXRjKSwgY29tcGFyZWQgdG8gYSBKT1NFLXNwZWNpZmljIGRlZmluaXRpb24gdGhhdCBp cyBhIHNtYWxsIHBhcnQgb2YgYSBKV0EgZG9jLg0KDQpELCBFLCAmIEYgYXJlIG1vcmUgdG8gZG8g d2l0aCBob3cgdGhlIGFsZ29yaXRobXMgZml0IHdpdGggY3J5cHRvIEFQSXMuIFdlIHdpbGwgb2Z0 ZW4gaGF2ZSBhcHBsaWNhdGlvbiBjb2RlLCBKT1NFIGxpYnJhcnkgY29kZSwgYW5kIGNyeXB0byBs aWJyYXJ5IGNvZGUuIFRoZSBpc3N1ZXMgYXJlIHdoaWNoIGxheWVycyBuZWVkIHRvIGtub3cgd2hp Y2ggYWxnb3JpdGhtLXNwZWNpZmljIGRldGFpbHMuDQoNCkNyeXB0byBsaWJyYXJpZXMgaGF2ZSBo aXN0b3JpY2FsbHkgb2ZmZXJlZCBDQkMgYW5kIEhNQUMgaW50ZXJmYWNlcy4gTm93IHRoZXkgYXJl IHN0YXJ0aW5nIHRvIG9mZmVyIEFFQUQgaW50ZXJmYWNlcy4gVGhlIENCQytITUFDIGFsZ29yaXRo bSB3ZSBwdXQgaW4gSk9TRSBzaG91bGQgYmUgYWJsZSB0byB3b3JrIHdlbGwgd2l0aCBBRUFEIGlu dGVyZmFjZXMuIERyYWZ0LW1ncmV3IHdpbGwgd29yayBhcyBpdCBmaXRzIGEgbW9kZWwgZm9yIEFF QUQgYWxnb3JpdGhtcyBkZWZpbmVkIGluIFJGQyA1MTE2ICJBbiBJbnRlcmZhY2UgYW5kIEFsZ29y aXRobXMgZm9yIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiIuIFRoZSBjdXJyZW50IEpPU0Utc3Bl Y2lmaWMgYWxnIHdpbGwgTk9UIGZpdCBBRUFEIGludGVyZmFjZXMgd2VsbCAtLSBwcmltYXJpbHkg YmVjYXVzZSBvZiBkaWZmZXJlbmNlIEYgKHRoYXQgbWl4ZXMgYXBwLWxheWVyIGJhc2U2NHVybC1l bmNvZGluZyB3aXRoIGEgc3RlcCB0aGF0IGlzIGludGVybmFsIHRvIHRoZSBBRUFEIGFsZ29yaXRo bSkuDQoNClRoZSBhdXRoZW50aWNhdGlvbiB0YWcgKGRpZmZlcmVuY2UgRCkgaXMgYSBzdWJ0bGVy IGlzc3VlLiBBIHRhZyBpcyBhIGNvcmUgY29tcG9uZW50IG9mIGEgYnVuY2ggb2YgQUVBRCBhbGdv cml0aG1zIHNvIHNvbWUgQUVBRCBBUElzIGhhdmUgZXhwbGljaXQgc3VwcG9ydCBmb3IgYSB0YWcg ZmllbGQuIEhvd2V2ZXIgaXQgaXMgcmVhbGx5IGFuIGludGVybmFsIGRldGFpbDogZWl0aGVyIHRo ZSBkZWNyeXB0aW9uIGhhbmRzIGJhY2sgcGxhaW50ZXh0IG9yIGl0IGZhaWxzLiBBIGNyeXB0byBs aWJyYXJ5J3MgaW1wbGVtZW50YXRpb24gb2YgYW4gQUVBRCBhbGcgdGhhdCBoYXMgYSB0YWcgbmVl ZHMgdG8gZGlzdGluZ3Vpc2ggdGhlIHRhZyBmcm9tIHRoZSByZXN0IG9mIHRoZSBjaXBoZXJ0ZXh0 IC0tIGJ1dCBkb2VzIHRoZSBhcHAtbGF5ZXIgbmVlZCB0byBkaXN0aW5ndWlzaCB0aGUgdHdvPyBO b3QgcmVhbGx5Lg0KDQoNCkkgdW5kZXJzdGFuZCAoYW5kIGhvcGUpIHRoZSBKT1NFIGNvbnNlbnN1 cyBpcyB0byBnbyB3aXRoIGRyYWZ0LW1jZ3JldyBvbiBwb2ludHMgQSwgQiwgQywgYW5kIEYuDQoN Ck15IG9waW5pb24gaXMgdGhhdCB3ZSBzaG91bGQgZ28gd2l0aCBkcmFmdC1tY2dyZXcgKGFuZCBS RkM1MTE2KSBmb3IgRCAmIEUgYXMgd2VsbCwgYnV0IE1pa2UgKGFuZCBvdGhlcnMpIGRpc2FncmVl LiBJdCBzaG91bGRuJ3QgYWZmZWN0IHRoZSBtYXRocyBvZiB0aGUgY3J5cHRvLCBidXQgaXQgZG9l cyBhZmZlY3QgQVBJcyBhbmQgdGhlIGRlZ3JlZSB0aGF0IHRoZSBhcHAgbGF5ZXIgY2FuIGJlIChw YXJ0aWFsbHkpIHJlbGlldmVkIG9mIHRoZSByZXNwb25zaWJpbGl0eSBvZiBkZWFsaW5nIHdpdGgg c29tZSB0b3VnaCBjcnlwdG8gaXNzdWVzIChzdWNoIGFzIGNyeXB0by1xdWFsaXR5IHJhbmRvbW5l c3MsIHVuaXF1ZW5lc3Mgb2Ygbm9uY2VzIGV0YykuDQoNCi0tDQpKYW1lcyBNYW5nZXINCg0K From dick.hardt@gmail.com Wed Mar 27 20:32:25 2013 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 1085221F940F for ; Wed, 27 Mar 2013 20:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.264 X-Spam-Level: X-Spam-Status: No, score=-1.264 tagged_above=-999 required=5 tests=[AWL=-1.912, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, J_CHICKENPOX_34=0.6, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_DYNAMIC=0.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 PpccAtz+kkIP for ; Wed, 27 Mar 2013 20:32:24 -0700 (PDT) Received: from mail-da0-x236.google.com (mail-da0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 74AE221F93FB for ; Wed, 27 Mar 2013 20:32:24 -0700 (PDT) Received: by mail-da0-f54.google.com with SMTP id p1so4329712dad.41 for ; Wed, 27 Mar 2013 20:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=DSs1I+D4GNpAkYkS5B8Chq/7GbLGIxRF1X9QJfjNxLw=; b=m8QZJs9CYncSzRQUCijNi2Rc/Ii/jDGgjeZThTWhQfKA4vP4TxjPe0tghNkRe+9fgF wJH1AvupyJDJISjnBaGJOyy+DL1urgFc/KVzAoxHJgZkFeZHLywoMJC2CleONWo4Qyfh fU5J9l17k07tWJ1+UKhCwxtVmIuZMEWCk56uJqKrCjUgmHOwt3T9f4uKyxEhYZUpfg9Q 67Ko6aGJGV8upcE2lswberSzIi40tY+kEv7KJWxpwxsoXzuaz4b5vAmG8K0BZbaBT/Xc kTMDKW1J+qRgDms7Y1cu4dXJxkXaIVVmA28CH55qCmbjPXRRNQvWLGaFTs0fQjomwS3i w3aA== X-Received: by 10.68.177.162 with SMTP id cr2mr32538130pbc.179.1364441544269; Wed, 27 Mar 2013 20:32:24 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id ql7sm23764691pbb.2.2013.03.27.20.32.20 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Mar 2013 20:32:21 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150C06E272@WSMSG3153V.srv.dir.telstra.com> Date: Wed, 27 Mar 2013 20:32:19 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <68E0869F-C3D0-4154-8E01-725509B59835@gmail.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> <366657CD-2349-4AA8-B5BC-2A08A136ED08@gmail.com> <255B9BB34FB7D647A506DC292726F6E1150C06E272@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: Mike Jones , Jim Schaad , jose@ietf.org Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 03:32:25 -0000 Thanks for taking the time to explain James. Not being at the meetings = makes it tough to track. My summary of what you said is that there are two different ways that = have been proposed to use AES-CBC and HMAC-SHA: the one currently in the = spec, and "David's algorithm".=20 FWIW as an implementer: none of the crypto libraries I have looked at = are going to do D, E, & F for me; so I am doing them in my library and = having them as separate fields vs yet-another-concatenation-algorithm is = preferred. I can see why that would not be desirable if the format is = then inconsistent with AEAD. Having said that, I'm coding in node.js, = and even though it uses opensll that has AEAD, none of the AEAD = interfaces are exposed currently in node.js, and I don't see that = changing anytime soon =3D> not sure AEAD is going to be incorporated = with JWT libraries. -- Dick On Mar 27, 2013, at 7:49 PM, "Manger, James H" = wrote: > Dick, >=20 > draft-mcgrew-aead-aes-cbc-hmac-sha2 "Authenticated Encryption with = AES-CBC and HMAC-SHA" < = http://tools.ietf.org/html/draft-mcgrew-aead-aes-cbc-hmac-sha2> is = "David's algorithm". >=20 >=20 > Both draft-mcgrew-aead-aes-cbc-hmac-sha2 and "A128CBC+HS256" in JWA = define a way to combine CBC and HMAC to get authenticated encryption. = They make some different choices: >=20 > A. Concatenate CBC & HMAC keys vs use a KDF to derive CBC & HMAC keys; >=20 > B. 128+128 bit key sizes vs 128+256 bit keys size (for AES-128 & = HMAC-256) >=20 > C. Authentication tag half the hash size vs the full hash size >=20 > D. Auth tag concatenated to ciphertext vs separate field >=20 > E. IV concatenated with ciphertext vs separate field >=20 > F. HMAC calculated over the raw ciphertext vs base64url-encoded = ciphertext >=20 > Mike is right that the crypto choices (A, B, C) will be more = acceptable coming from the Crypto Forum Research Group (CRFG) group in a = spec specifically describing CBC+HMAC (with security considerations and = rationales for its choices, plus test vectors etc), compared to a = JOSE-specific definition that is a small part of a JWA doc. >=20 > D, E, & F are more to do with how the algorithms fit with crypto APIs. = We will often have application code, JOSE library code, and crypto = library code. The issues are which layers need to know which = algorithm-specific details. >=20 > Crypto libraries have historically offered CBC and HMAC interfaces. = Now they are starting to offer AEAD interfaces. The CBC+HMAC algorithm = we put in JOSE should be able to work well with AEAD interfaces. = Draft-mgrew will work as it fits a model for AEAD algorithms defined in = RFC 5116 "An Interface and Algorithms for Authenticated Encryption". The = current JOSE-specific alg will NOT fit AEAD interfaces well -- primarily = because of difference F (that mixes app-layer base64url-encoding with a = step that is internal to the AEAD algorithm). >=20 > The authentication tag (difference D) is a subtler issue. A tag is a = core component of a bunch of AEAD algorithms so some AEAD APIs have = explicit support for a tag field. However it is really an internal = detail: either the decryption hands back plaintext or it fails. A crypto = library's implementation of an AEAD alg that has a tag needs to = distinguish the tag from the rest of the ciphertext -- but does the = app-layer need to distinguish the two? Not really. >=20 >=20 > I understand (and hope) the JOSE consensus is to go with draft-mcgrew = on points A, B, C, and F. >=20 > My opinion is that we should go with draft-mcgrew (and RFC5116) for D = & E as well, but Mike (and others) disagree. It shouldn't affect the = maths of the crypto, but it does affect APIs and the degree that the app = layer can be (partially) relieved of the responsibility of dealing with = some tough crypto issues (such as crypto-quality randomness, uniqueness = of nonces etc). >=20 > -- > James Manger >=20 From James.H.Manger@team.telstra.com Wed Mar 27 21:40:45 2013 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 9203A21F8ECB for ; Wed, 27 Mar 2013 21:40:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.551 X-Spam-Level: X-Spam-Status: No, score=-0.551 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, J_CHICKENPOX_34=0.6, RELAY_IS_203=0.994] 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 MPcYrCY0HUtR for ; Wed, 27 Mar 2013 21:40:44 -0700 (PDT) Received: from ipxcvo.tcif.telstra.com.au (ipxcvo.tcif.telstra.com.au [203.35.135.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9BC21F8EBE for ; Wed, 27 Mar 2013 21:40:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.84,924,1355058000"; d="scan'208";a="126784340" Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipocvi.tcif.telstra.com.au with ESMTP; 28 Mar 2013 15:40:41 +1100 X-IronPort-AV: E=McAfee;i="5400,1158,7027"; a="174642397" Received: from wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) by ipcavi.tcif.telstra.com.au with ESMTP; 28 Mar 2013 15:40:41 +1100 Received: from WSMSG3153V.srv.dir.telstra.com ([172.49.40.159]) by wsmsg3756.srv.dir.telstra.com ([172.49.40.84]) with mapi; Thu, 28 Mar 2013 15:40:41 +1100 From: "Manger, James H" To: Dick Hardt Date: Thu, 28 Mar 2013 15:40:40 +1100 Thread-Topic: [jose] Use of AES-HMAC algorithm Thread-Index: Ac4rZN5zdL6mEQU9TmOxKo0eAxyiwQAACp/A Message-ID: <255B9BB34FB7D647A506DC292726F6E1150C06E53B@WSMSG3153V.srv.dir.telstra.com> References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> <1D2E2774-4A20-43AE-A2D6-30FF797DAAAF@gmail.com> <4E1F6AAD24975D4BA5B168042967394367590D06@TK5EX14MBXC283.redmond.corp.microsoft.com> <366657CD-2349-4AA8-B5BC-2A08A136ED08@gmail.com> <255B9BB34FB7D647A506DC292726F6E1150C06E272@WSMSG3153V.srv.dir.telstra.com> <68E0869F-C3D0-4154-8E01-725509B59835@gmail.com> In-Reply-To: <68E0869F-C3D0-4154-8E01-725509B59835@gmail.com> Accept-Language: en-US, en-AU Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-AU Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 04:40:45 -0000 SSBoYXZlbuKAmXQgYmVlbiBhdCBhbnkgb2YgdGhlIG1lZXRpbmcgZWl0aGVyISBJdCBpcyBoYXJk IHRvIHRyYWNrLg0KDQpKYXZhIGFkZGVkIEFFQUQgc3VwcG9ydCBpbiB2NyAoZWcgamF2YXguY3J5 cHRvLmNpcGhlciN1cGRhdGVBQUQpLg0KT3BlblNTTCBoYXMgYWRkZWQgQUVBRCBzdXBwb3J0Lg0K SSB0aGluayBPcGVuU1NMIEFFQUQgc3VwcG9ydCBoYXMgZmlsdGVyZWQgaW50byBSdWJ5Lg0KQXBw YXJlbnRseSBpdCBoYXNuJ3QgZmlsdGVyZWQgaW50byBub2RlLmpzIHlldC4NCk1pY3Jvc29mdCBD cnlwdG8gTmV4dCBHZW5lcmF0aW9uIChDbmcpIGhhcyBhZGRlZCBBRUFEIHN1cHBvcnQuDQpHbyBz dXBwb3J0cyBBRS13aXRob3V0LXRoZS1BRCwgYXMgZG9lcyBOYUNsLg0KDQpTbyBJIHRoaW5rIEpP U0Ugd2lsbCBsaXZlIGxvbmcgZW5vdWdoIGZvciBleHBsaWNpdCBBRUFEIHN1cHBvcnQgaW4gY3J5 cHRvIGxpYnJhcmllcyB0byBiZSB0aGUgbm9ybS4NCg0KLS0NCkphbWVzIE1hbmdlcg0KDQoNCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogRGljayBIYXJkdCBbbWFpbHRvOmRp Y2suaGFyZHRAZ21haWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgMjggTWFyY2ggMjAxMyAyOjMy IFBNDQo+IFRvOiBNYW5nZXIsIEphbWVzIEgNCj4gQ2M6IE1pa2UgSm9uZXM7IEppbSBTY2hhYWQ7 IGpvc2VAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtqb3NlXSBVc2Ugb2YgQUVTLUhNQUMgYWxn b3JpdGhtDQo+IA0KPiBUaGFua3MgZm9yIHRha2luZyB0aGUgdGltZSB0byBleHBsYWluIEphbWVz LiBOb3QgYmVpbmcgYXQgdGhlIG1lZXRpbmdzDQo+IG1ha2VzIGl0IHRvdWdoIHRvIHRyYWNrLg0K PiANCj4gTXkgc3VtbWFyeSBvZiB3aGF0IHlvdSBzYWlkIGlzIHRoYXQgdGhlcmUgYXJlIHR3byBk aWZmZXJlbnQgd2F5cyB0aGF0DQo+IGhhdmUgYmVlbiBwcm9wb3NlZCB0byB1c2UgQUVTLUNCQyBh bmQgSE1BQy1TSEE6IHRoZSBvbmUgY3VycmVudGx5IGluDQo+IHRoZSBzcGVjLCBhbmQgIkRhdmlk J3MgYWxnb3JpdGhtIi4NCj4gDQo+IEZXSVcgYXMgYW4gaW1wbGVtZW50ZXI6IG5vbmUgb2YgdGhl IGNyeXB0byBsaWJyYXJpZXMgSSBoYXZlIGxvb2tlZCBhdA0KPiBhcmUgZ29pbmcgdG8gZG8gRCwg RSwgJiBGIGZvciBtZTsgc28gSSBhbSBkb2luZyB0aGVtIGluIG15IGxpYnJhcnkgYW5kDQo+IGhh dmluZyB0aGVtIGFzIHNlcGFyYXRlIGZpZWxkcyB2cyB5ZXQtYW5vdGhlci1jb25jYXRlbmF0aW9u LWFsZ29yaXRobQ0KPiBpcyBwcmVmZXJyZWQuIEkgY2FuIHNlZSB3aHkgdGhhdCB3b3VsZCBub3Qg YmUgZGVzaXJhYmxlIGlmIHRoZSBmb3JtYXQNCj4gaXMgdGhlbiBpbmNvbnNpc3RlbnQgd2l0aCBB RUFELiBIYXZpbmcgc2FpZCB0aGF0LCBJJ20gY29kaW5nIGluDQo+IG5vZGUuanMsIGFuZCBldmVu IHRob3VnaCBpdCB1c2VzIG9wZW5zbGwgdGhhdCBoYXMgQUVBRCwgbm9uZSBvZiB0aGUNCj4gQUVB RCBpbnRlcmZhY2VzIGFyZSBleHBvc2VkIGN1cnJlbnRseSBpbiBub2RlLmpzLCBhbmQgSSBkb24n dCBzZWUgdGhhdA0KPiBjaGFuZ2luZyBhbnl0aW1lIHNvb24gPT4gbm90IHN1cmUgQUVBRCBpcyBn b2luZyB0byBiZSBpbmNvcnBvcmF0ZWQgd2l0aA0KPiBKV1QgbGlicmFyaWVzLg0KPiANCj4gLS0g RGljaw0KPiANCj4gT24gTWFyIDI3LCAyMDEzLCBhdCA3OjQ5IFBNLCAiTWFuZ2VyLCBKYW1lcyBI Ig0KPiA8SmFtZXMuSC5NYW5nZXJAdGVhbS50ZWxzdHJhLmNvbT4gd3JvdGU6DQo+IA0KPiA+IERp Y2ssDQo+ID4NCj4gPiBkcmFmdC1tY2dyZXctYWVhZC1hZXMtY2JjLWhtYWMtc2hhMiAiQXV0aGVu dGljYXRlZCBFbmNyeXB0aW9uIHdpdGgNCj4gQUVTLUNCQyBhbmQgSE1BQy1TSEEiIDwgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWNncmV3LWFlYWQtDQo+IGFlcy1jYmMtaG1hYy1z aGEyPiBpcyAiRGF2aWQncyBhbGdvcml0aG0iLg0KPiA+DQo+ID4NCj4gPiBCb3RoIGRyYWZ0LW1j Z3Jldy1hZWFkLWFlcy1jYmMtaG1hYy1zaGEyIGFuZCAiQTEyOENCQytIUzI1NiIgaW4gSldBDQo+ IGRlZmluZSBhIHdheSB0byBjb21iaW5lIENCQyBhbmQgSE1BQyB0byBnZXQgYXV0aGVudGljYXRl ZCBlbmNyeXB0aW9uLg0KPiBUaGV5IG1ha2Ugc29tZSBkaWZmZXJlbnQgY2hvaWNlczoNCj4gPg0K PiA+IEEuIENvbmNhdGVuYXRlIENCQyAmIEhNQUMga2V5cyB2cyB1c2UgYSBLREYgdG8gZGVyaXZl IENCQyAmIEhNQUMNCj4ga2V5czsNCj4gPg0KPiA+IEIuIDEyOCsxMjggYml0IGtleSBzaXplcyB2 cyAxMjgrMjU2IGJpdCBrZXlzIHNpemUgKGZvciBBRVMtMTI4ICYNCj4gSE1BQy0yNTYpDQo+ID4N Cj4gPiBDLiBBdXRoZW50aWNhdGlvbiB0YWcgaGFsZiB0aGUgaGFzaCBzaXplIHZzIHRoZSBmdWxs IGhhc2ggc2l6ZQ0KPiA+DQo+ID4gRC4gQXV0aCB0YWcgY29uY2F0ZW5hdGVkIHRvIGNpcGhlcnRl eHQgdnMgc2VwYXJhdGUgZmllbGQNCj4gPg0KPiA+IEUuIElWIGNvbmNhdGVuYXRlZCB3aXRoIGNp cGhlcnRleHQgdnMgc2VwYXJhdGUgZmllbGQNCj4gPg0KPiA+IEYuIEhNQUMgY2FsY3VsYXRlZCBv dmVyIHRoZSByYXcgY2lwaGVydGV4dCB2cyBiYXNlNjR1cmwtZW5jb2RlZA0KPiBjaXBoZXJ0ZXh0 DQo+ID4NCj4gPiBNaWtlIGlzIHJpZ2h0IHRoYXQgdGhlIGNyeXB0byBjaG9pY2VzIChBLCBCLCBD KSB3aWxsIGJlIG1vcmUNCj4gYWNjZXB0YWJsZSBjb21pbmcgZnJvbSB0aGUgQ3J5cHRvIEZvcnVt IFJlc2VhcmNoIEdyb3VwIChDUkZHKSBncm91cCBpbg0KPiBhIHNwZWMgc3BlY2lmaWNhbGx5IGRl c2NyaWJpbmcgQ0JDK0hNQUMgKHdpdGggc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCj4gYW5kIHJh dGlvbmFsZXMgZm9yIGl0cyBjaG9pY2VzLCBwbHVzIHRlc3QgdmVjdG9ycyBldGMpLCBjb21wYXJl ZCB0byBhDQo+IEpPU0Utc3BlY2lmaWMgZGVmaW5pdGlvbiB0aGF0IGlzIGEgc21hbGwgcGFydCBv ZiBhIEpXQSBkb2MuDQo+ID4NCj4gPiBELCBFLCAmIEYgYXJlIG1vcmUgdG8gZG8gd2l0aCBob3cg dGhlIGFsZ29yaXRobXMgZml0IHdpdGggY3J5cHRvDQo+IEFQSXMuIFdlIHdpbGwgb2Z0ZW4gaGF2 ZSBhcHBsaWNhdGlvbiBjb2RlLCBKT1NFIGxpYnJhcnkgY29kZSwgYW5kDQo+IGNyeXB0byBsaWJy YXJ5IGNvZGUuIFRoZSBpc3N1ZXMgYXJlIHdoaWNoIGxheWVycyBuZWVkIHRvIGtub3cgd2hpY2gN Cj4gYWxnb3JpdGhtLXNwZWNpZmljIGRldGFpbHMuDQo+ID4NCj4gPiBDcnlwdG8gbGlicmFyaWVz IGhhdmUgaGlzdG9yaWNhbGx5IG9mZmVyZWQgQ0JDIGFuZCBITUFDIGludGVyZmFjZXMuDQo+IE5v dyB0aGV5IGFyZSBzdGFydGluZyB0byBvZmZlciBBRUFEIGludGVyZmFjZXMuIFRoZSBDQkMrSE1B QyBhbGdvcml0aG0NCj4gd2UgcHV0IGluIEpPU0Ugc2hvdWxkIGJlIGFibGUgdG8gd29yayB3ZWxs IHdpdGggQUVBRCBpbnRlcmZhY2VzLiBEcmFmdC0NCj4gbWdyZXcgd2lsbCB3b3JrIGFzIGl0IGZp dHMgYSBtb2RlbCBmb3IgQUVBRCBhbGdvcml0aG1zIGRlZmluZWQgaW4gUkZDDQo+IDUxMTYgIkFu IEludGVyZmFjZSBhbmQgQWxnb3JpdGhtcyBmb3IgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIi4g VGhlDQo+IGN1cnJlbnQgSk9TRS1zcGVjaWZpYyBhbGcgd2lsbCBOT1QgZml0IEFFQUQgaW50ZXJm YWNlcyB3ZWxsIC0tDQo+IHByaW1hcmlseSBiZWNhdXNlIG9mIGRpZmZlcmVuY2UgRiAodGhhdCBt aXhlcyBhcHAtbGF5ZXIgYmFzZTY0dXJsLQ0KPiBlbmNvZGluZyB3aXRoIGEgc3RlcCB0aGF0IGlz IGludGVybmFsIHRvIHRoZSBBRUFEIGFsZ29yaXRobSkuDQo+ID4NCj4gPiBUaGUgYXV0aGVudGlj YXRpb24gdGFnIChkaWZmZXJlbmNlIEQpIGlzIGEgc3VidGxlciBpc3N1ZS4gQSB0YWcgaXMgYQ0K PiBjb3JlIGNvbXBvbmVudCBvZiBhIGJ1bmNoIG9mIEFFQUQgYWxnb3JpdGhtcyBzbyBzb21lIEFF QUQgQVBJcyBoYXZlDQo+IGV4cGxpY2l0IHN1cHBvcnQgZm9yIGEgdGFnIGZpZWxkLiBIb3dldmVy IGl0IGlzIHJlYWxseSBhbiBpbnRlcm5hbA0KPiBkZXRhaWw6IGVpdGhlciB0aGUgZGVjcnlwdGlv biBoYW5kcyBiYWNrIHBsYWludGV4dCBvciBpdCBmYWlscy4gQQ0KPiBjcnlwdG8gbGlicmFyeSdz IGltcGxlbWVudGF0aW9uIG9mIGFuIEFFQUQgYWxnIHRoYXQgaGFzIGEgdGFnIG5lZWRzIHRvDQo+ IGRpc3Rpbmd1aXNoIHRoZSB0YWcgZnJvbSB0aGUgcmVzdCBvZiB0aGUgY2lwaGVydGV4dCAtLSBi dXQgZG9lcyB0aGUNCj4gYXBwLWxheWVyIG5lZWQgdG8gZGlzdGluZ3Vpc2ggdGhlIHR3bz8gTm90 IHJlYWxseS4NCj4gPg0KPiA+DQo+ID4gSSB1bmRlcnN0YW5kIChhbmQgaG9wZSkgdGhlIEpPU0Ug Y29uc2Vuc3VzIGlzIHRvIGdvIHdpdGggZHJhZnQtbWNncmV3DQo+IG9uIHBvaW50cyBBLCBCLCBD LCBhbmQgRi4NCj4gPg0KPiA+IE15IG9waW5pb24gaXMgdGhhdCB3ZSBzaG91bGQgZ28gd2l0aCBk cmFmdC1tY2dyZXcgKGFuZCBSRkM1MTE2KSBmb3IgRA0KPiAmIEUgYXMgd2VsbCwgYnV0IE1pa2Ug KGFuZCBvdGhlcnMpIGRpc2FncmVlLiBJdCBzaG91bGRuJ3QgYWZmZWN0IHRoZQ0KPiBtYXRocyBv ZiB0aGUgY3J5cHRvLCBidXQgaXQgZG9lcyBhZmZlY3QgQVBJcyBhbmQgdGhlIGRlZ3JlZSB0aGF0 IHRoZQ0KPiBhcHAgbGF5ZXIgY2FuIGJlIChwYXJ0aWFsbHkpIHJlbGlldmVkIG9mIHRoZSByZXNw b25zaWJpbGl0eSBvZiBkZWFsaW5nDQo+IHdpdGggc29tZSB0b3VnaCBjcnlwdG8gaXNzdWVzIChz dWNoIGFzIGNyeXB0by1xdWFsaXR5IHJhbmRvbW5lc3MsDQo+IHVuaXF1ZW5lc3Mgb2Ygbm9uY2Vz IGV0YykuDQo+ID4NCj4gPiAtLQ0KPiA+IEphbWVzIE1hbmdlcg0KPiA+DQoNCg== From vladimir@nimbusds.com Thu Mar 28 02:19:44 2013 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 D45DC21F90C7 for ; Thu, 28 Mar 2013 02:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6] 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 8GJ48op-NTUp for ; Thu, 28 Mar 2013 02:19:44 -0700 (PDT) Received: from n1plwbeout07-02.prod.ams1.secureserver.net (n1plsmtp07-02-02.prod.ams1.secureserver.net [188.121.52.107]) by ietfa.amsl.com (Postfix) with SMTP id 6341F21F9063 for ; Thu, 28 Mar 2013 02:19:43 -0700 (PDT) Received: (qmail 18709 invoked from network); 28 Mar 2013 09:19:42 -0000 Received: from unknown (HELO localhost) (188.121.52.244) by n1plwbeout07-02.prod.ams1.secureserver.net with SMTP; 28 Mar 2013 09:19:41 -0000 Received: (qmail 5817 invoked by uid 99); 28 Mar 2013 09:19:41 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 90.154.175.98 User-Agent: Workspace Webmail 5.6.34 Message-Id: <20130328021940.cc40c4f3d92d2001859047cd8cabb9ab.9074ac9d02.wbe@email07.europe.secureserver.net> From: "Vladimir Dzhuvinov / NimbusDS" To: "Manger, James H" , "Dick Hardt" Date: Thu, 28 Mar 2013 02:19:40 -0700 Mime-Version: 1.0 Cc: "jose@ietf.org" Subject: Re: [jose] Use of AES-HMAC algorithm 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, 28 Mar 2013 09:19:45 -0000 Hi guys,=0A=0AI studied draft-mcgrew-aead-aes-cbc-hmac-sha2-01. It addresse= s the exact=0Asame issue that we do with our JOSE-specific KDF-based A128CB= C_HS256 and=0AA256CBC_HS512 JWAs, but in a spec of its own and in a way tha= t is more=0Abroadly applicable. =0A=0AThe spirit of the IETF standards is t= o provide a body of useful and=0Ainterconnected specs that refer to one ano= ther, instead of reinventing=0Athe wheel each time. This makes the individu= al specs simpler and more=0Afocused, and helps with software reuse and inte= roperability. I suggest=0Awe follow this good spirit and adopt McGrew's dra= ft.=0A=0AIf the draft needs to be amended to suit some particular JOSE enco= ding=0Arequirement, the authors would be glad to cooperate with us, as they= =0Ahave written in section 4 Rationale.=0A=0AWhat do we gain by adopting Mc= Grew's draft:=0A=0A* We can have a common spec for authenticated AES/CBC wi= th W3C web=0Acrypto to refer to.=0A=0A* We gain the expertise and the suppo= rt of the McGrew draft authors.=0A=0A* The McGrew draft has better chances = to become a mainstream solution=0Afor authenticated AES/CBC, with following= library implementations, and=0Aeven more so if we adopt it (than our JOSE = KDF alg).=0A=0A* The JOSE specs remain focused on what they were initially = intended to=0Aachieve - specify a nimble JSON format for crypto messages, n= ot delving=0Ainto devising new crypto algorithms :)=0A=0A=0AYes, we will lo= se the work that was already done to implement the=0AKDF-based AES/CBC AEAD= . I have also spent time on that. But the end=0Aresult will be better for u= s and the community, I believe.=0A=0A=0AThanks,=0A=0AVladimir=0A=0A--=0AVla= dimir Dzhuvinov : www.NimbusDS.com : vladimir@nimbusds.com=0A=0A=0A--------= Original Message --------=0ASubject: Re: [jose] Use of AES-HMAC algorithm= =0AFrom: "Manger, James H" =0ADate: Thu, M= arch 28, 2013 4:40 am=0ATo: Dick Hardt =0ACc: "jose@i= etf.org" =0A=0AI haven=E2=80=99t been at any of the meeting = either! It is hard to track.=0A=0AJava added AEAD support in v7 (eg javax.c= rypto.cipher#updateAAD).=0AOpenSSL has added AEAD support.=0AI think OpenSS= L AEAD support has filtered into Ruby.=0AApparently it hasn't filtered into= node.js yet.=0AMicrosoft Crypto Next Generation (Cng) has added AEAD suppo= rt.=0AGo supports AE-without-the-AD, as does NaCl.=0A=0ASo I think JOSE wil= l live long enough for explicit AEAD support in=0Acrypto libraries to be th= e norm.=0A=0A--=0AJames Manger=0A=0A=0A> -----Original Message-----=0A> Fro= m: Dick Hardt [mailto:dick.hardt@gmail.com]=0A> Sent: Thursday, 28 March 20= 13 2:32 PM=0A> To: Manger, James H=0A> Cc: Mike Jones; Jim Schaad; jose@iet= f.org=0A> Subject: Re: [jose] Use of AES-HMAC algorithm=0A> =0A> Thanks for= taking the time to explain James. Not being at the meetings=0A> makes it t= ough to track.=0A> =0A> My summary of what you said is that there are two d= ifferent ways that=0A> have been proposed to use AES-CBC and HMAC-SHA: the = one currently in=0A> the spec, and "David's algorithm".=0A> =0A> FWIW as an= implementer: none of the crypto libraries I have looked at=0A> are going t= o do D, E, & F for me; so I am doing them in my library and=0A> having them= as separate fields vs yet-another-concatenation-algorithm=0A> is preferred= . I can see why that would not be desirable if the format=0A> is then incon= sistent with AEAD. Having said that, I'm coding in=0A> node.js, and even th= ough it uses opensll that has AEAD, none of the=0A> AEAD interfaces are exp= osed currently in node.js, and I don't see that=0A> changing anytime soon = =3D> not sure AEAD is going to be incorporated with=0A> JWT libraries.=0A> = =0A> -- Dick=0A> =0A> On Mar 27, 2013, at 7:49 PM, "Manger, James H"=0A> wrote:=0A> =0A> > Dick,=0A> >=0A> > draft-m= cgrew-aead-aes-cbc-hmac-sha2 "Authenticated Encryption with=0A> AES-CBC and= HMAC-SHA" < http://tools.ietf.org/html/draft-mcgrew-aead-=0A> aes-cbc-hmac= -sha2> is "David's algorithm".=0A> >=0A> >=0A> > Both draft-mcgrew-aead-aes= -cbc-hmac-sha2 and "A128CBC+HS256" in JWA=0A> define a way to combine CBC a= nd HMAC to get authenticated encryption.=0A> They make some different choic= es:=0A> >=0A> > A. Concatenate CBC & HMAC keys vs use a KDF to derive CBC &= HMAC=0A> keys;=0A> >=0A> > B. 128+128 bit key sizes vs 128+256 bit keys si= ze (for AES-128 &=0A> HMAC-256)=0A> >=0A> > C. Authentication tag half the = hash size vs the full hash size=0A> >=0A> > D. Auth tag concatenated to cip= hertext vs separate field=0A> >=0A> > E. IV concatenated with ciphertext vs= separate field=0A> >=0A> > F. HMAC calculated over the raw ciphertext vs b= ase64url-encoded=0A> ciphertext=0A> >=0A> > Mike is right that the crypto c= hoices (A, B, C) will be more=0A> acceptable coming from the Crypto Forum R= esearch Group (CRFG) group in=0A> a spec specifically describing CBC+HMAC (= with security considerations=0A> and rationales for its choices, plus test = vectors etc), compared to a=0A> JOSE-specific definition that is a small pa= rt of a JWA doc.=0A> >=0A> > D, E, & F are more to do with how the algorith= ms fit with crypto=0A> APIs. We will often have application code, JOSE libr= ary code, and=0A> crypto library code. The issues are which layers need to = know which=0A> algorithm-specific details.=0A> >=0A> > Crypto libraries hav= e historically offered CBC and HMAC interfaces.=0A> Now they are starting t= o offer AEAD interfaces. The CBC+HMAC algorithm=0A> we put in JOSE should b= e able to work well with AEAD interfaces. Draft-=0A> mgrew will work as it = fits a model for AEAD algorithms defined in RFC=0A> 5116 "An Interface and = Algorithms for Authenticated Encryption". The=0A> current JOSE-specific alg= will NOT fit AEAD interfaces well --=0A> primarily because of difference F= (that mixes app-layer base64url-=0A> encoding with a step that is internal= to the AEAD algorithm).=0A> >=0A> > The authentication tag (difference D) = is a subtler issue. A tag is a=0A> core component of a bunch of AEAD algori= thms so some AEAD APIs have=0A> explicit support for a tag field. However i= t is really an internal=0A> detail: either the decryption hands back plaint= ext or it fails. A=0A> crypto library's implementation of an AEAD alg that = has a tag needs to=0A> distinguish the tag from the rest of the ciphertext = -- but does the=0A> app-layer need to distinguish the two? Not really.=0A> = >=0A> >=0A> > I understand (and hope) the JOSE consensus is to go with draf= t-mcgrew=0A> on points A, B, C, and F.=0A> >=0A> > My opinion is that we sh= ould go with draft-mcgrew (and RFC5116) for D=0A> & E as well, but Mike (an= d others) disagree. It shouldn't affect the=0A> maths of the crypto, but it= does affect APIs and the degree that the=0A> app layer can be (partially) = relieved of the responsibility of dealing=0A> with some tough crypto issues= (such as crypto-quality randomness,=0A> uniqueness of nonces etc).=0A> >= =0A> > --=0A> > James Manger=0A> >=0A=0A___________________________________= ____________=0Ajose mailing list=0Ajose@ietf.org=0Ahttps://www.ietf.org/mai= lman/listinfo/jose From juraj.somorovsky@rub.de Wed Mar 27 00:36:51 2013 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 3906A21F900B for ; Wed, 27 Mar 2013 00:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 OkLvP5SXQ5-Z for ; Wed, 27 Mar 2013 00:36:50 -0700 (PDT) Received: from mx4.rz.ruhr-uni-bochum.de (mi.ruhr-uni-bochum.de [134.147.64.53]) by ietfa.amsl.com (Postfix) with SMTP id 1CE8821F8FFB for ; Wed, 27 Mar 2013 00:36:49 -0700 (PDT) X-Queued: (qmail 12374 invoked by alias); 27 Mar 2013 07:36:49 -0000 X-Queued: (qmail 12359 invoked from network); 27 Mar 2013 07:36:49 -0000 Received: from c2-3-4.rz.ruhr-uni-bochum.de (134.147.64.5) by mx4.rz.ruhr-uni-bochum.de with SMTP; 27 Mar 2013 07:36:49 -0000 X-Queued: (qmail 19350 invoked by uid 281); 27 Mar 2013 07:36:48 -0000 X-Qmailscanner: from 134.147.40.78 (7Cil8M2CiUxUH/PRCe4KGA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de (envelope-from , uid 80) with qmail-scanner-2.01 (sophie: 3.05/3.37/4.83. Clear:RC:1(134.147.40.78):. Processed in 0.072953 secs); 27 Mar 2013 07:36:48 -0000 Received: from jontop.nds.ruhr-uni-bochum.de (HELO ?134.147.40.78?) (7Cil8M2CiUxUH/PRCe4KGA==@134.147.40.78) by c2-3-4.rz.ruhr-uni-bochum.de with (DHE-RSA-CAMELLIA256-SHA encrypted) SMTP; 27 Mar 2013 07:36:48 -0000 Date: 27 Mar 2013 08:36:45 +0100 Message-ID: <5152A18D.5040504@rub.de> From: "Juraj Somorovsky" To: "Manger, James H" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 References: <20130325070200.cc40c4f3d92d2001859047cd8cabb9ab.b714da08bb.wbe@email07.europe.secureserver.net> <51505BFA.7080100@rub.de> <255B9BB34FB7D647A506DC292726F6E1150BE3C5A5@WSMSG3153V.srv.dir.telstra.com> <5150E950.5060301@rub.de> <255B9BB34FB7D647A506DC292726F6E1150BEFF2FC@WSMSG3153V.srv.dir.telstra.com> In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BEFF2FC@WSMSG3153V.srv.dir.telstra.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 28 Mar 2013 08:03:32 -0700 Cc: IETF JOSE WG , Vladimir Dzhuvinov / NimbusDS Subject: Re: [jose] backwards compatibility attack on JWT impls (was: I-D Action: draft-ietf-jose-json-web-algorithms-02.txt) 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, 27 Mar 2013 07:36:51 -0000 On 03/26/2013 02:30 AM, Manger, James H wrote: >>>> SecretKey randomCMK = AES.generateAESCMK(keyLength); >>>> >>>> try { >>>> cmk = RSA1_5.decryptCMK(privateKey, encryptedKey.decode(), >>>> keyLength); >>>> } catch (Exception e) { >>>> // Protect against MMA attack by generating random CMK on >> failure, >>>> // see http://www.ietf.org/mail- >>>> archive/web/jose/current/msg01832.html >>>> cmk = randomCMK; >>>> } >>>> } >>>> > For a start the fixes need to be much lower down where the PKCS#1 padding is first handled, not way up the stack were you see an exception vs a normal return. > > The Go language appears to have code with decent protections to avoid leaking crucial timing details: http://golang.org/src/pkg/crypto/rsa/pkcs1v15.go. > > The Java code I found in a quick search (sun.security.rsa.RSAPadding#unpadV15) makes no effort to be constant time. I doubt there is anything (reasonable) that can be done at a higher layer (such as com.nimbusds.jose.crypto.RSA1_5) to make RSAES-PKCS1-V1_5 safe with that foundation. > [http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/7-b147/sun/security/rsa/RSAPadding.java#RSAPadding.unpadV15%28byte%5B%5D%29] Such countermeasures are very precise, but are also very difficult to implement. I do not think they are necessary to implement against the state-of-the art timing attacks. I would say the countermeasure that I presented is enough and would thwart practical Bleichenbacher timing attacks. Regards Juraj From jricher@mitre.org Thu Mar 28 08:46:30 2013 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 BA8F621F8EF7 for ; Thu, 28 Mar 2013 08:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.338 X-Spam-Level: X-Spam-Status: No, score=-6.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 qYL-3HpvTkkJ for ; Thu, 28 Mar 2013 08:46:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0C29A21F8EEC for ; Thu, 28 Mar 2013 08:46:29 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A45102260098; Thu, 28 Mar 2013 11:46:28 -0400 (EDT) Received: from IMCCAS03.MITRE.ORG (imccas03.mitre.org [129.83.29.80]) by smtpksrv1.mitre.org (Postfix) with ESMTP id 93ACC1F0786; Thu, 28 Mar 2013 11:46:28 -0400 (EDT) Received: from [10.146.15.29] (129.83.31.58) by IMCCAS03.MITRE.ORG (129.83.29.80) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 28 Mar 2013 11:46:07 -0400 Message-ID: <51546575.9090301@mitre.org> Date: Thu, 28 Mar 2013 11:44:53 -0400 From: Justin Richer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: References: <5150B533.2080205@mitre.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020501090904000201080701" X-Originating-IP: [129.83.31.58] Cc: jose@ietf.org Subject: Re: [jose] JWK Generator 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, 28 Mar 2013 15:46:30 -0000 --------------020501090904000201080701 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I've updated the key generator so that it now handles EC keys as well. Note that you'll have to wait for the latest Nimbus-JOSE-JWT library to hit Maven Central (should be any time now) before it'll build. By the time most of you read this message, it should compile and run. The new keytype paramter is "-k EC" and it requires a curve specification like "-c P-256". -- Justin On 03/25/2013 05:05 PM, Axel.Nennker@telekom.de wrote: > > EC key generation can be found in http://jsoncrypto.org/ > > ES512 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2726 > > ES384 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2685 > > ES256 > > https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2642 > > I guess that the println lines can be converted into JWKs. > > -Axel > > *From:*jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Justin Richer > *Sent:* Monday, March 25, 2013 9:36 PM > *To:* jose@ietf.org > *Subject:* [jose] JWK Generator > > A while ago, several folks complained that there was no toolchain for > creating bare keys in the JWK/JPSK format. Indeed, my team's been > using Java's keytool program and making self-signed dummy certs and > pulling them out of there. That was a bit of a pain, to be honest. > > So now I've just written a utility program to generate JWK formatted > keys from whole cloth given a set of parameters. It's a Java app built > using the NimbusDS JWT-JOSE library, and at the moment it supports > both RSA and oct keytypes, with an option to extract the public-only > portion of the RSA as well. This is all based on the current JPSK > format, which we plan to track with the aforementioned Nimbus library. > > You can get the code here: > > https://github.com/mitreid-connect/json-web-key-generator > > It's open sourced under an Apache 2.0 license, so feel free to pull it > down and use it to your heart's content. It's a Java Maven project, so > you build it with: > > mvn package > > This will create a couple of .jar files in the target/ directory, one > of which is an executable fat jar, usble from the commandline: > > usage: java -jar json-web-key-generator.jar -t -s [-u > -a -i -p] > -a Algorithm. > -i Key ID (optional) > -p Display public key separately > -s Key Size in bits, must be an integer, generally divisible by 8 > -t Key Type, one of: RSA, oct > -u Usage, one of: enc, sig. Defaults to sig > > > For instance, to generate a 1024-bit RSA key with the algorithm of > RS256, no key id, and display the public key separately, you would run > (after doing a mvn package): > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar > -a RS256 -t RSA -s 1024 -p > > This prints out (for example, your keys should vary): > > Full key: > { > "alg": "RS256", > "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0", > "e": "AQAB", > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", > "kty": "RSA", > "use": "sig" > } > > Public key: > { > "alg": "RS256", > "e": "AQAB", > "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0", > "kty": "RSA", > "use": "sig" > } > > > To create a 256-bit symmetric key with algorithm HS256 and key id of > "myKey", you'd do: > > java -jar > target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar > -t oct -s 256 > > Which outputs something like: > > Full key: > { > "kty": "oct", > "use": "sig", > "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME" > } > > > It doesn't do EC keys yet because I don't know the Java Magic needed > to make such a thing happen, but I'd be happy to have someone help out > with that with a pull request. > > Hopefully people find this utility useful. I've got a few features I'm > planning to add (write output to files, Java GUI with dropdowns for > options), but this is a minimally-useful set of functionality. > > -- Justin > --------------020501090904000201080701 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit I've updated the key generator so that it now handles EC keys as well. Note that you'll have to wait for the latest Nimbus-JOSE-JWT library to hit Maven Central (should be any time now) before it'll build. By the time most of you read this message, it should compile and run. The new keytype paramter is "-k EC" and it requires a curve specification like "-c P-256".

 -- Justin

On 03/25/2013 05:05 PM, Axel.Nennker@telekom.de wrote:

EC key generation can be found in http://jsoncrypto.org/

 

ES512

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2726

 

ES384

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2685

 

ES256

https://code.google.com/p/jsoncrypto/source/browse/trunk/testsrc/org/jsoncrypto/JcBaseTest.java#2642

 

I guess that the println lines can be converted into JWKs.

 

-Axel

 

From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Justin Richer
Sent: Monday, March 25, 2013 9:36 PM
To: jose@ietf.org
Subject: [jose] JWK Generator

 

A while ago, several folks complained that there was no toolchain for creating bare keys in the JWK/JPSK format. Indeed, my team's been using Java's keytool program and making self-signed dummy certs and pulling them out of there. That was a bit of a pain, to be honest.

So now I've just written a utility program to generate JWK formatted keys from whole cloth given a set of parameters. It's a Java app built using the NimbusDS JWT-JOSE library, and at the moment it supports both RSA and oct keytypes, with an option to extract the public-only portion of the RSA as well. This is all based on the current JPSK format, which we plan to track with the aforementioned Nimbus library.

You can get the code here:

  https://github.com/mitreid-connect/json-web-key-generator

It's open sourced under an Apache 2.0 license, so feel free to pull it down and use it to your heart's content. It's a Java Maven project, so you build it with:

  mvn package

This will create a couple of .jar files in the target/ directory, one of which is an executable fat jar, usble from the commandline:

usage: java -jar json-web-key-generator.jar -t <keyType> -s <keySize> [-u
            <keyUsage> -a <algorithm> -i <keyId> -p]
 -a <arg>   Algorithm.
 -i <arg>   Key ID (optional)
 -p         Display public key separately
 -s <arg>   Key Size in bits, must be an integer, generally divisible by 8
 -t <arg>   Key Type, one of: RSA, oct
 -u <arg>   Usage, one of: enc, sig. Defaults to sig


For instance, to generate a 1024-bit RSA key with the algorithm of RS256, no key id, and display the public key separately, you would run (after doing a mvn package):

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -a RS256 -t RSA -s 1024 -p

This prints out (for example, your keys should vary):

Full key:
{
  "alg": "RS256",
  "d": "IXhRb4mXMOLlX1nEcv--CRX5WjGZdUTHzI2qIg-iX5QXY-noSZqit-BeWO0CTwBtryCU4DgNIjV4cvYHpWqkr8ES-FoH7DHDgt41lH5_YDv-MeeCU3hRSPbACLuWEbWQfjgLPgIL1cmh1q-eFOEpXWUtKy7DCFymMves7ojPxY0",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}
 
Public key:
{
  "alg": "RS256",
  "e": "AQAB",
  "n": "kWkuetDiodUI-0jZ2KpmwOMJ7jsnO8qG8ChMs7ax3xXKIr5g5K0axWtXm1HwA5OJRE-OyVHfJkda6xVgTFaV1AhWP8Zp7KL_Oq-moKRe5-BtahHpFJe7HZ1P6hxXAdhaygXen1lR0NAMNi4K4H5pn1KDCeRpuxAhJZsQnq5dxp0",
  "kty": "RSA",
  "use": "sig"
}


To create a 256-bit symmetric key with algorithm HS256 and key id of "myKey", you'd do:

  java -jar target/json-web-key-generator-0.1-SNAPSHOT-jar-with-dependencies.jar -t oct -s 256

Which outputs something like:

Full key:
{
  "kty": "oct",
  "use": "sig",
  "k": "CsoV5LeX6S3RRlLr-hk0_VyIuTOWyovMPbU2UmbphME"
}


It doesn't do EC keys yet because I don't know the Java Magic needed to make such a thing happen, but I'd be happy to have someone help out with that with a pull request.

Hopefully people find this utility useful. I've got a few features I'm planning to add (write output to files, Java GUI with dropdowns for options), but this is a minimally-useful set of functionality.

 -- Justin


--------------020501090904000201080701-- From sakimura@gmail.com Thu Mar 28 17:16:35 2013 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 D771421F8FBE for ; Thu, 28 Mar 2013 17:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 quVdp4kjdSgM for ; Thu, 28 Mar 2013 17:16:35 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id D034521F8F7A for ; Thu, 28 Mar 2013 17:16:31 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gw10so141170lab.13 for ; Thu, 28 Mar 2013 17:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=QYrXOOHj+RGjcDzs+oE9DGW7gVxyW8H08bO37Qv/CKU=; b=OmGR08gtUqDHDIIhtP6WtsUv5aJsPmcs31IXUYqEVcWd5OENEeqEJgSWgaJQEjmnZo L0IR3hRr02CI1l2ewAtpPf4zO+CupX4PwJQ9ohLjj3JFl2xHyUIOVObkxAJtp6rgWWHu HZu4Z1a2DQEqe630c8t+HMZm97mMnr+RvaJxW7yZ8uKOpnkTAkQW4ysv3kO0MCg1xw+P Gcx7yDfGuFUAgik8bFa/ADGECdieY/wWTbTZOHGofDFxpoFO9sXONylWN0wSum5XwLoi fFQ5mnJ/KahdbLn0R6/OLUXG7t4d5CHI85ZnMfGcdV7G8PfqXoufgPVoKkRpCwlLwaxm rqFg== MIME-Version: 1.0 X-Received: by 10.112.98.227 with SMTP id el3mr451322lbb.131.1364516190662; Thu, 28 Mar 2013 17:16:30 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 28 Mar 2013 17:16:30 -0700 (PDT) In-Reply-To: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> Date: Fri, 29 Mar 2013 09:16:30 +0900 Message-ID: From: Nat Sakimura To: Jim Schaad Content-Type: multipart/alternative; boundary=f46d04017315d5bea404d9052e55 Cc: jose@ietf.org Subject: Re: [jose] Consensus calls 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, 29 Mar 2013 00:16:36 -0000 --f46d04017315d5bea404d9052e55 Content-Type: text/plain; charset=ISO-8859-1 HI. Could you please specify which drafts for item 3? Nat 2013/3/28 Jim Schaad > > > The following "decisions" were made at the face to face meeting. This > message is to ratify these decisions on the list. You have one week to > object and provide a solid defense of your objection or the actions will be > considered as adopted. Note that for some of these we are running slightly > ahead of our charter changes but this is not expected to be a problem > > 1. Adopt the proposed compromise language from John Bradley's presentation > dealing with the critical language. This is to adopt points 1, 2, 3 and 4 > but not point 5. (presentation is available on the materials website > http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). > > 2. The private fields of public/private key algorithms and the symmetric > key field are to be folded into the mail JWA draft. > > 3. The multiple recipient/signer serialization drafts are to be folded into > the JWE and JWS drafts respectively. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --f46d04017315d5bea404d9052e55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI.=A0

Could you please specify which drafts for item 3?= =A0

Nat

2013/3/2= 8 Jim Schaad <ietf@augustcellars.com>
<chair>

The following "decisions" were made at the face to face meeting. = =A0This
message is to ratify these decisions on the list. =A0You have one week to object and provide a solid defense of your objection or the actions will be=
considered as adopted. =A0Note that for some of these we are running slight= ly
ahead of our charter changes but this is not expected to be a problem

1. =A0Adopt the proposed compromise language from John Bradley's presen= tation
dealing with the critical language. =A0This is to adopt points 1, 2, 3 and = 4
but not point 5. =A0(presentation is available on the materials website
http://www.ietf.org/proceedings/86/slides/slides-86-jose-= 4.pdf).

2. =A0The private fields of public/private key algorithms and the symmetric=
key field are to be folded into the mail JWA draft.

3. The multiple recipient/signer serialization drafts are to be folded into=
the JWE and JWS drafts respectively.

Jim


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--f46d04017315d5bea404d9052e55-- From Michael.Jones@microsoft.com Thu Mar 28 17:21:13 2013 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 E527D21F844C for ; Thu, 28 Mar 2013 17:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 GNRkJ0DCwKYz for ; Thu, 28 Mar 2013 17:21:12 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0238.outbound.protection.outlook.com [207.46.163.238]) by ietfa.amsl.com (Postfix) with ESMTP id 36AC321F843F for ; Thu, 28 Mar 2013 17:21:12 -0700 (PDT) Received: from BY2FFO11FD012.protection.gbl (10.173.161.201) by BL2FFO11HUB040.protection.gbl (10.173.160.246) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 29 Mar 2013 00:21:10 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD012.mail.protection.outlook.com (10.1.14.130) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 29 Mar 2013 00:21:08 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC101.redmond.corp.microsoft.com ([157.54.7.153]) with mapi id 14.02.0318.003; Fri, 29 Mar 2013 00:21:01 +0000 From: Mike Jones To: Nat Sakimura , Jim Schaad Thread-Topic: [jose] Consensus calls Thread-Index: Ac4rMM//FnZzL+f2TX67H9zVPdX2bAA4dkwAAAAQQJA= Date: Fri, 29 Mar 2013 00:21:01 +0000 Message-ID: <4E1F6AAD24975D4BA5B168042967394367596FA1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394367596FA1TK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(479174001)(243025002)(377454001)(189002)(199002)(16406001)(47976001)(46102001)(50986001)(71186001)(31966008)(79102001)(76482001)(20776003)(80022001)(77982001)(49866001)(54356001)(55846006)(81342001)(59766001)(63696002)(5343635001)(15202345001)(74502001)(74662001)(69226001)(44976002)(56776001)(47736001)(54316002)(65816001)(512954001)(33656001)(4396001)(16236675001)(51856001)(47446002)(5343655001)(53806001)(66066001)(56816002); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB040; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0800C0C167 Cc: "jose@ietf.org" Subject: Re: [jose] Consensus calls 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, 29 Mar 2013 00:21:14 -0000 --_000_4E1F6AAD24975D4BA5B168042967394367596FA1TK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I would be highly surprised if Jim meant anything except http://tools.ietf.= org/html/draft-jones-jose-jws-json-serialization-04 and http://tools.ietf.o= rg/html/draft-jones-jose-jwe-json-serialization-04 for item 3 - especially = since were the drafts referenced in your presentation at IETF 86. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nat= Sakimura Sent: Thursday, March 28, 2013 5:17 PM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Consensus calls HI. Could you please specify which drafts for item 3? Nat 2013/3/28 Jim Schaad = > The following "decisions" were made at the face to face meeting. This message is to ratify these decisions on the list. You have one week to object and provide a solid defense of your objection or the actions will be considered as adopted. Note that for some of these we are running slightly ahead of our charter changes but this is not expected to be a problem 1. Adopt the proposed compromise language from John Bradley's presentation dealing with the critical language. This is to adopt points 1, 2, 3 and 4 but not point 5. (presentation is available on the materials website http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). 2. The private fields of public/private key algorithms and the symmetric key field are to be folded into the mail JWA draft. 3. The multiple recipient/signer serialization drafts are to be folded into the JWE and JWS drafts respectively. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=3Dnat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --_000_4E1F6AAD24975D4BA5B168042967394367596FA1TK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I would be highly surpris= ed if Jim meant anything except http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-0= 4 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-0= 4 for item 3 - especially since were the drafts referenced in your pres= entation at IETF 86.

 <= /p>

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

 <= /p>

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 28, 2013 5:17 PM
To: Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] Consensus calls

 

HI. 

 

Could you please specify which drafts for item 3?&nb= sp;

 

Nat

2013/3/28 Jim Schaad <ietf@augustcellars.com><= /p>

<chair>

The following "decisions" were made at the face to face meeting. =  This
message is to ratify these decisions on the list.  You have one week t= o
object and provide a solid defense of your objection or the actions will be=
considered as adopted.  Note that for some of these we are running sli= ghtly
ahead of our charter changes but this is not expected to be a problem

1.  Adopt the proposed compromise language from John Bradley's present= ation
dealing with the critical language.  This is to adopt points 1, 2, 3 a= nd 4
but not point 5.  (presentation is available on the materials website<= br> http://www.ietf.org/proceedings/86/slides/slides-86-jose-= 4.pdf).

2.  The private fields of public/private key algorithms and the symmet= ric
key field are to be folded into the mail JWA draft.

3. The multiple recipient/signer serialization drafts are to be folded into=
the JWE and JWS drafts respectively.

Jim


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



 

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en

--_000_4E1F6AAD24975D4BA5B168042967394367596FA1TK5EX14MBXC283r_-- From sakimura@gmail.com Thu Mar 28 17:31:18 2013 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 2A03021F8521 for ; Thu, 28 Mar 2013 17:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] 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 unoN-pqlyB6Z for ; Thu, 28 Mar 2013 17:31:17 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CD82421F84DC for ; Thu, 28 Mar 2013 17:31:16 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id er20so152269lab.4 for ; Thu, 28 Mar 2013 17:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=mjRCwulDM3cDFcb/P16O9J4rr4c2J4FwmJZNrPloOuY=; b=Clx1B0QZ0a27vyyHxjtf/ufkbSpBCH0u8UVsyhnjL96xOdANgr7FkXqHftLKUE2Uag VgtQxHo51FOziosaV7M3ETHJJ5wQCmTFvstp6OIp/9RxpBnFReUemwQWMFa9cOhDFe9J F/Mt9tIM7/BOnHUWI80t3OPAvs4aEaTkWVkGne+JFlilffAL7HZPduDXk7jnim+qmUMT T59v30MtOY2c3xsdxqxKojwnvuvrNJZ4xHhFi8Vh+7VM+ywW8qymPUpHpZmeUsxed3yI cCTFzlCYnE+4jRfNB4xDOTf0Wv6ZppMaMMpd7HYMPpivyi+l99gXfRelpsQrOu9hgEC/ g4Hw== MIME-Version: 1.0 X-Received: by 10.152.87.73 with SMTP id v9mr298782laz.2.1364517075684; Thu, 28 Mar 2013 17:31:15 -0700 (PDT) Received: by 10.112.103.202 with HTTP; Thu, 28 Mar 2013 17:31:15 -0700 (PDT) In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367596FA1@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367596FA1@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Fri, 29 Mar 2013 09:31:15 +0900 Message-ID: From: Nat Sakimura To: Mike Jones Content-Type: multipart/alternative; boundary=001a11c34d9a96153a04d90563f8 Cc: Jim Schaad , "jose@ietf.org" Subject: Re: [jose] Consensus calls 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, 29 Mar 2013 00:31:18 -0000 --001a11c34d9a96153a04d90563f8 Content-Type: text/plain; charset=ISO-8859-1 That's what I thought, but wanted to be sure, especially for the people who was not at the F2F. 2013/3/29 Mike Jones > I would be highly surprised if Jim meant anything except > http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 and > http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for > item 3 - especially since were the drafts referenced in your presentation > at IETF 86.**** > > ** ** > > -- Mike*** > * > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Nat Sakimura > *Sent:* Thursday, March 28, 2013 5:17 PM > *To:* Jim Schaad > *Cc:* jose@ietf.org > *Subject:* Re: [jose] Consensus calls**** > > ** ** > > HI. **** > > ** ** > > Could you please specify which drafts for item 3? **** > > ** ** > > Nat**** > > 2013/3/28 Jim Schaad **** > > > > The following "decisions" were made at the face to face meeting. This > message is to ratify these decisions on the list. You have one week to > object and provide a solid defense of your objection or the actions will be > considered as adopted. Note that for some of these we are running slightly > ahead of our charter changes but this is not expected to be a problem > > 1. Adopt the proposed compromise language from John Bradley's presentation > dealing with the critical language. This is to adopt points 1, 2, 3 and 4 > but not point 5. (presentation is available on the materials website > http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). > > 2. The private fields of public/private key algorithms and the symmetric > key field are to be folded into the mail JWA draft. > > 3. The multiple recipient/signer serialization drafts are to be folded into > the JWE and JWS drafts respectively. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose**** > > > > **** > > ** ** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en --001a11c34d9a96153a04d90563f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
That's what I thought, but wanted to be sure, especial= ly for the people who was not at the F2F.=A0


2013/3/29 Mike Jones <Micha= el.Jones@microsoft.com>

I would be highly surpris= ed if Jim meant anything except http://tools.ietf.org/html/draft-jones-jose-jws-js= on-serialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-js= on-serialization-04 for item 3 - especially since were the drafts refer= enced in your presentation at IETF 86.

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0 -- Mike

=A0<= /p>

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Nat Sakimura
Sent: Thursday, March 28, 2013 5:17 PM
To: Jim Schaad
Cc: jose@ietf.org=
Subject: Re: [jose] Consensus calls

=A0

HI.=A0

=A0

Could you please specify which drafts for item 3?=A0=

=A0

Nat

2013/3/28 Jim Schaad <ietf@augustcellars.com>

<chair>

The following "decisions" were made at the face to face meeting. = =A0This
message is to ratify these decisions on the list. =A0You have one week to object and provide a solid defense of your objection or the actions will be=
considered as adopted. =A0Note that for some of these we are running slight= ly
ahead of our charter changes but this is not expected to be a problem

1. =A0Adopt the proposed compromise language from John Bradley's presen= tation
dealing with the critical language. =A0This is to adopt points 1, 2, 3 and = 4
but not point 5. =A0(presentation is available on the materials website
http://www.ietf.org/proceedings/86/slides/slides-86-jose-= 4.pdf).

2. =A0The private fields of public/private key algorithms and the symmetric=
key field are to be folded into the mail JWA draft.

3. The multiple recipient/signer serialization drafts are to be folded into=
the JWE and JWS drafts respectively.

Jim


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose



=A0

--
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.= org/
@_nat_en




--
Nat Sakimura= (=3Dnat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en
--001a11c34d9a96153a04d90563f8-- From ietf@augustcellars.com Thu Mar 28 19:02:36 2013 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 B1D1821F89AF for ; Thu, 28 Mar 2013 19:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 m-2cgVkjrWNR for ; Thu, 28 Mar 2013 19:02:35 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 7015921F8967 for ; Thu, 28 Mar 2013 19:02:35 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 154122CA20 for ; Thu, 28 Mar 2013 19:02:35 -0700 (PDT) From: "Jim Schaad" To: References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> In-Reply-To: <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> Date: Thu, 28 Mar 2013 19:01:58 -0700 Message-ID: <006701ce2c21$65accf10$31066d30$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01CE2BE6.B950B630" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDc/nSECiQAb+v2IzCf58qtgKDeAZqeRckw Content-Language: en-us Subject: [jose] FW: GCM nonce reuse question 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, 29 Mar 2013 02:02:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0068_01CE2BE6.B950B630 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For those people not on the CFRG list - Jim From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Thursday, March 28, 2013 4:15 AM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: GCM nonce reuse question Hi Jim, From: Jim Schaad Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew Cc: "cfrg@irtf.org" Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM encryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and Key pairings. Do these problems apply to having a different set of auxiliary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5116#section-5.1.1 but apparently they are not described generally enough. They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag = GCM(Key, Recipient #1 data, nonce, plain text) Recipient #2 authentication tag = GCM(Key, Recipient #2 data, nonce, plain text) As the key, nonce and plain text are fixed it would produce the same encrypted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distinct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim ------=_NextPart_000_0068_01CE2BE6.B950B630 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For those people not on the CFRG list = –

 

Jim

 

 

From:= = David McGrew (mcgrew) [mailto:mcgrew@cisco.com]
Sent: = Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: = cfrg@irtf.org
Subject: Re: GCM nonce reuse = question

 

Hi = Jim,

 

=

From: = Jim Schaad <jimsch@augustcellars.com>=
Date: Wednesday, March 27, 2013 6:43 PM
To: David = McGrew <mcgrew@cisco.com>
Cc: = "cfrg@irtf.org" = <cfrg@irtf.org>
Subject: = GCM nonce reuse question

 

=

David,

 

In doing a write up I = became worried about a security property of the GCM encryption mode in = the way that the JOSE group is currently using = it.

 

There are known problems = with not having a unique set of values for IVs and Key pairings.  = Do these problems apply to having a different set of auxiliary data as = well as the plain text?

 

 

=

Yes.  The security issues = are summarized in http://tools.ie= tf.org/html/rfc5116#section-5.1.1  but apparently they are not = described generally enough.   They should read "plaintext or = associated data values".

 

=

Specifically the current = way that GCM mode is being used in JOSE is

 

Recipient #1 = authentication tag =3D GCM(Key, Recipient #1 data, nonce, plain = text)

Recipient #2 authentication tag =3D GCM(Key, = Recipient #2 data, nonce, plain text)

 

As the key, nonce and = plain text are fixed it would produce the same encrypted text value but = different authentication tags.

 

 

=

Can't do that.   Each = invocation of the encryption operation needs a distinct nonce, unless = all of the encryption operation inputs are = identical.

 

=

Many thanks for calling this out, = Jim.

 

=

David

<= div>

 

=

Jim

 

------=_NextPart_000_0068_01CE2BE6.B950B630-- From Michael.Jones@microsoft.com Thu Mar 28 19:05:34 2013 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 7677821F89D8 for ; Thu, 28 Mar 2013 19:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 fmhx5UNDbaSw for ; Thu, 28 Mar 2013 19:05:33 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0235.outbound.protection.outlook.com [207.46.163.235]) by ietfa.amsl.com (Postfix) with ESMTP id F22F421F89C3 for ; Thu, 28 Mar 2013 19:05:32 -0700 (PDT) Received: from BL2FFO11FD024.protection.gbl (10.1.15.202) by BY2FFO11HUB023.protection.gbl (10.1.14.110) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 29 Mar 2013 02:05:30 +0000 Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD024.mail.protection.outlook.com (10.173.161.103) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 29 Mar 2013 02:05:30 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.02.0318.003; Fri, 29 Mar 2013 02:05:26 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] FW: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AABzjcgAAAAvPoA== Date: Fri, 29 Mar 2013 02:05:25 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436759732D@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <006701ce2c21$65accf10$31066d30$@augustcellars.com> In-Reply-To: <006701ce2c21$65accf10$31066d30$@augustcellars.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_4E1F6AAD24975D4BA5B16804296739436759732DTK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(377454001)(189002)(66654001)(52604002)(199002)(63696002)(47446002)(80022001)(46102001)(5343635001)(5343655001)(20776003)(47736001)(44976002)(31966008)(69226001)(74502001)(4396001)(74662001)(50986001)(76482001)(16406001)(54316002)(79102001)(512954001)(55846006)(51856001)(15202345001)(49866001)(56776001)(71186001)(65816001)(77982001)(54356001)(53806001)(59766001)(33656001)(47976001)(56816002)(66066001)(16236675001)(81342001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB023; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0800C0C167 Cc: "crfg@irtf.org" Subject: Re: [jose] FW: GCM nonce reuse question 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, 29 Mar 2013 02:05:34 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436759732DTK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll plan to add text to the GCM section of JWA during the current round of= edits pointing this out. David McGrew was also going to get me some text = about constraints on GCM initialization vector values. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, March 28, 2013 7:02 PM To: jose@ietf.org Subject: [jose] FW: GCM nonce reuse question For those people not on the CFRG list - Jim From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Thursday, March 28, 2013 4:15 AM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: GCM nonce reuse question Hi Jim, From: Jim Schaad = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and= Key pairings. Do these problems apply to having a different set of auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#section-5.1.1 but apparently they are not described generally enough. = They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_4E1F6AAD24975D4BA5B16804296739436759732DTK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll plan to add= text to the GCM section of JWA during the current round of edits pointing = this out.  David McGrew was also going to get me some text about const= raints on GCM initialization vector values.

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: jose@ietf.org
Subject: [jose] FW: GCM nonce reuse question

 

For those people not o= n the CFRG list –

 

Jim<= /p>

 

 

From: David Mc= Grew (mcgrew) [mailto:mcgrew@cisco.com<= /a>]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg@irtf.org
Subject: Re: GCM nonce reuse question

 

Hi Jim,=

&n= bsp;

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

&n= bsp;

David,=

 =

In doing a write up I be= came worried about a security property of the GCM encryption mode in the wa= y that the JOSE group is currently using it.

 =

There are known problems= with not having a unique set of values for IVs and Key pairings.  Do = these problems apply to having a different set of auxiliary data as well as= the plain text?

 =

&n= bsp;

Yes. &n= bsp;The security issues are summarized in http://tools.ietf.org/html/rfc5116#section= -5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated da= ta values".

&n= bsp;

Specifically the current= way that GCM mode is being used in JOSE is

 =

Recipient #1 authenticat= ion tag =3D GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authenticat= ion tag =3D GCM(Key, Recipient #2 data, nonce, plain text)

 =

As the key, nonce and pl= ain text are fixed it would produce the same encrypted text value but diffe= rent authentication tags.

 =

&n= bsp;

Can't d= o that.   Each invocation of the encryption operation needs a distinct= nonce, unless all of the encryption operation inputs are identical.

&n= bsp;

Many th= anks for calling this out, Jim.

&n= bsp;

David

&n= bsp;

Jim

 =

--_000_4E1F6AAD24975D4BA5B16804296739436759732DTK5EX14MBXC283r_-- From Michael.Jones@microsoft.com Thu Mar 28 19:06:52 2013 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 E4EA621F89D8 for ; Thu, 28 Mar 2013 19:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] 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 HM8ecZKXZqBV for ; Thu, 28 Mar 2013 19:06:51 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0241.outbound.protection.outlook.com [207.46.163.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD4921F890D for ; Thu, 28 Mar 2013 19:06:51 -0700 (PDT) Received: from BL2FFO11FD021.protection.gbl (10.1.15.200) by BY2FFO11HUB024.protection.gbl (10.1.14.138) with Microsoft SMTP Server (TLS) id 15.0.651.3; Fri, 29 Mar 2013 02:06:48 +0000 Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD021.mail.protection.outlook.com (10.173.161.100) with Microsoft SMTP Server (TLS) id 15.0.651.3 via Frontend Transport; Fri, 29 Mar 2013 02:06:49 +0000 Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.224]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 29 Mar 2013 02:06:45 +0000 From: Mike Jones To: Jim Schaad , "jose@ietf.org" Thread-Topic: [jose] FW: GCM nonce reuse question Thread-Index: Ac4rPAw7MkpmLDvlR4e6aC3llihwKgAccr0AABzjcgAAACgWkA== Date: Fri, 29 Mar 2013 02:06:44 +0000 Message-ID: <4E1F6AAD24975D4BA5B16804296739436759736A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <006701ce2c21$65accf10$31066d30$@augustcellars.com> In-Reply-To: <006701ce2c21$65accf10$31066d30$@augustcellars.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_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(66654001)(199002)(52604002)(377454001)(79102001)(512954001)(15202345001)(55846006)(49866001)(51856001)(74662001)(50986001)(4396001)(54316002)(76482001)(16406001)(47976001)(56816002)(16236675001)(81342001)(66066001)(65816001)(77982001)(56776001)(71186001)(59766001)(33656001)(54356001)(53806001)(80022001)(5343655001)(46102001)(5343635001)(63696002)(47446002)(69226001)(74502001)(20776003)(44976002)(47736001)(31966008); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB024; H:TK5EX14HUBC107.redmond.corp.microsoft.com; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0800C0C167 Cc: "cfrg@irtf.org" Subject: Re: [jose] FW: GCM nonce reuse question 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, 29 Mar 2013 02:06:53 -0000 --_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'll plan to add text to the GCM section of JWA during the current round of= edits pointing this out. David McGrew was also going to get me some text = about constraints on GCM initialization vector values. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim= Schaad Sent: Thursday, March 28, 2013 7:02 PM To: jose@ietf.org Subject: [jose] FW: GCM nonce reuse question For those people not on the CFRG list - Jim From: David McGrew (mcgrew) [mailto:mcgrew@cisco.com] Sent: Thursday, March 28, 2013 4:15 AM To: Jim Schaad Cc: cfrg@irtf.org Subject: Re: GCM nonce reuse question Hi Jim, From: Jim Schaad = > Date: Wednesday, March 27, 2013 6:43 PM To: David McGrew > Cc: "cfrg@irtf.org" > Subject: GCM nonce reuse question David, In doing a write up I became worried about a security property of the GCM e= ncryption mode in the way that the JOSE group is currently using it. There are known problems with not having a unique set of values for IVs and= Key pairings. Do these problems apply to having a different set of auxili= ary data as well as the plain text? Yes. The security issues are summarized in http://tools.ietf.org/html/rfc5= 116#section-5.1.1 but apparently they are not described generally enough. = They should read "plaintext or associated data values". Specifically the current way that GCM mode is being used in JOSE is Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, plai= n text) Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, plai= n text) As the key, nonce and plain text are fixed it would produce the same encryp= ted text value but different authentication tags. Can't do that. Each invocation of the encryption operation needs a distin= ct nonce, unless all of the encryption operation inputs are identical. Many thanks for calling this out, Jim. David Jim --_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’ll plan to add= text to the GCM section of JWA during the current round of edits pointing = this out.  David McGrew was also going to get me some text about const= raints on GCM initialization vector values.

 

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

 

From: jose-bou= nces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: jose@ietf.org
Subject: [jose] FW: GCM nonce reuse question

 

For those people not o= n the CFRG list –

 

Jim<= /p>

 

 

From: David Mc= Grew (mcgrew) [mailto:mcgrew@cisco.com<= /a>]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg@irtf.org
Subject: Re: GCM nonce reuse question

 

Hi Jim,=

&n= bsp;

From: Jim Schaad <jimsch@augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisc= o.com>
Cc: "cfrg@irtf.org" &= lt;cfrg@irtf.org>
Subject: GCM nonce reuse question

&n= bsp;

David,=

 =

In doing a write up I be= came worried about a security property of the GCM encryption mode in the wa= y that the JOSE group is currently using it.

 =

There are known problems= with not having a unique set of values for IVs and Key pairings.  Do = these problems apply to having a different set of auxiliary data as well as= the plain text?

 =

&n= bsp;

Yes. &n= bsp;The security issues are summarized in http://tools.ietf.org/html/rfc5116#section= -5.1.1  but apparently they are not described generally enough.   They should read "plaintext or associated da= ta values".

&n= bsp;

Specifically the current= way that GCM mode is being used in JOSE is

 =

Recipient #1 authenticat= ion tag =3D GCM(Key, Recipient #1 data, nonce, plain text)

Recipient #2 authenticat= ion tag =3D GCM(Key, Recipient #2 data, nonce, plain text)

 =

As the key, nonce and pl= ain text are fixed it would produce the same encrypted text value but diffe= rent authentication tags.

 =

&n= bsp;

Can't d= o that.   Each invocation of the encryption operation needs a distinct= nonce, unless all of the encryption operation inputs are identical.

&n= bsp;

Many th= anks for calling this out, Jim.

&n= bsp;

David

&n= bsp;

Jim

 =

--_000_4E1F6AAD24975D4BA5B16804296739436759736ATK5EX14MBXC283r_-- From ietf@augustcellars.com Thu Mar 28 19:14:26 2013 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 F183021F8A84 for ; Thu, 28 Mar 2013 19:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 O8u-PfjRnO1J for ; Thu, 28 Mar 2013 19:14:25 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 3367021F89C3 for ; Thu, 28 Mar 2013 19:14:25 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EAF712CA20; Thu, 28 Mar 2013 19:14:24 -0700 (PDT) From: "Jim Schaad" To: "'Mike Jones'" , References: <006801ce2b39$52595700$f70c0500$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: <4E1F6AAD24975D4BA5B168042967394367590C2F@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 28 Mar 2013 19:13:48 -0700 Message-ID: <006d01ce2c23$0cd29d50$2677d7f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLvMnkknFYcqiiltjjBmV7CFJpF2gGCRpdslm3OPRA= Content-Language: en-us Subject: Re: [jose] Use of AES-HMAC algorithm 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, 29 Mar 2013 02:14:26 -0000 Sorry for the delayed response - my mail server was not delivering mail since I updated a certificate. > -----Original Message----- > From: Mike Jones [mailto:Michael.Jones@microsoft.com] > Sent: Wednesday, March 27, 2013 5:21 PM > To: Jim Schaad; jose@ietf.org > Subject: RE: [jose] Use of AES-HMAC algorithm > > Per your point 1, I don't think anyone was advocating doubling the key size. The > proposal in John's slides for issue #3 > (http://trac.tools.ietf.org/wg/jose/trac/ticket/3) was to use a CMK that is the > concatenation of the AES-CBC and HMAC-SHA-2 keys, as draft-mcgrew-aead- > aes-hmac-sha2 does. For instance, when using A128CBC with HS256, the key > size would be 384 bits and when using A256CBC with HS512, the key size would > be 768 bits. This would multiply the current key sizes by 1.5, with the > compensating benefit being the elimination of the use of the KDF. Doubling was indeed a poor choice of words - but I think you are understanding things. We are going to go from a 256 bit key to a 768 bit key - that is actually a tripling of size for the A256CBC + HS512. > > Your point 2 wasn't part of issue #3. This seems like an unnecessary change, > particularly for GCM, where the IV is specified as a separate value from the > ciphertext. > > Your point 3 wasn't part of issue #3. This seems like an unnecessary change, > particularly for GCM, where the Authentication Tag is specified as a separate > value from the ciphertext. > > Per your point 4, after a conversation initiated by Joe Hildebrand and a call > scheduled by Matt Miller, David McGrew has agreed refactor his draft so that > the inputs and outputs are specified separately and independently from the RFC > 5116 encoding of those values. While RFC 5116 specifies a binary serialization > for authenticated encryption algorithms, JWE specifies a textual serialization. > This refactoring would make it easy for JOSE to use the McGrew draft, since > the computation would be specified separately from the serialization, should > the working group choose to do so. > > I suspect that once the refactoring is done, should the working group choose to > use the McGrew algorithm, JWA could reference the appropriate sections of > draft-mcgrew-aead-aes-hmac-sha2 and JWE could include an example > computation for this algorithm, making it easy for developers to build. > > Per your point 5, I think the term "key wrapping" is being used for two different > things: (1) Encrypting the ephemeral symmetric Content Master Key for a JWE > and (2) encrypting a JWK or JWK Set containing symmetric and/or private key > information and potentially other key attributes, enabling the encrypted JWK or > JWK Set to be safely stored or transported. It think it would clarify the > discussions to keep these operations distinct. I don't think anyone is proposing > using AES-GCM or A128CBC+HS256 for (1), whereas they can already be used > as part of (2) if the JWK is encrypted in a JWE, per Matt's draft. Given the > opinions voiced at the CFRG meeting that it's fine to use approved > authenticated encryption algorithms to encrypt keys, I believe that there's > already no problem with using these algorithms for (2). I was actually looking at the case of wrapping the CMK and not wrapping content when I wrote point 5. Jim > > -- Mike > > -----Original Message----- > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Jim > Schaad > Sent: Wednesday, March 27, 2013 3:21 PM > To: jose@ietf.org > Subject: [jose] Use of AES-HMAC algorithm > > > After spending time looking at and thinking about how to resolve this issue > since I was unable to do so at the last F2F meeting. I have come up with the > following set of issues that might need to be addressed as part of resolving this > issue. > > 1. Do we change from using KDC to having a double size key for the algorithm? > I think that there is probably a consensus that this should be done. > > 2. Should IVs be prepended to the encrypted body as part of the encoding > steps? If so then this change should be universal. > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > > 3. Should Authentication Tags be appended to the encrypted body as part of the > encoding steps? > > Doing so would eliminate one field from all of the encoding formats which > should be considered a plus. > Doing so would force code writers to understand how large the IV is for all > algorithms as the IV would no longer be a separate item. > Doing so would force a re-organization for the multiple recipient case as either > all recipient specific data would need to be excluded from the authentication > step or all of the recipient data would need to be included for by all recipients. > Changing how the recipient info is process is going to give a performance > benefit for sending encrypted items for multiple recipients. > The current strategy of a single IV and key pair with AES-GCM and different > authentication data needs to have CFRG look at it. I am worried that it might > be a serious security flaw. > > 4. Should we reference the McGrew draft and provide text on how things are > changed or should we "copy" the draft into our text? > > 5. If we allow for the use of AES-GCM or AES-HMAC for doing key wrapping, > does this change how we think about any of the above questions? > > Allowing for AES-GCM for key wrapping has a benefit for hardware situations > as only the encrypt and not the decrypt functions need to be placed in > hardware. However allowing for this key wrapping give a problem as there is > no way to encode the three fields into the encrypted value unless with use > either a JSON structure in this location or we do use the single appended binary > output stream. The first approach leads to an expansion of the field by double > base64 encoding which is highly undesirable. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose From ietf@augustcellars.com Thu Mar 28 19:17:50 2013 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 32F5521F8DDD for ; Thu, 28 Mar 2013 19:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.565 X-Spam-Level: X-Spam-Status: No, score=-3.565 tagged_above=-999 required=5 tests=[AWL=0.033, 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 jN1JSPkhP2hX for ; Thu, 28 Mar 2013 19:17:49 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id E77E021F8DD6 for ; Thu, 28 Mar 2013 19:17:48 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 22B4138EA6; Thu, 28 Mar 2013 19:17:48 -0700 (PDT) From: "Jim Schaad" To: "'Nat Sakimura'" , "'Mike Jones'" References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> <4E1F6AAD24975D4BA5B168042967394367596FA1@TK5EX14MBXC283.redmond.corp.microsoft.com> In-Reply-To: Date: Thu, 28 Mar 2013 19:17:11 -0700 Message-ID: <007201ce2c23$85e86300$91b92900$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0073_01CE2BE8.D98C7130" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIVtGiZD+ejgU/m+d7nyMc0S6wm1wJ0lMGoARrkAtcCJZAoeZf/NdpA Content-Language: en-us Cc: jose@ietf.org Subject: Re: [jose] Consensus calls 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, 29 Mar 2013 02:17:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0073_01CE2BE8.D98C7130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Yes _ I was referring to the current one serialization drafts. Sorry for not being more explicit. From: Nat Sakimura [mailto:sakimura@gmail.com] Sent: Thursday, March 28, 2013 5:31 PM To: Mike Jones Cc: Jim Schaad; jose@ietf.org Subject: Re: [jose] Consensus calls That's what I thought, but wanted to be sure, especially for the people who was not at the F2F. 2013/3/29 Mike Jones I would be highly surprised if Jim meant anything except http://tools.ietf.org/html/draft-jones-jose-jws-json-serialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-serialization-04 for item 3 - especially since were the drafts referenced in your presentation at IETF 86. -- Mike From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, March 28, 2013 5:17 PM To: Jim Schaad Cc: jose@ietf.org Subject: Re: [jose] Consensus calls HI. Could you please specify which drafts for item 3? Nat 2013/3/28 Jim Schaad The following "decisions" were made at the face to face meeting. This message is to ratify these decisions on the list. You have one week to object and provide a solid defense of your objection or the actions will be considered as adopted. Note that for some of these we are running slightly ahead of our charter changes but this is not expected to be a problem 1. Adopt the proposed compromise language from John Bradley's presentation dealing with the critical language. This is to adopt points 1, 2, 3 and 4 but not point 5. (presentation is available on the materials website http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). 2. The private fields of public/private key algorithms and the symmetric key field are to be folded into the mail JWA draft. 3. The multiple recipient/signer serialization drafts are to be folded into the JWE and JWS drafts respectively. Jim _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en ------=_NextPart_000_0073_01CE2BE8.D98C7130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes _ I was referring to the current one serialization drafts.  = Sorry for not being more explicit.

 

From:= = Nat Sakimura [mailto:sakimura@gmail.com]
Sent: Thursday, = March 28, 2013 5:31 PM
To: Mike Jones
Cc: Jim = Schaad; jose@ietf.org
Subject: Re: [jose] Consensus = calls

 

That's = what I thought, but wanted to be sure, especially for the people who was = not at the F2F. 

 

2013/3/29 Mike Jones <Michael.Jones@microsoft.com>

=

I would be highly surprised if Jim meant anything except http://tools.ietf.org/html/draft-jones-jose-jws-json-se= rialization-04 and http://tools.ietf.org/html/draft-jones-jose-jwe-json-se= rialization-04 for item 3 - especially since were the drafts = referenced in your presentation at IETF 86.

 

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

 

From:= = jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of Nat = Sakimura
Sent: Thursday, March 28, 2013 5:17 PM
To: = Jim Schaad
Cc: jose@ietf.org
Subject: Re: [jose] = Consensus calls

 <= /o:p>

HI. 

 <= /o:p>

Could you = please specify which drafts for item = 3? 

 <= /o:p>

Nat

=

2013/3/28 = Jim Schaad <ietf@augustcellars.com>

<chair>= ;

The following "decisions" were made at the face to = face meeting.  This
message is to ratify these decisions on the = list.  You have one week to
object and provide a solid defense = of your objection or the actions will be
considered as adopted. =  Note that for some of these we are running slightly
ahead of = our charter changes but this is not expected to be a problem

1. =  Adopt the proposed compromise language from John Bradley's = presentation
dealing with the critical language.  This is to = adopt points 1, 2, 3 and 4
but not point 5.  (presentation is = available on the materials website
http://www.ietf.org/proceedings/86/slides/slides-86-jos= e-4.pdf).

2.  The private fields of public/private key = algorithms and the symmetric
key field are to be folded into the mail = JWA draft.

3. The multiple recipient/signer serialization drafts = are to be folded into
the JWE and JWS drafts = respectively.

Jim


_____________________________________= __________
jose mailing list
jose@ietf.org
https://www.ietf.org/mailman/listinfo/jose



 <= /o:p>

--
Nat = Sakimura (=3Dnat)

Chairman, = OpenID Foundation
http://nat.sakimura.org/
@_nat_en

=



 

-- =
Nat Sakimura (=3Dnat)

Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en

=
------=_NextPart_000_0073_01CE2BE8.D98C7130-- From rlb@ipv.sx Thu Mar 28 19:54:26 2013 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 2100521F8735 for ; Thu, 28 Mar 2013 19:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, 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 FHIFjkNd1JJQ for ; Thu, 28 Mar 2013 19:54:25 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3721F872E for ; Thu, 28 Mar 2013 19:54:25 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id n1so136806oag.37 for ; Thu, 28 Mar 2013 19:54:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=jkvA8SZLE1moegxTeF2QV7xA5iPyZhaitcSMNKhQsf0=; b=QsoAMrWngLjpTYOo4rObZFpjsp8IoC6oaSTeOFmykSCWIDtu6ZK43kEPY53CQrfm+T NUdpQzUfhU3lL7UbNZvjJnZ7wfOXGQ8uJk4D366btO/xe9TMloyswoHdoYKEgOfXD+0w JKIxvhiaKk6NEu3785wpvLBNDgaCP7TsRHHZEUr60Johbdob/RivD5BcAr/Sam/uMXe/ dsPSWK6UehWWHhNsNbVSmuReqlq/6r0WOWyTl4wEQ8aA1Fm3VIe8xbiL7Cy3YELERPVE gx2I4HwMZBiWVMmFue6/c/adHWOAj4fJVk6JLyobtZkDdQ7mDRTmFaJI60ad65xogXlA ol7Q== MIME-Version: 1.0 X-Received: by 10.60.3.71 with SMTP id a7mr336354oea.35.1364525664608; Thu, 28 Mar 2013 19:54:24 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Thu, 28 Mar 2013 19:54:24 -0700 (PDT) X-Originating-IP: [128.89.254.209] In-Reply-To: <4E1F6AAD24975D4BA5B16804296739436759736A@TK5EX14MBXC283.redmond.corp.microsoft.com> References: <006a01ce2b3c$8f0d03b0$ad270b10$@augustcellars.com> <747787E65E3FBD4E93F0EB2F14DB556B183EF2E3@xmb-rcd-x04.cisco.com> <006701ce2c21$65accf10$31066d30$@augustcellars.com> <4E1F6AAD24975D4BA5B16804296739436759736A@TK5EX14MBXC283.redmond.corp.microsoft.com> Date: Thu, 28 Mar 2013 22:54:24 -0400 Message-ID: From: Richard Barnes To: Mike Jones Content-Type: multipart/alternative; boundary=e89a8f839d51870c4804d90763a7 X-Gm-Message-State: ALoCoQkRfzBDDcBwb2XGCQKJajfk2t8xl+2XyCbwBgCxr5CNvkxtmbBU04ES2RIeZJNQUDASqYU8 Cc: Jim Schaad , cfrg@irtf.org, "jose@ietf.org" Subject: Re: [jose] FW: GCM nonce reuse question 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, 29 Mar 2013 02:54:26 -0000 --e89a8f839d51870c4804d90763a7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [trimmed CFRG, since we're talking about JOSE now] Out of curiosity, what text are you planning to add? As I read David's response, he is saying that GCM is unusable with multiple recipients, because multiple header values are fed into GCM with the same nonce. Outlawing GCM is not an acceptable outcome. Instead, we should fix the underlying issue. Namely, we should make the header value the same for all recipients. Or, even better, remove the header from the AAD field. Imagine a world in which the JOSE header is not input as AAD to GCM (i.e., it receives no integrity protection). Instead, we provide an actual "AAD field" that contains the value for that field in the AEAD computation: OLD: header.key.iv.ciphertext.mac NEW: header.key.iv.aad.ciphertext.mac That world is simpler to write code for (since you don't have to keep the encoded header around), supports more applications (since you can actually use the AAD field), and the problems with GCM do not exist. Let's create that world! --Richard On Thu, Mar 28, 2013 at 10:06 PM, Mike Jones w= rote: > I=92ll plan to add text to the GCM section of JWA during the current rou= nd > of edits pointing this out. David McGrew was also going to get me some > text about constraints on GCM initialization vector values.**** > > ** ** > > -- Mike**** > > ** ** > > *From:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] *On Behalf > Of *Jim Schaad > *Sent:* Thursday, March 28, 2013 7:02 PM > *To:* jose@ietf.org > *Subject:* [jose] FW: GCM nonce reuse question**** > > ** ** > > For those people not on the CFRG list =96**** > > ** ** > > Jim**** > > ** ** > > ** ** > > *From:* David McGrew (mcgrew) [mailto:mcgrew@cisco.com = ] > > *Sent:* Thursday, March 28, 2013 4:15 AM > *To:* Jim Schaad > *Cc:* cfrg@irtf.org > *Subject:* Re: GCM nonce reuse question**** > > ** ** > > Hi Jim,**** > > ** ** > > *From: *Jim Schaad > *Date: *Wednesday, March 27, 2013 6:43 PM > *To: *David McGrew > *Cc: *"cfrg@irtf.org" > *Subject: *GCM nonce reuse question**** > > ** ** > > David,**** > > **** > > In doing a write up I became worried about a security property of the GCM > encryption mode in the way that the JOSE group is currently using it.**** > > **** > > There are known problems with not having a unique set of values for IVs > and Key pairings. Do these problems apply to having a different set of > auxiliary data as well as the plain text?**** > > **** > > ** ** > > Yes. The security issues are summarized in > http://tools.ietf.org/html/rfc5116#section-5.1.1 but apparently they are > not described generally enough. They should read "plaintext or associat= ed > data values".**** > > ** ** > > Specifically the current way that GCM mode is being used in JOSE is**** > > **** > > Recipient #1 authentication tag =3D GCM(Key, Recipient #1 data, nonce, pl= ain > text)**** > > Recipient #2 authentication tag =3D GCM(Key, Recipient #2 data, nonce, pl= ain > text)**** > > **** > > As the key, nonce and plain text are fixed it would produce the same > encrypted text value but different authentication tags.**** > > **** > > ** ** > > Can't do that. Each invocation of the encryption operation needs a > distinct nonce, unless all of the encryption operation inputs are identic= al. > **** > > ** ** > > Many thanks for calling this out, Jim.**** > > ** ** > > David**** > > ** ** > > Jim**** > > **** > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > --e89a8f839d51870c4804d90763a7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable [trimmed CFRG, since we're talking about JOSE now]

<= div>Out of curiosity, what text are you planning to add?

As I read David's response, he is saying that GCM is unusable wi= th multiple recipients, because multiple header values are fed into GCM wit= h the same nonce.=A0

Outlawing GCM is not an acceptable outcome.
<= br>
Instead, we should fix the underlying issue. =A0Namely, we sh= ould make the header value the same for all recipients. =A0Or, even better,= remove the header from the AAD field.

Imagine a world in which the JOSE header is not input a= s AAD to GCM (i.e., it receives no integrity protection). =A0Instead, we pr= ovide an actual "AAD field" that contains the value for that fiel= d in the AEAD computation:

OLD: header.key.iv.ciphertext.mac
NEW: header= .key.iv.aad.ciphertext.mac

That world is simpler t= o write code for (since you don't have to keep the encoded header aroun= d), supports more applications (since you can actually use the AAD field), = and the problems with GCM do not exist. =A0Let's create that world!

--Richard=A0



On Thu, Mar 28, 2013 at 10:06 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

I=92ll plan to add tex= t to the GCM section of JWA during the current round of edits pointing this= out.=A0 David McGrew was also going to get me some text about constraints = on GCM initialization vector values.

=A0

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0 -- Mike

=A0

From: jose-bounces@ietf.org [mailto:jose-= bounces@ietf.org] On Behalf Of Jim Schaad
Sent: Thursday, March 28, 2013 7:02 PM
To: jose@ietf.org=
Subject: [jose] FW: GCM nonce reuse question

=A0

For those people= not on the CFRG list =96

=A0

Jim

=A0

=A0

From: David Mc= Grew (mcgrew) [mailto= :mcgrew@cisco.com]
Sent: Thursday, March 28, 2013 4:15 AM
To: Jim Schaad
Cc: cfrg@irtf.org=
Subject: Re: GCM nonce reuse question

=A0

Hi Jim,

=A0

From: Jim Scha= ad <jimsch= @augustcellars.com>
Date: Wednesday, March 27, 2013 6:43 PM
To: David McGrew <mcgrew@cisco.com>
Cc: "cfrg@ir= tf.org" <cfr= g@irtf.org>
Subject: GCM nonce reuse question

=A0

David,

=A0

In doing a write up I became worried abo= ut a security property of the GCM encryption mode in the way that the JOSE = group is currently using it.

=A0

There are known problems with not having= a unique set of values for IVs and Key pairings.=A0 Do these problems appl= y to having a different set of auxiliary data as well as the plain text?=

=A0

=A0

Yes. =A0The securit= y issues are summarized in=A0http://tools.ietf.org/html/rfc5116#section= -5.1.1=A0 but apparently they are not described generally enough. =A0 They should read "plaintext or associated data = values".

=A0

Specifically the current way that GCM mo= de is being used in JOSE is

=A0

Recipient #1 authentication tag =3D GCM(= Key, Recipient #1 data, nonce, plain text)

Recipient #2 authentication tag =3D GCM(= Key, Recipient #2 data, nonce, plain text)

=A0

As the key, nonce and plain text are fix= ed it would produce the same encrypted text value but different authenticat= ion tags.

=A0

=A0

Can't do that. = =A0 Each invocation of the encryption operation needs a distinct nonce, unl= ess all of the encryption operation inputs are identical.

=A0

Many thanks for cal= ling this out, Jim.

=A0

David=

=A0

Jim

=A0


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose


--e89a8f839d51870c4804d90763a7-- From rlb@ipv.sx Thu Mar 28 19:55:48 2013 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 69FA921F8739 for ; Thu, 28 Mar 2013 19:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.258 X-Spam-Level: X-Spam-Status: No, score=-1.258 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 WqYqa8z6xsPn for ; Thu, 28 Mar 2013 19:55:47 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id C6F2921F872E for ; Thu, 28 Mar 2013 19:55:47 -0700 (PDT) Received: by mail-ob0-f178.google.com with SMTP id wd20so132342obb.37 for ; Thu, 28 Mar 2013 19:55:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=e2q0ESfs2SpXGoIUHQoiakjoHtBRwbHnwyAQ0q5HnGE=; b=WR7e/4RyPhm6eL9pMsT2uMjOoUIPe21Wx69vZ3LP2kAu09tK7zO1PZDfqszvL8Px4g V0Fx2xamyDM2c00PSsJsN39XwRpmYQEra4yHXjY8YVWYqW+zoxtIyMl/NNyVjIIufUm8 l0jFvgq2xBSyBzJCY1LcXNyHRpYqhy49FqPTVuDCMzK/1riGVe8ydTURB9lCkMGkqpNj bnNIL27DqlnkXvbpmT6j+yujfvKlAFNdIGjo9h870q4lEwQrpXzIlxaXefDd8S4JLAu/ Ka1yMQ1W3Xadvt4ZtHoH0CakRj7ZFb9H83WgCiUnqWg1cLDgX/sNxDGfWw1JFiDce8Y4 6VGQ== MIME-Version: 1.0 X-Received: by 10.182.97.5 with SMTP id dw5mr298671obb.91.1364525745072; Thu, 28 Mar 2013 19:55:45 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Thu, 28 Mar 2013 19:55:44 -0700 (PDT) X-Originating-IP: [128.89.254.209] In-Reply-To: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> References: <006901ce2b39$e7ee2fc0$b7ca8f40$@augustcellars.com> Date: Thu, 28 Mar 2013 22:55:44 -0400 Message-ID: From: Richard Barnes To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7b2e41b852e2cf04d9076806 X-Gm-Message-State: ALoCoQmHmizEO8Yv+cZAhmDLdspvqImUf/v1tv7R7tZBsIIEJkuxmN0+9CVh900VdcG51+0rsXiN Cc: jose@ietf.org Subject: Re: [jose] Consensus calls 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, 29 Mar 2013 02:55:48 -0000 --047d7b2e41b852e2cf04d9076806 Content-Type: text/plain; charset=ISO-8859-1 Big +1 from me on all 3. --Richard On Wed, Mar 27, 2013 at 6:24 PM, Jim Schaad wrote: > > > The following "decisions" were made at the face to face meeting. This > message is to ratify these decisions on the list. You have one week to > object and provide a solid defense of your objection or the actions will be > considered as adopted. Note that for some of these we are running slightly > ahead of our charter changes but this is not expected to be a problem > > 1. Adopt the proposed compromise language from John Bradley's presentation > dealing with the critical language. This is to adopt points 1, 2, 3 and 4 > but not point 5. (presentation is available on the materials website > http://www.ietf.org/proceedings/86/slides/slides-86-jose-4.pdf). > > 2. The private fields of public/private key algorithms and the symmetric > key field are to be folded into the mail JWA draft. > > 3. The multiple recipient/signer serialization drafts are to be folded into > the JWE and JWS drafts respectively. > > Jim > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > --047d7b2e41b852e2cf04d9076806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Big +1 from me on all 3.
--Richard


On Wed, Mar 27, 2013 at 6:24 PM, Jim Schaad <= ietf@augustcell= ars.com> wrote:
<chair>

The following "decisions" were made at the face to face meeting. = =A0This
message is to ratify these decisions on the list. =A0You have one week to object and provide a solid defense of your objection or the actions will be=
considered as adopted. =A0Note that for some of these we are running slight= ly
ahead of our charter changes but this is not expected to be a problem

1. =A0Adopt the proposed compromise language from John Bradley's presen= tation
dealing with the critical language. =A0This is to adopt points 1, 2, 3 and = 4
but not point 5. =A0(presentation is available on the materials website
http://www.ietf.org/proceedings/86/slides/slides-86-jose-= 4.pdf).

2. =A0The private fields of public/private key algorithms and the symmetric=
key field are to be folded into the mail JWA draft.

3. The multiple recipient/signer serialization drafts are to be folded into=
the JWE and JWS drafts respectively.

Jim


_______________________________________________
jose mailing list
jose@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/jose

--047d7b2e41b852e2cf04d9076806-- From trac+jose@trac.tools.ietf.org Sat Mar 30 12:40:41 2013 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 5F16821F84CE for ; Sat, 30 Mar 2013 12:40:41 -0700 (PDT) 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 Cu0N4Sxq7cHz for ; Sat, 30 Mar 2013 12:40:40 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8E58221F8498 for ; Sat, 30 Mar 2013 12:40:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:39539 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM1dd-0001XJ-1m; Sat, 30 Mar 2013 20:40:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 19:40:28 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/jose/trac/ticket/3#comment:2 Message-ID: <069.39abc719fa845205ea2eb8adb81c9412@trac.tools.ietf.org> References: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <054.a15803fd3572518a930ea29172e37e67@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330194040.8E58221F8498@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 12:40:37 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #3: Concat used outside of key agreement X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:40:41 -0000 #3: Concat used outside of key agreement Comment (by michael.jones@microsoft.com): After a conversation initiated by Joe Hildebrand and a call scheduled by Matt Miller, David McGrew has agreed refactor draft-mcgrew-aead-aes-hmac- sha2 so that the inputs and outputs are specified separately and independently from the RFC 5116 encoding of those values, as documented in the minutes at http://www.ietf.org/mail- archive/web/jose/current/msg01884.html. While RFC 5116 specifies a binary serialization for authenticated encryption algorithms, JWE specifies a textual serialization. This refactoring would make it easy for JOSE to use the McGrew draft, since the computation would be specified separately from the serialization, should the working group choose to do so. JWA could then reference the appropriate sections of draft-mcgrew-aead- aes-hmac-sha2 and JWE could include an example computation for this algorithm, making it easy for developers to build. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 12:42:03 2013 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 BF0BF21F84D1 for ; Sat, 30 Mar 2013 12:42:03 -0700 (PDT) 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 ahOqchPirEgT for ; Sat, 30 Mar 2013 12:42:03 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F080C21F84CE for ; Sat, 30 Mar 2013 12:42:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:39555 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM1ev-0000JA-Rg; Sat, 30 Mar 2013 20:41:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 19:41:49 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/11#comment:1 Message-ID: <069.ff0d071ed5ab3c1ea6999a72c382d0ea@trac.tools.ietf.org> References: <054.e72d4c43dc02c0b9f61660ef223433e1@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <054.e72d4c43dc02c0b9f61660ef223433e1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330194202.F080C21F84CE@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 12:42:02 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #11: Use RFC 5116 and remove MAC field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 19:42:03 -0000 #11: Use RFC 5116 and remove MAC field Comment (by michael.jones@microsoft.com): After a conversation initiated by Joe Hildebrand and a call scheduled by Matt Miller, David McGrew? has agreed refactor draft-mcgrew-aead-aes-hmac- sha2 so that the inputs and outputs are specified separately and independently from the RFC 5116 encoding of those values, as documented in the minutes at ​http://www.ietf.org/mail- archive/web/jose/current/msg01884.html. While RFC 5116 specifies a binary serialization for authenticated encryption algorithms, JWE specifies a textual serialization. This refactoring would make it easy for JOSE to use the McGrew? draft, since the computation would be specified separately from the serialization, should the working group choose to do so. JWA could then reference the appropriate sections of draft-mcgrew-aead- aes-hmac-sha2 and JWE could include an example computation for this algorithm, making it easy for developers to build. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 13:08:17 2013 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 5E43821F8696 for ; Sat, 30 Mar 2013 13:08:17 -0700 (PDT) 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=[AWL=0.000, 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 LqGn6ATFA1hR for ; Sat, 30 Mar 2013 13:08:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A702521F855A for ; Sat, 30 Mar 2013 13:08:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:41015 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM24O-00033i-CY; Sat, 30 Mar 2013 21:08:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 20:08:08 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/jose/trac/ticket/5#comment:2 Message-ID: <069.e4c859bcb852cb3d210ccc1f033d3028@trac.tools.ietf.org> References: <054.f240878e1815afe10f9256d1163853c9@trac.tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <054.f240878e1815afe10f9256d1163853c9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330200816.A702521F855A@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 13:08:16 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #5: Unclear instructions for key management X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:08:17 -0000 #5: Unclear instructions for key management Comment (by michael.jones@microsoft.com): I plan to address these clarifications as part of the edits incorporating the agreed upon "must understand" issue resolution. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 13:10:29 2013 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 42B4C21F8507 for ; Sat, 30 Mar 2013 13:10:29 -0700 (PDT) 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 X++u1v0zWFKm for ; Sat, 30 Mar 2013 13:10:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8AB21F8484 for ; Sat, 30 Mar 2013 13:10:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:41089 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM26a-0004Qk-Lj; Sat, 30 Mar 2013 21:10:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 20:10:24 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/jose/trac/ticket/6#comment:1 Message-ID: <069.8c519f4d0a5b1c367aa8ce3973b07ad7@trac.tools.ietf.org> References: <054.162afb78c358483db55af2b36ee8f61d@trac.tools.ietf.org> X-Trac-Ticket-ID: 6 In-Reply-To: <054.162afb78c358483db55af2b36ee8f61d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330201028.3D8AB21F8484@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 13:10:28 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #6: Unclear requirements levels on fields X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:10:29 -0000 #6: Unclear requirements levels on fields Comment (by michael.jones@microsoft.com): I plan to address these clarifications as part of the edits incorporating the agreed upon "must understand" issue resolution. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web- | Version: encryption | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 13:29:14 2013 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 5E15D21F86D6 for ; Sat, 30 Mar 2013 13:29:14 -0700 (PDT) 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=[AWL=0.000, 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 NbfsaUlUytj3 for ; Sat, 30 Mar 2013 13:29:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8E221F8651 for ; Sat, 30 Mar 2013 13:29:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:41608 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM2Ob-0003yU-BC; Sat, 30 Mar 2013 21:29:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-signature@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 20:29:01 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/9#comment:2 Message-ID: <069.5836d8aad3eede22b7de8eb8998b985c@trac.tools.ietf.org> References: <054.4f35581a87ca4998a14bdcf1846560d1@trac.tools.ietf.org> X-Trac-Ticket-ID: 9 In-Reply-To: <054.4f35581a87ca4998a14bdcf1846560d1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-signature@tools.ietf.org, sakimura@gmail.com, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com, n-sakimura@nri.co.jp, ve7jtb@ve7jtb.com Resent-Message-Id: <20130330202913.9B8E221F8651@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 13:29:13 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #9: Add "spi" field X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:29:14 -0000 #9: Add "spi" field Comment (by michael.jones@microsoft.com): FYI, this proposal has now been written up as draft-barnes-jose-spi-00. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | signature@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: json-web- | Version: signature | Resolution: Severity: Active WG | Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 13:46:00 2013 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 8B99D21F86BB for ; Sat, 30 Mar 2013 13:46:00 -0700 (PDT) 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=[AWL=0.000, 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 RO2Llxyx7nSw for ; Sat, 30 Mar 2013 13:46:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E8A4F21F86AF for ; Sat, 30 Mar 2013 13:45:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:42122 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM2ex-0002gm-QH; Sat, 30 Mar 2013 21:45:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 20:45:55 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/10#comment:1 Message-ID: <069.69926f15d027e812e1fcdda301d1c9a2@trac.tools.ietf.org> References: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-Trac-Ticket-ID: 10 In-Reply-To: <054.b5192313ecd5b8e4a95a25cae11a5ca9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-algorithms@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130330204559.E8A4F21F86AF@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 13:45:59 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #10: Remove implementation requirements X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 20:46:00 -0000 #10: Remove implementation requirements Comment (by michael.jones@microsoft.com): Based upon recent IESG feedback to the OAuth working group, the IESG does appear to continue to want specifications to include sufficient mandatory- to-implement (MTI) features to facilitate interoperability. Also, as our area directors have pointed out, people should bear in mind that mandatory-to-implement is not the same thing as mandatory-to-use. Finally, our charter currently requires us to define mandatory-to- implement (MTI) algorithms. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- rbarnes@bbn.com | algorithms@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: algorithms | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 14:25:57 2013 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 4EA1A21F84E3 for ; Sat, 30 Mar 2013 14:25:57 -0700 (PDT) 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 jMGxTk4xCcpm for ; Sat, 30 Mar 2013 14:25:56 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id AD02521F84B8 for ; Sat, 30 Mar 2013 14:25:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:44522 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3Ha-0004FS-Ay; Sat, 30 Mar 2013 22:25:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 21:25:50 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: https://tools.ietf.org/wg/jose/trac/ticket/12#comment:3 Message-ID: <080.fec3c931ff7caa6172df3c6f437eb638@trac.tools.ietf.org> References: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <065.7762ca21750ef2a07382e66a81acadef@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, michael.jones@microsoft.com, bcampbell@pingidentity.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330212556.AD02521F84B8@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 14:25:56 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #12: x5c incorrect in JWE X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 21:25:57 -0000 #12: x5c incorrect in JWE Comment (by michael.jones@microsoft.com): For generality, I'll note that if people believe that "x5c" should be removed from JWE, then the same logic probably suggests that "x5u", "jku" should be removed, as all are ways of including or referencing public key values corresponding to the private key used to encrypt the content. And by that logic, if we don't need a way to reference or include public key values for JWEs, then the "x5t" and possibly "kid" parameters would then also be of dubious value. At least by that reasoning, the inclusion of all the key reference parameters would likely stand or fall together. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-jose-json- bcampbell@pingidentity.com | web-encryption@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: json-web-encryption | Version: Severity: Submitted WG Document | Resolution: Keywords: | -------------------------------------+------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 14:50:52 2013 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 96DEE21F860A for ; Sat, 30 Mar 2013 14:50:52 -0700 (PDT) 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 GC0Q+wppWF3U for ; Sat, 30 Mar 2013 14:50:52 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B9AA621F85FC for ; Sat, 30 Mar 2013 14:50:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:45433 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM3fh-0000B4-RF; Sat, 30 Mar 2013 22:50:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 21:50:45 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/13#comment:2 Message-ID: <064.7e556a4408d202220401ca6145738431@trac.tools.ietf.org> References: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <049.6bd4c5bdeedc5862a9b09a5b5d16aadf@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330215051.B9AA621F85FC@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 14:50:51 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #13: Enable AEAD key wrapping X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 21:50:52 -0000 #13: Enable AEAD key wrapping Comment (by michael.jones@microsoft.com): It seems to me that the term "key wrapping" is being used for two different things in discussions with the JOSE working group: (1) Encrypting the ephemeral symmetric key value used within a JWE and (2) encrypting a JWK or JWK Set containing symmetric and/or private key information and potentially other key attributes, enabling the encrypted JWK or JWK Set to be safely stored or transported. It think it would clarify the discussions to clearly distinguish between these use cases, and to consider them separately. For instance, I don't think anyone is proposing using A128GCM or A128CBC+HS256 directly for (1), whereas they can already be used as part of (2) if the JWK is encrypted in a JWE, per draft-miller-jose-jwe- protected-jwk. Given the opinions voiced at the IETF 86 CFRG meeting that it's fine to use approved authenticated encryption algorithms to encrypt keys (http://www.ietf.org/mail-archive/web/cfrg/current/msg03319.html), I believe that there's nothing additional we need to do to enable using these algorithms for (2). Finally, I believe that this issue statement would be much more useful if accompanied by a concrete proposed solution to be considered by the working group. As it is, it's not clear what specific specification changes are being requested or suggested. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 15:13:49 2013 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 3968321F8633 for ; Sat, 30 Mar 2013 15:13:49 -0700 (PDT) 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=[AWL=0.000, 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 ONMSrcPndlcV for ; Sat, 30 Mar 2013 15:13:48 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6817421F862B for ; Sat, 30 Mar 2013 15:13:48 -0700 (PDT) Received: from localhost ([127.0.0.1]:46945 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM41u-0002qN-I6; Sat, 30 Mar 2013 23:13:42 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 22:13:42 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/14#comment:2 Message-ID: <064.d3c40af21353833721175bca5772180c@trac.tools.ietf.org> References: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <049.a881241698112408b4f26b7cfb4b9103@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, rlb@ipv.sx, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330221348.6817421F862B@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 15:13:48 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #14: Support longer wrapped keys than OAEP allows X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 22:13:49 -0000 #14: Support longer wrapped keys than OAEP allows Comment (by michael.jones@microsoft.com): As pointed out by James Manger in http://www.ietf.org/mail- archive/web/jose/current/msg01853.html, "Keys for all of the algorithms fit within OAEP with a 2048-bit RSA key. JWA already says RSA key sizes MUST be at least 2048 bits. This already looks sufficient." I agree with James that I know of no use case where this limit will be hit in practice. However it could be that Richard is thinking of encrypting JWKs, rather than wrapping keys, in which case we already have a solution in the form of draft-miller-jose-jwe-protected-jwk. Also, see my comments at http://trac.tools.ietf.org/wg/jose/trac/ticket/13#comment:2 on the desirability of distinguishing between (1) Encrypting the ephemeral symmetric key value used within a JWE and (2) encrypting a JWK or JWK Set containing symmetric and/or private key information and potentially other key attributes, enabling the encrypted JWK or JWK Set to be safely stored or transported. Finally, as Matt Miller wrote in http://www.ietf.org/mail- archive/web/jose/current/msg01863.html, "Personally, I don't think it's worth discussing this much further without a more complete counter- proposal on the table." I agree that a concrete set of proposed changes would be needed to make this actionable. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: major | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 15:48:30 2013 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 5269421F8759 for ; Sat, 30 Mar 2013 15:48:30 -0700 (PDT) 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=[AWL=0.000, 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 p5rImBsQGoFz for ; Sat, 30 Mar 2013 15:48:29 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDC921F8675 for ; Sat, 30 Mar 2013 15:48:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:48587 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM4ZS-0004MU-2c; Sat, 30 Mar 2013 23:48:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx X-Trac-Project: jose Date: Sat, 30 Mar 2013 22:48:21 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/15#comment:5 Message-ID: <064.383a9035ff5dbcefff673d771be14f7a@trac.tools.ietf.org> References: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <049.dec2e6a11006261f47529bfcdfa8c51d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-encryption@tools.ietf.org, ignisvulpis@gmail.com, michael.jones@microsoft.com, rlb@ipv.sx, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: ekr@rtfm.com, jhildebr@cisco.com, mbj@microsoft.com Resent-Message-Id: <20130330224829.9BDC921F8675@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 15:48:28 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #15: At least one key indicator should be mandatory X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 22:48:30 -0000 #15: At least one key indicator should be mandatory Comment (by michael.jones@microsoft.com): In lots of OAuth deployments, the keys used are negotiated out of band and known in advance by both parties. The same is true of many other deployment scenarios. In these cases, any key indicators in the JOSE object itself would be redundant. We should not change the specifications to mandate including often unnecessary information. -- -------------------------+------------------------------------------------- Reporter: rlb@ipv.sx | Owner: draft-ietf-jose-json-web- Type: defect | encryption@tools.ietf.org Priority: minor | Status: new Component: json-web- | Milestone: encryption | Version: Severity: - | Resolution: Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From trac+jose@trac.tools.ietf.org Sat Mar 30 16:19:22 2013 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 50EF621F85A0 for ; Sat, 30 Mar 2013 16:19:22 -0700 (PDT) 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=[AWL=0.000, 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 Fic4xMO5uxVi for ; Sat, 30 Mar 2013 16:19:21 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id A87AA21F857A for ; Sat, 30 Mar 2013 16:19:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:50731 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UM53K-0000wg-UU; Sun, 31 Mar 2013 00:19:14 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "jose issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com X-Trac-Project: jose Date: Sat, 30 Mar 2013 23:19:14 -0000 X-URL: http://tools.ietf.org/jose/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/jose/trac/ticket/16#comment:1 Message-ID: <073.97f52f55118bcf1f267077e78a7fa163@trac.tools.ietf.org> References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-jose-json-web-key@tools.ietf.org, michael.jones@microsoft.com, jose@ietf.org X-SA-Exim-Mail-From: trac+jose@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mbj@microsoft.com Resent-Message-Id: <20130330231921.A87AA21F857A@ietfa.amsl.com> Resent-Date: Sat, 30 Mar 2013 16:19:20 -0700 (PDT) Resent-From: trac+jose@trac.tools.ietf.org Cc: jose@ietf.org Subject: Re: [jose] #16: URI identifying a specific key in a JWK set X-BeenThere: jose@ietf.org X-Mailman-Version: 2.1.12 List-Id: Javascript Object Signing and Encryption List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 23:19:22 -0000 #16: URI identifying a specific key in a JWK set Comment (by michael.jones@microsoft.com): First, having just a "jku" value is often sufficient to determine which key to use, as other parameters in the JWK Set such as the "use" or "alg" parameters may be used to unambiguously determine which key to use. There may also be only one key in the set. Second, we already support more than one means of disambiguating keys within JWK Sets, including using the "kty", "kid", "use", and "alg" values as inputs to this decision. And once the spec says that other fields must be ignored if not understood, I'm sure that people will use other key properties they'll invent such as ("current": true) to aid in the key selection process for their applications. I understand that the request may seem simple on the face of it, but doing this in a general way would involve more than just using a "kid" value as a fragment identifier for a "jku" value. As such, the proposal seems underspecified to me. Furthermore, if all that's being conveyed is a "jku" value and a "kid" value pair - we already have a straightforward way of doing that - include both parameters in the header. Whereas requiring implementations to support two ways of accepting the same information doesn't seem like a good cost/benefit tradeoff. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-jose-json-web- james@manger.com.au | key@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: json-web- | Version: key | Resolution: Severity: - | Keywords: | -------------------------+------------------------------------------------- Ticket URL: jose From dick.hardt@gmail.com Sat Mar 30 16:48:59 2013 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 A6F4621F872E for ; Sat, 30 Mar 2013 16:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.728 X-Spam-Level: X-Spam-Status: No, score=-2.728 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 WccRV+QjXXRy for ; Sat, 30 Mar 2013 16:48:58 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id A322421F851C for ; Sat, 30 Mar 2013 16:48:58 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id y14so711551pdi.22 for ; Sat, 30 Mar 2013 16:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=l4lkWjZWt64jRgGN5fjgQ4hg12EuePT+4MVIj2eoL70=; b=axiTJs2bvOjuFdOQ+e5mb9kwAlwDdODplBev7tYnS4HlG9GcsCwpQNQpzfbNuKXDut KKv7rHCkekNbdfOq1a+8ud1nCDbGGeM9P4vQuu8+RacSgAXqqR8JoBfsGWOlaAQqZj+g 6SzCQlTwNUTEiryd+trDLagOpAwEAkZtazf235oFUiIOCg4rYtq+WiJtPfIKi61tWN+D sBHSU8NLB6mhaoXoS5q4hfjYRuHRQT4xE1xN7z2+xK+Zb381+I4S+Gky8uhLafpAcCIk kwOHvpNXyOWcgIiaX5qONh5f3JRRU2O9tMlMyn6pXzo7YfENtPxJlVfJ9qWDOc3Sq/IX wabQ== X-Received: by 10.66.119.202 with SMTP id kw10mr11529882pab.181.1364687338257; Sat, 30 Mar 2013 16:48:58 -0700 (PDT) Received: from [10.0.0.89] (c-24-5-69-173.hsd1.ca.comcast.net. [24.5.69.173]) by mx.google.com with ESMTPS id i10sm8036915pbd.1.2013.03.30.16.48.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Mar 2013 16:48:56 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_01F41A53-9A3B-4512-A5EC-C4B5BA8ECC0C" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dick Hardt In-Reply-To: <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> Date: Sat, 30 Mar 2013 16:48:54 -0700 Message-Id: References: <058.7d398c285ac07c1a4b2f1bfd0d8b7312@trac.tools.ietf.org> <255B9BB34FB7D647A506DC292726F6E1150BE3C554@WSMSG3153V.srv.dir.telstra.com> To: "Manger, James H" X-Mailer: Apple Mail (2.1503) Cc: Brian Campbell , "jose@ietf.org" Subject: Re: [jose] #16: URI identifying a specific key in a JWK set 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, 30 Mar 2013 23:48:59 -0000 --Apple-Mail=_01F41A53-9A3B-4512-A5EC-C4B5BA8ECC0C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 A related issue is that a 'kid' may not be enough to uniquely identify = the key in symmetric systems. If a recipient (A) accepts tokens from multiple parties (B and C), and = 'kid' is managed at those parties (B and C), then there is no guarantee = that the 'kid' value will be unique at A. Knowing the issuer is required = unless you force B and C to use a URI like mechanism for 'kid' On Mar 25, 2013, at 3:46 PM, "Manger, James H" = wrote: > > I'd always just assumed that, short of some other means of figuring = it out, a kid header would accompany a jku to identify the specific key = in the set. > =20 > Indeed, =93jku=94 needs to be accompanied by =93kid=94 to work in = general =97 but this is a crappy solution. 99% of the time that a =93jku=94= is used you want to identify a single specific key so =93jku=94 should = be capable of doing that without requiring an extra field. > =20 > A JOSE header does have room for =93kid=94 as well as =93jku=94. = However, many contexts that use URIs as identifiers expect a URI to be = THE identifier. Needing two fields to do one task is inevitably awkward. > =20 > Finally, identifying 1 item from a set is a perfect match for the = whole purpose of URI fragments so merely by the principle of least = astonishment JWK should specify how the fragment picks 1 key. > =20 > -- > James Manger > =20 > From: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf = Of Brian Campbell > Sent: Monday, 25 March 2013 11:31 PM > To: jose issue tracker > Cc: draft-ietf-jose-json-web-key@tools.ietf.org; jose@ietf.org; = james@manger.com.au > Subject: Re: [jose] #16: URI identifying a specific key in a JWK set > =20 > I'd always just assumed that, short of some other means of figuring it = out, a kid header would accompany a jku to identify the specific key in = the set. > =20 >=20 > On Sun, Mar 24, 2013 at 6:40 PM, jose issue tracker = wrote: > #16: URI identifying a specific key in a JWK set >=20 > When a public key is required to process a JOSE message, providing a = URI > for the key is a useful alternative to providing the actual key or a > certificate. The URI needs to identify the specific individual public = key > required for the specific JOSE message. A URI that merely identifies = a set > of keys (one of which is the correct one) is not sufficient. >=20 > Given that a "jku" field holds a URI pointing to a set of keys, we = need to > define how to use the fragment part of those URIs to identify a = specific > key in the set. >=20 > Using the "kid" (key id) in the fragment would be a sensible choice. >=20 > -- > = -------------------------+------------------------------------------------= - > Reporter: | Owner: draft-ietf-jose-json-web- > james@manger.com.au | key@tools.ietf.org > Type: defect | Status: new > Priority: major | Milestone: > Component: json-web- | Version: > key | Keywords: > Severity: - | > = -------------------------+------------------------------------------------= - >=20 > Ticket URL: > jose >=20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > =20 > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_01F41A53-9A3B-4512-A5EC-C4B5BA8ECC0C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 A related issue is that a 'kid' = may not be enough to uniquely identify the key in symmetric = systems.

If a recipient (A) accepts tokens from = multiple parties (B and C), and 'kid' is managed at those parties (B and = C), then there is no guarantee that the 'kid' value will be unique at A. = Knowing the issuer is required unless you force B and C to use a URI = like mechanism for 'kid'

On Mar 25, = 2013, at 3:46 PM, "Manger, James H" <James.H.Manger@team.telstr= a.com> wrote:

> I'd always just assumed that, short of some = other means of figuring it out, a kid header would accompany a jku to = identify the specific key in the set.
 
Indeed, =93jku=94 needs = to be accompanied by =93kid=94 to work in general =97 but this is a = crappy solution. 99% of the time that a =93jku=94 is used you want to = identify a single specific key so =93jku=94 should be capable of doing = that without requiring an extra field.
 
A JOSE header does have = room for =93kid=94 as well as =93jku=94. However, many contexts that use = URIs as identifiers expect a URI to be THE identifier. Needing two = fields to do one task is inevitably awkward.
 
Finally, identifying 1 = item from a set is a perfect match for the whole purpose of URI = fragments so merely by the principle of least astonishment JWK should = specify how the fragment picks 1 key.
 
James Manger
 
From: jose-bounces@ietf.org = [mailto:jose-bounces@ietf.org] On Behalf Of Brian = Campbell
Sent: Monday, 25 March 2013 11:31 = PM
To: jose = issue tracker
Cc: draft-ietf-jos= e-json-web-key@tools.ietf.org; jose@ietf.org; james@manger.com.au
Subject:=  Re: [jose] #16: = URI identifying a specific key in a JWK = set
I'd always = just assumed that, short of some other means of figuring it out, a kid = header would accompany a jku to identify the specific key in the = set.

On Sun, Mar = 24, 2013 at 6:40 PM, jose issue tracker <#16: URI identifying a specific key in a JWK = set

 When a public key is required to process a JOSE = message, providing a URI
 for the key is a useful alternative to = providing the actual key or a
 certificate. The URI needs to = identify the specific individual public key
 required for the = specific JOSE message. A URI that merely identifies a set
 of = keys (one of which is the correct one) is not = sufficient.

 Given that a "jku" field holds a URI pointing = to a set of keys, we need to
 define how to use the fragment = part of those URIs to identify a specific
 key in the = set.

 Using the "kid" (key id) in the fragment would be a = sensible = choice.

--
-------------------------+---------------------------= ----------------------
 Reporter:         =       |      Owner: =  draft-ietf-jose-json-web-
  james@manger.com.au    |  key@tools.ietf.org
    =  Type:  defect       |     Status: =  new
 Priority:  major        | =  Milestone:
Component:  json-web-    |   =  Version:
  key             =        |   Keywords:
 Severity:  - =           =  |
-------------------------+-------------------------------------= ------------

Ticket URL: <jose@ietf.org
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose


= --Apple-Mail=_01F41A53-9A3B-4512-A5EC-C4B5BA8ECC0C-- From mountie@paygate.net Sun Mar 31 06:19:42 2013 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 7119A21F866E for ; Sun, 31 Mar 2013 06:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Kqu3py+jsh5n for ; Sun, 31 Mar 2013 06:19:41 -0700 (PDT) Received: from exprod7og119.obsmtp.com (exprod7og119.obsmtp.com [64.18.2.16]) by ietfa.amsl.com (Postfix) with ESMTP id 92C4921F8651 for ; Sun, 31 Mar 2013 06:19:41 -0700 (PDT) Received: from mail-qa0-f69.google.com ([209.85.216.69]) (using TLSv1) by exprod7ob119.postini.com ([64.18.6.12]) with SMTP ID DSNKUVg37IOuO7Gm/Qmqjp+Mon8s1OIzRgtK@postini.com; Sun, 31 Mar 2013 06:19:41 PDT Received: by mail-qa0-f69.google.com with SMTP id o13so2173374qaj.0 for ; Sun, 31 Mar 2013 06:19:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=kwyo6qgpBYqz8fBm2Gkqle9LrT6zFxxwrE8pFt6TGB4=; b=EmcTnGioTS5vBGEyHqgLaqaGmR6D+wBkebASSIyNQR+dpL/yxlL8ARACT9w9z+23QE ER8pgjbHGBAE4rHgFOS6B0B1iLzKw2ICBNiEhkWRRw6+vZQe/MrmZ6S38XzIGGV/N7Kj vDDXJcHMwKdy+yquTC2hPkqJl7pn0w/ybnNHqA1Zke0zfsconAaws+RttRmNyxPBhz2T PBSVmDD2dQYZUBSJuuxwnvFNL8N7q98m2WzPL0nZpEUS54+aiGNIy8qVXrEj8faSM/0E SDDiTzmH/7jE9hhe1Asyts4DbC7/d7WoIeMQOvLapwlLeiCH9A4c6NTMlGsW1ZUx0GE3 NHFw== X-Received: by 10.224.198.67 with SMTP id en3mr9999209qab.23.1364735980149; Sun, 31 Mar 2013 06:19:40 -0700 (PDT) X-Received: by 10.224.198.67 with SMTP id en3mr9999204qab.23.1364735979980; Sun, 31 Mar 2013 06:19:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.108.71 with HTTP; Sun, 31 Mar 2013 06:19:19 -0700 (PDT) From: Mountie Lee Date: Sun, 31 Mar 2013 22:19:19 +0900 Message-ID: To: jose@ietf.org Content-Type: multipart/alternative; boundary=20cf300fb1074ca82304d9385ba8 X-Gm-Message-State: ALoCoQnLDaeZn6Dqz4IRkyRKrgv750VobRp1VUpWHlnPMsds/fiBzsop0flBoDCaaEbEpHqGQSiQU+dYxffiNVn4/zgZnJgIKYXIQeR374uqhsEFOa+aelKW29sET/acGJpexMDzlBjnNWu0twKNOunODP2JvOn0aQ== Subject: [jose] JOSE and RFC4210 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, 31 Mar 2013 13:19:42 -0000 --20cf300fb1074ca82304d9385ba8 Content-Type: text/plain; charset=ISO-8859-1 Hi. I'm Mountie Lee from Korea. recently I'm trying to write draft for Web Certificate API as the part of W3C WebCrypto WG (http://www.w3.org/2012/webcrypto/) RFC4210 is the standard for Certificate Management Protocol and defines list of response data types in their process. for example RFC4210 CMP defines Certificate Reponse data structure as http://tools.ietf.org/html/rfc4210#section-5.3.4 also it defines the Revocation Response data structure as http://tools.ietf.org/html/rfc4210#section-5.3.10 my question is in JOSE Working Group is there any discussion for JOSE data format for RFC4210 data structures? if not, where can I start to discuss for these requirements? Korea and in some other countries are using RFC4210 as their base pki standard. previously and until to now, binary plugins (like ActiveX) are used to implement CMP. already huge infrastructures (legal, physical and services) are established and operated over 10 years. that is the reason why we have interest for JOSE as the data structure of RFC4210 CMP. best regards mountie. -- Mountie Lee PayGate CTO, CISSP Tel : +82 2 2140 2700 E-Mail : mountie@paygate.net ======================================= PayGate Inc. THE STANDARD FOR ONLINE PAYMENT for Korea, Japan, China, and the World --20cf300fb1074ca82304d9385ba8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi.
I'm Mountie Lee from Korea.

recently I'm trying to write draft for Web Certificate API as th= e part=A0of W3C WebCrypto WG (http://www.w3.org/2012/webcrypto/)

RFC4210 is the standard for Certificate Management Prot= ocol
and defines list of response data types in their process.

for example
RFC4210 CMP defines Certificat= e Reponse data structure as

also i= t defines the Revocation Response data structure as

my question is

in JOSE Working= Group
is there any discussion for JOSE data format for RFC4210 d= ata structures?

if not, where can I start to discu= ss for these requirements?

Korea and in some other countries are using RFC4210 as = their base pki standard.
previously and=A0until=A0to now, binary = plugins (like ActiveX) are used to implement CMP.

already huge infrastructures (legal, physical and services) are established= and operated over 10 years.

that is the reason wh= y we have interest for JOSE as the data structure of RFC4210 CMP.

best regards
mountie.
<= br>
--
Mountie Lee

PayGate
CTO, CISSP
Tel : +82 2 21= 40 2700
E-Mail : mountie@paygate.net

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
PayGate Inc.
THE STANDARD FOR ONLINE PAYMENT
for Korea, Japan, China, and the World
=0D
--20cf300fb1074ca82304d9385ba8--