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
>
>
>
> _______________________________________________
_____________________________= __________________
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:=A0
Karen 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.orgOn 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 PG1haWx0bzpib3VuY2VzQGlld